You have two ways to implement virtual hosting:
IP-based virtual hosting: Based on machines with multiple distinct IP addresses, every domain is allocated one IP address. The Web server listens to each of these network interfaces and serves resources from the relevant domain based on the IP address on which the request had arrived.
Name-based virtual hosting: The Web server listens on a single IP addresses and serves resources from the relevant Web site, based on the HTTP request headers from the Web client.
In this form of virtual hosting, the machine is configured to have the same number of IP addresses as the hosts it’s to serve. So a machine hosting ten Web sites needs ten IP addresses. You configure these additional IP addresses either by adding physical network interfaces to the machine or, as is more common, by adding aliased network interfaces to the computer.
Normally when you add a network interface card (NIC) to your machine, you configure it with a single IP address, which you then use in various services. However, it’s possible to configure the same NIC with more than one IP address. Adding these additional IP addresses involves using operating system–specific commands for creating a virtual interface and then configuring it with a virtual IP address. This process normally involves using a physical NIC and adding virtual interfaces on top, a process known as aliasing.
Windows versions from Windows NT onward support aliasing and therefore IP-based virtual hosting. Each flavor of Windows has slightly different ways to configure this, but they’re similar enough that you’ll be able to transfer the example shown here to your version.
This example uses Windows 2000 Professional. Open Control Panel Network and Dial-up Connections, and double-click the network interface you want to configure. For example, this may be your local area network connection. You’ll see a properties dialog box similar to that in Figure 13-1.
Figure 13-1: The network properties dialog box
Select the TCP/IP component as shown, and click Properties. The TCP/IP properties box allows you to specify a main IP address and DNS servers for this network interface. If there’s no IP address, enter a value that’s appropriate for your network, as shown in Figure 13-2. The default subnet mask should be sufficient.
Figure 13-2: The TCP/IP properties dialog box
To add further IP addresses, click Advanced. You’ll see that the IP address you just entered listed in the top pane of the resultant dialog box. To add further IP addresses, click Add and enter another value. You’ll see the new IP address that has been added to the list, as in Figure 13-3. This computer will now listen on 192.168.0.1 and 192.168.0.2.
Figure 13-3: The Advanced TCP/IP Settings dialog box
To set network interface options on Unix-like systems, you use the ifconfig utility. On most systems, to check which network interfaces are installed, run ifconfig with the -a switch.
# ifconfig -a
If this doesn’t work, try netstat -i.
Once you know which network interfaces are installed, you can view the details of a specific interface with the following:
# ifconfig interface_name
To set the IP address of a network interface, specify the interface’s name, followed by the IP address, options such as the netmask, and the up parameter. So, to set the IP address of eth0 to 192.168.0.1, run the following:
# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
eth0 will now be listening on the new IP address. To turn the network interface off, use the down parameter:
# ifconfig eth0 down
To add an additional IP address to a network interface to implement aliasing, run the following:
# ifconfig eth0:1 192.168.0.2
eth0 will now listen on 192.168.0.1 and 192.168.0.2.
While IP-based virtual hosts help maximize resources, they’re still not feasible in places where hundreds of domains need to be hosted on the same machine. In such cases, either obtaining one IP address for each host or configuring many network interfaces on the same machine becomes a logistical nightmare. In these cases, you can use name-based virtual hosting.
An HTTP 1.1 request contains the Host: header, which specifies the host on which the requested resource resides. When such a request is sent to a server, the server can read the Host: header and determine which of its hosts the client would like to reach. The server then processes the request accordingly and sends back the response. This system requires the client to first look up a list of IP address/hostname mappings, which is usually configured in a DNS server. Figure 13-4 shows this process.
Figure 13-4: Name-based virtual hosting
You can see how this makes more efficient use of the available resources. If you were limited to one host for one IP address, the Internet would soon run out of space.
Name-based virtual hosting does have some problems.
SSL connections aren’t on HTTP, so the Host: header can’t be extracted in advance. Therefore, it isn’t possible to have multiple SSL servers running on the same IP address. For this reason, each SSL-enabled Web site needs to be configured on a unique IP address.
Older Web clients and many Web access software libraries still use the old HTTP 1.0 protocol. Since they don’t send the Host: header to the Web server, name-based virtual hosting wouldn’t work properly with them. However, these clients are pretty rare, so this isn’t as big a consideration as it used to be.