解讀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的設計思想中已經為未來做了考慮，應用層和傳輸層職責嚴格隔離，避免再出現“傳輸層一看埠就知道應用層在幹什麼”的情況。

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

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

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

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

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