2018年11月，網際網路工程任務組 (IETF) 在曼谷召開會議，通過了新的網際網路草案。HTTP/2的繼承者QUIC傳輸協議已重新命名為HTTP/3。HTTP/3建立在使用者資料包協議 (UDP) 之上，並且已經被谷歌和Facebook等知名網際網路公司使用。如果您使用Chrome並連線到Google服務，那麼您可能已經在使用QUIC。
新版本的HTTP協議受益於裸機、低階UDP協議，並在TCP層定義了許多以前版本的HTTP中的新特性。這提供了一種解決現有網際網路基礎設施內限制的方法。
第一個結果是有希望的，當IETF的Internet草案在2021年8月到期時，我們可以期待HTTP/3被推廣為新的第三代HTTP標準。
2022年HTTP/3進展
有人說，網路行業對更快速度和更低延遲的渴望與谷歌瀏覽器對更多RAM的渴望相匹配。
我們曾經發表了一篇關於HTTP/2的文章，據W3Techs稱，該標準目前已達到45%左右的全球採用率。根據Can I Use，所有現代網路瀏覽器也支援它。然而，我們在這裡，正在寫一篇關於協議的下一個版本HTTP/3的文章。
HTTP/2採用趨勢
在撰寫本文時，HTTP/3是IETF Internet-Draft或ID，這意味著Internet工程任務組（一個國際網際網路標準機構，負責定義推廣商定的網際網路協議標準，如 TCP、IPv6、VoIP、物聯網等。
它是一個開放的機構，它聯合了網路行業並促進了關於網際網路方向的討論。目前，HTTP/3的“網際網路草案”階段是提案被提升到Request-for-Comments（或RFC）級別之前的最後一個階段，出於所有意圖和目的，我們可以考慮官方網際網路協議定義。
儘管HTTP/3還不是官方的Internet協議，但許多公司和專案已經開始將HTTP/3支援新增到他們的產品中。
什麼是HTTP/3 – 通俗地說
HTTP/3是超文字傳輸協議 (HTTP) 的第三個版本，以前稱為HTTP-over-QUIC。QUIC（Quick UDP Internet Connections）最初由Google開發，是HTTP/2的繼承者。谷歌和Facebook等公司已經在使用QUIC來加速網路。
對HTTP/3的Web瀏覽器支援
在Web瀏覽器前端，Chrome v87、Firefox v88和Edge v87都預設啟用了HTTP/3。對於Safari使用者，啟用HTTP/3的選項已新增到Safari Technology Preview v104。但是，Safari的穩定版本目前不支援HTTP/3。
對HTTP/3的庫支援
對於希望利用HTTP/3技術的開發人員，許多流行的庫已經新增了對HTTP/3的支援。由於HTTP/3仍處於Internet草案階段，因此在使用以下庫之一時，您需要確保已調整到最新更新。
HTTP/3的基礎架構支援
在基礎架構方面，Cloudflare在其整個邊緣網路中支援HTTP/3一直處於領先地位。這意味著啟用Cloudflare的站點無需任何額外工作即可利用HTTP/3的安全性和效能增強。
要測試您的站點是否支援HTTP/3，您可以使用Geekflare的HTTP/3測試工具。只需輸入您的域並按“Check HTTP/3”按鈕，該工具就會讓您知道您的網站是否啟用了HTTP/3。
Geekflare HTTP/3測試工具
如果您的站點支援HTTP/3，您應該會看到如下所示的訊息。
支援HTTP/3連線提示資訊
您還可以使用瀏覽器的檢查器來檢查HTTP/3支援。對於本示例，我們將使用支援HTTP/3的最新版本的Google Chrome。
要開啟檢查器，請右鍵單擊頁面並單擊“檢查”並導航到“網路”選項卡。在“協議”列中，您可以看到用於連線的HTTP 協議。 HTTP/2連線顯示為“h2”，而HTTP/3連線顯示為“h3-XX”（XX 指的是特定的HTTP/3草案）。如下圖所示，kinstalife.com支援通過“h3-29”進行連線，即“HTTP/3 Draft 29”。
Chrome支援h3-29協議
現在我們已經瞭解了HTTP/3的當前狀態，讓我們深入瞭解HTTP/2與HTTP/3之間的一些差異！
一點背景知識——從HTTP/2開始
HTTP/2在非阻塞下載、流水線和伺服器推送方面帶來了一些重大改進，幫助我們克服了底層TCP協議的一些限制。它使我們能夠最大限度地減少請求-響應週期和握手的次數。
HTTP/2使得在單個TCP連線中推送多個資源成為可能——多路複用。我們在靜態下載的順序上也獲得了更大的靈活性，我們的頁面現在不再受到下載線性進展的限制。
HTTP/2推送
實際上，這意味著現在一個大型javascript資源不一定等於所有其他等待輪到它們的靜態資源的阻塞點。
無流水線與流水線（圖片來源：維基百科，作者Mwhitlock）
再加上HTTP/2的標頭HPACK壓縮和資料傳輸的預設二進位制格式，在許多情況下，我們擁有一個明顯更高效的協議。
HTTP/2 HPACK壓縮
主要的瀏覽器實現要求網站實現加密 – SSL – 才能獲得HTTP/2的好處 – 有時這會產生計算開銷，導致速度提升不明顯。甚至在某些情況下，使用者在過渡到HTTP/2後報告速度變慢。
讓我們說，採用此版本的早期並不是為了弱者。
Nginx實現也缺少server-push特性，依賴於一個模組。而Nginx的模組是不是你平時的Apache插入式模組，你可以複製- Nginx已經將這些重新編譯。
雖然其中一些問題現在已經解決，但如果我們檢視整個協議棧，我們會發現主要約束位於比HTTP/2敢於冒險的更低階別。
為了詳細說明這一點，我們將從底層到頂層剖析當今的網際網路協議棧。如果您想了解更多關於HTTP/2的背景知識，請務必檢視我們的終極HTTP/2指南。
網際網路協議 (IP)
網際網路協議 (IP) 定義了整個網際網路拓撲的底部。它是網際網路堆疊的一部分，我們可以肯定地說，如果不改變一切，包括更換整個硬體基礎設施，從路由器到伺服器，甚至是終端使用者的機器，它確實是不可協商的。
因此，雖然協議大修可能到期，但目前還沒有出現如此深遠的努力，主要是因為我們還沒有提出一個可行的、開創性的、但向後相容的替代方案。
我們可以將IP協議的起源追溯到1974年，由電氣和電子工程師協會發表並由Vint Cerf和Bob Cahn撰寫的一篇論文。它詳細說明了通過網路傳送的資料包，跨IP地址路由它們，以及網路/網路中節點的數字定義地址。該協議定義了這些資料包或資料包的格式——它的標頭和有效負載。
在1980年的RFC 760定義之後，IETF在其Request For Comments 791中採用了至今廣泛使用的定義。這是協議的第四個版本，但我們可以說它是第一個生產版本。
網際網路協議（圖片來源：RFC791）
它使用32位地址，將地址數量限制在40億左右。這個限制解釋了為什麼非商業網際網路使用者從他們的ISP那裡獲得“動態IP地址”，而靜態IP被認為是“附加值”並且經常需要額外收費。
他們正在配給。
不久之後，人們意識到32位地址是不夠的，而且短缺迫在眉睫，因此釋出了許多RFC試圖解決這個問題。儘管這些解決方案在今天被廣泛使用，並且是我們日常生活的一部分，但可以肯定地說這些相當於黑客。
Internet協議版本 6或IPv6是解決這些限制的一種方式，包括逐漸被以前的版本採用。它於1998年成為IETF的標準草案檔案，並於2017年提升為網際網路標準。
雖然IPv4地址空間受到其32位地址長度的限制，但IPv6標準被賦予128位，即 3.4 * 10 ^ 38 個可能的地址。這應該足以維持我們相當長的一段時間。
根據谷歌和使用者之間的IPv6連線，截至2021年6月，IPv6的採用率剛剛超過35%。
IPv6採用
IP是網際網路堆疊的基本層，定義了最基本的東西，但不保證交付、資料完整性或傳輸資料包的順序。就其本身而言，它是不可靠的。IPv4的報頭格式提供了報頭校驗和，傳輸節點使用它來驗證報頭的完整性。這使得它與 IPv6 版本不同，後者依賴於下面的鏈路層，使其速度更快。
網際網路資料包頭（圖片來源：RFC791）
瞭解TCP和UDP的作用
現在是時候探索HTTP/3與TCP和UDP的匹配度了。
TCP
雖然IP是當今我們所有線上通訊的底層，但TCP（傳輸控制協議）是Internet協議套件的更高階別部分，提供Web、郵件、檔案傳輸 (FTP) 所需的可靠性 -用於網際網路的應用層/協議。
這包括多步連線建立、握手、確保資料包順序和丟失資料包的重傳。它向發件人提供交付的反饋（Acks）等。還有校驗和計算來檢測錯誤。
所有這些都表明了使TCP成為可靠協議的許多步驟，使其成為我們今天使用的最臭名昭著的網際網路服務的基礎。
其可追溯到1974年 (RFC 675)和1981年 (RFC 793) 的規範至今未發生重大變化。
然而，TCP提供的可靠性並非沒有代價。握手、交付反饋、訂購保證和校驗和所需的所有往返開銷，這些開銷可能被認為是弱且冗餘的。它使TCP成為現代協議棧的瓶頸。HTTP/2已經達到了可以在TCP之上實現的速度提升的平穩期。
UDP
使用者資料包協議(UDP) 也是Internet協議套件的組成部分之一，其規範可以追溯到1980年 (RFC 768)。
顧名思義，它是一種基於資料包的無連線協議。這意味著沒有握手，也沒有訂購或交付的保證。這意味著確保交付、資料完整性和其他事情的任何可能步驟都留給了應用程式層。這意味著構建在UDP之上的應用程式可以根據具體情況選擇將採用的策略，或者它可以利用鏈路層的元素（如校驗和）來避免開銷。
由於UDP與TCP一樣廣泛傳播，因此無需在連線到Internet的各種裝置上進行韌體更新或對作業系統進行重大更改即可實現改進。
許多防火牆、NAT、路由器和其他只允許在使用者和他們需要到達的伺服器之間部署TCP或UDP的中間裝置阻礙了新協議的部署。– HTTP/3解釋
Hacker News上的這個帖子可以幫助我們開始理解在現有網路堆疊之上構建新HTTP版本背後的原因，而不是重新發明它（儘管還有更多內容）。
UDP資料包格式規範比較少，它的包頭由包頭和包資料的源埠、目的埠、長度（以位元組為單位）和校驗和組成。校驗和可用於驗證資料包標頭和資料部分的資料完整性。
當底層協議層是IPv4時，校驗和是可選的，對於IPv6是強制性的。到目前為止，UDP已被用於計算機系統時鐘同步 ( NTP )、VoIP 應用程式、視訊流、DNS系統和DHCP協議等。
QUIC和HTTP/3
QUIC（Quick UDP Internet Connections）由谷歌於2012年首次部署。它重新定義了網路層的邊界，依賴於較低階別的UDP協議，重新定義了“使用者空間”中的握手、可靠性特性和安全特性，避免了需要升級網際網路系統的核心。
HTTP/2堆疊與HTTP/3堆疊
就像HTTP/2一樣，由Google的SPDY或speedy帶頭的進步，HTTP/3將再次建立在這些成就的基礎上。
雖然HTTP/2確實為我們提供了多路複用，並減輕了線頭阻塞，但它受到TCP的限制。您可以將單個TCP連線用於多路複用在一起的多個流以傳輸資料，但是當其中一個流遭受資料包丟失時，整個連線（及其所有流）都 被扣為人質，也就是說，直到TCP完成它的事情（重新傳輸丟失的資料包）。
這意味著所有資料包，即使它們已經被傳輸並在目標節點的緩衝區中等待，也會被阻塞，直到丟失的資料包被重新傳輸。Daniel Stenberg在他關於http/3的書中稱其為“基於TCP的行頭塊”。他聲稱，如果丟包率為2%，使用者使用HTTP/1會做得更好，使用六個連線來規避這種風險。
QUIC不受此限制。QUIC建立在無連線的UDP協議上，連線的概念沒有TCP的限制，一個流的故障也不必影響其餘的流。
正如Cloudflare的Lucas Pardue所說：
盧卡斯·帕杜談HTTP/3
專注於UDP流，QUIC實現了多路複用，而無需捎帶一個TCP連線。QUIC在比TCP更高的層次上建立連線。QUIC連線中的新流不會被迫等待其他連線完成。QUIC連線還受益於取消TCP握手開銷，從而減少延遲。
Cisco的人制作了一段有趣的視訊，解釋TCP的3次握手：
雖然QUIC取消了TCP可靠性特性，但它在UDP層之上彌補了這一點，提供了資料包的重傳、排序等。谷歌雲平臺在 2018 年為其負載均衡器引入了QUIC支援，全球平均頁面載入時間提高了8%，在延遲較高的地區提高了13%。
在谷歌瀏覽器、YouTube、Gmail、谷歌搜尋和其他服務之間，谷歌能夠在網際網路的一大塊上部署QUIC，而無需等待IETF。谷歌的工程師聲稱，在2017年，7%的網際網路流量已經通過QUIC進行。
Google的QUIC版本只專注於HTTP傳輸，使用HTTP/2語法。IETF的人員（負責標準化QUIC的人員）認為，IETF版本的QUIC應該能夠傳輸的不僅僅是HTTP。然而，就目前而言，任何基於QUIC的非HTTP協議的工作都被擱置了。
IETF工作組決定的另一件事是標準化版本將使用TLS 1.3加密而不是Google的自定義解決方案。與舊版本相比，TLS 1.3也有助於提高協議速度，因為它的握手需要更少的往返。
目前，谷歌繼續在其產品中使用自己的QUIC版本，同時將其開發工作導向IETF標準。大多數其他網際網路參與者都在IETF版本之上構建（除了加密之外，兩者在其他方面有所不同）。
如果我們開啟Chrome開發工具，並在Network選項卡的Protocol列中載入一些谷歌的產品，比如Gmail，我們會看到很多資源正在通過谷歌版本的QUIC協議載入。谷歌的產品如分析、谷歌標籤管理器等也是如此。
谷歌服務QUIC
Cloudflare釋出了關於標準化進展的非常廣泛的更新。
雖然UDP確實為QUIC和HTTP/3提供了一些固有的優勢，但它也帶來了一些挑戰。
TCP多年來一直是主流協議，而UDP不是，因此作業系統和它的軟體堆疊通常沒有得到優化。因此，據估計，QUIC的CPU負載/要求要高得多，是HTTP/2的兩倍。
優化深入到作業系統的核心，以及不同的路由器和裝置韌體。這份Red Hat調優指南可能會為那些更傾向於技術的人提供更多關於該主題的資訊。
可以說，QUIC嘗試在更小、更靈活的協議之上重新設計TCP功能。
我們前面提到的QUIC連線結合了TLS和傳輸握手。一旦建立，它們將由唯一的CID（連線ID）標識。這些ID在IP更改中持續存在，並且可以幫助確保不間斷的下載，例如從4G切換到WiFi。這是相關的，特別是因為越來越多的網際網路流量是在移動裝置上進行的。可能會出現問題，谷歌是否構思了這個元素來促進更好地跨不同連線和網際網路提供商的使用者跟蹤。
TLS是強制性的，旨在使中間裝置難以篡改或嗅探流量。這就是為什麼經常看到防火牆提供商和供應商（如Cisco）將UDP協議視為一個問題，並提供禁用它的方法。中間商更難檢查、監督或過濾QUIC流量。
QUIC流通過QUIC連線傳送，單向或雙向。流具有標識發起者的ID，以及流是單向的還是雙向的，並且還提供流內流控制。
QUIC是傳輸層協議，而HTTP是其之上的層，即應用層協議或應用程式協議。
由於向後相容至關重要，IETF推動了HTTP/3的實現，並將在響應中包含舊版本（HTT1或HTTP/2）。它將包含一個標頭，通知客戶端HTTP/3可用，以及埠/主機資訊，如RFC7838中所述。
這與HTTP/2不同，後者可以在TLS握手中協商傳輸。但由於IETF幾乎採用了基於QUIC的HTTP/3作為下一個標準，我們可以預期Web客戶端會越來越多地期望對HTTP/3的支援。客戶端可以快取來自先前HTTP/3連線的資料，並在後續訪問同一主機時直接連線（零往返或0-RTT）。
小結
有人認為，由於HTTP/2標準尚未完全採用，現在廣泛推動HTTP/3可能還為時過早。這是一個有效的觀點，但是，正如我們所提到的，這個協議已經看到了大規模的測試和實現。谷歌早在2015年就開始對其進行測試，Facebook也在2017年開始測試。
2022年，我們獲得了來自Google Chrome和Brave等主要瀏覽器的HTTP/3支援。在基礎設施方面，像Litespeed和Nginx這樣的網路伺服器都有HTTP/3的工作實現，而像Cloudflare這樣的網路提供商已經部署了對HTTP/3的全面支援。
目前，HTTP/3仍處於Internet Draft階段，最新的修訂版將於2021年8月到期。未來將是令人興奮的，因為我們可以期待看到主要軟體供應商實施新版本的舉措標準。
評論留言