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到達對方，重新組裝後，應用程式才使用自己的解碼方法還原它們。
http1.1採用了持久的連線，也就是一次tcp的連線不馬上釋放，允許許多的請求跟響應在乙個tcp的連線上傳送，所以客戶機與伺服器需要某種方式來標示乙個報文在**結束和在下乙個報文在**開始。簡單的方法是使用呢content-length，但這只有當報文長度可以預先判斷的時候才起作用，而對於動態的內容或者在傳送資料前不能判定長度的情況下，可以使用分塊的方法來傳送編碼。
如圖：
web伺服器有時生成httpresponse無法在header就確定訊息大小的，這時一般來說伺服器將不會提供content-length的頭資訊，而採用chunked編碼動態的提供body內容的長度。
進行chunked編碼傳輸的http response會在訊息頭部設定：
transfer-encoding: chunked
表示content body將用chunked編碼傳輸內容。
chunked編碼使用若干個chunk串連而成，由乙個標明長度為0的chunk標示結束。每個chunk分為頭部和正文兩部分，頭部內容指定下一段正文的字元總數（十六進製制的數字）和數量單位（一般不寫），正文部分就是指定長度的實際內容，兩部分之間用回車換行(crlf)隔開。在最後乙個長度為0的chunk中的內容是稱為footer的內容，是一些附加的header資訊（通常可以直接忽略）。
這裡面只有乙個有意義的chunke以及乙個footer。第乙個chunk，頭部是3134這兩個位元組，表示的是1和4這兩個ascii字元，被http協議解釋為十六進製制數14，也就是十進位制的20。後面緊跟0d0a，再接著是20個位元組的chunk正文（圖中的011e~0131）。
後面再接著0d0a，然後就是footer了，30表示ascii字元0，http解釋為長度是0（也說明了這是最後乙個chunk），後面緊跟0d0a，然後正文部分為空，再接0d 0a表示結束
http協議chunk 編碼
有時伺服器生成http回應是無法確定訊息大小的，這時用content length就無法事先寫入長度，而需要實時生成訊息長度，這時伺服器一般採用chunked編碼。http協議之chunk資料結構 chunk編碼其實是一種動態資料傳輸協議，針對大資料可以動態傳輸，網頁可以動態顯示。chunk編碼格式...
HTTP協議chunked編碼
當不能預先確定報文體的長度時，不可能在頭中包含content length域來指明報文體長度，此時就需要通過transfer encoding域來確定報文體長度。此時，transfer encoding域的值應當為chunked，表明採用chunked編碼方式來進行報文體的傳輸。chunked編碼是...
http協議中編碼問題
http協議報文有兩種 請求報文和響應報文，這兩種報文結構是差不多的，都由三個部分組成，依次是 1 start line 開始行 在請求報文中叫請求行，響應報文中叫狀態行 如 get index.jsp http crlf 2 header 報頭 如 accept host user agent等 ...