互聯(lián)網(wǎng)是一個(gè)分組（或者稱為數(shù)據(jù)包）交換網(wǎng)絡(luò)，其中傳輸?shù)臄?shù)據(jù)的基本單位是數(shù)據(jù)包。互聯(lián)網(wǎng)中時(shí)時(shí)刻刻在發(fā)生的是距離有限的兩個(gè)路由節(jié)點(diǎn)之間通過物理鏈路的數(shù)據(jù)包交換。那互聯(lián)網(wǎng)中遠(yuǎn)距離復(fù)雜環(huán)境下的數(shù)據(jù)傳輸究竟如何完成的呢？它們正是借助于多次路由節(jié)點(diǎn)間直接的這種數(shù)據(jù)交換完成的。直覺上就讓人覺得這種數(shù)據(jù)傳輸不是那么的可靠，不像電話網(wǎng)絡(luò)連接那樣。實(shí)際上互聯(lián)網(wǎng)的數(shù)據(jù)傳輸確實(shí)不是百分之百的可靠，互聯(lián)網(wǎng)上傳輸?shù)臄?shù)據(jù)天然地可能出現(xiàn)丟失，亂序，重復(fù)等等問題，但目前來看，絕大多數(shù)情況下，互聯(lián)網(wǎng)還是比較有效。

互聯(lián)網(wǎng)有效性的一個(gè)保證即是數(shù)據(jù)的可靠傳輸協(xié)議，如 TCP。TCP 對(duì)于當(dāng)今的互聯(lián)網(wǎng)是如此的重要，以至于整個(gè)網(wǎng)絡(luò)協(xié)議棧被以 TCP/IP 來指代。通常情況下傳輸層協(xié)議及之下的協(xié)議由內(nèi)核層實(shí)現(xiàn)，由硬件設(shè)備實(shí)現(xiàn)，之上的協(xié)議的數(shù)據(jù)，是我們平常寫的應(yīng)用程序可以比較方便的拿到的數(shù)據(jù)。TCP 在內(nèi)核實(shí)現(xiàn)了一套復(fù)雜的可靠傳輸?shù)淖止?jié)流的語(yǔ)義，而 UDP 在發(fā)送時(shí)，是在數(shù)據(jù)包的前面簡(jiǎn)單的加個(gè) IP 頭部等就發(fā)送出去，接收時(shí)簡(jiǎn)單的剔除掉 IP 頭部就拋給應(yīng)用層的數(shù)據(jù)包。除了 TCP，互聯(lián)網(wǎng)的可靠傳輸協(xié)議也多有基于 UDP 實(shí)現(xiàn)的，畢竟這類協(xié)議運(yùn)行在用戶空間，不管是部署還是更新，都要方便得多，比如 RUDP，UDT 等，當(dāng)然還有 QUIC。

不管是 TCP，還是基于 UDP 并運(yùn)行于用戶空間的可靠傳輸協(xié)議，它們要解決的問題都是類似的，解決問題的方法也多有相似之處，在分析這些協(xié)議時(shí)也可以從類似的幾個(gè)角度入手。

提供給應(yīng)用方的操作。可靠傳輸協(xié)議提供給應(yīng)用方的操作，通常包含：

• 等待連接/接受連接的 listen/accept
• 建立連接的 connect
• 發(fā)送數(shù)據(jù)的 send/write
• 接收數(shù)據(jù)的 receive/read
• 關(guān)閉連接的 close/shutdown

可靠傳輸協(xié)議的連接的生命周期，通常包含：

• 建立連接。
• 數(shù)據(jù)傳輸及傳輸控制。
• 斷開連接。

斷開連接的過程，通常主要涉及資源的清理和容錯(cuò)等，不太容易成為為了優(yōu)化傳輸效率和安全性而開發(fā)的新協(xié)議的關(guān)注重點(diǎn)。而建立連接和數(shù)據(jù)傳輸控制方面，則是各種新方法新手段層出不窮。

連接建立過程主要為了協(xié)商傳輸參數(shù)及協(xié)議安全性而存在，不同的可靠傳輸協(xié)議有不同的看法及選擇，如 TCP 的 3 次握手，UDT 則是 4 次握手，這是其一，即一般的連接握手過程需要經(jīng)過幾個(gè) RTT。

數(shù)據(jù)傳輸過程中多一個(gè) RTT，少一個(gè) RTT 對(duì)于傳輸數(shù)據(jù)量很大的情況，可能沒有太大的影響，但對(duì)于當(dāng)今互聯(lián)網(wǎng)中大量存在的數(shù)據(jù)量不大，如 REST API 訪問這種請(qǐng)求則有著顯著的影響，于是一些較新的協(xié)議會(huì)有減少連接建立過程中的 RTT 的嘗試。為了減少連接建立過程的 RTT，一般來說有幾種方法：一是嘗試增加狀態(tài)減少整體建連開銷，即第一次連接建立耗時(shí)較長(zhǎng)，后續(xù)再建立連接時(shí)，耗時(shí)減少，如 TLS 的會(huì)話恢復(fù)，TCP 的 Fast Open 優(yōu)化，QUIC 的 0 RTT 建連等；二是嘗試在建連的握手包中發(fā)送應(yīng)用數(shù)據(jù)，如TCP 的 Fast Open 優(yōu)化，QUIC 的 0 RTT 建連等；三是合并多個(gè)層次的協(xié)議的連接建立協(xié)商，如 QUIC 的合并可靠傳輸協(xié)議的協(xié)議協(xié)商和為了安全性的 TLS 的協(xié)議協(xié)商等；四是每次建立連接之后，試圖多傳一些數(shù)據(jù)，甚至是并發(fā)地傳數(shù)據(jù)，比如 HTTP/2 的連接復(fù)用，QUIC 的連接復(fù)用等；五新的連接標(biāo)識(shí)及連接維護(hù)方法，如 QUIC 的連接遷移特性。

我們寫代碼時(shí)，都討厭狀態(tài)，能少一個(gè)狀態(tài)就少一個(gè)狀態(tài)。狀態(tài)幾乎難免要增加不同代碼和程序邏輯的耦合，增加部署維護(hù)成本，降低并發(fā)性，降低伸縮性等，然而為了更有效的網(wǎng)絡(luò)數(shù)據(jù)傳輸，許許多多的協(xié)議將狀態(tài)引入進(jìn)來了。

然后是數(shù)據(jù)傳輸控制過程。無論哪種可靠傳輸協(xié)議，為了實(shí)現(xiàn)有效的可靠傳輸，發(fā)送緩沖區(qū)，接收緩沖區(qū)，數(shù)據(jù)包的接收確認(rèn)，丟包/超時(shí)重傳，快速重傳，發(fā)送滑動(dòng)窗口，接收滑動(dòng)窗口，擁塞窗口擁塞控制等等幾乎都是必不可少的。

數(shù)據(jù)傳輸過程主要由數(shù)據(jù)發(fā)送方控制，數(shù)據(jù)發(fā)送方依據(jù)接收方的接收能力，對(duì)于網(wǎng)絡(luò)環(huán)境的探測(cè)感知，以及發(fā)送方的發(fā)送能力對(duì)發(fā)送過程進(jìn)行控制。接收緩沖區(qū)和接收窗口代表數(shù)據(jù)接收方的數(shù)據(jù)接收能力，發(fā)送方的發(fā)送緩沖區(qū)代表發(fā)送方的發(fā)送能力，擁塞控制和擁塞窗口則代表發(fā)送方對(duì)于網(wǎng)絡(luò)環(huán)境狀態(tài)的感知，發(fā)送方主要綜合考慮接收窗口和擁塞窗口，來控制發(fā)送窗口的大小。

為了探測(cè)網(wǎng)絡(luò)狀況，類似于 TCP 的 CUBIC 算法幾乎總是無法避免的，慢啟動(dòng)，擁塞避免，快速重傳，丟包/超時(shí)重傳等。為了充分利用當(dāng)前網(wǎng)絡(luò)環(huán)境的網(wǎng)絡(luò)帶寬，慢啟動(dòng)過程的初始擁塞窗口可以適當(dāng)?shù)卣{(diào)整的比之前大一些，如 UDT 的做法。為了更精確地感知網(wǎng)絡(luò)狀態(tài)和接收方的接收能力的變化，如 RTT 等，QUIC 引入了單調(diào)遞增的 Seqno，Ack Delay 時(shí)間，更多的 Ack 等特性，TCP 的數(shù)據(jù)包中總是會(huì)攜帶有接收窗口的大小，還有 HTTP/2 和 QUIC 中的 WINDOW_UPDATE 等。為了盡可能避免重傳，FEC 也常常作為一種優(yōu)化手段。探測(cè)到網(wǎng)絡(luò)狀況之后，對(duì)于傳輸更精細(xì)的控制，則可以專門再來探討。

總結(jié)

以上是生活随笔為你收集整理的QUIC 之类的可靠传输协议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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