10 一 12 杂谈Nginx与HTTP协议在项目中遇到一个问题,需要详细了解下HTTP协议及其Nginx中对HTTP协议的支持程度。今天一天收集了一些资料,也梳理出最终方案。记录到博客上,方便后续查阅。重点关注以下几个方面:1、Http交互中如何判定内容的长度及其HTTP协议中关于Content-Length的解读。2、Chunk和Gzip在Nginx中的实现及原理。3、Upstream如何和Chunked结合。 Http协议中关于Content-Length的解读在HTTP协议中,有Content-Length的详细解读。Content-Length用于描述HTTP消息实体的传输长度the transfer-length of the message-body。在HTTP协议中,消息实体长度和消息实体的传输长度是有区别,比如说gzip压缩下,消息实体长度是压缩前的长度,消息实体的传输长度是gzip压缩后的长度。 在具体的HTTP交互中,客户端是如何获取消息长度的呢,主要基于以下几个规则:
其实后面几条几乎可以忽视,简单总结后如下: 1、Content-Length如果存在并且有效的话,则必须和消息内容的传输长度完全一致。(经过测试,如果过短则会截断,过长则会导致超时。) 2、如果存在Transfer-Encoding(重点是chunked),则在header中不能有Content-Length,有也会被忽视。 3、如果采用短连接,则直接可以通过服务器关闭连接来确定消息的传输长度。(这个很容易懂) 结合HTTP协议其他的特点,比如说Http1.1之前的不支持keep alive。那么可以得出以下结论: 1、在Http 1.0及之前版本中,content-length字段可有可无。 2、在http1.1及之后版本。如果是keep alive,则content-length和chunk必然是二选一。若是非keep alive,则和http1.0一样。content-length可有可无。 Nginx在Http协议方面的处理第一、Nginx的chunk模块 Nginx的Chunk模块是一个典型的Filter模块,它本身是内置必选的Nginx模块。在0.7.66版本之后,有一个配置项chunked_transfer_encoding可以开启或者关闭chunk模式,默认是开启的。 首先,先简单了解下在HTTP协议中Chunked相关的知识点。Chunked一种transfer coding方式,在HTTP1.0之前(包含http1.0)的版本是不支持的。在HTTP协议中定义如下:
其中可以看到,每一个chunk都是可以大小自描述的。 在Nginx的Chunked模块中,header filter函数的流程如下:
对应的body filter的流程,则更加简单,直接对当前输出的buf chain进行一个chunk封装。 第二、Nginx中Gzip模块和r->headers_out.content_length_n r->headers_out.content_length_n :这个在Nginx内部用于表述请求返回内容的长度。但注意这不是完全相等的,只有在 r->headers_out.content_length_n >=0的时候,才有意义。比如说,通常后端的upstream(比如说PHP),如果没有在脚本中强制header输出content-length,则默认在nginx中 r->headers_out.content_length_n = -1。 Gzip模块也是一个典型的Filter模块。这里简单介绍下,后续可以详细描述。在header filter中会直接清空 r->headers_out.content_length_n和header中输出的content_length。为什么要清空呢?主要是因为gzip要对内容模块进行压缩处理,而在header filter的时候,gzip模块不可能计算出压缩后的内容长度(原因是在nginx中,header 输出和body的输出是完全两个不同的阶段),所以最好的办法就是在清空header中的content-length。这样结合之前的介绍的chunked模块,可以看出:在nginx中,如果采用gzip,如果是keep alive,则必然是chunked模式。 Upsteam如何和chunked结合在前面介绍的Nginx Chunked模式实现中提到,Chunked模块的body filter是对当前处理的buf chain进行封装成一个Chunk。那么在Nginx中是如何实现多个Chunk的呢?这里要从 ngx_event_pipe_write_to_downstream这个函数说起,该函数是upstream处理中非常关键的一个函数,用于把upstream返回的数据直接进行输出。 分析该函数的伪代码如下:
可以看到,有一个关键点,就是busy_size,它决定了一个chunk的大小。这个对应一个配置,追查后如下:在不同的upstream中有不同的定义,比如说proxy模式下,有proxy_busy_buffers_size,该值默认是proxy buffer size * 2 。(proxy buffer size根据操作系统,可以是4K或者8k)。fastcgi模式下,buffer_size默认是ngx_pagesize。配置项是fastcgi_busy_buffers_size。默认情况下是fastcgi的buffer size的2倍。(buffer size个是可配置的,buffer 个个数也是可以配置的,个数不能小于2)。 |
|