HTTP協議之chunk編碼(分塊傳輸編碼

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表示結束