通常，HTTP协议中使用Content-Length这个头来告知数据的长度。然后，在数据下行的过程中，Content-Length的方式要预先在服务器中缓存所有数据，然后所有数据再一股脑儿地发给客户端。如果要一边产生数据，一边发给客户端，WEB 服务器就需要使用"Transfer-Encoding: chunked"这样的方式来代替Content-Length。（不让服务器返回Transfer-Encoding:chunked，在客户端请求的时候可以使用http 1.0的协议。）
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到达对方，重新组装后，应用程序才使用自己的解码方法还原它们。
image.png
