Apache VM documentation --------- in-depth study of VM matching

Apache VM documentation --------- in-depth study of VM matching-Linux Enterprise Application-Linux server application information. The following is a detailed description. The VM code is completely rewritten in Apache 1.3. This document attempts to explain in detail how Apache determines which VM to use for Servo after receiving the request. With the help of the new NameVirtualHost command, the configuration of the VM is simpler and safer than before version 1.3.

If you just want to make it work and do not want to understand it in depth, here are some examples.
Top
Parse configuration file

In A master server (main_server) segment contains all definitions. There are The Virtual Server defined in the configuration section is called the virtual host.

The Listen, ServerName, ServerPath, and ServerAlias commands can appear anywhere in a server-defined segment. In addition, each command overwrites the same definition (in that server configuration) that appears previously ).

The default value of the Listen command in the master server segment is 80. The master server segment does not have the default ServerPath and ServerAlias command values. The default value of ServerName is inferred from the IP address of the server.

The Listen command of the master server has two functions: one is to determine the network port to be bound to Apache, and the other is to specify the port number used by the absolute URI in the redirection.

Unlike the master server, the port of the virtual server does not affect the listening port of Apache.

Each address in the VirtualHost command can contain an optional port. Otherwise, the port is specified as the most recent Listen command on the master server by default. The special port "*" indicates that all ports are matched. All these addresses (including all A records queried by DNS) are collectively referred to as address sets of virtual hosts ).

If the NameVirtualHost command is not used for a specific IP address, the first VM using this address will be considered as an IP-based VM. The IP address can also be indicated by the wildcard.

If a domain name-based VM is used, you must use the NameVirtualHost command to specify an IP address set for the domain name-based VM. In other words, you must use the NameVirtualHost command in the configuration file to specify the IP address that includes the host name ing (CNAME.

Multiple NameVirtualHost commands can be used to correspond to one set of NameVirtualHost commands, but only one NameVirtualHost command can be used for each specific "IP: port" command.

The order in which the NameVirtualHost and VirtualHost commands appear is not important. Only the order of VirtualHost commands corresponding to the same IP address is important. Therefore, the following two examples play the same role:

NameVirtualHost 111.22.33.44

# Server
...


# Server B
...


NameVirtualHost 111.22.33.55

# Server C
...


# Server D
...




# Server


# Server C
...


# Server B
...


# Server D
...


NameVirtualHost 111.22.33.44
NameVirtualHost 111.22.33.55

(We recommend that you use the format on the left to make your configuration file more readable)

After the VirtualHost command is parsed, the VM server is assigned the port corresponding to the first name in its VirtualHost command as the default Listen port.

If all domain names direct to the same address set, the list of all domain names in the VirtualHost command will be processed in the same way as the ServerAlias command (but not overwritten by other ServerAlias statements ). Note that the Listen command of the VM cannot affect the port number of the address set.

During initialization, a list is generated for each IP address and inserted into a hash. If this IP address is used in a NameVirtualHost command, this list will contain all domain name-based virtual hosts specified as this IP address. If no VM is targeting this IP address, the NameVirtualHost command is ignored and an error message is recorded in the log. For IP-based virtual hosts, the list in this hash is empty.

Because the efficient hash algorithm is used, the overhead for finding IP addresses in requests becomes very small, or you do not need to consider it at all. This table also optimizes IP addresses with different octal bits.

Each variable of the VM has an initial value. In particular, the following:

1. If the VM does not have the ServerAdmin, ResourceConfig, AccessConfig, Timeout, KeepAliveTimeout, KeepAlive, MaxKeepAliveRequests, ReceiveBufferSize, and SendBufferSize commands, their values will be inherited from the master server. (That is, use the last set value in the master server ).
2. The default directory permission of the VM inherits the settings of the master server (including the configuration information of all modules for each directory ).
3. the VM inherits the settings of each module on the master server.

Essentially, the master server acts as a default value or a root role when creating each virtual host. However, the locations defined in the master server are irrelevant-the configuration of the master server has been resolved before integration with the virtual host. Therefore, even if the configuration of a master server appears after the virtual host definition, it also affects the configuration of the virtual host.

If ServerName is not defined in the master server, it will be replaced by the Host Name of the machine running the httpd service. The DNS will query the IP address returned by this ServerName as the master server address set (main_server address set ).

If ServerName is not defined, a domain name-based virtual host uses the first address in the VirtualHost command when defining the virtual host by default.

All virtual hosts that use the "_ default _" wildcard will be assigned the same ServerName as the master server.
Top
VM matching

The server uses the following methods to determine which VM to use for a specific request:
Hash Query

When the client is connected for the first time, it searches for the IP address that the client wants to connect to from the internal IP address list.

If the search fails (the corresponding IP address is not found) and the requested port has another "_ default _" Vm, the request will be servo by the VM. If the "_ default _" virtual host is not found, the request will be servo by the master server.

If no IP address is found in the hash, but a "NameVirtualHost *" command matches the requested port number, the VM will be used to process the request.

If the search succeeds (the list corresponding to this IP address is found), the next step is to check whether an IP-based virtual host or a domain-based virtual host is to be processed.
IP-based VM

If the domain name list in the returned list is empty, we are processing an IP-based virtual host, which will be processed directly without any other steps.
Domain name-based VM

If the returned Domain Name List contains the structure of one or more virtual hosts, We are processing a domain name-based virtual host. The order of the virtual hosts in this list is the same as that of the corresponding VirtualHost commands in the configuration file.

The first VM in this list (that is, the first Vm with this IP address specified in the configuration file) has the highest priority for processing requests. All requests with Unknown Server names or without the "Host:" header will be processed by the server.

If the client provides a "Host:" header in the request, the first ServerName or ServerAlias virtual Host that matches it will be searched in the list and applied to the servo request. Although the "Host:" header can contain a port number, Apache uses the real port that received the request for matching.

If the client submits an HTTP/1.0 request that does not contain the "Host:" header, we cannot confirm that the client wants to connect to the server. If a ServerPath corresponds to the URI in the request submitted by the client, the first qualified VM in the list will be used to servo the request.

If the corresponding virtual host still cannot be found, the request will be servo by the first VM in the list corresponding to the IP address connected to the client, which is the same as the requested port (as described above ).
Persistent connection

The preceding IP address lookup only executes a specific TCP/IP process once. However, in KeepAlive, every request performs such a search process. In other words, a client can send a request to a page of a different domain name-based VM in a persistent connection.
Absolute URI

If the requested URI is an absolute URI, and the host name and port number are consistent with the master server or a virtual host, the request type, host name, and port prefix will also be erased, only the relative URI is left as the servo of the corresponding master server or virtual host. If the above conditions are not met, the URI will be retained as is, and the request will be processed as a proxy request.
Memorandum

* Domain name-based virtual hosts and IP-based virtual hosts do not interfere with each other. An IP-based VM only accepts requests sent to its own address set, rather than other IP addresses. Domain name-based virtual hosts are the same. They only accept access to the address set defined by the NameVirtualHost command.
* Server alias and ServerPath checks will never be performed on an IP-based virtual host.
* In the configuration file, the order in which domain name-based virtual hosts, IP-based virtual hosts, "_ default _" virtual hosts, and NameVirtualHost commands appear is not important. For a specified address set, the domain name-based VM sequence cannot be confused: the VM that appears first in the configuration file has a higher priority in the corresponding address set.
* For security reasons, the port numbers displayed in the "Host:" header are not used for matching. Apache always uses the real Port connected by the client as a match.
* If a ServerPath command happens to be the prefix of another ServerPath command, the former will be used for matching, and the latter will be ignored. (The "Host:" header is not used to separate the two cases)
* If two IP-based virtual hosts use the same address, the one that appears first in the configuration file is used for matching. This may happen when you are negligent. When the server encounters this situation, an error message is written into the log file.
* The "_ default _" VM captures the request only when no other VM meets the IP address and port number requested by the client. The request is captured only when the "_ default _" virtual host port number (specified by your Listen by default) matches the destination port number of the request sent by the client. You can also use wildcards (for example, "_ default _: *") to capture requests of any port number. This also applies to "NameVirtualHost *" virtual hosts.
* Only when the destination IP address and port number of the client connection are not specified and do not match any virtual host (including "_ default _" virtual host, the master server is used for Servo requests. In other words, the master server only captures requests without a specified IP address or port (unless there is a "_ default _" VM matching the port ).
* If the client connects to an address (and port) used by a virtual Host for domain name-based use, for example, the NameVirtualHost command is used, then an unknown or "Host: the "header request will not match the" _ default _ "Vm or master server.
* You cannot use the DNS name in the VirtualHost command. Otherwise, your server will depend on DNS for startup. In addition, if you cannot control all the domains in the list, you will face security threats. You can obtain more details about the problem and the following two questions here.
* ServerName should be set for each virtual host. Otherwise, you need to perform DNS queries for each virtual host.

Top
Tips

As an extension of the DNS problem page tips, here are some additional tips:

* Put the definitions of all master servers before all VirtualHost definitions (to improve readability). Otherwise, problems such as definitions next to virtual hosts will not be easily discovered.
* Put the corresponding NameVirtualHost and VirtualHost definitions in your configuration together for better readability.
* Avoid that the previous ServerPaths is the prefix of the last ServerPaths. If you cannot avoid this situation, you 'd better make sure that in your configuration file "long before, short after" (that is: "ServerPath/abc/def" should appear before "ServerPath/abc ).