本文轉(zhuǎn)載自公眾號(hào)??余晟以為

去年（2018年）1月，滬江的兩位前端工程師翻譯了O’Reilly的《HTTP/2基礎(chǔ)教程》。似乎到目前為止，這似乎仍然是唯一關(guān)于HTTP/2的中文技術(shù)資料。

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

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

如今HTTP/2已經(jīng)不新鮮了，根據(jù)2019年2月對訪問量最大的1000萬個(gè)網(wǎng)站的統(tǒng)計(jì)，33.5%已經(jīng)支持HTTP/2。在國內(nèi)，如果你打開瀏覽器看看調(diào)試模式，會(huì)發(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ù)幕締挝皇菐?#xff08;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中為大家所津津樂道的“多路復(fù)用”，簡單說就是把數(shù)據(jù)流分解為多個(gè)幀，多個(gè)數(shù)據(jù)流的幀混合之后以同一個(gè)TCP連接來發(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)帶來了巨大的性能提升，但大家對性能的渴求是沒有止境的。在應(yīng)用層的許多問題解決之后，下一個(gè)優(yōu)化的重點(diǎn)就是傳輸層了。無論SPDY還是HTTP/2，傳輸層協(xié)議都是TCP，TCP有一些娘胎里帶來的問題，比如慢啟動(dòng)，如果擁塞窗口尺寸設(shè)置不合理，TCP的性能會(huì)急劇下降。關(guān)于這個(gè)問題，網(wǎng)絡(luò)上已經(jīng)有許多討論，這里不贅述。

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

所以思路自然就是“改掉TCP的這些毛病”?？紤]到現(xiàn)實(shí)中已經(jīng)有成千上萬的網(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了。對了，還有人考慮過SCTP，但SCTP在隊(duì)頭阻塞、TLS、四次握手等方面仍然存在缺陷，尚不能讓人滿意。

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

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

盡管Google的QUIC很先進(jìn)，但QUIC不止這一家，IETF也有QUIC，如今已經(jīng)改名HTTP/3，所以Google的QUIC有時(shí)候也寫作gQUIC。與Google單純在傳輸層動(dòng)手，應(yīng)用層基本沿用HTTP/2不同，IETF的QUIC是一個(gè)混合方案，既包括傳輸層的改動(dòng)，也包括HTTP層的改動(dòng)（比如全新的頭部壓縮）。從另一個(gè)角度來說，它更“完整”。雖然理論上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有各種問題，但換成UDP的話，TCP的不少功能也需要原樣移植過來。許多人都知道，TCP是可靠的傳輸協(xié)議，而UDP是不可靠的。HTTP/3當(dāng)然不能不可靠，所以它必須自己實(shí)現(xiàn)有序性、錯(cuò)誤偵測、重傳、擁塞控制、傳輸節(jié)奏調(diào)整等等特性。

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

與此相反，QUIC的所有連接都是加密的，目前采用的是TLS 1.3。如果你仔細(xì)觀察上面的圖就會(huì)發(fā)現(xiàn)，TLS 1.3是“囊括”在QUIC當(dāng)中的，也就是說，QUIC建立連接的握手過程當(dāng)中就同時(shí)完成了加密握手。HTTP/3的握手很快，如果兩臺(tái)主機(jī)之間建立過連接，并且緩存了之前的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)找資料來看看）。

QUIC中雖然也有連接（Connection），也基于IP和port建立，但它并不能直接與TCP的連接對應(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)可對方的連接ID。連接ID的作用在于從邏輯上標(biāo)識(shí)當(dāng)前連接。所以，如果用戶的IP發(fā)生變化而連接ID沒有變化，因?yàn)閜acket包含了網(wǎng)絡(luò)ID標(biāo)識(shí)符，所以只需要繼續(xù)發(fā)送數(shù)據(jù)包就可以重新建立連接。而目前，如果用戶的設(shè)備發(fā)生了網(wǎng)絡(luò)切換，比如從Wi-Fi切換到4G，則所有連接都要斷掉再重連。

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

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

做過在線升級(jí)的朋友都知道，在線升級(jí)中的一個(gè)必須成分是提供降級(jí)方案，以保證“退化”兼容。無論HTTP/2還是HTTP/3，都不能逃避這部分的工作量。HTTP/2雖然可以通過upgrade這個(gè)header來升級(jí)，但也有更簡單的辦法，就是在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無縫切換，客戶端完全無感知，它們的經(jīng)驗(yàn)值得參考。

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

Alt-Svc: h3=":20003"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后感謝狗叔(Googol Lee)介紹的資料。同時(shí)推薦一本電子書，對HTTP/3做了詳細(xì)完整的解讀，比我說的要好，有興趣可以點(diǎn)擊“原文鏈接”前往。

以上就是我的學(xué)習(xí)筆記。如果你認(rèn)為有不對的地方，歡迎留言指出。討論HTTP/3相關(guān)問題的留言也同樣歡迎。

總結(jié)

以上是生活随笔為你收集整理的我的HTTP/3学习笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。