I've been working on networks for decades and for as long as I can remember, network proxies have existed. I first came across the idea when I worked for IBM as an SNA programmer back in the late 90s but it's in more recent years that network proxies have taken on more importance.
The world of WAN optimisation is a highly interesting and potentially complex one and it is in this bailiwick that network proxies have become essential tools. Companies like F5, Allot and Ipanema, all of whose WAN optimisation equipment I have become extremely familiar with over the past decade or so will frequently trumpet that the benefits acquired by using their application delivery controllers are only enjoyed because their equipment is a full proxy. Over the years I've heard of full, reverse, half and forward proxies but as is often the case with notions with which we believe we have become familiar, dig a little deeper and we find that our perceived understanding is not so ironclad. So, setting out to put things right, I sought out the truth.
Proxies are typically called intermediaries by Service Oriented Architecture folk and can be either physical or virtual devices but in all instances are interposed between server and client modifying requests and responses to those requests. Back in my IBM days, the purpose of the proxy was to manage Web access and effectively corral all of the outbound activity on the WWW from our facility into one device through which policies relating to security and content could be applied. All of our web requests were made to the proxy and it was the proxy which would connect to external resources keeping a clean separation between our client devices and the potentially hazardous wild west web outside. Turns out however that this type of proxy is just one of the various types that exist.
Forward proxies are the best-understood types of proxy and are by far the most common. The IBM proxy I described above was an example of a forward proxy placed as it was between a private network and the public net. If you are old enough to have had a Compuserve account you may well remember the messages you would see on your screen regarding content not being available or suitable for display. These proxies were known as "mega-proxies" because of the volume of data they would handle and deserved the title.
The application of proxies to web content delivery facilitating content filtering and caching as well as exercising some type of authentication in order to apply relevant policies to user traffic is the bread and butter of the forward proxy. Companies such as Cloudflare operate these types of proxy that occasionally serve up messages such as "Your request has been denied by ......" but Cloudflare is also well known for using proxies in reverse mode. Let's take a look at those.
The term reverse proxy has actually drifted out of use in favour of such highfalutin names as load balancers (f5), application controllers (Ipanema) and net enforcer (Allot). These devices though are in some sense reverse proxies, interposed as they are in front of web and other application servers and by inspecting traffic up to and including layer 7, they can apply policies to the traffic passing through them to either restrict or facilitate flows as necessary. In this sense, the term reverse is only to represent the fact that the devices are proxying inbound as opposed to outbound requests.
A reverse or forward proxy can be (or not be) a half proxy. It's all to do with the way that they handle the dimensions in a network traffic data interchange. The term actually describes two different situations. Let's look at each in turn.
The first type of half proxy is also known as half-proxy DSR. DSR stands for direct server return. Inbound requests are handled by the proxy but return traffic is sent directly to the requesting client (or server). This is particularly appropriate when the traffic is a streamed type such as streaming audio or video.
The second type of half proxy describes a situation where the proxy acts as a gatekeeper to the network enacting arbitration of newly established sessions by policy. Once the policy decisions have been applied the proxy then steps back and allows the connection to continue directly.
Half proxies are almost always reverse proxies.
A full proxy is so named because it establishes and maintains two distinct connections as part of its role as interlocutor. In this configuration, a full proxy is both an endpoint and an originator for the traffic under proxy hence the name of full-proxy - incoming and outgoing.
As the full proxy is a bonafide endpoint in the chain, it must fully implement the protocol stacks involved. it, therefore, has the capability to superimpose its own connection behaviours such as retransmission, windowing and TCP options. Full proxies are therefore the most versatile and capable option and it is for this reason that manufacturers such as f5 networks go to great pains to emphasise the full proxy nature of their products. As full proxies, these devices are able to apply a full suite of policy activity to clients and servers independently and differently.
And so now, equipped with an understanding of the facts about proxies, I, and now you dear reader can go forward with confidence into the complex world of application-aware networking. If you've enjoyed reading this post please do say so in the comments. If you have questions, let me know. If you just feel like saying hi, go for it. Check back soon for more helpful nuggets.