【HTTP】持久连接与分块chunked传输

系统管理员 2022-06-02 00:29 188阅读 0赞

## 1、已知报文的长度Content-Length时 ##

HTTP1.1支持持久连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟（也就是一次TCP的连接不马上释放，允许许多的请求跟响应在一个TCP的连接上发送），所以客户机与服务器需要某种方式来标示一个报文在哪里结束和下一个报文从哪里开始。简单的方法是使用Content-Length，但这只有当报文长度可以预先判断的时候才起作用。

## 2、未知报文的长度Content-Length时 ##

有的时候，服务器无法确定HTTP回应的消息的大小，比如非常大的文件的下载，或者处理的逻辑比较复杂，需要一边处理一边实时生成消息，这个时候服务器一般都使用分块chunked编码。此时，服务器不会带上Content-Length这个响应头，带上了两外一个头：Transfer-encoding:chunked。

chunked编码使用若干个Chunk组成，由一个标明长度为0的chunk结束，每个Chunk有两部分组成，每个部分用回车换行隔开。

因此，接收数据的时候，需要首先获取每一个chunk数据的字节长度，然后，跳过2个字节(/r/n)，取出数据，然后，再跳过2个字节(/r/n)，获取下一个chunk的长度，直到最后一个chunk，最后一个chunk一定是0，并且字节的长度都是十六进制形式传输，需要进行相应的转化成十进制，如果是gzip格式的数据，那么，在最后完成所有数据组合之后，需要再解压。

HTTP 1.1引入分块传输编码提供了以下几点好处：

1.  HTTP分块传输编码允许服务器为动态生成的内容维持HTTP持久连接。通常，持久链接需要服务器在开始发送消息体前发送Content-Length消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。\[动态内容，content-length无法预知\]
2.  分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要，例如消息的内容要使用散列进行签名，散列的结果通过HTTP消息头字段进行传输。没有分块传输编码时，服务器必须缓冲内容直到完成后计算头字段的值并在发送内容前发送这些头字段的值。\[散列签名，需缓冲完成才能计算\]
3.  HTTP服务器有时使用压缩 （gzip或deflate）以缩短传输花费的时间。分块传输编码可以用来分隔压缩对象的多个部分。在这种情况下，块不是分别压缩的，而是整个负载进行压缩，压缩的输出使用本文描述的方案进行分块传输。在压缩的情形中，分块编码有利于一边进行压缩一边发送数据，而不是先完成压缩过程以得知压缩后数据的大小。\[gzip压缩，压缩与传输同时进行\]