在網(wǎng)絡(luò)的早期時(shí)期，人們發(fā)送的文件大小僅為幾KB。到了2023年，我們享受著高分辨率的MB級(jí)別圖像，并在幾GB的4K（即將是8K）視頻中觀看。

即使有良好的互聯(lián)網(wǎng)連接，下載一個(gè)5GB的文件仍然需要一些時(shí)間。如果你擁有Xbox或PlayStation，你就知道這種感覺。

我們有三種方法可以通過HTTP縮短發(fā)送大量數(shù)據(jù)的時(shí)間：

•壓縮數(shù)據(jù)•發(fā)送分塊數(shù)據(jù)•請(qǐng)求選擇范圍內(nèi)的數(shù)據(jù)

它們并不是互斥的。你可以根據(jù)用例一起使用所有方法。

壓縮數(shù)據(jù)

要壓縮數(shù)據(jù)，我們需要壓縮算法。

在發(fā)送請(qǐng)求時(shí)，瀏覽器會(huì)包含一個(gè)名為Accept-Encoding的頭，其中包含支持的壓縮算法列表，包括gzip（GZIP）、compress、deflate和br（Brotli）。

接下來，服務(wù)器從列表中選擇其支持的算法，并在Content-Encoding頭中設(shè)置算法名稱。

當(dāng)瀏覽器接收到響應(yīng)時(shí)，它知道如何解析正文中的數(shù)據(jù)。

在這些算法中，最流行的是GZIP。它是壓縮文本數(shù)據(jù)（如HTML、CSS和Javascript）的絕佳選擇。

Brotli是另一個(gè)值得一提的算法。它在壓縮HTML方面的性能甚至比GZIP更好。

這些高效的算法有一些限制。

它們對(duì)文本的壓縮效果很好，但對(duì)于壓縮圖像或視頻來說則不足夠。畢竟，媒體已經(jīng)過了優(yōu)化。

試著在你的計(jì)算機(jī)上壓縮一個(gè)視頻文件。在壓縮之前和之后，你幾乎看不到太大的區(qū)別。

此外，幾乎不可能將一個(gè)5GB的視頻壓縮到幾KB而不損失質(zhì)量。

壓縮是好的，但我們需要一個(gè)更好的解決方案——將文件分塊發(fā)送并在客戶端組裝部分?jǐn)?shù)據(jù)。

發(fā)送分塊數(shù)據(jù)

在版本1.1中，HTTP引入了分塊數(shù)據(jù)以處理大數(shù)據(jù)情況。

在發(fā)送響應(yīng)時(shí)，服務(wù)器添加一個(gè)頭Transfer-Encoding: chunked，讓瀏覽器知道數(shù)據(jù)是分塊傳輸?shù)摹?/p>

每個(gè)分塊數(shù)據(jù)都有以下組件：

•一個(gè)長度塊標(biāo)記，標(biāo)記當(dāng)前分塊數(shù)據(jù)的長度•分塊數(shù)據(jù)塊•在每個(gè)塊的末尾的CRLF分隔符

想知道CRLF是什么嗎？

CR緊接著LF（CRLF，\r\n，或0x0D0A）將光標(biāo)移動(dòng)到下一行，然后移到行的開頭。 在本文末尾的進(jìn)一步閱讀部分，你可以找到更多詳細(xì)信息。在這里，你可以簡單地將其視為一個(gè)分隔符。

服務(wù)器繼續(xù)向?yàn)g覽器流式傳輸分塊數(shù)據(jù)。當(dāng)達(dá)到數(shù)據(jù)流的末尾時(shí)，它附加一個(gè)包含以下部分的結(jié)束標(biāo)記：

•一個(gè)長度塊，數(shù)字為0，末尾為CRLF•一個(gè)額外的CRLF

在瀏覽器端，它等待所有數(shù)據(jù)塊，直到達(dá)到結(jié)束標(biāo)記。然后，它移除分塊編碼，包括CRLF和長度信息。

接下來，它將分塊數(shù)據(jù)組合成一個(gè)整體。因此，在Chrome DevTools上，你只能看到組裝后的數(shù)據(jù)，而不是分塊數(shù)據(jù)。

最終，你會(huì)收到整個(gè)數(shù)據(jù)的一塊。

分塊數(shù)據(jù)是有用的。然而，對(duì)于一個(gè)5GB的視頻，完整的數(shù)據(jù)仍然需要一些時(shí)間才能到達(dá)。

我們能不能獲取數(shù)據(jù)的選定塊，并在需要時(shí)請(qǐng)求其他塊呢？

HTTP說可以。

在選定范圍內(nèi)請(qǐng)求數(shù)據(jù)

在YouTube上打開一個(gè)視頻，你會(huì)看到一個(gè)灰色的進(jìn)度條正在向前移動(dòng)。

你剛剛看到的是YouTube在請(qǐng)求選定范圍內(nèi)的數(shù)據(jù)。

此功能使你可以在時(shí)間軸的任何地方跳躍。當(dāng)點(diǎn)擊進(jìn)度條上的某個(gè)位置時(shí)，瀏覽器會(huì)請(qǐng)求視頻數(shù)據(jù)的特定范圍。

在服務(wù)器上實(shí)現(xiàn)范圍請(qǐng)求是可選的。如果實(shí)現(xiàn)了，你可以在響應(yīng)頭中看到Accept-Ranges: bytes。

這是一個(gè)YouTube請(qǐng)求的示例。在任何“playback”請(qǐng)求中，你都可以找到這個(gè)頭。

范圍請(qǐng)求頭看起來像`Range:

bytes=0-80`，它是從0開始的索引。

這個(gè)頭是一個(gè)設(shè)計(jì)非常巧妙且具有出色靈活性的頭。

假設(shè)一個(gè)數(shù)據(jù)總共有100個(gè)字節(jié)。

•Range: bytes=20請(qǐng)求從20開始到末尾的范圍，等于Range: bytes=20-99。•Range: bytes=-20請(qǐng)求數(shù)據(jù)的最后20個(gè)字節(jié)，等于Range: bytes=80-99。

如果請(qǐng)求的范圍有效，服務(wù)器將發(fā)送帶有Content-Range頭的響應(yīng)，驗(yàn)證數(shù)據(jù)范圍和總長度，例如Content-Range: bytes 70-80/100。

范圍請(qǐng)求廣泛用于視頻流媒體和文件下載服務(wù)。

你有沒有在互聯(lián)網(wǎng)中斷后繼續(xù)文件下載？那就是范圍請(qǐng)求。

此外，范圍請(qǐng)求支持多個(gè)范圍。

例如，你可以從文件中請(qǐng)求兩個(gè)范圍，如Range: bytes=20-45, 70-80。

多范圍體看起來類似于分塊數(shù)據(jù)。每個(gè)數(shù)據(jù)塊都有以下部分：

•一個(gè)邊界塊，標(biāo)識(shí)不同數(shù)據(jù)塊的邊界，以--開始，以CRLF結(jié)束•兩個(gè)頭，Content-Type和Content-Range，顯示相應(yīng)數(shù)據(jù)塊的屬性，以CRLF結(jié)束•一個(gè)額外的CRLF，告訴客戶端真正的數(shù)據(jù)即將到來•最后，以CRLF結(jié)束的數(shù)據(jù)塊

邊界僅僅是一個(gè)看起來像3d6b6a416f9b5的隨機(jī)字符串，標(biāo)記不同數(shù)據(jù)塊的邊界。

最終，體結(jié)束于邊界塊，以--開始，以--和CRLF結(jié)束。這個(gè)部分告訴瀏覽器多部分已經(jīng)結(jié)束。

讓我們把它全部整合起來。響應(yīng)體的結(jié)構(gòu)如下所示。

總結(jié)

HTTP幫助我們通過壓縮、分塊數(shù)據(jù)和范圍數(shù)據(jù)傳送大量數(shù)據(jù)。

這里的思想是在需要的時(shí)候傳送我們需要的數(shù)據(jù)，然后在需要時(shí)發(fā)送其他數(shù)據(jù)。當(dāng)在設(shè)計(jì)類似系統(tǒng)時(shí)遇到問題時(shí)，你可以嘗試相同的思路。

通過結(jié)合這三種方法，我們可以發(fā)送壓縮的分塊數(shù)據(jù)范圍數(shù)據(jù)。