業(yè)務(wù)專線：15989169178
超文本傳輸協(xié)議的第三個主版本，即HTTP/3，上個月被正式采納為IETF 標(biāo)準(zhǔn)（互聯(lián)網(wǎng)工程任務(wù)組）。
HTTP/3 是超文本傳輸協(xié)議 (HTTP) 的第三個版本，以前稱為 HTTP-over-QUIC。 QUIC 最初由 Google 開發(fā)，是 HTTP/2 的繼承者。Google 和 Facebook 等已經(jīng)使用 QUIC 來加速網(wǎng)絡(luò)。
HTTP 簡史
對于游戲開發(fā)者來說，重要的協(xié)議是UDP（用戶數(shù)據(jù)報協(xié)議）。UDP是快速、即發(fā)即棄的標(biāo)準(zhǔn)：你在網(wǎng)絡(luò)上扔了一個數(shù)據(jù)包，它就被抓住或者有時被丟掉了。
像Web這樣要求穩(wěn)定的系統(tǒng)，正確使用的底層協(xié)議是TCP（傳輸控制協(xié)議）。這是一個更正式的系統(tǒng)，它保證了數(shù)據(jù)包的交付與正確順序。TCP 創(chuàng)建了可靠連接，后來又創(chuàng)建了可靠的信息流。
隨后，它們被正式命名為“TCP/IP 堆棧”。
后來，基于 TCP/IP 編寫的WWW和 HTTP 成為互聯(lián)網(wǎng)的主要用途。另一個缺失的首字母縮略詞是TLS（傳輸層安全），它提供了加密相關(guān)元素，并成為事實上的安全標(biāo)準(zhǔn)。
而在那個年代里， PC 之間的連接通常是有線的，任何損失都是由于舊銅線上的噪音造成的。
TCP 協(xié)議非常適合收集偶爾出錯的數(shù)據(jù)包，而隨著Web的發(fā)展使用 UDP 協(xié)議逐漸減少。
進入QUIC
今天的互聯(lián)網(wǎng)已經(jīng)進入一個發(fā)展非常不同的場景了。
比如現(xiàn)在家中的 PC 都有良好的光纖連接和線路，大多數(shù)用戶通過手機或筆記本電腦體驗互聯(lián)網(wǎng)。
舉個例子，當(dāng)你從一根桅桿移動到另一根桅桿時，遇到阻擋或反彈信號的墻后，網(wǎng)絡(luò)連接通常會被切斷并重新啟動。這種情況并不是 TCP 所喜歡的——如果沒有正式的介紹和良好的握手，它就不想進行通信。事實上，TCP 對最后一個散數(shù)據(jù)包的嚴(yán)格記賬和等待，意味著用戶必須等待網(wǎng)頁加載和新應(yīng)用程序下載，或者超時時再重新建立連接。
為了利用好 UDP 的非連接正式性，并讓網(wǎng)絡(luò)在運行中使用一些智能的東西，新的QUIC（快速 UDP 互聯(lián)網(wǎng)連接）格式得到了更多人們的關(guān)注。
雖然人們不希望在網(wǎng)絡(luò)本身中看到太多智能屬性，但如今我們對自動決策感到更加自在。QUIC 協(xié)議會知道一個網(wǎng)站是由多個文件組成的，它不會因為一個文件沒有完成加載而破壞整個連接。
QUIC 發(fā)展的另一個趨勢是內(nèi)置安全性。而之前加密是可選的（使用 HTTP 或 HTTPS）而 QUIC 協(xié)議將始終是加密的。
經(jīng)過幾年的進化，每個站點都已經(jīng)加密——盡管開銷很大。這不僅僅是為了確保中間人看不到你點的是什么類型的橙汁，它還確認(rèn)你是在與真正的橙汁供應(yīng)商交談。
協(xié)議格式幾乎總是在改進，但它們真正做的是隨著時間的推移解決不同的問題。
主動使用
那么HTTP/3的實施進展如何？這里我們實際上要考慮的有三個方面：瀏覽器、云基礎(chǔ)設(shè)施和用戶程序。
第一個考慮的是瀏覽器。
這是來自“我可以使用”網(wǎng)站上可以支持HTTP/3的表格：
很明顯，谷歌很熱衷此協(xié)議——從Chrome v87（2020 年末）開始的版本就已經(jīng)能夠使用 HTTP/3 協(xié)議。而蘋果最近在瀏覽器開發(fā)方面有點保守，Safari 是落后的。
你現(xiàn)在可以使用以下網(wǎng)站中的任何一個，來檢查自己的瀏覽器是否支持 HTTP/3（可能需要重新啟動）：
cloudflare-quic.com
quic.nginx.org
https://http3.is/
如何測試現(xiàn)有的網(wǎng)站是否支持呢？要測試現(xiàn)有站點，請嘗試如下網(wǎng)址：
https://geekflare.com/tools/http3-test。
一個好消息是，如果你的網(wǎng)站在 HTTP/2 下運行良好，那么它在 HTTP/3 下會更好或更好。
誰在推廣 HTTP/3？
現(xiàn)在，誰在推動 HTTP/3？好吧，你已經(jīng)知道了；它是Google，還有眾多 CDN 廠商。
他們的面包和黃油是網(wǎng)絡(luò)響應(yīng)速度。因此實現(xiàn) HTTP/3 的最簡單方法是通過 CDN，這也是一項讓移動用戶受益更多的變化。
現(xiàn)在也存在使用 QUIC 構(gòu)建的Web服務(wù)器（例如Litespeed），但采用率參差不齊。
許多Web服務(wù)器依賴于第三方庫，因此在這種情況下重用現(xiàn)有的、經(jīng)過驗證的工作的模式會中斷。現(xiàn)有的服務(wù)器，如 Node.js、NGINX 和 Apache，在開始實施新的內(nèi)部結(jié)構(gòu)時，就會失去用戶體驗優(yōu)勢。新的QUIC庫相對未經(jīng)證實，而使用 Web 服務(wù)器的關(guān)鍵在于它是可靠的、經(jīng)過良好測試和維護的。
采用 HTTP/3的編程語言
在正常情況下，我會深入研究一些代碼——雖然我覺得現(xiàn)階段這樣做有點為時過早。有很多項目可能都在變化，因此要深入研究。
| 語言 | 實現(xiàn)庫 |
|---|---|
| Python | aioquic |
| Go | quic-go |
| Rust | quiche (Cloudflare), Quinn, Neqo (Mozilla), s2n-quic (AWS) |
| C and C++ | mvfst (Facebook), MsQuic, (Microsoft), LSQUIC (Litespeed), picoquic, quicly (Fastly) |
| Ruby | :-( |
可以瀏覽一些簡單的最小工作示例（例如，一個簡單的服務(wù)器和客戶端），我們可以識別出幾個級別的任務(wù)。
第一點，連接。這個更高級別的通道最初是在兩個端點之間建立的，先建立連接標(biāo)識符。一旦建立，如果下面的協(xié)議發(fā)生變化（例如，電話切換 Wi-Fi），連接將保持不變，以避免重新開始會話協(xié)商。
然后連接打開攜帶自己的數(shù)據(jù)類型，并且是不會相互干擾的字符流。
下面仍然是數(shù)據(jù)包。每個數(shù)據(jù)包，就像一封地址良好的信件，都有它的連接和加密信息。信封里面是框架，這些代表正在傳輸?shù)膶嶋H數(shù)據(jù)。
正如之前所說，進步實際上只是反映了不斷變化的使用模式。
今天如此重視安全性和速度，因為我們不再將網(wǎng)絡(luò)視為不可靠的魔法——因此可以使用它來管理我們的個人事務(wù)。
HTTP/3 將更有助于解決以上這些問題，而HTTP/3房間里的大象可能是 Web3 和新興的元宇宙世界，也許這些領(lǐng)域的新想法將在未來為 HTTP/4 做出貢獻。
