反饋

分塊傳輸編碼

分塊傳輸編碼（Chunked transfer encoding）是超文本傳輸協議（HTTP）中的一種數據傳輸機制，允許HTTP由網頁服務器發送給客户端應用（通常是網頁瀏覽器）的數據可以分成多個部分。分塊傳輸編碼只在HTTP協議1.1版本（HTTP/1.1）中提供。

中文名: 分塊傳輸編碼
外文名: Chunked transfer encoding
實質: 一種數據傳輸機制

應用領域: 通訊工程
學科: 通訊工程
版本: HTTP協議1.1版本

分塊傳輸編碼簡介

通常，HTTP應答消息中發送的數據是整個發送的，Content-Length消息頭字段表示數據的長度。數據的長度很重要，因為客户端需要知道哪裏是應答消息的結束，以及後續應答消息的開始。然而，使用分塊傳輸編碼，數據分解成一系列數據塊，並以一個或多個塊發送，這樣服務器可以發送數據而不需要預先知道發送內容的總大小。通常數據塊的大小是一致的，但也不總是這種情況。

分塊傳輸編碼原理

HTTP 1.1引入分塊傳輸編碼提供了以下幾點好處：

HTTP分塊傳輸編碼允許服務器為動態生成的內容維持HTTP持久鏈接。通常，持久鏈接需要服務器在開始發送消息體前發送Content-Length消息頭字段，但是對於動態生成的內容來説，在內容創建完之前是不可知的。^[1]
分塊傳輸編碼允許服務器在最後發送消息頭字段。對於那些頭字段值在內容被生成之前無法知道的情形非常重要，例如消息的內容要使用散列進行簽名，散列的結果通過HTTP消息頭字段進行傳輸。沒有分塊傳輸編碼時，服務器必須緩衝內容直到完成後計算頭字段的值並在發送內容前發送這些頭字段的值。
HTTP服務器有時使用壓縮（gzip或deflate）以縮短傳輸花費的時間。分塊傳輸編碼可以用來分隔壓縮對象的多個部分。在這種情況下，塊不是分別壓縮的，而是整個負載進行壓縮，壓縮的輸出使用本文描述的方案進行分塊傳輸。在壓縮的情形中，分塊編碼有利於一邊進行壓縮一邊發送數據，而不是先完成壓縮過程以得知壓縮後數據的大小。

分塊傳輸編碼格式

如果一個HTTP消息（請求消息或應答消息）的Transfer-Encoding消息頭的值為chunked，那麼，消息體由數量未定的塊組成，並以最後一個大小為0的塊為結束。

每一個非空的塊都以該塊包含數據的字節數（字節數以十六進制表示）開始，跟隨一個CRLF （回車及換行），然後是數據本身，最後塊CRLF結束。在一些實現中，塊大小和CRLF之間填充有白空格（0x20）。

最後一塊是單行，由塊大小（0），一些可選的填充白空格，以及CRLF。最後一塊不再包含任何數據，但是可以發送可選的尾部，包括消息頭字段。

消息最後以CRLF結尾。

分塊傳輸編碼例子

分塊傳輸編碼編碼的應答

HTTP/1.1 200 OKContent-Type: text/plainTransfer-Encoding: chunked25This is the data in the first chunk1Cand this is the second one3con8sequence0

分塊傳輸編碼編碼應答的解釋

前兩個塊的數據中包含有顯式的\r\n字符。

"This is the data in the first chunk\r\n" (37 字符 => 十六進制: 0x25)

"and this is the second one\r\n" (28 字符 => 十六進制: 0x1C)

"con" (3 字符 => 十六進制: 0x03)

"sequence" (8 字符 => 十六進制: 0x08)

應答需要以0長度的塊（"0\r\n\r\n".）結束。

分塊傳輸編碼解碼的數據

This is the data in the first chunk

and this is the second one

consequence

分塊傳輸編碼參見

HTTP

參考資料

1. Roy T. Fielding. Keep-Alive Notes. HTTP Working Group (HTTP-WG) mailing list. 10 Oct 1995.

詞條統計

瀏覽次數：次
編輯次數：10次歷史版本
最近更新：自己的神7 （2022-04-26）

1 簡介
2 原理
3 格式
4 例子: 4.1 編碼的應答; 4.2 編碼應答的解釋; 4.3 解碼的數據
5 參見