HTTP 3.0 是 HTTP 協(xié)議的第三個主要版本,前兩個分別是 HTTP 1.0 和 HTTP 2.0 ,但其實 HTTP 1.1 我認為才是真正的 HTTP 1.0。
我們大家知道,HTTP 是應用層協(xié)議,應用層產(chǎn)生的數(shù)據(jù)會通過傳輸層協(xié)議作為載體來傳輸?shù)交ヂ?lián)網(wǎng)上的其他主機中,而其中的載體就是 TCP 協(xié)議,這是 HTTP 2 之前的主流模式。
但是隨著 TCP 協(xié)議的缺點不斷暴露出來,新一代的 HTTP 協(xié)議 - HTTP 3.0 毅然決然切斷了和 TCP 的聯(lián)系,轉(zhuǎn)而擁抱了 UDP 協(xié)議,這么說不太準確,其實 HTTP 3.0 其實是擁抱了QUIC 協(xié)議,而 QUIC 協(xié)議是建立在 UDP 協(xié)議基礎上的。
【資料圖】
HTTP 3.0 于 2022 年 6 月 6 日正式發(fā)布,IETF 把 HTTP 3.0 標準制定在了RFC 9114中,HTTP 3.0 其實相較于 HTTP 2.0 要比 HTTP 2.0 相較于 HTTP 1.1 的變化來說小很多,最大的提升就在于效率,替換 TCP 協(xié)議為 UDP 協(xié)議,HTTP 3.0 具有更低的延遲,它的效率甚至要比 HTTP 1.1 快 3 倍以上。
其實每一代 HTTP 協(xié)議的不斷發(fā)展都是建立在上一代 HTTP 的缺點上的,就比如 HTTP 1.0 最大的問題就是傳輸安全性和不支持持久連接上,針對此出現(xiàn)了 HTTP 1.1 ,引入了 Keep-Alive 機制來保持長鏈接和 TLS 來保證通信安全性。但此時的 HTTP 協(xié)議并發(fā)性還做的不夠好。
隨著網(wǎng)絡的不斷發(fā)展,每個網(wǎng)站所需資源(CSS、JavaScript、圖像等)的數(shù)量逐年增加,瀏覽器發(fā)現(xiàn)自己在獲取和呈現(xiàn)網(wǎng)頁時需要越來越多的并發(fā)性。但是由于 HTTP 1.1 只能夠允許客戶端/服務器進行一次 HTTP 請求交換,因此在網(wǎng)絡層獲得并發(fā)性的唯一方法是并行使用多個 TCP 連接到同一個源,不過使用多個 TCP 鏈接就失去了 keep-Alive 的意義。
然后出現(xiàn)了SPDY協(xié)議,主要解決 HTTP 1.1 效率不高的問題,包括降低延遲,壓縮 header 等等,這些已經(jīng)被 Chrome 瀏覽器證明能夠產(chǎn)生優(yōu)化效果,后來 HTTP 2.0 基于 SPDY ,并且引入了 **流( Stream )**的概念,它允許將不同的 HTTP 交換多路復用到同一個 TCP 連接上,從而達到讓瀏覽器重用 TCP 鏈接的目的。
TCP 的主要作用是以正確的順序?qū)⒄麄€字節(jié)流從一個端點傳輸?shù)搅硪粋€端點,但是當流中的某些數(shù)據(jù)包丟失時,TCP 需要重新發(fā)送這些丟失的數(shù)據(jù)包,等到丟失的數(shù)據(jù)包到達對應端點時才能夠被 HTTP 處理,這被稱為 TCP 隊頭阻塞問題。
那么可能就會有人考慮到去修改 TCP 協(xié)議,其實這已經(jīng)是一件不可能完成的任務了。因為 TCP 存在的時間實在太長,已經(jīng)充斥在各種設備中,并且這個協(xié)議是由操作系統(tǒng)實現(xiàn)的,更新起來不大現(xiàn)實。
基于這個原因,Google 就更起爐灶搞了一個基于 UDP 協(xié)議的 QUIC 協(xié)議,并且使用在了 HTTP/3 上,HTTP/3 之前名為 HTTP-over-QUIC,從這個名字中我們也可以發(fā)現(xiàn),HTTP/3 最大的改造就是使用了 QUIC。
QUIC 協(xié)議QUIC 的小寫是 quic,諧音 quick,意思就是快。它是 Google 提出來的一個基于 UDP 的傳輸協(xié)議,所以 QUIC 又被叫做快速 UDP 互聯(lián)網(wǎng)連接。
首先 QUIC 的第一個特征就是快,為什么說它快,它到底快在哪呢?
我們大家知道,HTTP 協(xié)議在傳輸層是使用了 TCP 進行報文傳輸,而且 HTTPS 、HTTP/2.0 還采用了 TLS 協(xié)議進行加密,這樣就會導致三次握手的連接延遲:即 TCP 三次握手(一次)和 TLS 握手(兩次),如下圖所示。
對于很多短連接場景,這種握手延遲影響較大,而且無法消除。畢竟 RTT 是人類和效率的終極斗爭。
相比之下,QUIC 的握手連接更快,因為它使用了 UDP 作為傳輸層協(xié)議,這樣能夠減少三次握手的時間延遲。而且 QUIC 的加密協(xié)議采用了 TLS 協(xié)議的最新版本TLS 1.3,相對之前的TLS 1.1-1.2,TLS1.3 允許客戶端無需等待 TLS 握手完成就開始發(fā)送應用程序數(shù)據(jù)的操作,可以支持1 RTT 和 0 RTT,從而達到快速建立連接的效果。
我們上面還說過,HTTP/2.0 雖然解決了隊頭阻塞問題,但是其建立的連接還是基于 TCP,無法解決請求阻塞問題。
而 UDP 本身沒有建立連接這個概念,并且 QUIC 使用的 stream 之間是相互隔離的,不會阻塞其他 stream 數(shù)據(jù)的處理,所以使用 UDP 并不會造成隊頭阻塞。
在 TCP 中,TCP 為了保證數(shù)據(jù)的可靠性,使用了序號+確認號機制來實現(xiàn),一旦帶有 synchronize sequence number 的包發(fā)送到服務器,服務器都會在一定時間內(nèi)進行響應,如果過了這段時間沒有響應,客戶端就會重傳這個包,直到服務器收到數(shù)據(jù)包并作出響應為止。
那么 TCP 是如何判斷它的重傳超時時間呢?
TCP 一般采用的是自適應重傳算法,這個超時時間會根據(jù)往返時間 RTT 動態(tài)調(diào)整的。每次客戶端都會使用相同的 syn 來判斷超時時間,導致這個 RTT 的結(jié)果計算的不太準確。
雖然 QUIC 沒有使用 TCP 協(xié)議,但是它也保證了可靠性,QUIC 實現(xiàn)可靠性的機制是使用了Packet Number,這個序列號可以認為是 synchronize sequence number 的替代者,這個序列號也是遞增的。與 syn 所不同的是,不管服務器有沒有接收到數(shù)據(jù)包,這個 Packet Number 都會 + 1,而 syn 是只有服務器發(fā)送 ack 響應之后,syn 才會 + 1。
比如有一個 PN = 10 的數(shù)據(jù)包在發(fā)送的過程中由于某些原因遲遲沒到服務器,那么客戶端會重傳一個 PN = 11 的數(shù)據(jù)包,經(jīng)過一段時間后客戶端收到 PN = 10 的響應后再回送響應報文,此時的 RTT 就是 PN = 10 這個數(shù)據(jù)包在網(wǎng)絡中的生存時間,這樣計算相對比較準確。
雖然 QUIC 保證了數(shù)據(jù)包的可靠性,但是數(shù)據(jù)的可靠性是如何保證的呢?
QUIC 引入了一個stream offset的概念,一個 stream 可以傳輸多個 stream offset,每個 stream offset 其實就是一個 PN 標識的數(shù)據(jù),即使某個 PN 標識的數(shù)據(jù)丟失,PN + 1 后,它重傳的仍舊是 PN 所標識的數(shù)據(jù),等到所有 PN 標識的數(shù)據(jù)發(fā)送到服務器,就會進行重組,以此來保證數(shù)據(jù)可靠性。到達服務器的 stream offset 會按照順序進行組裝,這同時也保證了數(shù)據(jù)的順序性。
眾所周知,TCP 協(xié)議的具體實現(xiàn)是由操作系統(tǒng)內(nèi)核來完成的,應用程序只能使用,不能對內(nèi)核進行修改,隨著移動端和越來越多的設備接入互聯(lián)網(wǎng),性能逐漸成為一個非常重要的衡量指標。雖然移動網(wǎng)絡發(fā)展的非常快,但是用戶端的更新卻非常緩慢,我仍然看見有很多地區(qū)很多計算機還仍舊使用 xp 系統(tǒng),盡管它早已發(fā)展了很多年。服務端系統(tǒng)不依賴用戶升級,但是由于操作系統(tǒng)升級涉及到底層軟件和運行庫的更新,所以也比較保守和緩慢。
QUIC 協(xié)議的一個重要特點就是可插拔性,能夠動態(tài)更新和升級,QUIC 在應用層實現(xiàn)了擁塞控制算法,不需要操作系統(tǒng)和內(nèi)核的支持,遇到擁塞控制算法切換時,只需要在服務器重新加載一邊即可,不需要停機和重啟。
我們知道 TCP 的流量控制是通過滑動窗口來實現(xiàn)的,如果你對滑動窗口不太熟悉,你可以看下我寫的這篇文章
TCP 基礎知識在文章后面有提到了滑動窗口的一些概念。
而 QUIC 也實現(xiàn)了流量控制,QUIC 的流量控制也是使用了窗口更新window_update,來告訴對端它可以接受的字節(jié)數(shù)。
TCP 協(xié)議頭部沒有經(jīng)過加密和認證,所以在傳輸?shù)倪^程中很可能被篡改,與之不同的是,QUIC 中的報文頭部都是經(jīng)過認證,報文也經(jīng)過加密處理。這樣只要對 QUIC 的報文有任何修改,接收端都能夠及時發(fā)現(xiàn),保證了安全性。
總的來說,QUIC 具有下面這些優(yōu)勢
使用 UDP 協(xié)議,不需要三次連接進行握手,而且也會縮短 TLS 建立連接的時間。解決了隊頭阻塞問題。實現(xiàn)動態(tài)可插拔,在應用層實現(xiàn)了擁塞控制算法,可以隨時切換。報文頭和報文體分別進行認證和加密處理,保障安全性。連接能夠平滑遷移。連接平滑遷移指的是,你的手機或者移動設備在 4G 信號下和 WiFi 等網(wǎng)絡情況下切換,不會斷線重連,用戶甚至無任何感知,能夠直接實現(xiàn)平滑的信號切換。
QUCI 協(xié)議已經(jīng)被寫在了RFC 9000中。
標簽: HTTP
- 焦點關注:HTTP/3 ,它來了,你學到了什么?
- 全新榮耀MagicBook14銳龍版即將發(fā)布 帶來10%的綜合性能提升
- 環(huán)球最資訊丨3GPP XR相關標準調(diào)研
- 全球信息:用戶“能用4G就絕不用5G”5G現(xiàn)在為何難討喜?
- 熱門:API 請求慢?這次鍋真不在后端
- 每日熱點:剖析Netty內(nèi)部網(wǎng)絡實現(xiàn)原理
- 天天快訊:HTTP/3來了!存續(xù)二十多年的TCP協(xié)議最終被拋棄!
- 雙重黑科技加持 諸多細節(jié)設計讓ROG魔霸6Plus戰(zhàn)力十足
- 觀熱點:SD-WAN的自動化以及為什么需要WAN加速
- 天天熱推薦:圖解網(wǎng)絡:訪問控制列表 ACL,功能堪比防火墻