在项目中遇到一个问题,需要详细了解下HTTP协议及其Nginx中对HTTP协议的支持程度。今天一天收集了一些资料,也梳理出最终方案。记录到博客上,方便后续查阅。重点关注以下几个方面:1、Http交互中如何判定内容的长度及其HTTP协议中关于Content-Length的解读。2、Chunk和Gzip在Nginx中的实现及原理。3、Upstream如何和Chunked结合。
在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的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模式。
在前面介绍的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)。
本文首发 xlq的博客 (转载请保留) http://blog.xiuwz.com/2012/01/10/talk-nginx-with-http/