通常，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