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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

做過(guò)在線升級(jí)的朋友都知道，在線升級(jí)中的一個(gè)必須成分是提供降級(jí)方案，以保證“退化”兼容。無(wú)論HTTP/2還是HTTP/3，都不能逃避這部分的工作量。HTTP/2雖然可以通過(guò)upgrade這個(gè)header來(lái)升級(jí)，但也有更簡(jiǎn)單的辦法，就是在TLS握手時(shí)協(xié)商HTTP的版本，比如Nginx就有NPN(Nginx Protocol Negotiation)擴(kuò)展，自動(dòng)協(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無(wú)縫切換，客戶端完全無(wú)感知，它們的經(jīng)驗(yàn)值得參考。

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

Alt-Svc: h3=":20003"

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

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

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

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

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

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

第二個(gè)問(wèn)題是QUIC的性能問(wèn)題。

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

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

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

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

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

最后一個(gè)問(wèn)題來(lái)自調(diào)試和支持的工具。

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