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