链接：https://pan.baidu.com/s/1r4udRf-pXCdxDrtu48_3hA 

提取码：ahqv 

 

1.协议描述

rfc2616协议3.6.1章节中描述如下：

The chunked encoding modifies the body of a message in order to  transfer it as a series of chunks, each with its own size indicator,followed by an OPTIONAL trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information necessary for the recipient to verify that it has received the full message.

块编码改变消息主体成块发送，每一个块有它自己的长度指示器，所有块之后会紧接着一个可选的包含实体头域的尾部。这种编码允许发送端发送生成动态的内容，并携带了能够使接收端判断消息是否接收完整的有用信息。

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)

The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.

Chunk-size是用16进制数字字符串。块编码以大小为0的块结束，紧接着是尾部，尾部以空行终止。

 

The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field can be used to indicate which header fields are included in a trailer (see section 14.40).

尾部允许发送端在消息的末尾包含额外的HTTP头域。尾部头域被用来指明哪些头域包含在尾部。

 

A server using chunked transfer-coding in a response MUST NOT use the trailer for any header fields unless at least one of the following is true:

如果一个服务器要使用块传输进行响应，除非以下一条为真它才能在尾部包含头域。

 

a)the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the  response, as described in section 14.39; or,

如果此请求包含一个TE头域，表明“尾部”在响应中用这种传输编码被接受

 

   b)the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable to the origin server) without receiving this metadata.  In other words, the origin server is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.

如果是源服务器做出响应，尾部包含的全部是可选的元信息，并且接受者会接收这个信息但是忽略这些元信息（以一种源服务器可以接收的方式）。换句话说源服务器接收尾部中的域在未到达客户端被丢弃的情况。

 

   This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly infinite buffer on the proxy.

当一个消息被HTTP1.1或者更高版本的代理接收并且转发到一个HTTP1.1的接收者的时候，此要求防止了一种互操作性的失败。

 

   An example process for decoding a Chunked-Body is presented in appendix 19.4.6.

19.4.6中有一个例子介绍了一个块主体解码过程。

 

   All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand.

   所有HTTP1.1应用必须能够接收和解码”chunked”传输编码方式，并且必须忽略它们不能理解的块扩展。

2.举例说明

下面分析用ethereal抓包使用Firefox与某网站通信的结果（从头域结束符后开始）：

 

Address  0..........................  f

000c0                       31

000d0    66 66 63 0d 0a ...............   // ASCII码:1ffc/r/n, chunk-data数据起始地址为000d5

显然，“1ffc”为第一个chunk的chunk-size,转换为int为8188。由于1ffc后，马上就是CRLF,因此没有chunk-extension。chunk-data的起始地址为000d5, 计算可知下一块chunk的起始

地址为000d5+1ffc + 2=020d3，如下：

020d0    .. 0d 0a 31 66 66 63 0d 0a .... // ASCII码:/r/n1ffc/r/n

前一个0d0a是上一个chunk的结束标记符，后一个0d0a则是chunk-size和chunk-data的分隔符。

此块chunk的长度同样为8188, 依次类推，直到最后一块

100e0                          0d 0a 31

100f0    65 61 39 0d 0a......            //ASII码：/r/n/1ea9/r/n

此块长度为0x1ea9 = 7849, 下一块起始为100f5 + 1ea9 + 2 = 11fa0,如下：

11fa0    30 0d 0a 0d 0a                  //ASCII码：0/r/n/r/n

“0”说明当前chunk为last-chunk, 第一个0d 0a为chunk结束符。第二个0d0a说明没有trailer部分，整个Chunk-body结束。

 

length最后的值实际为所有chunk的chunk-size之和，在上面的抓包实例中，一共有八块chunk-size为0x1ffc(8188)的chunk,剩下一块为0x1ea9(7849),加起来一共73353字节。

      注：对于上面例子中前几个chunk的大小都是8188,可能是因为:"1ffc" 4字节，""r"n"2字节，加上块尾一个""r"n"2字节一共8字节，因此一个chunk整体为8196,正好可能是发送端一次TCP发送的缓存大小。