正如上篇日志所述，當(dāng)不能預(yù)先確定報(bào)文體的長(zhǎng)度時(shí)，不可能在頭中包含Content-Length域來指明報(bào)文體長(zhǎng)度，此時(shí)就需要通過Transfer-Encoding域來確定報(bào)文體長(zhǎng)度。
    通常情況下，Transfer-Encoding域的值應(yīng)當(dāng)為chunked,表明采用chunked編碼方式來進(jìn)行報(bào)文體的傳輸。chunked編碼是HTTP/1.1 RFC里定義的一種編碼方式，因此所有的HTTP/1.1應(yīng)用都應(yīng)當(dāng)支持此方式。
    chunked編碼的基本方法是將大塊數(shù)據(jù)分解成多塊小數(shù)據(jù)，每塊都可以自指定長(zhǎng)度，其具體格式如下（BNF文法）:
    Chunked-Body   = *chunk            //0至多個(gè)chunk
                     last-chunk         //最后一個(gè)chunk
                     trailer            //尾部
                     CRLF               //結(jié)束標(biāo)記符

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