Http 协议之 Content-Length

小渣渣

前言

http协议是互联网中最重要的协议之一，虽然看上去很简单，但是实际中经常遇到问题，我们就已经遇到好几次了。有长连接相关的，有报文解析相关的。对http协议不能一知半解，必须透彻理解才行。所以就写了这个系列分享http协议的问题与经验。



Http协议的请求报文和回复报文都有header和body，body就是你要获取的资源，例如一个html页面，一个jpeg图片，而header是用来做某些约定的。例如客户端与服务端商定一些传输格式，客户端先获取头部，得知一些格式信息，然后才开始读取body。

客户端： Accept-Encoding:gzip （给我压缩一下，我用的是流量，先下载下来我再慢慢解压吧）

服务端1：Content-Encoding:null(没有Content-Encoding头。 我不给压缩，CPU没空，你爱要不要）

服务端2：Content-Encoding:gzip (给你节省流量，压缩一下）

客户端：Connection: keep-alive (大哥，咱好不容易建了个TCP连接，下次接着用）

服务端1: Connection: keep-alive （都不容易，接着用）

服务端2: Connection: close (谁跟你接着用，我们这个TCP是一次性的，下次再找我还得重新连)

http协议没有三次握手，一般客户端向服务端请求资源时，以服务端为准。还有一些header并没有协商的过程，而是服务端直接告诉客户端按什么来。例如上述的Content-Length，是服务端告诉客户端body的大小有多大。但是！服务端并不一定能准确的提前告诉你body有多大。服务端要先写header，再写body，如果要在header里把body大小写进去，就得提前知道body大小。如果这个body是动态生成的，服务端先生成完，再开始写header，这样需要很多额外的开销，所以header里不一定有content-length。

那客户端怎么知道body的大小呢？服务器有三种方式告诉你。


1. 服务器已经知道资源大小，通过content-length这个header告诉你。

Content-Length:1076(body的大小是1076B，你读取1076B就可以完成任务了）

Transfer-Encoding: null


2. 服务器没法提前知道资源的大小，或者不愿意花费资源提前计算资源大小，就会把http回复报文中加一个header叫Transfer-Encoding:chunked，就是分块传输的意思。每一块都使用固定的格式，前边是块的大小，后面是数据，然后最后一块大小是0。这样客户端解析的时候就需要注意去掉一些无用的字段。

Content-Length:null

Transfer-Encoding:chunked (接下来的body我要一块一块的传，每一块开始是这一块的大小，等我传到大小为0的块时，就没了）


3. 服务器不知道资源的大小，同时也不支持chunked的传输模式，那么就既没有content-length头，也没有transfer-encoding头，这种情况下必须使用短连接，以连接结束来标示数据传输结束，传输结束就能知道大小了。这时候服务器返回的header里Connection一定是close。

Content-Length:null

Transfer-Encoding:null

Connection:close(我不知道大小，我也用不了chunked，啥时候我关了tcp连接，就说明传输结束了）

Okay

谢谢楼主