Caching Dynamic Data
As with a forward proxy, we can cache content from the individual Web servers, enabling the reverse proxy to appear as a single machine. Because the information is cached, it can be returned significantly quicker than from a typical static or dynamic solution. In a Web server design where individual pages are generated from a large number of dynamic components this can be a significant benefit.
Consider a typical page, made up of 10 different dynamic elements. If 100 clients attempt to access those dynamic elements simultaneously, then 1,000 requests must be loaded. For some sites, these ‘dynamic’ elements are nothing more than data extracted from a database. The actual basis page data doesn’t change much, but when used with a dynamic site, we must still process that same database request each time the page is accessed.
If a reverse proxy is placed between the clients and the Web servers, we can cache the basic content, reducing the load on the database that provides the information and on the server that must execute the application to load that data and convert it into a page.
The reverse proxy could cache the entire content of the dynamic elements in memory, or on disk, and return them to clients much quicker than the dynamic process. You could also set the cache to be updated (through the cache expiry system) to provide the latest versions of stories and data for the site.
Because all requests give the appearance of coming in through a single server, not to one of the many back-end servers that actually support the site, reverse proxying enables us to provide a single point of authentication. Users log in to the proxy server — as the gateway to the Web site — and need never log in again, even though they may be accessing other machines to obtain information. This can be done with either Apache’s own authentication systems (using a cookie or database-based authentication) or SSL-based communication. Using a reverse proxy, you need manage only one certificate on one machine.
The same basic principles also apply when restricting access. If you were supporting an intranet and wanted to support connectivity from specific hosts, domains, or through a VPN connection, then you could open up the connectivity through a reverse proxy without having to open up the main servers.
If you have a firewall, then you can use the proxy server on the public side, or within your DMZ using secured (VPN) or restricted communication links between the reverse proxy and the real servers behind the firewall, as shown in Figure 2.