A more complex configuration of the Sun Java System Web Server is one in which the server hosts a few virtual servers for an intranet deployment. For example, you have three internal sites where employees can look up other users’ phone numbers, look at maps of the campus, and track the status of their requests to the Information Services department. Previously (in this example), these sites were hosted on three different computers that had the names phone.example.com, maps.example.com and is.example.com mapped to them.
To minimize hardware and administrative overhead, you want to consolidate all three sites into one web server living on the machine example.com. You could set this up in two ways: using URL-host-based virtual servers or using separate listen sockets. Both have their distinct advantages and disadvantages.
While URL-host-based virtual servers are easy to set up, they have the following disadvantages:
Supporting SSL in this configuration requires non-standard setup using wildcard certificates. For more information see Chapter 5, J2SE-based Security for Web Container and Web Applications.
URL-host-based virtual servers don’t work with legacy HTTP clients
You could also set up the IP-address-based configuration with one listen socket per address:
The advantages to IP-address-based virtual servers are:
They work with older clients that do not support the HTTP/1.1 Host header.
Providing SSL support is straightforward.
The disadvantages are:
They require configuration changes on the host computer (configuration of real or virtual network interfaces)
They don’t scale to configurations with thousands of virtual servers
Both configurations require setting up name-to-address mappings for the three names. In the IP-address-based configuration, each name maps to a different address. The host machine must be set up to receive connections on all these addresses. In the URL-host-based configuration, all names can map to the same address, the one the machine had originally.
The configuration with multiple listen sockets could give you a minimal performance gain because the server does not have to find out the address the request came in on. However, using multiple listen sockets also results in additional overhead (memory and scheduling) because of the additional acceptor threads.