QUIC協議簡史

QUIC簡史

QUIC(Quick UDP Internet Connection)是谷歌推出的一套基於UDP的傳輸協議,它實現了TCP + HTTPS + HTTP/2的功能,目的是保證可靠性的同時降低網絡延遲。因爲UDP是一個簡單傳輸協議,基於UDP可以擺脫TCP傳輸確認、重傳慢啓動等因素,建立安全連接只需要一的個往返時間,它還實現了HTTP/2多路複用、頭部壓縮等功能。

爲什麼要使用QUIC

衆所周知UDP比TCP傳輸速度快,TCP是可靠協議,但是代價就是 雙方確認數據而衍生的一系列消耗,可以參看《再深談TCP/IP三步握手&四步揮手原理及衍生問題—長文解剖IP》。其次TCP是系統內核實現的,如果升級TCP協議,就得讓用戶升級系統,這個的門檻比較高,而QUIC在UPD基礎上由客戶端自由發揮,只要有服務器能對接就可以

技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解_WX20180104-122733@2x.png

這些不止讓傳輸速度更快,多路複用等優勢,還可應付移動網絡裏面頻發的切換。這些都是quic的優勢。

 

QUIC優勢

連接建立延時低

QUIC只需要一次往返就能建立HTTPS連接

改進的擁塞控制

TCP 的擁塞控制實際上包含了四個算法:慢啓動,擁塞避免,快速重傳,快速恢復。

QUIC 協議當前默認使用了 TCP 協議的 Cubic 擁塞控制算法,同時也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制算法

 

QUIC的NACK比TCP的延遲確認機制高效

TCP 爲了保證可靠性,使用了基於字節序號的 Sequence Number 及 Ack 來確認消息的有序到達。

QUIC 同樣是一個可靠的協議,它使用 Packet Number 代替了 TCP 的 sequence number,並且每個 Packet Number 都嚴格遞增,也就是說就算 Packet N 丟失了,重傳的 Packet N 的 Packet Number 已經不是 N,而是一個比 N 大的值。而 TCP 呢,重傳 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不變,也正是由於這個特性,引入了 Tcp 重傳的歧義問題。

技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解_3.jpeg

 

在普通的TCP裏面,如果發送方收到三個重複的ACK就會觸發快速重傳,如果太久沒收到ACK就會觸發超時重傳,而使用NACK可以直接告知發送方哪些包丟了,不用等到超時重傳。TCP有一個SACK的選項,也具備NACK的功能,QUIC的NACK有一個區別它每次重傳的報文序號都是新的。

但是單純依靠嚴格遞增的 Packet Number 肯定是無法保證數據的順序性和可靠性。QUIC 又引入了一個 Stream Offset 的概念。

即一個 Stream 可以經過多個 Packet 傳輸,Packet Number 嚴格遞增,沒有依賴。但是 Packet 裏的 Payload 如果是 Stream 的話,就需要依靠 Stream 的 Offset 來保證應用數據的順序。如錯誤! 未找到引用源。所示,發送端先後發送了 Pakcet N 和 Pakcet N+1,Stream 的 Offset 分別是 x 和 x+y。

假設 Packet N 丟失了,發起重傳,重傳的 Packet Number 是 N+2,但是它的 Stream 的 Offset 依然是 x,這樣就算 Packet N + 2 是後到的,依然可以將 Stream x 和 Stream x+y 按照順序組織起來,交給應用程序處理。

技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解_4.jpeg

技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解_9.jpeg

FEC前向糾正擁塞控制

FEC是Forward Error Correction前向錯誤糾正的意思,就是通過多發一些冗餘的包,當有些包丟失時,可以通過冗餘的包恢復出來,而不用重傳。這個算法在多媒體網關擁塞控制有重要的地位。QUIC的FEC是使用的XOR的方式,即發N + 1個包,多發一個冗餘的包,在正常數據的N個包裏面任意一個包丟了,可以通過這個冗餘的包恢復出來,使用異或可以做到

切換網絡操持連接

經常會有從4G切換到wifi網絡或者是從wifi切換到4G網絡的場景,由於網絡的IP變了,導致需要重新建立連接,而QUIC使用一個ID來標誌連接,即使切換網絡也可以使用之前的建立連接的數據如交換的密鑰,而不用再重新HTTPS握手,不過切換的過程可能會導致有些包丟了,需要利用FEC恢復或者重傳。

不爲人知的網絡編程(六):深入地理解UDP協議並用好它_11.jpg

 

更安全的傳輸協議

TCP 協議頭部沒有經過任何加密和認證,所以在傳輸過程中很容易被中間網絡設備篡改,注入和竊聽。比如修改序列號、滑動窗口。這些行爲有可能是出於性能優化,也有可能是主動攻擊。

但是 QUIC 的 packet 可以說是武裝到了牙齒。除了個別報文比如 PUBLIC_RESET 和 CHLO,所有報文頭部都是經過認證的,報文 Body 都是經過加密的。

這樣只要對 QUIC 報文任何修改,接收端都能夠及時發現,有效地降低了安全風險。

如下圖所示,紅色部分是 Stream Frame 的報文頭部,有認證。綠色部分是報文內容,全部經過加密。

 

這一切,歸功於 UDP的不可靠 變爲可靠。

技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解_15.jpeg

強烈推薦:

讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享 https://www.cnblogs.com/jb2011/p/8458549.html

QUIC協議的分析,性能測試以及在QQ會員實踐 https://wetest.qq.com/lab/view/384.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章