當不能預先確定報文體的長度時，不可能在頭中包含Content-Length域來指明報文體長度，此時就需要通過Transfer-Encoding域來確定報文體長度。
??? 通常情況下，Transfer-Encoding域的值應當為chunked,表明采用chunked編碼方式來進行報文體的傳輸。chunked編碼是HTTP/1.1 RFC里定義的一種編碼方式，因此所有的HTTP/1.1應用都應當支持此方式。
??? chunked編碼的基本方法是將大塊數據分解成多塊小數據，每塊都可以自指定長度，其具體格式如下（BNF文法）:
??? Chunked-Body?? = *chunk?? ?? ?? ?? //0至多個chunk
???????????????????? last-chunk?? ?? ?? //最后一個chunk
???????????????????? trailer?? ?? ?? ?? //尾部
???????????????????? CRLF?? ?? ?? ?? ?? //結束標記符

?? chunk????????? = chunk-size [ chunk-extension ] CRLF??
??????????????????????? chunk-data CRLF
?? chunk-size???? = 1*HEX
?? last-chunk???? = 1*("0") [ chunk-extension ] CRLF

?? chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
?? chunk-ext-name = token
?? chunk-ext-val? = token | quoted-string
?? chunk-data???? = chunk-size(OCTET)
?? trailer??????? = *(entity-header CRLF)?? ??
???
??? 解釋：
??? Chunked-Body表示經過chunked編碼后的報文體。報文體可以分為chunk, last-chunk，trailer和結束符四部分。chunk的數量在報文體中最少可以為0，無上限；每個chunk的長度是自指定的，即，起始的數據必然是16進制數字的字符串，代表后面chunk-data的長度（字節(jié)數）。這個16進制的字符串第一個字符如果是“0”，則表示chunk- size為0，該chunk為last-chunk,無chunk-data部分。可選的chunk-extension由通信雙方自行確定，如果接收者不理解它的意義，可以忽略。
??? trailer是附加的在尾部的額外頭域，通常包含一些元數據（metadata, meta means "about information"），這些頭域可以在解碼后附加在現有頭域之后。
??? 實例分析：
??? 下面分析用ethereal抓包使用Firefox與某網站通信的結果（從頭域結束符后開始）：
Address? 0..........................? f
000c0??? ?? ? ?? ??? ??? ??? ??? ??? 31
000d0 ?? 66 66 63 0d 0a ...............?? // ASCII碼:1ffc"r"n, chunk-data數據起始地址為000d5
???? ??? 很明顯，“1ffc”為第一個chunk的chunk-size,轉換為int為8188.由于1ffc后馬上就是
???? ??? CRLF,因此沒有chunk-extension.chunk-data的起始地址為000d5, 計算可知下一塊chunk的起始
??? ?? ? 地址為000d5+1ffc + 2=020d3,如下：
020d0??? .. 0d 0a 31 66 66 63 0d 0a .... // ASCII碼:"r"n1ffc"r"n
???? ??? 前一個0d0a是上一個chunk的結束標記符，后一個0d0a則是chunk-size和chunk-data的分隔符。
??? ?? ? 此塊chunk的長度同樣為8188, 依次類推，直到最后一塊
100e0?? ?? ?? ?? ?? ?? ?? ?? ? 0d 0a 31
100f0??? 65 61 39 0d 0a......?? ?? ?? ?? //ASII碼："r"n"1ea9"r"n
??? ?? ? 此塊長度為0x1ea9 = 7849, 下一塊起始為100f5 + 1ea9 + 2 = 11fa0,如下：
100a0??? 30 0d 0a 0d 0a?? ?? ?? ?? ?? ?? //ASCII碼：0"r"n"r"n
??? ?? ? “0”說明當前chunk為last-chunk, 第一個0d 0a為chunk結束符。第二個0d0a說明沒有trailer部分，整個Chunk-body結束。
??? 解碼流程：
??? 對chunked編碼進行解碼的目的是將分塊的chunk-data整合恢復成一塊作為報文體，同時記錄此塊體的長度。
??? RFC2616中附帶的解碼流程如下：(偽代碼）
??? length := 0?? ?? ?? //長度計數器置0
??? read chunk-size, chunk-extension (if any) and CRLF?? ?? //讀取chunk-size, chunk-extension
??? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? //和CRLF
??? while(chunk-size > 0 )?? {?? ?? ?? ?? //表明不是last-chunk
??? ?? ?? read chunk-data and CRLF?? ?? ?? ?? //讀chunk-size大小的chunk-data,skip CRLF
??? ?? ?? append chunk-data to entity-body?? ? //將此塊chunk-data追加到entity-body后
??? ?? ?? read chunk-size and CRLF ?? ?? ?? //讀取新chunk的chunk-size 和 CRLF
??? }
??? read entity-header?? ?? //entity-header的格式為name:valueCRLF,如果為空即只有CRLF
??? while （entity-header not empty)?? //即，不是只有CRLF的空行
??? {
??? ?? append entity-header to existing header fields
??? ?? read entity-header
??? }
??? Content-Length:=length?? ?? //將整個解碼流程結束后計算得到的新報文體length
??? ?? ?? ?? ?? ?? ?? ?? ?? ?? ? //作為Content-Length域的值寫入報文中
??? Remove "chunked" from Transfer-Encoding? //同時從Transfer-Encoding中域值去除chunked這個標記
??? length最后的值實際為所有chunk的chunk-size之和，在上面的抓包實例中，一共有八塊chunk-size為0x1ffc(8188)的chunk,剩下一塊為0x1ea9(7849),加起來一共73353字節(jié)。
??? 注：對于上面例子中前幾個chunk的大小都是8188,可能是因為:"1ffc" 4字節(jié)，""r"n"2字節(jié)，加上塊尾一個""r"n"2字節(jié)一共8字節(jié)，因此一個chunk整體為8196,正好可能是發(fā)送端一次TCP發(fā)送的緩存大小。

總結

以上是生活随笔為你收集整理的HTTP协议中的Tranfer-Encoding：chunked编码解析的全部內容，希望文章能夠幫你解決所遇到的問題。

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