業(yè)務(wù)專線：15989169178
HTTP/3 就在這里，它對 Web 性能來說意義重大?？纯此茏尵W(wǎng)站速度變多快吧！
等等，等等，HTTP/2 發(fā)生了什么？這不是幾年前還挺火的嗎？
確實(shí)是這樣，但是出現(xiàn)了一些問題。為了解決這些問題，這個(gè)古老的協(xié)議的改進(jìn)版本正在標(biāo)準(zhǔn)軌道上運(yùn)行。
HTTP 3 正式標(biāo)準(zhǔn)化
2022年6月7日，IETF QUIC和HTTP工作組成員Robin Mars 在Twitter上宣布，歷時(shí)5年，HTTP/3終于被標(biāo)準(zhǔn)化為 RFC 9114，這是HTTP超文本傳輸協(xié)議的第三個(gè)主要版本。
與此同時(shí)， HTTP/2 也被更新為新的 RFC 9113。
Robin寫道，新發(fā)布的HTTP/3標(biāo)準(zhǔn)將與RFC 9204（QPACK header壓縮） 和 RFC 9218（可擴(kuò)展的優(yōu)先級）一起為Web打開重要的新一頁。
并且，cURL作者Danniel已經(jīng)將HTTP/3 設(shè)置為缺省狀態(tài)。
但是 HTTP/3 真的讓事情變更快了嗎？來看一下基準(zhǔn)測試。
基準(zhǔn)測試
先看一下基準(zhǔn)測試結(jié)果的快速預(yù)覽。
在下面的圖中，同一個(gè)瀏覽器被用來通過同一個(gè)網(wǎng)絡(luò)請求同一個(gè)站點(diǎn)，只改變正在使用的 HTTP 協(xié)議。每個(gè)站點(diǎn)被檢索 20 次，響應(yīng)時(shí)間通過性能 API 測量。
可以清楚地看到使用 HTTP 協(xié)議的每個(gè)新版本時(shí)的性能改進(jìn)：
當(dāng)在更大的地理距離和不太可靠的網(wǎng)絡(luò)上請求資源時(shí)，這些變化變得更加明顯。
在完全了解所有 HTTP/3 基準(zhǔn)測試細(xì)節(jié)之前，需要一點(diǎn)上下文。
HTTP 簡史
HTTP（超文本傳輸協(xié)議 1.0）的第一個(gè)正式版本于 1996 年完成。由于存在一些實(shí)際問題和部分標(biāo)準(zhǔn)需要更新，因此HTTP/1.1于一年后的 1997 年發(fā)布。根據(jù)作者的說法：
然而，HTTP/1.0 沒有充分考慮分層代理、緩存、持久連接的需求和虛擬主機(jī)的影響。此外，自稱為“HTTP/1.0”的未完全實(shí)現(xiàn)的應(yīng)用程序激增，需要更改協(xié)議版本，以便兩個(gè)通信應(yīng)用程序確定彼此的真實(shí)能力。
新版本的 HTTP 發(fā)布等了 18 年。2015 年， RFC 7540開始大肆宣傳，將 HTTP/2 標(biāo)準(zhǔn)化為該協(xié)議的下一個(gè)主要版本。
一次一個(gè)文件
如果一個(gè)網(wǎng)頁需要 10 個(gè) javascript 文件，瀏覽器需要在頁面完成加載之前檢索這 10 個(gè)文件。在 HTTP/1.1-land 中，Web 瀏覽器一次只能通過與服務(wù)器的 TCP 連接下載一個(gè)文件。這意味著文件是按順序下載的，一個(gè)文件中的任何延遲都會(huì)阻止它后面的所有其他內(nèi)容。這稱為行頭阻塞，對性能不利。
為了解決這個(gè)問題，瀏覽器可以打開到服務(wù)器的多個(gè) TCP 連接以并行化數(shù)據(jù)檢索。但這種方法是資源密集型的。每個(gè)新的 TCP 連接都需要客戶端和服務(wù)器資源，當(dāng)您在混合中添加 TLS 時(shí)，也會(huì)發(fā)生大量 SSL 協(xié)商。這需要一種更好的方法。
與 HTTP/2 多路復(fù)用
HTTP/2 的一大賣點(diǎn)是多路復(fù)用。它通過切換到允許多路復(fù)用文件下載的二進(jìn)制在線格式修復(fù)了應(yīng)用程序級別的線頭阻塞問題。也就是說，客戶端可以一次請求所有 10 個(gè)文件，并開始通過單個(gè) TCP 連接并行下載它們。
不幸的是，HTTP/2 仍然存在線頭阻塞問題，只是低了一層。TCP 本身成為鏈條中的薄弱環(huán)節(jié)。任何丟失數(shù)據(jù)包的數(shù)據(jù)流都必須等到該數(shù)據(jù)包被重新傳輸才能繼續(xù)。
但是，由于 HTTP/2 多路復(fù)用的并行特性對 TCP 的丟失恢復(fù)機(jī)制不可見，因此丟失或重新排序的數(shù)據(jù)包會(huì)導(dǎo)致所有活動(dòng)事務(wù)都經(jīng)歷停頓，無論該事務(wù)是否直接受到丟失數(shù)據(jù)包的影響。
事實(shí)上，在丟包率高的環(huán)境中，反而是 HTTP/1.1 性能更好，因?yàn)闉g覽器打開了多個(gè)并行 TCP 連接。
使用 HTTP/3 和 QUIC 實(shí)現(xiàn)真正的多路復(fù)用
HTTP/2 和 HTTP/3 之間的主要區(qū)別在于它們使用的傳輸協(xié)議。HTTP/3 使用一種稱為QUIC的新協(xié)議來代替 TCP 。
QUIC 是一種通用傳輸協(xié)議，旨在解決 HTTP/2 與 TCP 的線頭阻塞問題。它允許您通過 UDP 創(chuàng)建一系列有狀態(tài)的流（類似于 TCP）。
QUIC 傳輸協(xié)議結(jié)合了流多路復(fù)用和每個(gè)流的流控制，類似于 HTTP/2 提供的成幀層。通過提供流級別的可靠性和整個(gè)連接的擁塞控制，與 TCP 映射相比，QUIC 能夠有效提高 HTTP 的性能。
為什么 HTTP/3 這么快？
真正的多路復(fù)用
HTTP/3 真正的多路復(fù)用特性意味著堆棧上的任何地方都不會(huì)發(fā)生線頭阻塞。當(dāng)從更遠(yuǎn)的地方請求資源時(shí)，在地理上，丟包的可能性要高得多，并且 TCP 需要重新傳輸這些數(shù)據(jù)包。
0-RTT 改變游戲規(guī)則
此外，HTTP/3 支持O-RTT QUIC 連接，這減少了與服務(wù)器建立安全 TLS 連接所需的往返次數(shù)。
QUIC 中的 0-RTT 功能允許客戶端在握手完成之前發(fā)送應(yīng)用程序數(shù)據(jù)。這可以通過重用來自先前連接的協(xié)商參數(shù)來實(shí)現(xiàn)。為了實(shí)現(xiàn)這一點(diǎn)，0-RTT 依賴于客戶端記住關(guān)鍵參數(shù)并向服務(wù)器提供允許服務(wù)器恢復(fù)相同信息的 TLS 會(huì)話票證。
但是不應(yīng)盲目啟用 0-RTT。根據(jù)你的威脅模型而定，否則可能存在安全問題。
0-RTT 數(shù)據(jù)的安全屬性弱于其他類型的 TLS 數(shù)據(jù)。具體來說：
此數(shù)據(jù)不是前向機(jī)密，因?yàn)樗鼉H在使用提供的 PSK 派生的密鑰下加密。
不保證連接之間不重放。
今天可以使用 HTTP/3 嗎？
目前該協(xié)議目前處于標(biāo)準(zhǔn)化狀態(tài)，也已經(jīng)有很多現(xiàn)有的實(shí)現(xiàn)。
NGINX 也有實(shí)驗(yàn)性支持，并正在努力在不久的將來發(fā)布官方 HTTP/3 版本。像 Google 和 Facebook 這樣的大型科技公司已經(jīng)通過 HTTP/3 為他們的流量提供服務(wù)。Google已經(jīng)完全通過 HTTP/3 為現(xiàn)代瀏覽器提供服務(wù)。
對于那些在 Windows 生態(tài)系統(tǒng)中的人來說，據(jù)說 Windows Server 2022 將支持 HTTP/3，但需要一些步驟才能啟用它。
結(jié)論
HTTP/3 可以對網(wǎng)站的用戶體驗(yàn)方式產(chǎn)生重大影響。
一般來說，站點(diǎn)需要的資源越多，你會(huì)看到 HTTP/3 和 QUIC 的性能提升就越大。隨著HTTP/3標(biāo)準(zhǔn)最終確定，是時(shí)候開始考慮為你的網(wǎng)站啟用它了。
