IP-Friendly Services


Specifically with regard to the topic of web serving, it is impossible for two machines to share a single IP address on the same Ethernet segment because the address resolution protocol (ARP) poses a fundamental obstacle. As such, without a load-balancing device that provides virtual IP services, the rule is at least one distinct IP address per machine.

What does this mean? Well, a lot actually. DNS allows the exposure of multiple IP addresses for a single hostname. Multiple IP addresses are being used to provide the same service. It should be noted that nothing in the DNS specification guarantees an even distribution of traffic over the exposed IP addresses (or a distribution at all). However, in practice, a distribution is realized. Although the distribution is uniform over a large time quantum, the methodology is naive and has no underlying intelligence. Given its shortcomings, you will see its usefulness in specific environments in Chapter 6, "Static Content Serving for Speed and Glory."

For example, dig www.yahoo.com yields something like the following:

;; ANSWER SECTION: www.yahoo.com.          1738    IN      CNAME   www.yahoo.akadns.net. www.yahoo.akadns.net.   30      IN      A       216.109.118.70 www.yahoo.akadns.net.   30      IN      A       216.109.118.67 www.yahoo.akadns.net.   30      IN      A       216.109.118.64 www.yahoo.akadns.net.   30      IN      A       216.109.118.77 www.yahoo.akadns.net.   30      IN      A       216.109.118.69 www.yahoo.akadns.net.   30      IN      A       216.109.118.74 www.yahoo.akadns.net.   30      IN      A       216.109.118.73 www.yahoo.akadns.net.   30      IN      A       216.109.118.68 


This means that you could visit any of the preceding IP addresses to access the Yahoo! World Wide Web service. However, consider secure hypertext transport protocol (HTTPS), commonly referred to as SSL (even though SSL applies to much more than just the Web).

The HTTP protocol allows for arbitrary headers to be added to any request. One common header is the Host: header used to specify which web real estate you want to query. This technique, called name-based virtual hosting, allows several web real estates to be serviced from the same IP address.

However, when using SSL, the client and server participate in a strong cryptographic handshake that allows the client to verify and trust that the server is who it claims to be. Unfortunately, this handshake is required to occur before HTTP requests are made, and as such no Host: header has been transmitted. This shortcoming of HTTP over SSL inhibits the use of name-based virtual hosting on secure sites. Although the question whether this is good or bad can be argued from both sides, the fact remains that servicing multiple secure websites from the same IP address is not feasible.

If you expose a single IP address for each web service, you need one IP address for each secure web real estate in service. But if multiple (N) IP addresses are used for each web service, you need N IP addresses for each secure web real estate. This can be wasteful if you manage thousands of secure websites.

There are two workarounds for this. The first is to run SSL on a different port than the default 443. This is a bad approach because many corporate firewalls only allow SSL connections over port 443, which can lead to widespread accessibility issues that are not easily rectified.

The second approach is to use a delegate namespace for all secure transactions. Suppose that we host www.example1.com through www.example1000.com, but do not want to allocate 1,000 (or N times 1,000) IP addresses for SSL services. This can be accomplished by using secure.example.com as the base site name for all secure transactions that happen over the hosted domains. This approach may or may not be applicable in your environment. Typically, if this is not a valid approach, it is due to the business issue of trust.

If you visit a site www.example1000.com and are transferred to secure.example.com for secure transactions, users will be aware that they were just tossed from one domain to another. Although it may not be so obvious with those domain names, consider a hosting company named acmehosting.com and a client named waldoswidgets.com. To preserve IP space, ACME hosting chooses to put all client SSL transactions through a single host named secure.acmehosting.com. However, the end customer who is expecting to purchase something from Waldo's Widgets is oblivious to the fact that Waldo chose ACME as a hosting company.

The end-user placed enough trust in waldoswidgets.com to conduct a secure transaction, but suddenly that user is placed on secure.acmehosting.com to conduct this transaction. Although the user can be put at ease by having seamless creative continuity between the two sites (both sites look the same), the URL in the browser has still changed, and that hand-off has diminished trust.

Although there is no real way to fix IP consumption issues with running a tremendous number of SSL sites, it can certainly be alleviated by running each secure site on at most one IP address. This approach brings up a scalability issuewhich is why this discussion belongs in this chapter.

If you expose only a single IP address for a service, that IP must be capable of servicing all requests directed there. If it is a large site and the workload exceeds the capacity of a single web server, we have a problem that can only be solved by load balancing.




Scalable Internet Architectures
Scalable Internet Architectures
ISBN: 067232699X
EAN: 2147483647
Year: 2006
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net