分塊傳輸編碼

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

基本介紹

• 中文名：分塊傳輸編碼
• 外文名：Chunked transfer encoding
• 實質：一種數據傳輸機制
• 套用領域：通訊工程
• 學科：通訊工程
• 版本：HTTP協定1.1版本

簡介

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

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

原理

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

1. HTTP分塊傳輸編碼允許伺服器為動態生成的內容維持HTTP持久連結。通常，持久連結需要伺服器在開始傳送訊息體前傳送Content-Length訊息頭欄位，但是對於動態生成的內容來說，在內容創建完之前是不可知的。
   
2. 分塊傳輸編碼允許伺服器在最後傳送訊息頭欄位。對於那些頭欄位值在內容被生成之前無法知道的情形非常重要，例如訊息的內容要使用散列進行簽名，散列的結果通過HTTP訊息頭欄位進行傳輸。沒有分塊傳輸編碼時，伺服器必須緩衝內容直到完成後計算頭欄位的值並在傳送內容前傳送這些頭欄位的值。
   
3. 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