In case anyone was wondering, like me, what a reverse proxy is, or why implementing one would achieve dramatic performance improvements, here's a Definition of reverse proxy:
"Reverse Proxies
A reverse proxy is a gateway for servers, and enables one web server to provide content from another transparently. As with a standard proxy, a reverse proxy may serve to improve performance of the web by caching; this is a simple way to mirror a website. But the most common reason to run a reverse proxy is to enable controlled access from the Web at large to servers behind a firewall."
| [reply] |
I've used reverse proxies for:
- Firewalls. Instead of just letting any packet on port 80 through, use a reverse proxy. This means that no TCP/IP packet passes through the firewall. Data of course will, but only if it's valid HTTP.
- URL rewriting. Shielding your internal layout from the outside world.
- SSL accellerator. Doing your encryption/decryption at a dedicated reverse proxy means it cannot only be done by a service that's optimally configured for this task, but it also means that on the inside, your architecture can be simpler.
- Access control. Is user X allowed to access URL Y. Doing this at a reverse proxy means you can have global rules - and not every project on the inside needs to worry about this type of access control.
- Caching.
- Load balancing/High availability.
Scary thing is, I've once worked on a project where they used all of the points mentioned above. With different departments controlling different reverse proxies. Which made debugging fun, fun, fun!
| [reply] |