1. 对于动态生成的应答内容来说，内容在未生成完成前总长度是不可知的。因此需要先缓存生成的内容，再计算总长度填充到Content-Length，再发送整个数据内容。这样显得不太灵活，而使用分块编码则能得到改观。
   
2. 分块传输编码允许服务器在最后发送消息头字段。例如在头中添加散列签名。
   
3. 对于压缩传输传输而言，可以一边压缩一边传输。
   

　　如果在http的消息头里Transfer-Encoding为chunked，那么就是使用此种编码方式。接下来会发送数量未知的块，每一个块的开头都有一个十六进制的数,表明这个块的大小，然后接CRLF("\r\n")。然后是数据本身，数据结束后，还会有CRLF两个字符。有一些实现中，块大小的十六进制数和CRLF之间可以有空格。
　　最后一块的块大小为0，表明数据发送结束。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。消息最后以CRLF结尾。

• 抓包截图
  
  

如何测试支持chunked编码

　　如何测试自己的程序支持接收这种编码方式的数据呢？第一想到的当然是配下服务器，使其固定以这种方式发数据，但是没有搜索到如果把apache配成这个模式。好在强大的Stack Overflow里找到了有用信息。
　　http://www.httpwatch.com/httpgallery/chunked/chunkedimage.aspx 这个页面就是chunked编码传输的。只需要测试看能否正确下载这个页面就可以了，分块发送时服务器是每0.1s发送1k的数据过来。
　　

一般HTTP通信时会使用是Content-Length头信息来指定body信息大小，但是有时候无法确定信息大小，就要使用trunked编码动态的提供body内容的长度。进行Chunked编码传输的HTTP数据要在消息头部设置：Transfer-Encoding: chunked表示Content Body将用chunked编码传输内容。Chunked编码一般使用若干个chunk串连而成，最后由一个标明长度为0的chunk标示结束。每个chunk分为头部和正文两部分，头部内容指定下一段正文的字符总数（非零开头的十六进制的数字）和数量单位（一般不写,表示字节）.正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）

上述解释过于官方，简而言之，chunked编码的基本方法是将大块数据分解成多块小数据，每块都可以自指定长度，其具体格式如下：