參考鏈接:

HTTP?協(xié)議中的?Transfer-Encoding

分塊傳輸編碼

一、背景:

? ? 1.持續(xù)連接的問題:對于非持續(xù)連接，瀏覽器可以通過連接時否關(guān)閉來界定請求或響應(yīng)實體的邊界;而對于持續(xù)連接，這種方法顯然不奏效。有時，盡管我已經(jīng)發(fā)送完所有數(shù)據(jù)，但瀏覽器并不知道這一點，它無法得知這個打開的連接上是否還會有新數(shù)據(jù)進(jìn)來，只能傻傻地等了。

? ? 2.用Content-Length解決:計算實體長度，并通過頭部告訴對方。瀏覽器可以通過Content-Length的長度信息，判斷出響應(yīng)實體已結(jié)束。

? ? 3.Content-Length引入的新問題:由于Content-Length字段必須真實反映實體長度，但是對于動態(tài)生成的內(nèi)容來說，在內(nèi)容創(chuàng)建完之前，長度是不可知的。這時候要想準(zhǔn)確獲取長度，只能開一個足夠大的buffer，等內(nèi)容全部生成號再計算。但這樣做一方面需要更大的內(nèi)存開銷，另一方面也會讓客戶端等更久。

? ? 4.我們需要一個新的機制:不依賴頭部的長度信息，也能知道實體的邊界----分塊編碼(Transfer-Encoding:chunked)

二、分塊編碼(Transfer-Encoding:chunked)

? ? 1.Transfer-Encoding,是一個HTTP頭部字段(響應(yīng)頭域),字面意思是[傳輸編碼]。最新的HTTP規(guī)范里，只定義了一種編碼傳輸:分塊編碼(chunked)。

? ? 2.分塊傳輸編碼(Chunked transfer encoding)是超文本傳輸協(xié)議(HTTP)中的一種數(shù)據(jù)傳輸機制，允許HTTP由網(wǎng)頁服務(wù)器發(fā)送給客戶端的數(shù)據(jù)可以分成多個部分。分塊傳輸編碼只在HTTP協(xié)議1.1版本(HTTP/1.1)中提供。

? ? 3.數(shù)據(jù)分解成一系列數(shù)據(jù)塊，并以一個或多個塊發(fā)送，這樣服務(wù)器可以發(fā)送數(shù)據(jù)而不需要預(yù)先知道發(fā)送內(nèi)容的總大小。

? ? 4.具體方法

? ? ? ? 1).在頭部加入Transfer-Encoding:chunked之后，就代表這個報文采用了分塊編碼。這時，報文中的實體需要改為用一系列分塊來傳輸。

? ? ? ? 2).每個分塊包含十六進(jìn)制的長度值和數(shù)據(jù)，長度值獨占一行，長度不包括它結(jié)尾的CRLF(\r\n),也不包括分塊數(shù)據(jù)結(jié)尾的CRLF。

? ? ? ? 3).最后一個分塊長度值必須為0，對應(yīng)的分塊數(shù)據(jù)沒有內(nèi)容，表示實體結(jié)束。

? ? 5.例子:

? ? ? ??

HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked25\r\n This is the data in the first chunk\r\n1C\r\n and this is the second one\r\n3\r\n con\r\n8\r\n sequence\r\n\0\r\n \r\n

6.Content-Encoding和Transfer-Encoding二者經(jīng)常會結(jié)合來用，其實就是針對Transfer-Encoding的分塊在進(jìn)行Content-Encoding壓縮。

?

總結(jié)

以上是生活随笔為你收集整理的分块编码(Transfer-Encoding:chunked)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。