nginx http模块 http过滤模块

request

　　

连接池

 　　在linux系统中，每一个进程能够打开的文件描述符fd是有限的，而每创建一个socket就会占用一个fd，这样创建的socket就会有限的。在Nginx中，采用连接池的方法，可以避免这个问题。

 　　Nginx在实现时，是通过一个连接池来管理的，每个worker进程都有一个独立的连接池，连接池的大小是worker_connections。这里的连接池里面保存的其实不是真实的连接，它只是一个worker_connections大小的一个ngx_connection_t结构的数组。并且，nginx会通过一个链表free_connections来保存所有的空闲ngx_connection_t，每次获取一个连接时，就从空闲连接链表中获取一个，用完后，再放回空闲连接链表里面（这样就节省了创建与销毁connection结构的开销）。

　　所以对于一个Nginx服务器来说,它所能创建的连接数也就是socket连接数目可以达到worker_processes（worker数）*worker_connections。

竞争问题

　　对于多个worker进程同时accpet时产生的竞争，有可能导致某一worker进程accept了大量的连接，而其他worker进程却没有几个连接，这样就导致了负载不均衡，对于负载重的worker进程中的连接响应时间必然会增大。很显然，这是不公平的，有的进程有空余连接，却没有处理机会，有的进程因为没有空余连接，却人为地丢弃连接。

　　nginx中存在accept_mutex选项，只有获得了accept_mutex的进程才会去添加accept事件，也就是说，nginx会控制进程是否添加accept事件。nginx使用一个叫ngx_accept_disabled的变量来控制进程是否去竞争accept_mutex锁。

ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;  //可以看出来随着空余连接的增加，disabled的值降低

 if (ngx_use_accept_mutex) {
        if (ngx_accept_disabled > 0) {　　　　　　　　　　　//当disabled的值大于0时，禁止竞争，但每次-1
            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 > ngx_accept_mutex_delay) {
                    timer = ngx_accept_mutex_delay;
                }
            }
        }
}

在nginx中，request是http请求，具体到nginx中的数据结构是ngx_http_request_t。ngx_http_request_t是对一个http请求的封装。 

HTTP

 　　这里需要复习下Http协议了。

　　http请求是典型的请求-响应类型的的网络协议，需要一行一行的分析请求行与请求头，以及输出响应行与响应头。

　　Request 消息分为3部分，第一部分叫请求行requset line， 第二部分叫http header, 第三部分是body. header和body之间有个空行。

　　Response消息的结构， 和Request消息的结构基本一样。 同样也分为三部分，第一部分叫response line, 第二部分叫response header，第三部分是body. header和body之间也有个空行。

　　分别为Request和Response消息结构图：

处理流程

　　worker进程负责业务处理。在worker进程中有一个函数ngx_worker_process_cycle()，执行无限循环，不断处理收到的来自客户端的请求，并进行处理，直到整个nginx服务被停止。

　　一个HTTP Request的处理过程:　

1. 初始化HTTP Request（读取来自客户端的数据，生成HTTP Requst对象，该对象含有该请求所有的信息）。
2. 处理请求头。
3. 处理请求体。
4. 如果有的话，调用与此请求（URL或者Location）关联的handler
5. 依次调用各phase handler进行处理。

　　一个phase handler的执行过程：

1. 获取location配置。
2. 产生适当的响应。
3. 发送response header.
4. 发送response body.

　　这里直接上taobao团队的给出的Nginx流程图了。

　　从这个图中可以清晰的看到解析http消息每个部分的不同模块。

keepalive长连接

　　长连接的定义：所谓长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。

　　在这里，http请求是基于TCP协议之上的，所以建立需要三次握手，关闭需要四次握手。而http请求是请求应答式的，如果我们能知道每个请求头与响应体的长度，那么我们是可以在一个连接上面执行多个请求的，这就需要在请求头中指定content-length来表明body的大小。在http1.0与http1.1中稍有不同，具体情况如下：

 Http1.0与Http1.1 length

 

　　当客户端的一次访问，需要多次访问同一个server时，打开keepalive的优势非常大，比如图片服务器，通常一个网页会包含很多个图片。打开keepalive也会大量减少time-wait的数量。

pipeline管道线

 　　管道技术是基于长连接的，目的是利用一个连接做多次请求。

　　keepalive采用的是串行方式，而pipeline也不是并行的，但是它可以减少两个请求间的等待的事件。nginx在读取数据时，会将读取的数据放到一个buffer里面，所以，如果nginx在处理完前一个请求后，如果发现buffer里面还有数据，就认为剩下的数据是下一个请求的开始，然后就接下来处理下一个请求，否则就设置keepalive。

lingering_close延迟关闭

　　 当Nginx要关闭连接时，并非立即关闭连接，而是再等待一段时间后才真正关掉连接。目的在于读取客户端发来的剩下的数据。

　　如果服务器直接关闭，恰巧客户端刚发送消息，那么就不会有ACK，导致出现没有任何错误信息的提示。

　　Nginx通过设置一个读取客户数据的超时事件lingering_timeout来防止以上问题的发生。

与HTTP处理模块不同，HTTP过滤模块的工作是对发送给用户的HTTP响应做一些加工。服务器返回的一个响应可以被任意多个HTTP过滤模块以流水线的方式依次处理。HTTP响应分为头部和包体，ngx_http_send_header和ngx_http_output_filter函数分别负责发送头部和包体，它们会依次调用各个过滤模块对待发送的响应进行处理。

在事件处理的分析中，提到过当有http请求过来时事件的触发和处理过程。我们知道，在一个子进程accept()请求之后，会调用ngx_http_init_connection()函数。这个函数会添加一个读事件，并设置其handler为ngx_http_init_request()。但是，对于http模块的载入以及初始化，却是要从http_block()开始。在父进程(master process)调用ngx_init_cycle()的时候，会调用一次ngx_conf_parse()函数(先不在这里分析)，这个时候(解析到了"http {...}" block)，ngx_http_module模块的set()函数即ngx_http_block()就被调用。

一些访问量非常大、业务逻辑简单的Web应用，如果采用PHP等解析型语言去处理，虽然可行，但是在并发能力、处理速度上将受到限制，耗费的系统资源也会较大，这就要求我们增加更多的服务器来处理这类应用。而采用Nginx模块来处理这类Web应用，在性能上将得到极大的提高，大大减少服务器的数量，并将在很大程度上节省服务器的运维成本。

   要编写一个Nginx模块，你要熟悉Nginx的配置文件，这里简单介绍一下：Nginx配置文件主要分成四部分：main（全局设置）、server（主机设置）、upstream（上游服务器设置，主要为反向代理、负载均衡相关配置）和 location（URL匹配特定位置后的设置），每部分包含若干个指令。main部分设置的指令将影响其它所有部分的设置；server部分的指令主要用于指定虚拟主机域名、IP和端口；upstream的指令用于设置一系列的后端服务器，设置反向代理及后端服务器的负载均衡；location部分用于匹配网页位置（比如，根目录“/”,“/images”,等等）。他们之间的关系式：server继承main，location继承server；upstream既不会继承指令也不会被继承。它有自己的特殊指令，不需要在其他地方的应用。

   接下来我们开始Nginx的模块征程：

   Nginx的模块有三种角色： 
    * handlers（处理模块）--处理http请求并构造输出
    * filters（过滤模块）--用于过滤handler产生的输出
    * load-balancers（负载均衡模块） 当有多于一个的后端服务器时，选择一台将http请求转发到该服务器
   当Nginx发送文件或转发请求到其他服务器时，可以用handles处理模块为其服务；当需要Nginx把输出压缩或在服务端加一些东西时，可以在filters过滤模块；Nginx的核心模块主要管理网络层和应用层协议（网络层协议：包括：IP协议、ICMP协议、ARP协议、RARP协议；应用层协议：FTP、Telnet、SMTP、HTTP、RIP、NFS、DNS）,以及启动针对特定应用的一系列候选模块。

    Nginx模块的处理流程：

    客户端发送HTTP request到Nginx服务器 → Nginx基于location的配置选择一个合适的handler → (如果有) load-balancer选择一个后端服务器 → Handler处理请求并顺序将每一个响应buffer发送给第一个filter → 第一个filter讲输出交给第二个filter → 第二个给第三个 → 第三个给第四个 → 以此类推 → 最终响应发送给客户端。模块调用实际上是通过一系列的回调函数做到的，很多很多。名义上来说，你的函数可以在以下时候被执行：

    * server读取配置文件之前
    * 读取location和server部分或其他任何部分的每一条配置指令时
    * 当Nginx初始化全局部分main配置时
    * 当Nginx初始化server配置时（例如：host/port）
    * 当Nginx合并server配置和main配置时
    * 当Nginx初始化location配置时
    * 当Nginx合并location配置和它的父server配置时
    * 当Nginx的主进程启动时
    * 当一个新的worker进程启动时
    * 当一个worker进程退出时
    * 当主进程退出时
    * handle一个请求，即处理HTTP请求时
    * Filter响应头，即过滤HTTP回复的头部时
    * Filter响应体，即过滤HTTP回复的主体时
    * 选择一个后端服务器
    * 初始化一个将发往后端服务器的请求
    * 重新-初始化一个将发往后端服务器的请求
    * 处理来自后端服务器的响应
    * 完成与后端服务器的交互

引言：最近实习由于项目需要，为了追求稳定性加上烤鱼利用Nginx本身提供的优秀的基础设施，使用了Nginx提供的一些扩展功能来做Nginx本身的开发。

Nginx提供了很强的可以自己定制扩展功能的“插件式”扩展，在需要加钩子的地方构造回调函数来完成相应功能（说起来容易做起来难）。

Nginx可以提供三种方式的模块扩展：

1.Handler方式处理HTTP请求

2.Filter方式对于输出的HTTP做过滤，可以加解密或其他功能等

3.Load Balancer,作为HTTP方向代理时候的负载均衡所用

由于项目原因，暂时使用的是Handler方式，不过大多数场景下也是使用了Handler方式

Nginx处理HTTP请求的时候，Nginx模块通过读取配置文件的参数找到相应的钩子函数