Proxies (often called intermediaries in the SOA world) are hardware or software solutions that sit between the client and the server and do something to requests and sometimes responses. The most often heard use of the term proxy is in conjunction with making Web surfing anonymous. That’s because proxies sit between your browser and your desired destination and proxy the connection; that is you talk to the proxy while the proxy talks to the web server and neither you nor the webserver know about each other.
Proxies are not all the same. Some are half proxies, some are full proxies; some are forward and some are the reverse. Yes, that came excruciatingly close to sounding like a Dr. Seuss book.
Forward proxies are probably the most well-known of all proxies, primarily because most folks have dealt with them either directly or indirectly. Forward proxies are those proxies that sit between two networks, usually a private internal network and the public Internet. Large service providers have also traditionally employed forward proxies as a bridge between their isolated network of subscribers and the public Internet, such as CompuServe and AOL in days gone by. These are often referred to as “mega-proxies” because they managed such high volumes of traffic.
Forward proxies are generally HTTP (Web) proxies that provide many services but primarily focus on web content filtering and caching services. These forward proxies often include authentication and authorization as a part of their product to provide more control over access to public content. If you’ve ever gotten a web page that says “Your request has been denied by blah blah. If you think this is an error please contact the help desk/your administrator” then you’ve probably used a forward proxy.
A reverse proxy is less well known, generally because we don’t use the term anymore to describe products used as such. Load balancers (application delivery controllers) and caches are good examples of reverse proxies. Reverse proxies sit in front of web and application servers and process requests for applications and content coming in from the public Internet to the internal, private network. This is the primary reason for the name “reverse” proxy to differentiate it from a proxy that handles outbound requests.
Reverse proxies are also generally focused on HTTP but in recent years have expanded to include many other protocols commonly used on the web such as streaming audio (RTSP), file transfers (FTP), and generally any application protocol capable of being delivered via UDP or TCP.
Half-proxy is a description of how a proxy, reverse or forward, handles connections. There are two uses of the term half-proxy: one describing a deployment configuration that affects the way connections are handled and one that describes simply the difference between a first and subsequent connections.
The deployment-focused definition of half-proxy is associated with a direct server return (DSR) configuration.
Requests are proxied by the device, but the responses do not return through the device, but rather are sent directly to the client. For some types of data, particularly streaming protocols, this configuration results in improved performance. This configuration is known as a half-proxy because only half the connection (incoming) is proxied while for the other half, the response, is not.
The second use of the term “half-proxy” describes a solution in which the proxy performs what is known as delayed binding to provide additional functionality. This allows the proxy to examine the request before determining where to send it. Once the proxy determines where to route the request, the connection between the client and the server are “stitched” together. This is referred to as a half-proxy because the initial TCP handshaking and first requests are proxied by the solution but subsequently forwarded without an interception.
Half proxies can look at incoming requests to determine where the connection should be sent and can even use techniques to perform layer 7 inspection, but they are rarely capable of examining the responses. Almost all half-proxies fall into the category of reverse proxies
Full proxy is also a description of how a proxy, reverse or forward, handles connections. A full proxy maintains two separate connections – one between itself and the client and one between itself and the destination server. A full proxy completely understands the protocols and is itself an endpoint and an originator for the protocols. Full proxies are named because they completely proxy connections – incoming and outgoing.
Because the full proxy is an actual protocol endpoint, it must implement the protocols as both a client and a server. This also means the full proxy can have its TCP connection behavior, such as buffering, retransmits, and TCP options. With a full proxy, each connection is unique; each can have its TCP connection behavior. This means that a client connecting to the full proxy device would likely have different connection behavior than the full proxy might use for communicating with servers. Full proxies can look at incoming requests and outbound responses and can manipulate both if the solution allows it.
Many reverse and forward proxies use a full proxy model today. There is no guarantee that a given solution is a full proxy, so you should always ask your solution provider if it is important to you that the solution is a full proxy.