參考鏈接：?

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

分塊傳輸編碼

?

https://www.cnblogs.com/xuehaoyue/p/6639029.html

? ?

一、背景：?

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

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

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

我們需要一個(gè)新的機(jī)制：不依賴頭部的長度信息，也能知道實(shí)體的邊界——分塊編碼（Transfer-Encoding: chunked）

? ?

二、分塊編碼（Transfer-Encoding: chunked）?

Transfer-Encoding，是一個(gè) HTTP 頭部字段（響應(yīng)頭域），字面意思是「?jìng)鬏斁幋a」。最新的 HTTP 規(guī)范里，只定義了一種編碼傳輸：分塊編碼(chunked)。

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

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

具體方法

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

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

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

例：

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

? ?

25\r\n
This is the data in the first chunk\r\n

? ?

1C\r\n
and this is the second one\r\n

? ?

3\r\n

con\r\n

? ?

8\r\n
sequence\r\n

? ?

0\r\n

\r\n

? ?

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

總結(jié)

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

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