QUIC 之类的可靠传输协议
互聯網是一個分組(或者稱為數據包)交換網絡,其中傳輸的數據的基本單位是數據包。互聯網中時時刻刻在發生的是距離有限的兩個路由節點之間通過物理鏈路的數據包交換。那互聯網中遠距離復雜環境下的數據傳輸究竟如何完成的呢?它們正是借助于多次路由節點間直接的這種數據交換完成的。直覺上就讓人覺得這種數據傳輸不是那么的可靠,不像電話網絡連接那樣。實際上互聯網的數據傳輸確實不是百分之百的可靠,互聯網上傳輸的數據天然地可能出現丟失,亂序,重復等等問題,但目前來看,絕大多數情況下,互聯網還是比較有效。
互聯網有效性的一個保證即是數據的可靠傳輸協議,如 TCP。TCP 對于當今的互聯網是如此的重要,以至于整個網絡協議棧被以 TCP/IP 來指代。通常情況下傳輸層協議及之下的協議由內核層實現,由硬件設備實現,之上的協議的數據,是我們平常寫的應用程序可以比較方便的拿到的數據。TCP 在內核實現了一套復雜的可靠傳輸的字節流的語義,而 UDP 在發送時,是在數據包的前面簡單的加個 IP 頭部等就發送出去,接收時簡單的剔除掉 IP 頭部就拋給應用層的數據包。除了 TCP,互聯網的可靠傳輸協議也多有基于 UDP 實現的,畢竟這類協議運行在用戶空間,不管是部署還是更新,都要方便得多,比如 RUDP,UDT 等,當然還有 QUIC。
不管是 TCP,還是基于 UDP 并運行于用戶空間的可靠傳輸協議,它們要解決的問題都是類似的,解決問題的方法也多有相似之處,在分析這些協議時也可以從類似的幾個角度入手。
提供給應用方的操作。可靠傳輸協議提供給應用方的操作,通常包含:
- 等待連接/接受連接的 listen/accept
- 建立連接的 connect
- 發送數據的 send/write
- 接收數據的 receive/read
- 關閉連接的 close/shutdown
可靠傳輸協議的連接的生命周期,通常包含:
- 建立連接。
- 數據傳輸及傳輸控制。
- 斷開連接。
斷開連接的過程,通常主要涉及資源的清理和容錯等,不太容易成為為了優化傳輸效率和安全性而開發的新協議的關注重點。而建立連接和數據傳輸控制方面,則是各種新方法新手段層出不窮。
連接建立過程主要為了協商傳輸參數及協議安全性而存在,不同的可靠傳輸協議有不同的看法及選擇,如 TCP 的 3 次握手,UDT 則是 4 次握手,這是其一,即一般的連接握手過程需要經過幾個 RTT。
數據傳輸過程中多一個 RTT,少一個 RTT 對于傳輸數據量很大的情況,可能沒有太大的影響,但對于當今互聯網中大量存在的數據量不大,如 REST API 訪問這種請求則有著顯著的影響,于是一些較新的協議會有減少連接建立過程中的 RTT 的嘗試。為了減少連接建立過程的 RTT,一般來說有幾種方法:一是嘗試增加狀態減少整體建連開銷,即第一次連接建立耗時較長,后續再建立連接時,耗時減少,如 TLS 的會話恢復,TCP 的 Fast Open 優化,QUIC 的 0 RTT 建連等;二是嘗試在建連的握手包中發送應用數據,如TCP 的 Fast Open 優化,QUIC 的 0 RTT 建連等;三是合并多個層次的協議的連接建立協商,如 QUIC 的合并可靠傳輸協議的協議協商和為了安全性的 TLS 的協議協商等;四是每次建立連接之后,試圖多傳一些數據,甚至是并發地傳數據,比如 HTTP/2 的連接復用,QUIC 的連接復用等;五新的連接標識及連接維護方法,如 QUIC 的連接遷移特性。
我們寫代碼時,都討厭狀態,能少一個狀態就少一個狀態。狀態幾乎難免要增加不同代碼和程序邏輯的耦合,增加部署維護成本,降低并發性,降低伸縮性等,然而為了更有效的網絡數據傳輸,許許多多的協議將狀態引入進來了。
然后是數據傳輸控制過程。無論哪種可靠傳輸協議,為了實現有效的可靠傳輸,發送緩沖區,接收緩沖區,數據包的接收確認,丟包/超時重傳,快速重傳,發送滑動窗口,接收滑動窗口,擁塞窗口擁塞控制等等幾乎都是必不可少的。
數據傳輸過程主要由數據發送方控制,數據發送方依據接收方的接收能力,對于網絡環境的探測感知,以及發送方的發送能力對發送過程進行控制。接收緩沖區和接收窗口代表數據接收方的數據接收能力,發送方的發送緩沖區代表發送方的發送能力,擁塞控制和擁塞窗口則代表發送方對于網絡環境狀態的感知,發送方主要綜合考慮接收窗口和擁塞窗口,來控制發送窗口的大小。
為了探測網絡狀況,類似于 TCP 的 CUBIC 算法幾乎總是無法避免的,慢啟動,擁塞避免,快速重傳,丟包/超時重傳等。為了充分利用當前網絡環境的網絡帶寬,慢啟動過程的初始擁塞窗口可以適當地調整的比之前大一些,如 UDT 的做法。為了更精確地感知網絡狀態和接收方的接收能力的變化,如 RTT 等,QUIC 引入了單調遞增的 Seqno,Ack Delay 時間,更多的 Ack 等特性,TCP 的數據包中總是會攜帶有接收窗口的大小,還有 HTTP/2 和 QUIC 中的 WINDOW_UPDATE 等。為了盡可能避免重傳,FEC 也常常作為一種優化手段。探測到網絡狀況之后,對于傳輸更精細的控制,則可以專門再來探討。
總結
以上是生活随笔為你收集整理的QUIC 之类的可靠传输协议的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: QUIC 之路
- 下一篇: Linux 下的 AddressSani