HTTP协议之chunk编码(分块传输编码)

http://blog.csdn.net/xifeijian/article/details/42921827

分块传输编码（Chunked transfer encoding）是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由应用服务器发送给客户端应用（ 通常是网页浏览器）的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供。

通常，HTTP应答消息中发送的数据是整个发送的，Content-Length消息头字段表示数据的长度。数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。通常数据块的大小是一致的，但也不总是这种情况。

 

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

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

   一般情况HTTP的Header包含Content-Length域来指明报文体的长度。有时候服务生成HTTP回应是无法确定消息大小的，比如大文件的下载，或者后台需要复杂的逻辑才能全部处理页面的请求，这时用需要实时生成消息长度，服务器一般使用chunked编码。

   在进行Chunked编码传输时，在回复消息的Headers有transfer-coding域值为chunked，表示将用chunked编码传输内容。使用chunked编码的Headers如下（可以利用FireFox的FireBug插件或HttpWatch查看Headers信息）：

  　采用以下方式编码：   
  　　Chunked-Body=*chunk   
  　　　　　　　　　"0"CRLF   
  　　　　　　　　　footer   
  　　　　　　　　　CRLF   
  　　chunk=chunk-size[chunk-ext]CRLF   
  　　　　　　chunk-dataCRLF   
    
  　　hex-no-zero=<HEXexcluding"0">   
    
  　　chunk-size=hex-no-zero*HEX   
  　　chunk-ext=*(";"chunk-ext-name["="chunk-ext-value])   
  　　chunk-ext-name=token   
  　　chunk-ext-val=token|quoted-string   
  　　chunk-data=chunk-size(OCTET)   
    

  　　footer=*entity-header 

  　　编码使用若干个Chunk组成，由一个标明长度为0的chunk结束，每个Chunk有两部分组成，第一部分是该Chunk的长度和长度单位（一般不 写），第二部分就是指定长度的内容，每个部分用CRLF隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些没有写的头部内 容。   

  　　下面给出一个Chunked的解码过程（RFC文档中有）   
  　　length:=0   
  　　readchunk-size,chunk-ext(ifany)andCRLF   
  　　while(chunk-size>0){   
  　　readchunk-dataandCRLF   
  　　appendchunk-datatoentity-body   
  　　length:=length+chunk-size   
  　　readchunk-sizeandCRLF   
  　　}   
  　　readentity-header   
  　　while(entity-headernotempty){   
  　　appendentity-headertoexistingheaderfields   
  　　readentity-header   
  　　}   
  　　Content-Length:=length   
  　　Remove"chunked"fromTransfer-Encoding

 

---

 

http://www.cnblogs.com/ribavnu/p/5084458.html

Transfer-Encoding: chunked 表示输出的内容长度不能确定，普通的静态页面、图片之类的基本上都用不到这个。

但动态页面就有可能会用到，但我也注意到大部分asp,php,asp.net动态页面输出的时候大部分还是使用Content-Length，没有使用Transfer-Encoding: chunked。

不过如果结合：Content-Encoding: gzip 使用的时候，Transfer-Encoding: chunked还是比较有用的。

记得以前实现：Content-Encoding: gzip 输出时，先把整个压缩后的数据写到一个很大的字节数组里(如 ByteArrayOutputStream)，然后得到数组大小 -> Content-Length。

如果结合Transfer-Encoding: chunked使用，就不必申请一个很大的字节数组了，可以一块一块的输出，更科学，占用资源更少。

这在http协议中也是个常见的字段，用于http传送过程的分块技术，原因是http服务器响应的报文长度经常是不可预测的，使用Content-length的实体搜捕并不是总是管用。

          分块技术的意思是说，实体被分成许多的块，也就是应用层的数据，TCP在传送的过程中，不对它们做任何的解释，而是把应用层产生数据全部理解成二进制流，然后按照MSS的长度切成一分一分的，一股脑塞到tcp协议栈里面去，而具体这些二进制的数据如何做解释，需要应用层来完成，所以在这之前，一快整体应用层的数据需要等它分成的所有TCP  segment到达对方，重新组装后，应用程序才使用自己的解码方法还原它们。

   HTTP1.1采用了持久的连接，也就是一次TCP的连接不马上释放，允许许多的请求跟响应在一个TCP的连接上发送，所以客户机与服务器需要某种方式来标示一个报文在哪里结束和在下一个报文在哪里开始。简单的方法是使用呢content-length，但这只有当报文长度可以预先判断的时候才起作用，而对于动态的内容或者在发送数据前不能判定长度的情况下，可以使用分块的方法来传送编码。

如图：

 

 

Web服务器有时生成HTTPResponse无法在Header就确定消息大小的，这时一般来说服务器将不会提供Content-Length的头信息，而采用Chunked编码动态的提供body内容的长度。

 

进行Chunked编码传输的HTTP Response会在消息头部设置：

Transfer-Encoding: chunked

表示Content Body将用Chunked编码传输内容。

Chunked编码使用若干个Chunk串连而成，由一个标明长度为0的chunk标示结束。每个Chunk分为头部和正文两部分，头部内容指定下一段正文的字符总数（十六进制的数字）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。

这里面只有一个有意义的chunke以及一个footer。第一个chunk，头部是3134这两个字节，表示的是1和4这两个ascii字符，被http协议解释为十六进制数14，也就是十进制的20。后面紧跟0d0a，再接着是20个字节的chunk正文（图中的011e~0131）。

后面再接着0d0a，然后就是footer了，30表示ascii字符0，http解释为长度是0（也说明了这是最后一个chunk），后面紧跟0d0a，然后正文部分为空，再接0d 0a表示结束