Transfer-Encoding: chunked

标签：

在http1.1引入了 Transfer-Encoding 这个head

Transfer-Encoding: chunked

我们知道Content-Length 表明http的消息体的传输长度(不是消息体的原来长度)

在http1.1中，当服务器不明确的消息的长度是多少的时候，可以使用 Transfer-Encoding: chunked (表明服务器采用分块) 来代替Content-Length

根据协议描述，当出现Transfer-Encoding: chunked的时候Content-Length不应该出现

当Transfer-Encoding: chunked没有的时候必须出现Content-Length

在使用Transfer-Encoding: chunked的时候 还需要使用Connection: keep-alive模式

具体chunked是怎么编码的，请看下面

HTTP头
\r\n      (Length。

    "Transfer-Encoding: chunked"是这样编码的：
HTTP头
\r\n      (0D 0A)
\r\n      --连续的两个\r\n之后就是HTTP体了
16进制值代表的数据长度
\r\n
上面所指的数据长度
\r\n    --每段数据结束后，以\r\n标识

16进制代表的第二段数据
\r\n
XX长度的数据
\r\n

………… (反复通过这样的方式表示每次传输的数据长度)

0      --数据结束部分用0表示，然后是连续的两个\r\n
\r\n
\r\n

如果response没有设置Transfer-Encoding: chunked  也没有 Content-Length，那么客户端会等到服务器断掉tcp连接才认为数据传送完，这种情况下，无法区分是由于网络问题导致的还是由于response传输成功完成。

Transfer-Encoding: gzip, chunked 

表明内容是经过gzip压缩的然后chunked，所以chunked必须放在最后。

但是感觉基本上会使用Content-Encoding:gzip  不使用Transfer-Encoding: gzip.

客户端可以收到部分chunk就开始进行解析，这样会用户体验好一些，所以服务器进行chunk划分的时候也是有一些技巧的

另外科普了一下：

Request中

Accept-Encoding: gzip, deflate, sdch   表明客户端可以接受的Encoding方法

Response中

Content-Encoding:gzip         表明服务器使用的Encoding方法

Transfer-Encoding: chunked

标签：

原文地址：http://www.cnblogs.com/leon-zhu/p/4313746.html