Nginx在Gzip+ Upstream + HEAD模式下的一个Bug
2012/05/10 11:30 | by ipaddr ]
[转]杂谈Nginx与HTTP协议
2012/05/10 09:54 | by ipaddr ]
在项目中遇到一个问题，需要详细了解下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交互中，客户端是如何获取消息长度的呢，主要基于以下几个规则：
- 响应为1xx，204，304相应或者head请求，则直接忽视掉消息实体内容。
- 如果有Transfer-Encoding，则优先采用Transfer-Encoding里面的方法来找到对应的长度。比如说Chunked模式。
- “如果head中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。如果实体长度和传输长度不相等（比如说设置了Transfer-Encoding），那么则不能设置Content-Length。如果设置了Transfer-Encoding，那么Content-Length将被忽视”。这句话翻译的优点饶，其实关键就一点：有了Transfer-Encoding，则不能有Content-Length。
- Range传输。不关注，没详细看了：）
- 通过服务器关闭连接能确定消息的传输长度。（请求端不能通过关闭连接来指明请求消息体的结束，因为这样可以让服务器没有机会继续给予响应）。这种情况主要对应为短连接，即非keep-alive模式。
- HTTP1.1必须支持chunk模式。因为当不确定消息长度的时候，可以通过chunk机制来处理这种情况。
- 在包含消息内容的header中，如果有content-length字段，那么该字段对应的值必须完全和消息主题里面的长度匹配。
“The entity-length of a message is the length of the message-body before any transfer-codings have been applied”
也就是有chunk就不能有content-length 。
其实后面几条几乎可以忽视，简单总结后如下：
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协议中定义如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Chunked-Body = *chunk last-chunk trailer CRLF chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer = *(entity-header CRLF) |
其中可以看到，每一个chunk都是可以大小自描述的。
在Nginx的Chunked模块中，header filter函数的流程如下：
1 2 3 4 5 6 7 8 9 10 11 12 | //如果没有content或者是head请求，则直接跳过。 if (r->headers_out.content_length_n == -1) { if (http版本 < http 1.1) { r->keepalive = 0;//关闭keep alive } else { if (开启chunk) { r->chunked = 1; } else { r->keepalive = 0;//也就是，如果关闭了chunk，则也关闭了keep alive。 } } } |
对应的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返回的数据直接进行输出。
分析该函数的伪代码如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | for() { if (p->downstream_error) { return ngx_event_pipe_drain_chains(p);//出错了 } if (p->upstream_eof || p->upstream_error || p->upstream_done) { //是最后一个节点，或者已经读取upstream数据完毕 //分类比的flush输出，这里面一般都含有bodyfilter比如 rc = p->output_filter(p->output_ctx, p->in); //并且结束循环 p->downstream_done = 1; break; } /*计算当前BUF的size*/ if (bsize >= (size_t) p->busy_size) { /*超过大小则刷数据*/ go flush; } for ( ;; ) { //循环拼装输出buf，如果超过busy_size同样进行flush } flush： //flush输出 rc = p->output_filter(p->output_ctx, out); } |
可以看到，有一个关键点，就是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）。
