最近我專門學習了點關于HTTP/3的知識，在這里隨便寫寫，和大家做個分享。然而技術的發展總是讓人目不暇接，2018年10月，HTTP/3又發布了。雖然已經有一些中文技術媒體做了報道，但大多數是翻譯的，而且內容大同小異。最近我專門學習了點關于HTTP/3的知識，在這里隨便寫寫，和大家做個分享。

先簡單回顧一下HTTP/2吧。自從1999年HTTP 1.1發布之后，Web一直在迅猛發展，可惜HTTP協議一直沒有更新。等不及的Google自己搞了個SPDY(讀音是“speedy”)，并依靠Chrome瀏覽器大肆推廣。看到SPDY的效果確實很好(可以帶來近50%的性能提升)，IETF推動制定了HTTP/2。 SPDY和HTTP/2的主要特性展示如下： 

 

 

如今HTTP/2已經不新鮮了，根據2019年2月對訪問量最大的1000萬個網站的統計，33.5%已經支持HTTP/2。在國內，如果你打開瀏覽器看看調試模式，會發現各大廠已經廣泛使用HTTP/2，尤其是放置css、js、圖片的資源站，HTTP/2基本是標配。這也很好理解，基本什么都不用做，就可以直接享受多路復用帶來的好處，何樂而不為?

在傳統HTTP中，概念模型非常簡單：下層TCP通訊與上層HTTP完全不搭架，但TTP與TCP的“連接”是重合的，TCP傳輸的單位是packet，HTTP則采用request-response的模型。

在HTTP/2中，概念模型有所變化，HTTP/2中傳輸的基本單位是幀(frame)。與HTTP 1.1的明文傳輸不同的是，HTTP/2的幀是二進制的，同時TCP承載的“邏輯連接”叫數據流(stream)，所有的狀態流轉、流控、優先級等等特性都是在數據流上實現的。HTTP/2中為大家所津津樂道的“多路復用”，簡單說就是把數據流分解為多個幀，多個數據流的幀混合之后以同一個TCP連接來發送。

值得注意的是，HTTP有1.0和1.1的區分，所以寫作HTTP 1.0，HTTP 1.1，但HTTP/2不會有其它小版本，所以不要寫作HTTP 2.0，而應當寫成HTTP/2。

雖然HTTP/2已經帶來了巨大的性能提升，但大家對性能的渴求是沒有止境的。在應用層的許多問題解決之后，下一個優化的重點就是傳輸層了。無論SPDY還是HTTP/2，傳輸層協議都是TCP，TCP有一些娘胎里帶來的問題，比如慢啟動，如果擁塞窗口尺寸設置不合理，TCP的性能會急劇下降。關于這個問題，網絡上已經有許多討論，這里不贅述。

另一個重要問題是，HTTP/2的多路復用帶來的效果并不如想象的那么好。雖然HTTP/2中的傳輸連接可以多路復用，但仍然無法避免隊頭阻塞的情況出現。因為TCP是需要保證有序的，假如單個TCP連接同時承載了四路邏輯連接，其中某個邏輯連接丟包了，則其它三路都會受影響，都必須從丟包的時刻開始重傳，這無疑是極大的浪費。測試表明，如果丟包率超過2%，那么HTTP/2甚至不如HTTP 1.1，因為HTTP 1.1中各連接物理隔離，不會互相影響。 

 

 

所以思路自然就是“改掉TCP的這些毛病”。考慮到現實中已經有成千上萬的網絡設備，它們只能識別TCP和UDP，軟件不會進化，如果更新TCP協議當然不可行——雖然2014年12月發布了TCP的Fast Open，但現實應用中的情況并不讓人滿意。因此，可用的只有UDP了。對了，還有人考慮過SCTP，但SCTP在隊頭阻塞、TLS、四次握手等方面仍然存在缺陷，尚不能讓人滿意。

大概有人聽過QUIC(讀音quick)，知道它是基于UDP的HTTP，也知道它依然是Google最先提出來的。確實，上次是Google率先搞出了SPDY，這次Google又率先搞出了QUIC。根據Google本意，QUIC是把傳統的HTTP/TCP/IP協議棧中的TCP換成UDP(當然需要加密)，能通過加密的UDP傳輸HTTP/2的幀。

按照Google的說法，這樣的好處很多，比如UDP建立連接的延遲會低很多，而且避免了隊頭阻塞。除此之外，Google還提供了一個非常誘人的特性FEC(Forward Error Correction)。簡單說，它想做到的是，一旦有packet丟失，接收方可以根據之前和之后的packet推斷出丟失packet的數據，這樣就避免了重傳。但是這樣必然要求增加冗余載荷，或者說，這就是網絡協議中的RAID 5。按照目前看到的資料，其冗余比例大概是10%，也就是說，每10個pakcet中的冗余信息，就可以重構一個packet。

盡管Google的QUIC很先進，但QUIC不止這一家，IETF也有QUIC，如今已經改名HTTP/3，所以Google的QUIC有時候也寫作gQUIC。與Google單純在傳輸層動手，應用層基本沿用HTTP/2不同，IETF的QUIC是一個混合方案，既包括傳輸層的改動，也包括HTTP層的改動(比如全新的頭部壓縮)。從另一個角度來說，它更“完整”。雖然理論上QUIC也可以支持HTTP之外的其它上層應用，但目前這只是計劃而已，第一版QUIC并不包含這方面內容。

在2018年11月，IETF正式宣布，HTTP-over-QUIC更名為HTTP/3。

 

本文討論的是IETF版本的QUIC，Google已經宣布，會逐步把IETF的規范納入自己的協議版本，實現相同的規范。

雖然TCP有各種問題，但換成UDP的話，TCP的不少功能也需要原樣移植過來。許多人都知道，TCP是可靠的傳輸協議，而UDP是不可靠的。HTTP/3當然不能不可靠，所以它必須自己實現有序性、錯誤偵測、重傳、擁塞控制、傳輸節奏調整等等特性。

HTTP/2“似乎”必須用到HTTPS，但規范并不強求HTTP/2使用HTTPS，也就是說，如果你用HTTP來跑HTTP/2，理論上也是可以成立的，雖然這有點怪異。

與此相反，QUIC的所有連接都是加密的，目前采用的是TLS 1.3。如果你仔細觀察上面的圖就會發現，TLS 1.3是“囊括”在QUIC當中的，也就是說，QUIC建立連接的握手過程當中就同時完成了加密握手。HTTP/3的握手很快，如果兩臺主機之間建立過連接，并且緩存了之前的secret，只要客戶端驗證之前緩存的server config就可以直接建立連接，相當于0-RTT，否則也只需要1-RTT就可以建立連接。此外，QUIC還容許在0-RTT的情況下從一開始就捎帶數據，傳統的“建立連接-加密握手-發送數據”如今可以三步并作一步(這個0-RTT和1-RTT的實現都非常有意思，有興趣的話應當找資料來看看)。

QUIC中雖然也有連接(Connection)，也基于IP和port建立，但它并不能直接與TCP的連接對應，也不同于HTTP/2中的連接。原因在于QUIC建立連接時既完成了經典的傳輸握手，又完成了加密握手——你可以認為這樣分層責任不清晰，但它確實提升了效率。QUIC的連接與HTTP/2類似，一個物理連接也可以承載多個邏輯連接(也就是數據流)。但與HTTP/2不同的是，QUIC中的邏輯連接是彼此獨立的，所以避免了TCP上出現的“邏輯連接甲丟包導致邏輯連接乙、丙、丁都需要重傳”的情況。

QUIC連接的另一個特點是，每個連接都有一組連接ID。連接各端可以設定自己的連接ID，同時認可對方的連接ID。連接ID的作用在于從邏輯上標識當前連接。所以，如果用戶的IP發生變化而連接ID沒有變化，因為packet包含了網絡ID標識符，所以只需要繼續發送數據包就可以重新建立連接。而目前，如果用戶的設備發生了網絡切換，比如從Wi-Fi切換到4G，則所有連接都要斷掉再重連。

如果你詳細研究過HTTP/2，應當知道它的header壓縮采用的HPACK，因為gzip做header壓縮有安全性隱患。HTTP/3同樣提供了header壓縮，但不能直接沿用HPACK。原因在于，HPACK粗略來說就是一張動態表(dynamic table)，由request-response共同維護它，后續header中不會完整重復之前的條目，而是引用之前的條目，TCP的有序性保證了它一定是先修改再讀取，也就是先編碼再解碼。

然而如果使用HPACK，多個流的順序是無法保證的，這樣會導致解析錯誤。QUIC的解決方案是QPACK，其原理很簡單：所有的header必須通過同一數據流來傳輸，而且必須嚴格有序。但是這樣一來，從HTTP 1.1開始就困擾HTTP已久的隊頭阻塞又出現了。因此，QUIC的長期目標之一就是解決header的隊頭阻塞問題。

做過在線升級的朋友都知道，在線升級中的一個必須成分是提供降級方案，以保證“退化”兼容。無論HTTP/2還是HTTP/3，都不能逃避這部分的工作量。HTTP/2雖然可以通過upgrade這個header來升級，但也有更簡單的辦法，就是在TLS握手時協商HTTP的版本，比如Nginx就有NPN(Nginx Protocol Negotiation)擴展，自動協商協議，并已經被IETF采納，成為ALPN(Application Layer Protocol Negotiation)。

如果web server有這樣的特性，應用服務代碼就不必為兼容HTTP 1.1和HTTP/2做太多工作。但是，如果應用程序中使用了Push等新特性，還是免不了要做很多事情。在業界，Google、Youtube、Wikipedia等大廠早已經提供了完整服務，HTTP/2和HTTP 1.1無縫切換，客戶端完全無感知，它們的經驗值得參考。

與HTTP/2不同的是，HTTP/3中新定義了一個header，可以用來指示客戶端“在另一個端口提供了專用的HTTP/3服務”。

Alt-Svc: h3=":20003"

這個header說明，在本主機的20003端口開啟了HTTP/3的服務。所以，客戶端之后可以嘗試和這個端口建立純粹的HTTP/3連接。

聊了這么多QUIC的好處之后，再談談它的問題，有些觀點來自我個人，未必足夠準確客觀，歡迎討論。

雖然QUIC有這么多好處，但可以看到，相比HTTP/2，它的改動相當大，所以問題也不會少。

第一個問題是與遺留的網絡設備的兼容問題。

基于目前的應用情況，許多網絡設備對TCP和UDP的策略相當固定，TCP限制在常用端口，而UDP大概只開放了53端口(DNS)。所以如果HTTP/3使用UDP，兼容性方面可能會有不少問題需要解決。

不過如果這個問題可以解決，未來大概不會再出現這種問題，因為HTTP/3的設計思想中已經為未來做了考慮，應用層和傳輸層職責嚴格隔離，避免再出現“傳輸層一看端口就知道應用層在干什么”的情況。

第二個問題是QUIC的性能問題。

TCP雖然也是很老的協議，但應用廣泛，操作系統內核中有對應的處理代碼，BBR之類的新特性也可以大幅提升TCP的性能。但是QUIC放棄了TCP，據Google的文檔，恰恰是因為TCP太穩定了，內核里的代碼更新特別麻煩。此外，因為Linux內核設計之初并沒有考慮多核的擴展問題，在多核(core)情況下反而會產生反復的陷核，造成進程阻塞，嚴重影響性能。

針對上面的問題，不少新的方案都把網絡協議棧放到用戶態處理，QUIC也順應了這種大潮流。唯一的問題是，UDP的協議棧似乎還沒有現成的讓人滿意的方案，或許我們還得再等待一段時間，才能用上可靠高效的方案。

第三個問題是服務端推送。

雖然很多人很想要這個特性，而且HTTP/2也確實加入了它，但關于它的應用仍然存在許多爭議。簡單說，HTTP/2的推送打破了HTTP傳統的“一問一答”的通訊模式，在客戶端沒有請求的時候，服務端就可以給客戶端發送數據，這難免被濫用(想想隨處可見的那些最喜歡“在商言商”，最不喜歡談“道德”的留言吧)，盡管Chrome的開發人員說它們會檢查推送并阻止惡意內容，那也是要在收到推送數據之后進行，這個方案并不完善。

同時，服務端也可能不顧客戶端的緩存，執意重復推送，造成帶寬浪費。HTTP/3保留了推送，但機制有所不同。客戶端需要先同意，服務端才可以推送。而且，客戶端可以設置服務端推送上限，超過上限的推送會出錯。盡管如此，推送如何能妥善利用，目前還沒有公認明確的答案。

最后一個問題來自調試和支持的工具。

任何技術要想大規模工程應用，靠“標準實現”單打一肯定是不行的，因為無法切片，無法細粒度調試。在經典的HTTP技術棧中，各層都有對應的工具，比如IP層有ping和traceroute，傳輸層有telnet，應用層有curl，正是有這些工具簇擁著，開發人員才可以很方便地定位問題所處的層次和細節。HTTP/2雖然有改動，但調試工具也不少，curl可以支持，還有nghttp2、h2c等工具，初步形成了完整的體系。HTTP/3的改動很大，如果沒有對應的調試支持工具，可以想象部署和遷移都不會容易。