基本概念

我们在这里主要讨论connection和request两个方法。

连接方法connection

在Nginx中，connection就是对tcp连接的封装，包括连接的socket、读事件、写事件。

结合一个tcp连接的生命周期，我们看看Nginx是如何处理一个链接的。

Nginx刚启动时，解析配置文件，得到需要监听的IP地址和端口
在master进程初始化socket
fork()多个工作进程，同时工作进程会竞争accept新连接

完成这三步，客户端就可以像Nginx发起连接了。当进行TCP三次握手之后，Nginx的某一个worker进程会accept成功。然后就根据这个socket，创建Nginx对socket的封装，即ngx_connection_t结构体。

当然，Nginx也可以作为客户端来请求其他server的数据。此时，它创建的连接也会封装在ngx_connection_t结构体。
作为客户端，Nginx先获取一个ngx_connection_t结构体，然后创建socket并设置器属性，然后再添加读写事件。

Nginx的最大连接数

在Nginx中，每个进程会有一个连接数的最大上限，这个上限与系统对fd的限制不一样。

在操作系统中，我们可以通过ulimit -n来得到一个进程所能打开的最大的fd的最大数，即nofile。一般来说，每个socket连接会占用一个fd，会影响到我们程序所能支持的最大并发数。不过，这却对Nginx没有影响。

Nginx对连接数的限制与nofile没有直接关系，可以大于nofile，也可以小于。
Nginx通过设置worker_connectos来设置每个进程可使用的连接最大值。Nginx在实现的时候，是通过一个连接池来管理的。每个worker进程都有一个独立的连接池，连接池的大小是一个worker_connections大小的一个ngx_connection_t结构的数组。

而且，Nginx会通过一个链表（每个进程都有）free_connections来保存所有空闲的ngx_connection_t，每次获取一个连接时，就从空闲链表中获取一个。用完后，再放回链表里面。

所以，我们可以得出Nginx支持的最大并发数量其实是工作线程数 * 每个工作线程支持的并发数，即worker_connections * worker_processes。当然，如果作为HTTP作为反向代理，并发数应该是worker_connections * worker_processes / 2。因为作为反向代理服务器，每个并发都会建立与客户端以及后端服务的连接。

Nginx连接处理

当一个客户端连接过来，会有很多空闲的工作进程去竞争这个连接。既然有连接，那就会有不公平的情况发生。

如果某个进程得到accept的机会比较多，那么它连接池里面的空闲连接很快就会用完。如果不提前做一些控制，当accept到一个新的tcp连接后，因为没有空闲连接了且无法将连接转交给其他进程，就会导致此链接无法得到处理。

所以，Nginx会先打开accept_mutex选项。此时只有获得连接锁的进程才有资格去添加accept事件。也就是说，Nginx会控制进程是否去添加，Nginx采用ngx_accept_disabled的变量来控制是否去竞争accept_mutex锁。

ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;

这段代码中用来计算ngx_accept_disabled的值，这个值是Nginx单进程所有连接总数的1/8，然后再减去剩下的空闲连接数量。当剩余连接数小于总连接数的1/8，其值才大于0，且当前进程连接数越多，剩余连接数越小，这个值越大，越不可能获取锁。

if(ngx_accept_disabled > 0)
{
   
	ngx_accept_disabled--;
}
else
{
   
	if(ngx_trylock_accept_mutex(cycle) == NGX_ERROR)
	{
   
		return;
	}

	if(ngx_accept_mutex_held)
	{
   
		flags |= NGX_POST_EVENTS;
	}
	else
	{
   
		if(timer == NGX_TIMER_INFINITE || timer > mgx_accept_mutex_delay)
		{
   
			timer = ngx_accept_mutex_delay;
		}
	}
}

我们可以看到，当ngx_accept_disabled大于0的时候，也就是不可获取accept_mutex锁。当空闲连接越少的时候，出让的机会就越多。

请求方法request

我们这里指的是HTTP请求，具体到Nginx就是ngx_http_request_t。ngx_http_request_t是对一个HTTP请求的封装，包含请求行、请求头、请求体、响应行、响应头、响应体。

HTTP请求是典型的请求-响应类型网络协议。而http是文件协议，所以我们在分析请求行、请求头、响应行、响应头都是一行一行进程处理的。
如果我们自己写服务器，通常在一个连接建立好后，客户端会发送请求你过来，然后我们读取一行数据，分析请求行中包含的method、uri、http_version等信息去处理信息。然后再把啊响应发送给客户端。

当然，Nginx和这个有一点点的区别。比如，当请求完成后，就开始进行请求的处理。Nginx通过ngx_http_request_t来保存解析请求与输出响应相关的数据。

Nginx处理请求

对于Nginx来说，请求都是从ngx_http_init_request开始的。在这个函数中，会设置读事件为ngx_http_process_request_line。也就是，接下来的网络事件会从ngx_http_process_request_line来执行，这个函数也就是来处理请求行的。

通过ngx_http_read_request_header来读取请求数据，然后调用ngx_http_parse_request_line函数来解析请求行。
Nginx为了提高效率，采用状态机来解析请求行。整个请求行解析到的参数会保存在ngx_http_request_t结构中。

当Nginx解析到两个回车换行符的时候，就表示请求头的结束，ngx_http_process_request会设置当前的读写事件处理函数为ngx_http_request_handler，然后在调用ngx_http_handler来开始一个真正的http请求。

我们可以看到，读写事件处理函数都是ngx_http_request_handler。在这个函数中，会根据当前是读事件还是写事件分别调用ngx_http_request_t中的read_event_handler或者write_event_handler。到此刻，我们请求头就读完了。

在Nginx中，是先不读取请求body的。所以读事件处理函数会被设置成ngx_http_block_reading，即不读取数据了。

刚刚说到，数据的真正处理是在ngx_http_handler里面。这个函数会设置write_event_handler为ngx_http_core_run_phases，并执行ngx_http_core_run_phases函数。

在ngx_http_core_run_phases会执行多阶段请求处理。产生的响应头是放在ngx_http_request_t的headers_out中。这里的详细会之后再讲。

Nginx的各种阶段会对请求进行处理，最后会调用filter来过滤数据，对数据进行加工。如trunked传输、gzip压缩等。

filter模块

这里的filter包括header filter与body filter，即对响应头或响应体进行处理。

filter是一个链表结构，分别有 header filter 和 body filter，先会执行header中的所有filter，再执行body里面所有的filter。在 header filter 中最后一个filter，即ngx_http_header_filter。这个filter会遍历所有的响应头，最后需要输出的响应头是在一个连续的内存，然后调用ngx_http_write_filter进行输出。ngx_http_write_filter是body里面最后一个，所以Nginx的body信息在经过一系列的body filter之后，最后也会调用ngx_http_write_filter进行输出。

需要注意的是，Nginx会将整个请求头都放在一个buffer里面，这个buffer的大小可以通过配置项client_header_buffer_size来配置，如果用户请求头过大，这个buffer装不下，那么Nginx就会分配更大的一个buffer，这个大buffer可以通过large_client_header_buffer_size来设置。

所以，一个完整的请求行或者请求头，只会保存在一个buffer里面。

Nginx处理请求流程图

参考文献

[1] Nginx开发从入门到精通

Nginx基础概念及基本方法

目录