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

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

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

在傳統(tǒng)HTTP中，概念模型非常簡單：下層TCP通訊與上層HTTP完全不搭架，但TTP與TCP的“連接”是重合的，TCP傳輸?shù)膯挝皇莗acket，HTTP則采用request-response的模型。

在HTTP/2中，概念模型有所變化，HTTP/2中傳輸?shù)幕締挝皇菐?frame)。與HTTP 1.1的明文傳輸不同的是，HTTP/2的幀是二進(jìn)制的，同時TCP承載的“邏輯連接”叫數(shù)據(jù)流(stream)，所有的狀態(tài)流轉(zhuǎn)、流控、優(yōu)先級等等特性都是在數(shù)據(jù)流上實現(xiàn)的。HTTP/2中為大家所津津樂道的“多路復(fù)用”，簡單說就是把數(shù)據(jù)流分解為多個幀，多個數(shù)據(jù)流的幀混合之后以同一個TCP連接來發(fā)送。

值得注意的是，HTTP有1.0和1.1的區(qū)分，所以寫作HTTP 1.0，HTTP 1.1，但HTTP/2不會有其它小版本，所以不要寫作HTTP 2.0，而應(yīng)當(dāng)寫成HTTP/2。

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

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

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

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

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

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

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

本文討論的是IETF版本的QUIC，Google已經(jīng)宣布，會逐步把IETF的規(guī)范納入自己的協(xié)議版本，實現(xiàn)相同的規(guī)范。

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

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

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

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

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

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

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

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

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

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

Alt-Svc: h3=":20003"

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

聊了這么多QUIC的好處之后，再談?wù)勊膯栴}，有些觀點來自我個人，未必足夠準(zhǔn)確客觀，歡迎討論。

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

第一個問題是與遺留的網(wǎng)絡(luò)設(shè)備的兼容問題。

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

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

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

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

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

第三個問題是服務(wù)端推送。

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

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

最后一個問題來自調(diào)試和支持的工具。

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