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>0<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>0<CRLF><CRLF>Content-MD5: abcefgjslaa....<CRLF>

参考书籍：

《HTTP权威指南》