HTTP分块传输
用途
对于在发送HTTP头部前，无法计算出Content-Length的HTTP请求及回复（例如WEB服务端产生的动态内容），可以使用分块传输，使得不至于等待所有数据产生后，再发送带有Content-Length的HTTP头部，而是将已经产生的数据一块一块发送出去。
特点：
1，HTTP BODY数据成连续的块传输，每块数据的最开始处，指明了该数据块的大小，随后则是CRLF，数据，及结尾CRLF：
HTTP HEADERS
<CRLF>
1E<CRLF>
DATA1
<CRLF>
ED<CRLF>
DATA2
<CRLF><CRLF>
<CRLF>
可见每块数据都是包含在两个CRLF之间，最后一块数据则是0CRLFCRLF，两个CRLF之间没有任何数据；数据大小以16进制字符串表示（不是二进制）。
2，Transfer-Encoding、TE头部：
Transfer-Encoding 首部 — 告知接收方，BODY数据使用何种传输编码，Transfer-Encoding: chunked，表明使用分块传输；
TE 首部 — 告知服务端，可以使用哪些传输编码，TE: trailers, chunked，表明可以使用 分块传输及拖挂；
客户端发送请求时，也可以使用分块传输，但是一般客户端发送请求前，不知道服务端是否支持分块传输，所以，客户端可以发送HTTP头部，表明使用分块传输，假如服务端不支持，将会回复 411(Length Required) 错误，中断请求。
3，HTTP Header 拖挂
如果客户端TE首部中说明可以接受拖挂，则可以在最后一个分块后面加上拖挂的 Header Entity；
服务端产生的HTTP回复中，带有 Trailer 首部，告知客户端此回复中拖挂的 Header Entity 是哪些首部，除了 Transfer-Encoding、Trailer、Content-Length首部外，其他HTTP首部都可以作为拖挂发送；
HTTP/1.1 200 OK<CRLF>
...
Transfer-Encoding: chunked<CRLF>
Trailer: Content-MD5<CRLF>
<CRLF>
AA<CRLF>
....
<CRLF>
BB<CRLF>
...
<CRLF><CRLF>
<CRLF>
Content-MD5: abcefgjslaa....<CRLF>
参考书籍：
《HTTP权威指南》
