多进程端口监听 How nginx processes a request Server names

网络编程（六）：端口那些事儿 - 知乎专栏 https://zhuanlan.zhihu.com/p/20365900

不停服务reload、restart

多进程端口监听

我们都有一个计算机网络的常识：不同的进程不能使用同一端口。

如果一个端口正在被使用，无论是TIME_WAIT、CLOSE_WAIT、还是ESTABLISHED状态。这个端口都不能被复用，这里面自然也是包括不能被用来LISTEN（监听）。

但这件事也不是绝对的，之前跟大家讲进程的创建过程提到过一件事：当进程调用fork(2)系统调用的时候，会发生一系列资源的复制，其中就包括句柄。所以，在调用fork(2)之前，打开任何文件，监听端口产生的句柄也将会被复制。

通过这种方式，我们就可以达成"多进程端口监听"。

但，这又有什么用呢？

我们大名鼎鼎的Nginx就是通过这种手法让多个进程同时监听在HTTP的服务端口上的，这么做的好处就在于，当外部请求到达，Linux内核会保证多个进程只会有一个accept(2) 成功，这种情况下此端口的服务可用性就和单个进程存在与否无关。 Nginx正是利用这一点达成“不停服务reload、restart”的。

How nginx processes a request http://nginx.org/en/docs/http/request_processing.html

【

配置文件中的server_name去匹配请求头的Host字段，去路由至该Host-server_name的文件目录，本机或异机；

server_name为空字符串，去匹配请求头中缺失Host的情况；

】

How nginx processes a request

How to prevent processing requests with undefined server names
Mixed name-based and IP-based virtual servers
A simple PHP site configuration

Name-based virtual servers

nginx first decides which server should process the request. Let’s start with a simple configuration where all three virtual servers listen on port *:80:

server {
    listen      80;
    server_name example.org www.example.org;
    ...
}
 
server {
    listen      80;
    server_name example.net www.example.net;
    ...
}
 
server {
    listen      80;
    server_name example.com www.example.com;
    ...
}

In this configuration nginx tests only the request’s header field “Host” to determine which server the request should be routed to. If its value does not match any server name, or the request does not contain this header field at all, then nginx will route the request to the default server for this port. In the configuration above, the default server is the first one — which is nginx’s standard default behaviour. It can also be set explicitly which server should be default, with the default_serverparameter in the listen directive:

server {
    listen      80 default_server;
    server_name example.net www.example.net;
    ...
}

The default_server parameter has been available since version 0.8.21. In earlier versions the defaultparameter should be used instead.

Note that the default server is a property of the listen port and not of the server name. More about this later.

How to prevent processing requests with undefined server names

If requests without the “Host” header field should not be allowed, a server that just drops the requests can be defined:

server {
    listen      80;
    server_name "";
    return      444;
}

Here, the server name is set to an empty string that will match requests without the “Host” header field, and a special nginx’s non-standard code 444 is returned that closes the connection.

Since version 0.8.48, this is the default setting for the server name, so the server_name "" can be omitted. In earlier versions, the machine’s hostname was used as a default server name.

Mixed name-based and IP-based virtual servers

Let’s look at a more complex configuration where some virtual servers listen on different addresses:

server {
    listen      192.168.1.1:80;
    server_name example.org www.example.org;
    ...
}
 
server {
    listen      192.168.1.1:80;
    server_name example.net www.example.net;
    ...
}
 
server {
    listen      192.168.1.2:80;
    server_name example.com www.example.com;
    ...
}

In this configuration, nginx first tests the IP address and port of the request against the listendirectives of the server blocks. It then tests the “Host” header field of the request against theserver_name entries of the server blocks that matched the IP address and port. If the server name is not found, the request will be processed by the default server. For example, a request for www.example.com received on the 192.168.1.1:80 port will be handled by the default server of the 192.168.1.1:80 port, i.e., by the first server, since there is no www.example.com defined for this port.

As already stated, a default server is a property of the listen port, and different default servers may be defined for different ports:

server {
    listen      192.168.1.1:80;
    server_name example.org www.example.org;
    ...
}
 
server {
    listen      192.168.1.1:80 default_server;
    server_name example.net www.example.net;
    ...
}
 
server {
    listen      192.168.1.2:80 default_server;
    server_name example.com www.example.com;
    ...
}

A simple PHP site configuration

Now let’s look at how nginx chooses a location to process a request for a typical, simple PHP site:

server {
    listen      80;
    server_name example.org www.example.org;
    root        /data/www;
 
    location / {
        index   index.html index.php;
    }
 
    location ~* \.(gif|jpg|png)$ {
        expires 30d;
    }
 
    location ~ \.php$ {
        fastcgi_pass  localhost:9000;
        fastcgi_param SCRIPT_FILENAME
                      $document_root$fastcgi_script_name;
        include       fastcgi_params;
    }
}

nginx first searches for the most specific prefix location given by literal strings regardless of the listed order. In the configuration above the only prefix location is “/” and since it matches any request it will be used as a last resort. Then nginx checks locations given by regular expression in the order listed in the configuration file. The first matching expression stops the search and nginx will use this location. If no regular expression matches a request, then nginx uses the most specific prefix location found earlier.

Note that locations of all types test only a URI part of request line without arguments. This is done because arguments in the query string may be given in several ways, for example:

/index.php?user=john&page=1
/index.php?page=1&user=john

Besides, anyone may request anything in the query string:

/index.php?page=1&something+else&user=john

Now let’s look at how requests would be processed in the configuration above:

A request “/logo.gif” is matched by the prefix location “/” first and then by the regular expression “\.(gif|jpg|png)$”, therefore, it is handled by the latter location. Using the directive “root /data/www” the request is mapped to the file /data/www/logo.gif, and the file is sent to the client.
A request “/index.php” is also matched by the prefix location “/” first and then by the regular expression “\.(php)$”. Therefore, it is handled by the latter location and the request is passed to a FastCGI server listening on localhost:9000. The fastcgi_param directive sets the FastCGI parameter SCRIPT_FILENAME to “/data/www/index.php”, and the FastCGI server executes the file. The variable $document_root is equal to the value of the root directive and the variable $fastcgi_script_name is equal to the request URI, i.e. “/index.php”.
A request “/about.html” is matched by the prefix location “/” only, therefore, it is handled in this location. Using the directive “root /data/www” the request is mapped to the file /data/www/about.html, and the file is sent to the client.
Handling a request “/” is more complex. It is matched by the prefix location “/” only, therefore, it is handled by this location. Then the index directive tests for the existence of index files according to its parameters and the “root /data/www” directive. If the file /data/www/index.htmldoes not exist, and the file /data/www/index.php exists, then the directive does an internal redirect to “/index.php”, and nginx searches the locations again as if the request had been sent by a client. As we saw before, the redirected request will eventually be handled by the FastCGI server.

written by Igor Sysoev
edited by Brian Mercer