HTTP 1.1 中Transfer-Encoding chunked編碼 | haohtml’s blog

HTTP 1.1 中Transfer-Encoding chunked編碼 | haohtml's blog

    HTTP 1.1 中Transfer-Encoding chunked編碼
    Posted on 2010/07/24 by admin   

    大多數的網站相應使用者請求時發送的HTTP Headers中包含Content-Length頭.此頭資訊定義在HTTP1.0協議RFC 1945 10.4章節中.該資訊是用來告知使用者代理程式,通常意義上就是瀏覽器,服務端發送的文檔內容長度.瀏覽器接受到此資訊後,接收完Content-Length中定義的長度位元組後開始解析頁面.如果服務端有部分資料延遲發送,那麼瀏覽器就會白屏.這樣導致比較糟糕的使用者體驗.

    解決方案在HTTP1.1協議.RFC2616中14.41章節中定義的Transfer-Encoding:chunked的頭資訊.chunked編碼定義在3.6.1中.根據此定義瀏覽器不需要等到內容位元組全部下載完成,只要接收到一個chunked塊就可解析頁面.並且可以下載html中定義的頁面內容,包括js,css,image等.採用chunked編碼有兩種選擇,一種是設定Server的IO buffer長度讓Server自動flush buffer中的內容，另一種是手動調用IO中的flush函數。不同的語言IO中都有flush功能:

        php:    ob_flush(); flush();
        perl:   STDOUT->autoflush(1);
        java:  out.flush();
        python:  sys.stdout.flush()
        ruby:  stdout.flush

    從下面兩張圖中可以看出採用HTTP1.1的Transfer-Encoding:chunked,並且把IO的buffer flush下來,以便瀏覽器更早的下載頁面配套資源.

    ==============================================
    正如上篇日誌所述，當不能預先確定報文體的長度時，不可能在頭中包含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的長度（位元組數）。這個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位元組。
    註：對於上面例子中前幾個chunk的大小都是8188,可能是因為:"1ffc" 4位元組，"\r\n"2位元組，加上塊尾一個"\r\n"2位元組一共8位元組，因此一個chunk整體為8196,正好可能是發送端一次TCP發送的緩衝大小。

    正如上篇日誌所述，當不能預先確定報文體的長度時，不可能在頭中包含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的長度（位元組數）。這個16進位的字串第一個字元如果是“0”，則表示chunk-size為0，該chunk為last-chunk,無chunk-data部分。可選的chunk-extension由通訊雙方自行確定，如果接收者不理解它的意義，可以忽略。    trailer是附加的在尾部的額外頭域，通常包含一些中繼資料（metadata, meta means "about information"），這些頭域可以在解碼後附加在現有頭域之後。    執行個體分析：    下面分析用ethereal抓包使用Firefox與某網站通訊的結果（從頭域結束符後開始）：Address  0..........................  f000c0                                31000d0    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 31100f0    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位元組。    註：對於上面例子中前幾個chunk的大小都是8188,可能是因為:"1ffc" 4位元組，"\r\n"2位元組，加上塊尾一個"\r\n"2位元組一共8位元組，因此一個chunk整體為8196,正好可能是發送端一次TCP發送的緩衝大小。