next up previous
Next: Problems Up: Motivation Previous: Motivation

Reverse Proxy Caching

 As commercial interest in the Internet grows, more and more ISPs offer Web hosting services. They host and provide access to objects belonging to third-party information providers. Figure 1 shows a typical architecture of such service. The backbone exchanges traffic with the outside Internet only via backbone nodes that contain border routers, also known as Internet Gateway Routers (IGRs). For performance reasons, Web proxies are located at the nodes with IGRs.

When clients ask for the IP address of a web site hosted by the ISP, instead of returning the IP address of the server, the ISP's DNS server returns the IP address of a proxy. Thus, client requests are transparently delivered to proxies, which return requested objects either from their caches or after fetching the objects from the content server(s). Since these proxies are conceptually close to and under the same administrative control as the content servers, they are often called reverse proxies.

For the compactness of presentation we will equate an IGR with its co-located proxy in this paper, with the understanding that in reality these are two separate devices on the same LAN.


  
Figure 1: Reverse Proxy Caching
\begin{figure}
\centerline{
\psfig {figure=reverse_proxy.eps,height=2.5in, width=3.2in}
}\end{figure}

Reverse proxies can be cooperative: when the proxy processing a request does not not have the requested object but other proxies have valid copies, the first proxy can get the object from others, service the request, and cache the object. Similar to other cooperative caching, there are a number of ways for reverse proxies to track the location of cached objects:


next up previous
Next: Problems Up: Motivation Previous: Motivation
Limin Wang
2/20/2000