我們在去年Cloudflare 生日那天支持HTTP/3，它是HTTP/2的后繼產(chǎn)品。我們的目標(biāo)一直是幫助大家建立更好的Internet。在標(biāo)準(zhǔn)上進行協(xié)作是其中很大的一部分工作，我們很幸運做到了這一點。

即使HTTP 3仍處于草稿狀態(tài)，我們的用戶對此也有很大興趣。到目前為止，已經(jīng)有超過113,000個區(qū)域激活了HTTP/3，如果您使用的是實驗性瀏覽器，則可以使用新協(xié)議?？吹饺绱硕嗟娜藛⒂肏TTP/3真是太棒了：通過HTTP /3訪問真實的網(wǎng)站意味著瀏覽器具有更多可測試的屬性。

[[323307]]

當(dāng)我們和Google合作啟動對HTTP / 3的支持時，后者同時在Chrome中啟動了HTTP/3實驗特性。從那時起，我們看到更多的瀏覽器增加了實驗性的支持：Firefox在其nightly版本中支持，其他基于Chromium的瀏覽器(例如Opera和Microsoft Edge)以及Safari 。我們會密切關(guān)注其發(fā)展，并在我們盡可能幫助合作伙伴;許多站點支持且啟用了HTTP / 3也為瀏覽器實現(xiàn)者提供了一個出色的測試平臺。

現(xiàn)狀如何

IETF標(biāo)準(zhǔn)化過程將協(xié)議開發(fā)為一系列文檔草稿版本，其最終目的是生成RFC。QUIC工作組的成員在分析，實施和互操作規(guī)范方面進行協(xié)作，以發(fā)現(xiàn)不合適的特性。在我們啟動時，我們支持HTTP / 3草案23，此后又跟上了每個新草案，在撰寫本文時支持到草案27。在每一份草案中，小組都提高了QUIC定義的質(zhì)量，并更接近于關(guān)于其行為方式的“粗略共識”。為了避免永久性的分析癱瘓和無休止的調(diào)整，每一個新的草案都提高了對規(guī)范提出修改的門檻。這意味著版本之間的更改較小，并且我們在生產(chǎn)環(huán)境中運行的協(xié)議和最終的RFC差異更小。

好處

HTTP / 3的主要優(yōu)點是提高了性能，特別是在同時獲取多個對象時的性能。使用HTTP / 2，TCP連接中的任何中斷(數(shù)據(jù)包丟失)都會阻塞所有流(行頭阻塞)。因為HTTP / 3是基于UDP的，所以如果丟棄數(shù)據(jù)包，只會中斷一個流，而不會中斷所有流。

此外，HTTP / 3提供了0-RTT支持，這意味著通過在建立連接時消除服務(wù)器的TLS確認(rèn)，可以使后續(xù)連接的啟動速度更快。也意味著客戶端可以在完成TLS協(xié)商前請求數(shù)據(jù)，也就是說網(wǎng)站加載會提前。

下面說明了數(shù)據(jù)包丟失及其影響：HTTP / 2多路復(fù)用兩個請求。一個請求通過HTTP / 2從客戶端發(fā)送到服務(wù)器，請求兩個資源(我們將請求及其相關(guān)的響應(yīng)涂成綠色和黃色)。響應(yīng)被分解為多個數(shù)據(jù)包，一旦一個數(shù)據(jù)包丟失了，兩個請求都被阻止。

上圖展示了HTTP / 3復(fù)用2個請求。雖然黃色的數(shù)據(jù)包丟失了，但是綠色的數(shù)據(jù)包傳輸?shù)煤芎谩?/p>

會話啟動的改進意味著與服務(wù)器的“連接”啟動更快，因此瀏覽器開始更快地查看數(shù)據(jù)。我們很想知道改進有多大，所以進行了一些測試。為了衡量0-RTT帶來的改進，我們運行了一些基準(zhǔn)測試來測量首字節(jié)到達時間(TTFB)。平均而言，使用HTTP / 3，我們看到第一個字節(jié)出現(xiàn)在176ms之后。使用HTTP / 2，對應(yīng)的時間是201ms，這意味著HTTP / 3的性能提高了12.4%!

有趣的是，協(xié)議的每個方面均不受草案或RFC的約束。實現(xiàn)方式的選擇會會影響性能，例如有效的數(shù)據(jù)包傳輸和擁塞控制算法的選擇。擁塞控制是計算機和服務(wù)器用來適應(yīng)過載網(wǎng)絡(luò)的一種技術(shù)：通過丟棄數(shù)據(jù)包，隨后的傳輸受到限制。由于QUIC是一種新協(xié)議，因此正確進行擁塞控制需要進行實驗和調(diào)整。

“丟失檢測和擁塞控制”規(guī)范建議使用Reno算法，但允許選擇任何算法。我們的實現(xiàn)從New Reno算法開始，通過以往經(jīng)驗我們知道可以通過其他方式獲得更好的性能。我們最近已遷移到CUBIC算法，在我們的網(wǎng)絡(luò)中，CUBIC的傳輸和數(shù)據(jù)包丟失都比New Reno有所改善。

對于我們現(xiàn)有的HTTP / 2堆棧，我們目前支持BBR v1(TCP)。這意味著在我們的測試中，我們無法進行精確的比較，因為這些擁塞控制算法在較小內(nèi)容傳輸與較大內(nèi)容傳輸之間的行為會有所不同。話雖這么說，與HTTP/2相比，我們已經(jīng)看到使用HTTP/3的較小內(nèi)容傳輸?shù)乃俣雀?。對于較大內(nèi)容的傳輸，改進后的HTTP / 2堆棧的擁塞控制在性能上大放異彩。

對于15KB的小型測試網(wǎng)頁，HTTP / 3平均需要443ms加載，而HTTP / 2則為458ms。但是，一旦我們將頁面大小增加到1MB，優(yōu)勢就會消失：HTTP / 3僅比當(dāng)今網(wǎng)絡(luò)上的HTTP / 2慢一點，HTTP/3加載使用2.33秒而HTTP/2加載使用2.30秒。

基準(zhǔn)測試很有意思，然而我們想知道HTTP / 3在現(xiàn)實世界中的表現(xiàn)。

為了進行衡量，我們希望有一個第三方可以像瀏覽器一樣加載網(wǎng)站。WebPageTest是一個通用框架，使用瀑布圖來測量頁面加載時間。為了分析后端，我們使用了Browser Insights來捕獲邊緣節(jié)點記錄的時間。然后，我們將這兩部分?jǐn)?shù)據(jù)結(jié)合在一起。

作為測試用例，我們決定對公司博客進行性能監(jiān)控。我們在全球范圍配置了WebPageTest實例，同時通過HTTP / 2和HTTP / 3加載該頁面。我們還啟用了HTTP / 3和Browser Insight。因此，每當(dāng)我們的測試腳本使用支持HTTP / 3的瀏覽器啟動網(wǎng)頁加載網(wǎng)頁時，瀏覽器分析就會報告數(shù)據(jù)。清理數(shù)據(jù)并重復(fù)HTTP / 2的測試以進行比較。

下圖顯示了真實頁面(blog.cloudflare.com)的頁面加載時間，以比較HTTP / 3和HTTP / 2的性能。另外我們從不同的地理位置進行了性能評估。

如圖所示，在北美，HTTP / 3的性能仍落后于HTTP / 2的性能，落后的平均水平約為1-4%，在歐洲，亞洲和南美也看到了類似的結(jié)論。我們懷疑這可能是由于擁塞算法不同所致：BBR v1上的HTTP / 2與CUBIC上的HTTP / 3不同。將來，我們將努力在兩者上支持相同的擁塞算法，以實現(xiàn)更準(zhǔn)確的性能對比。

結(jié)論

總體而言，我們很高興推動這一標(biāo)準(zhǔn)的發(fā)展。我們的實現(xiàn)效果很好，在某些情況下提供了更好的性能，并且在最壞的情況下性能也和HTTP / 2接近。隨著標(biāo)準(zhǔn)的定稿，我們期待看到瀏覽器在主流版本中增加對HTTP / 3的支持。對于我們而言，我們將繼續(xù)支持最新的草案，同時尋找更多的方法來使HTTP / 3獲得更好的性能，無論是擁塞調(diào)整，優(yōu)先級劃分還是系統(tǒng)容量(CPU和原始網(wǎng)絡(luò)吞吐量)。

如果您想嘗試一下，只需在我們的儀表板上啟用HTTP / 3并使用支持的該特性的瀏覽器。有關(guān)如何啟用HTTP / 3的說明，請參見我們的開發(fā)人員文檔。

原文地址：

https://blog.cloudflare.com/http-3-vs-http-2/