Streaming Media Supplement sa2150 and sa2250

10
Chapter 2 Media-IXT Deployment Scenarios
Sometimes a web client does not include origin server hostname information in its request, and you must be
aware of this if you are using a layer 4 switch in proxy mode. Suppose, for example, that:
• your layer 4 switch, in proxy mode, answers to the advertised name of your website
• the switch rewrites the destination IP address of client request packets, so that their destination IP address
is that of your Media-IXT
• your Media-IXT is providing reverse proxy for an origin server
In this situation, Media-IXT receives packets whose destination IP address is its own. If the origin server
hostname information is included too, Media-IXT performs a DNS lookup on that hostname to learn the IP
address of the origin server. If no origin server hostname information reaches it, Media-IXT’s reverse proxy
configuration files must make the correlation between the origin server’s IP address and Media-IXT’s IP
address, so that Media-IXT can find the origin server.
By contrast, in a deployment without a layer 4 switch in proxy mode, Media-IXT answers to the advertised
name of the website, and client requests reach Media-IXT with the destination IP address to which the
advertised website name resolves. Then Media-IXT’s reverse proxy configuration files make a correlation
between the IP address to which the advertised website name resolves, and the IP address of the origin server.
In either case, Media-IXT’s reverse proxy configuration files must be crafted so that Media-IXT can find the
origin server for which it is performing reverse proxy.
RTSP requests do include the host information, but PNA requests do not. MMS requests from Windows Media
Player 7 do include the host information, but requests from Windows Media Player 6 do not. HTTP requests
usually include the host information, in what is called the host header.
These are issues that the network architect must take into account. Using proxy mode with a layer 4 switch is
not always the best choice. On the other hand, it may offer some administrative or other advantages. Network
design is always a matter of tradeoffs.
Beyond simple forward proxy, reverse proxy, and transparency
This section describes several deployment scenarios which go beyond the simplest ways to implement forward
proxy, reverse proxy, and transparency.
Less usual reverse proxy scenarios
Not all reverse proxy deployments involve Virtual IP Addressing. You can, without using Virtual IP Addresses,
configure DNS so that the advertised name of your site resolves to the IP address of Media-IXT. Some large
and sophisticated networks control network traffic with redirectors, which are neither routers nor switches, and
may involve proprietary hardware.
In the most common reverse proxy deployment, one Media-IXT host (or cluster) performs reverse proxy
caching for one origin server (or group of origin servers). Some less usual, more complex deployments make
use of geographically distributed proxy caches. Here are two examples of such deployments:
• If you do not own the network (that is, the Internet routers) that your traffic uses, it makes sense to use this
technique:
o Configure DNS to resolve your website’s advertised name to different IP addresses depending on the
geographical location of the client. A different proxy cache answers to each IP address.
• If, on the other hand, you do own the network, you can use an approach known as advertised route control:
o Configure DNS to resolve your website’s advertised name to a single VIP (virtual IP address), and put
rules in your gateway routers to route traffic for that VIP to different proxy caches in different
geographical areas.