Nginx与HTTP协议,content-length

最新推荐文章于 2025-06-14 23:44:43 发布

转载最新推荐文章于 2025-06-14 23:44:43 发布 · 1.2w 阅读

文章标签：

#http协议 #gzip

http协议专栏收录该内容

1 篇文章

订阅专栏

本文深入探讨了HTTP协议中Content-Length字段的作用及其与Chunked传输编码的关系，并解析了Nginx中Chunked模式和Gzip模块的工作原理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在项目中遇到一个问题，基于Android的apache httpdclient 无法获取到响应的content-length，通过排查确定是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交互中，客户端是如何获取消息长度的呢，主要基于以下几个规则：

* 响应为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协议中定义如下：
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函数的流程如下：
//如果没有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返回的数据直接进行输出。
分析该函数的伪代码如下：
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）。