參考鏈接:

HTTP?協議中的?Transfer-Encoding

分塊傳輸編碼

一、背景:

? ? 1.持續連接的問題:對于非持續連接，瀏覽器可以通過連接時否關閉來界定請求或響應實體的邊界;而對于持續連接，這種方法顯然不奏效。有時，盡管我已經發送完所有數據，但瀏覽器并不知道這一點，它無法得知這個打開的連接上是否還會有新數據進來，只能傻傻地等了。

? ? 2.用Content-Length解決:計算實體長度，并通過頭部告訴對方。瀏覽器可以通過Content-Length的長度信息，判斷出響應實體已結束。

? ? 3.Content-Length引入的新問題:由于Content-Length字段必須真實反映實體長度，但是對于動態生成的內容來說，在內容創建完之前，長度是不可知的。這時候要想準確獲取長度，只能開一個足夠大的buffer，等內容全部生成號再計算。但這樣做一方面需要更大的內存開銷，另一方面也會讓客戶端等更久。

? ? 4.我們需要一個新的機制:不依賴頭部的長度信息，也能知道實體的邊界----分塊編碼(Transfer-Encoding:chunked)

二、分塊編碼(Transfer-Encoding:chunked)

? ? 1.Transfer-Encoding,是一個HTTP頭部字段(響應頭域),字面意思是[傳輸編碼]。最新的HTTP規范里，只定義了一種編碼傳輸:分塊編碼(chunked)。

? ? 2.分塊傳輸編碼(Chunked transfer encoding)是超文本傳輸協議(HTTP)中的一種數據傳輸機制，允許HTTP由網頁服務器發送給客戶端的數據可以分成多個部分。分塊傳輸編碼只在HTTP協議1.1版本(HTTP/1.1)中提供。

? ? 3.數據分解成一系列數據塊，并以一個或多個塊發送，這樣服務器可以發送數據而不需要預先知道發送內容的總大小。

? ? 4.具體方法

? ? ? ? 1).在頭部加入Transfer-Encoding:chunked之后，就代表這個報文采用了分塊編碼。這時，報文中的實體需要改為用一系列分塊來傳輸。

? ? ? ? 2).每個分塊包含十六進制的長度值和數據，長度值獨占一行，長度不包括它結尾的CRLF(\r\n),也不包括分塊數據結尾的CRLF。

? ? ? ? 3).最后一個分塊長度值必須為0，對應的分塊數據沒有內容，表示實體結束。

? ? 5.例子:

? ? ? ??

HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked25\r\n This is the data in the first chunk\r\n1C\r\n and this is the second one\r\n3\r\n con\r\n8\r\n sequence\r\n\0\r\n \r\n

6.Content-Encoding和Transfer-Encoding二者經常會結合來用，其實就是針對Transfer-Encoding的分塊在進行Content-Encoding壓縮。

?

總結

以上是生活随笔為你收集整理的分块编码(Transfer-Encoding:chunked)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。