A proxy server takes outbound traffic and makes it appear as if it comes from a single IP address. This type of proxy is useful if you have a single access point to the Internet and want multiple computers behind that access point to be able to access the Internet. This is common in an office or corporate environment.
A reverse proxy takes incoming traffic and sends it to multiple backend computers. This is useful if you run a large website and want a single IP address to actually be served by multiple machines. You can also accomplish this with a load balancer, but load balancers typically lack several key features that a reverse proxy can provide.
Let's take a look at 4 reverse proxies that are currently available:
1. Apache's httpd
2. Squid
3. Perlbal
4. Pound
5. HAProxy
All of these are very good, but depending on your requirements some may not meet your needs. I'm interested in a reverse proxy that can handle the following requirements:
1. Easy to configure
2. Small memory footprint
3. Provides load balancing
4. Supports SSL to client, but non-ssl to the backend
5. Provides High Availability
6. Can proxy traffic based on URL pattern matching
7. Supports virtual hosts
Perlbal is really a terrific piece of software, but it has a lot of features that I don't need, plus it does not have one key feature that I do need, SSL. Although there is an option to configure Perlbal with SSL, don't do it. It's too easy to break because of this problem reported on their listserve. It appears this is not a problem with the Perlbal code, but a problem with the underlying libraries that Perlbal uses. I could stick stunnel in front of Perlbal and I think that would work great, but you have to setup one instance of stunnel per SSL site and that wouldn't work for me. Perlbal uses epoll, which would provide a big performance boost. Perbal doesn't support sticking users to backends (for session support), but that is not a requirement for me.
Squid has been around for a long time, but I think it's too bulky. First, the configuration is too hard. Second, it's primary goal is to serve as a proxy, but I do not need this, just the reverse proxy. Squid also does a lot of caching, I don't need this either, I would prefer to have something that never touches disk. Also, to my knowledge, Squid does not support high availability (checks to make sure a backend is not down).
Apache's latest release (2.2) of it's httpd server does have better support for load balancing and high availability than previous versions, but it's still too bulky for me. One thing that kills me about Apache is how hard it is to configure mod_rewrite. I actually was able to setup Apache 2.2 as a reverse proxy and it was working perfectly, but I realized that this was going to be too hard to maintain on a large scale system. It's great that Apache is so configurable and can handle just about any task, but that can also be looked at as a big negative too.
Bill showed me HAProxy and it looks great, very configurable. But it requires Apache for SSL support, and I don't think you can proxy traffic based on URL.
The final piece of software that I looked at as a possible reverse proxy that would meet all of my requirements was Pound. I had a little trouble compiling Pound at first on RHES3, but I finally figured out the right compiler flags. On RHES4 it compiled with no problems. Besides that Pound seems to work great. It's easily configurable, is designed to accomplish only one task, and is small in size.
So there you have it, my evaluation of reverse proxy software. If I missed anything or I am just dead wrong, feel free to leave a comment. I'll update this post if anything is inaccurate.
