當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？

發(fā)布時(shí)間：2025/3/20 编程问答 41 豆豆

生活随笔收集整理的這篇文章主要介紹了不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

本文內(nèi)容來自學(xué)霸君資深架構(gòu)師袁榮喜的技術(shù)分享。

1、前言

最近和很多實(shí)時(shí)音視頻領(lǐng)域的朋友交流中都有談?wù)摰?RUDP(Reliable UDP)，這其實(shí)是個(gè)老生常談的問題，RUDP 在很多著名的項(xiàng)目上都有使用，例如 Google 的 QUIC 和?WebRTC。在 UDP 之上做一層可靠，很多朋友認(rèn)為這是很不靠譜的事情，也有朋友認(rèn)為這是一個(gè)大殺器，可以解決實(shí)時(shí)領(lǐng)域里大部分問題。

作為教育公司，學(xué)霸君APP在很多實(shí)時(shí)場(chǎng)景下確實(shí)使用了 RUDP 技術(shù)來解決我們的問題，不同場(chǎng)景我們采用的 RUDP 方式也不一樣。

先來看看我們哪些場(chǎng)景使用了 RUDP：

1）全局 250 毫秒延遲的實(shí)時(shí) 1V1 答疑，采用的是 RUDP + 多點(diǎn) relay 智能路由方案；

2）500 毫秒 1080P 視頻連麥互動(dòng)系統(tǒng)，采用的是 RUDP + PROXY 調(diào)度傳輸方案；

3）6 方實(shí)時(shí)同步書寫系統(tǒng)，采用的是 RUDP+redo log 的可靠傳輸技術(shù)；

4）弱網(wǎng) Wi-Fi 下 Pad 的 720P 同屏傳輸系統(tǒng)，采用的是 RUDP +GCC 實(shí)時(shí)流控技術(shù)；

5）大型直播的 P2P 分發(fā)系統(tǒng)，通過 RUDP + 多點(diǎn)并聯(lián) relay 技術(shù)節(jié)省了 75% 以上的分發(fā)帶寬。

涉及到實(shí)時(shí)傳輸我們都會(huì)先考慮 RUDP，RUDP 應(yīng)用在我們APP核心傳輸體系的各個(gè)方面，但不同的系統(tǒng)場(chǎng)景我們?cè)O(shè)計(jì)了不同的 RUDP 方式，所以基于那些激烈的討論和我們使用的經(jīng)驗(yàn)，我決定扒一扒 RUDP，來給大家分享如何讓UDP變的可靠的實(shí)踐經(jīng)驗(yàn)。

學(xué)習(xí)交流：

- 即時(shí)通訊開發(fā)交流群：320837163[推薦]

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-1293-1-1.html）

2、系列文章

本文是系列文章中的第7篇（完結(jié)篇），本系列文章的大綱如下：

《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》

《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》

《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》

《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》

《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》

《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》

《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》（本文）

如果您覺得本系列文章過于專業(yè)，您可先閱讀《網(wǎng)絡(luò)編程懶人入門》系列文章，該系列目錄如下：

《網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》

《網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》

《網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》

《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說UDP有時(shí)比TCP更有優(yōu)勢(shì)》

3、參考資料

《TCP/IP詳解?-?第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》

《為什么QQ用的是UDP協(xié)議而不是TCP協(xié)議？》

《移動(dòng)端IM/推送系統(tǒng)的協(xié)議選型：UDP還是TCP？》

《簡(jiǎn)述傳輸層協(xié)議TCP和UDP的區(qū)別》

《UDP中一個(gè)包的大小最大能多大》

《為什么說基于TCP的移動(dòng)端IM仍然需要心跳?；?#xff1f;》

4、UDP的三角制約原則

其實(shí)在實(shí)時(shí)通信領(lǐng)域存在一個(gè)三角平衡關(guān)系——成本、質(zhì)量和時(shí)延三者的制約關(guān)系：

也就是說投入的成本、獲得的質(zhì)量和通信的時(shí)延之間是一個(gè)三角制約 (LEQ) 關(guān)系，所以實(shí)時(shí)通信系統(tǒng)的設(shè)計(jì)者會(huì)在這三個(gè)制約條件下找到一個(gè)平衡點(diǎn)，TCP 屬于通過增大延遲和傳輸成本來保證質(zhì)量的通信方式，UDP 是通過犧牲質(zhì)量來保證時(shí)延和成本的通信方式，所以在一些特定場(chǎng)景下 RUDP 更容易找到這樣的平衡點(diǎn)。RUDP 是怎么去找這個(gè)平衡點(diǎn)的，就要先從 RUDP 的可靠概念和使用場(chǎng)景來分析。

5、實(shí)時(shí)通信中什么是“可靠”

在實(shí)時(shí)通信過程中，不同的需求場(chǎng)景對(duì)可靠的需求是不一樣的，我們?cè)谶@里總體歸納為三類定義：

1）盡力可靠：通信的接收方要求發(fā)送方的數(shù)據(jù)盡量完整到達(dá)，但業(yè)務(wù)本身的數(shù)據(jù)是可以允許缺失的。例如：音視頻數(shù)據(jù)、冪等性狀態(tài)數(shù)據(jù)。；

2）無序可靠：通信的接收方要求發(fā)送方的數(shù)據(jù)必須完整到達(dá)，但可以不管到達(dá)先后順序。例如：文件傳輸、白板書寫、圖形實(shí)時(shí)繪制數(shù)據(jù)、日志型追加數(shù)據(jù)等；

3）有序可靠：通信接收方要求發(fā)送方的數(shù)據(jù)必須按順序完整到達(dá)。

RUDP 是根據(jù)這三類需求和上節(jié)圖中的三角制約關(guān)系來確定自己的通信模型和機(jī)制的，也就是找通信的平衡點(diǎn)。

6、UDP 為什么要可靠

說到這里可能很多人會(huì)說：干嘛那么麻煩，直接用 TCP 好了！?

確實(shí)很多人也都是這樣做的，TCP 是個(gè)基于公平性的可靠通信協(xié)議，但是在一些苛刻的網(wǎng)絡(luò)條件下 TCP 要么不能提供正常的通信質(zhì)量保證，要么成本過高。為什么要在 UDP 之上做可靠保證，究其原因就是在保證通信的時(shí)延和質(zhì)量的條件下盡量降低成本。

RUDP 主要解決以下相關(guān)問題：

1）端對(duì)端連通性問題：

一般終端直接和終端通信都會(huì)涉及到 NAT 穿越，TCP 在 NAT 穿越實(shí)現(xiàn)非常困難，相對(duì)來說 UDP 穿越 NAT 卻簡(jiǎn)單很多，如果是端到端的可靠通信一般用 RUDP 方式來解決，場(chǎng)景有：端到端的文件傳輸、實(shí)時(shí)音視頻傳輸、交互指令傳輸?shù)鹊?#xff1b;

2）弱網(wǎng)環(huán)境傳輸問題：

在一些 Wi-Fi 或者 3G/4G 移動(dòng)網(wǎng)下，需要做低延遲可靠通信，如果用 TCP 通信延遲可能會(huì)非常大，這會(huì)影響用戶體驗(yàn)。例如：實(shí)時(shí)的操作類網(wǎng)游通信、語音對(duì)話、多方白板書寫等，這些場(chǎng)景可以采用特殊的 RUDP 方式來解決這類問題；

3）帶寬競(jìng)爭(zhēng)問題：

有時(shí)候客戶端數(shù)據(jù)上傳需要突破本身 TCP 公平性的限制來達(dá)到高速低延時(shí)和穩(wěn)定，也就是說要用特殊的流控算法來壓榨客戶端上傳帶寬，例如：直播音視頻推流，這類場(chǎng)景用 RUDP 來實(shí)現(xiàn)不僅能壓榨帶寬，也能更好地增加通信的穩(wěn)定性，避免類似 TCP 的頻繁斷開重連；

4）傳輸路徑優(yōu)化問題：

在一些對(duì)延時(shí)要求很高的場(chǎng)景下，會(huì)用應(yīng)用層 relay 的方式來做傳輸路由優(yōu)化，也就是動(dòng)態(tài)智能選路，這時(shí)雙方采用 RUDP 方式來傳輸，中間的延遲進(jìn)行 relay 選路優(yōu)化延時(shí)。還有一類基于傳輸吞吐量的場(chǎng)景，例如：服務(wù)與服務(wù)之間數(shù)據(jù)分發(fā)、數(shù)據(jù)備份等，這類場(chǎng)景一般會(huì)采用多點(diǎn)并聯(lián) relay 來提高傳輸?shù)乃俣?#xff0c;也是要建立在 RUDP 上的（這兩點(diǎn)在后面著重來描述）；

5）資源優(yōu)化問題：

某些場(chǎng)景為了避免 TCP 的三次握手和四次揮手的過程，會(huì)采用 RUDP 來優(yōu)化資源的占用率和響應(yīng)時(shí)間，提高系統(tǒng)的并發(fā)能力，例如 QUIC。

不管哪類場(chǎng)景，都是要保證可靠性，也就是質(zhì)量，那么在 UDP 之上怎么實(shí)現(xiàn)可靠呢？答案就是重傳。

7、重傳模式

IP 協(xié)議在設(shè)計(jì)的時(shí)候就不是為了數(shù)據(jù)可靠到達(dá)而設(shè)計(jì)的，所以 UDP 要保證可靠，就依賴于重傳，這也就是我們通常意義上的 RUDP 行為。

在描述 RUDP 重傳之前先來了解下 RUDP 基本框架，如圖：

RUDP 分為發(fā)送端和接收端，每一種 RUDP 在設(shè)計(jì)的時(shí)候會(huì)做不一樣的選擇和精簡(jiǎn)，概括起來就是圖中的單元。RUDP 的重傳是發(fā)送端通過接收端 ACK 的丟包信息反饋來進(jìn)行數(shù)據(jù)重傳，發(fā)送端會(huì)根據(jù)場(chǎng)景來設(shè)計(jì)自己的重傳方式，重傳方式分為三類：定時(shí)重傳、請(qǐng)求重傳和 FEC 選擇重傳。

7.1 定時(shí)重傳

定時(shí)重傳很好理解，就是發(fā)送端如果在發(fā)出數(shù)據(jù)包（T1）時(shí)刻一個(gè) RTO 之后還未收到這個(gè)數(shù)據(jù)包的 ACK 消息，那么發(fā)送端就重傳這個(gè)數(shù)據(jù)包。這種方式依賴于接收端的 ACK 和 RTO，容易產(chǎn)生誤判，主要有兩種情況：

1）對(duì)方收到了數(shù)據(jù)包，但是 ACK 發(fā)送途中丟失；

2）ACK 在途中，但是發(fā)送端的時(shí)間已經(jīng)超過了一個(gè) RTO。

所以超時(shí)重傳的方式主要集中在 RTO 的計(jì)算上，如果你的場(chǎng)景是一個(gè)對(duì)延遲敏感但對(duì)流量成本要求不高的場(chǎng)景，就可以將 RTO 的計(jì)算設(shè)計(jì)得比較小，這樣能盡最大可能保證你的延時(shí)足夠小。

例如：實(shí)時(shí)操作類網(wǎng)游、教育領(lǐng)域的書寫同步，是典型的用 expense 換 latency 和 quality 的場(chǎng)景，適合用于小帶寬低延遲傳輸。如果是大帶寬實(shí)時(shí)傳輸，定時(shí)重傳對(duì)帶寬的消耗是很大的，極端情況會(huì)有 20% 的重傳率，所以在大帶寬模式下一般會(huì)采用請(qǐng)求重傳模式。

7.2 請(qǐng)求重傳

請(qǐng)求重傳就是接收端在發(fā)送 ACK 的時(shí)候攜帶自己丟失報(bào)文的信息反饋，發(fā)送端接收到 ACK 信息時(shí)根據(jù)丟包反饋進(jìn)行報(bào)文重傳。

如下圖：

這個(gè)反饋過程最關(guān)鍵的步驟就是回送 ACK 的時(shí)候應(yīng)該攜帶哪些丟失報(bào)文的信息，因?yàn)?UDP 在網(wǎng)絡(luò)傳輸過程中會(huì)亂序會(huì)抖動(dòng)，接收端在通信的過程中要評(píng)估網(wǎng)絡(luò)的 jitter time，也就是 rtt_var（RTT 方差值），當(dāng)發(fā)現(xiàn)丟包的時(shí)候記錄一個(gè)時(shí)刻 t1，當(dāng) t1 + rtt_var < curr_t(當(dāng)前時(shí)刻)，我們就認(rèn)為它丟失了。

這個(gè)時(shí)候后續(xù)的 ACK 就需要攜帶這個(gè)丟包信息并更新丟包時(shí)刻 t2，后續(xù)持續(xù)掃描丟包隊(duì)列，如果 t2 + RTO

這種方式是由丟包請(qǐng)求引起的重發(fā)，如果網(wǎng)絡(luò)很不好，接收端會(huì)不斷發(fā)起重傳請(qǐng)求，造成發(fā)送端不停的重傳，引起網(wǎng)絡(luò)風(fēng)暴，通信質(zhì)量會(huì)下降，所以我們?cè)诎l(fā)送端設(shè)計(jì)一個(gè)擁塞控制模塊來限流，這個(gè)后面我們重點(diǎn)分析。

整個(gè)請(qǐng)求重傳機(jī)制依賴于 jitter time 和 RTO 這個(gè)兩個(gè)時(shí)間參數(shù)，評(píng)估和調(diào)整這兩個(gè)參數(shù)和對(duì)應(yīng)的傳輸場(chǎng)景也息息相關(guān)。請(qǐng)求重傳這種方式比定時(shí)重傳方式的延遲會(huì)大，一般適合于帶寬較大的傳輸場(chǎng)景，例如：視頻、文件傳輸、數(shù)據(jù)同步等。

7.3 FEC 選擇重傳

除了定時(shí)重傳和請(qǐng)求重傳模式以外，還有一種方式就是以 FEC 分組方式選擇重傳，FEC（Forward Error Correction）是一種前向糾錯(cuò)技術(shù)，一般通過 XOR 類似的算法來實(shí)現(xiàn)，也有多層的 EC 算法和 raptor 涌泉碼技術(shù)，其實(shí)是一個(gè)解方程的過程。

應(yīng)用到 RUDP 上示意圖如下：

在發(fā)送方發(fā)送報(bào)文的時(shí)候，會(huì)根據(jù) FEC 方式把幾個(gè)報(bào)文進(jìn)行 FEC 分組，通過 XOR 的方式得到若干個(gè)冗余包，然后一起發(fā)往接收端，如果接收端發(fā)現(xiàn)丟包但能通過 FEC 分組算法還原，就不向發(fā)送端請(qǐng)求重傳，如果分組內(nèi)包是不能進(jìn)行 FEC 恢復(fù)的，就向發(fā)送端請(qǐng)求原始的數(shù)據(jù)包。

FEC 分組方式適合解決要求延時(shí)敏感且隨機(jī)丟包的傳輸場(chǎng)景，在一個(gè)帶寬不是很充裕的傳輸條件下，FEC 會(huì)增加多余的包，可能會(huì)使得網(wǎng)絡(luò)更加不好。FEC 方式不僅可以配合請(qǐng)求重傳模式，也可以配合定時(shí)重傳模式。

8、RTT 與 RTO 的計(jì)算

在上面介紹重傳模式時(shí)多次提到 RTT、RTO 等時(shí)間度量，RTT（Round Trip Time）即網(wǎng)絡(luò)環(huán)路延時(shí)，環(huán)路延遲是通過發(fā)送的數(shù)據(jù)包和接收到的 ACK 包計(jì)算的，示意圖如下：

RTT = T2 - T1：

這個(gè)計(jì)算方式只是計(jì)算了某一個(gè)報(bào)文時(shí)刻的 RTT，但網(wǎng)絡(luò)是會(huì)波動(dòng)的，這難免會(huì)有噪聲現(xiàn)象，所以在計(jì)算的過程中引入了加權(quán)平均收斂的方法（具體可以參考?RFC793）。

SRTT = (α * SRTT) + (1-α)RTT：

這樣可以求得逼近的 SRTT，在公式中一般α=0.8，確定了 SRTT，下一步就是計(jì)算 RTT_VAR(方差)，我們?cè)O(shè) RTT_VAR = |SRTT – RTT|，那么 SRTT_VAR =(α * SRTT_VAR) + (1-α) RTT_VAR，這樣可以得到 RTT_VAR 的值。

但最終我們是需要 RTO，因?yàn)樯婕暗綀?bào)文重傳，RTO 就是一個(gè)報(bào)文的重傳周期，從網(wǎng)絡(luò)的通信流程我們很容易知道，重傳一個(gè)包以后，如果一個(gè) RTT+RTT_VAR 之后的時(shí)間還沒收到確定，那我們就可以再次重傳，則可知：RTO = SRTT + SRTT_VAR。

但一般網(wǎng)絡(luò)在嚴(yán)重抖動(dòng)的情況下還是會(huì)有較大的重復(fù)率問題，所以：RTO = β*(SRTT + RTT_VAR)，1.2 <β<2.0，可以根據(jù)不同的傳輸場(chǎng)景來選擇β的值。

9、窗口與擁塞控制

RUDP 是通過重傳來保證可靠的，重傳在三角平衡關(guān)系中其實(shí)是用 expense 和 latency 來換取 quality 的行為，所以重傳會(huì)引來兩個(gè)問題，一個(gè)是延時(shí)，一個(gè)是重傳的帶寬，尤其是后者，如果控制不好會(huì)引來網(wǎng)絡(luò)風(fēng)暴，所以在發(fā)送端會(huì)設(shè)計(jì)一個(gè)窗口擁塞機(jī)制了避免并發(fā)帶寬占用過高的問題。

9.1 窗口

RUDP 需要一個(gè)收發(fā)的滑動(dòng)窗口系統(tǒng)來配合對(duì)應(yīng)的擁塞算法做流量控制，有些 RUDP 需要發(fā)送端和接收端的窗口嚴(yán)格地對(duì)應(yīng)，有些 RUDP 不要求收發(fā)窗口嚴(yán)格對(duì)應(yīng)。如果涉及到可靠有序的 RUDP，接收端就要做窗口排序和緩沖，如果是無序可靠或者盡力可靠的場(chǎng)景，接收端一般就不做窗口緩沖，只做位置滑動(dòng)。

先來看收發(fā)窗口關(guān)系圖：

上圖描述的是發(fā)送端從發(fā)送窗口中發(fā)了 6 個(gè)數(shù)據(jù)報(bào)文給接收端，接收端收到 101，102，103，106 時(shí)會(huì)先判斷報(bào)文的連續(xù)性并滑動(dòng)窗口開始位置到 103，接著每個(gè)包都回應(yīng) ACK，發(fā)送端在接收到 ACK 的時(shí)候，會(huì)確認(rèn)報(bào)文的連續(xù)性，并滑動(dòng)窗口到 103，發(fā)送端會(huì)再判斷窗口的空余，然后填補(bǔ)新的發(fā)送數(shù)據(jù)，這就是整個(gè)窗口滑動(dòng)的流程。

這里值的一提的是在接收端收到 106 時(shí)的處理，如果是有序可靠，那么 106 不會(huì)通知上層業(yè)務(wù)進(jìn)行處理，而是等待 104、105。如果是盡力可靠和無序可靠場(chǎng)景，會(huì)將 106 通知給上層業(yè)務(wù)先進(jìn)行處理。在收到 ACK 后，發(fā)送端的窗口要滑動(dòng)多少是由自己的擁塞機(jī)制定的，也就是說窗口的滑動(dòng)速度受擁塞機(jī)制控制，擁塞控制實(shí)現(xiàn)要么基于丟包率來實(shí)現(xiàn)，要么基于雙方的通信時(shí)延來實(shí)現(xiàn)，下面來看幾種典型的擁塞控制。

9.2 經(jīng)典擁塞算法

TCP 經(jīng)典擁塞算法分為四個(gè)部分：慢啟動(dòng)、擁塞避免、擁塞處理和快速恢復(fù)，這四個(gè)部分都是為了決定發(fā)送窗口和發(fā)送速度而設(shè)計(jì)的，其實(shí)就是為了在當(dāng)前網(wǎng)絡(luò)條件下通過網(wǎng)絡(luò)丟包來判斷網(wǎng)絡(luò)擁塞狀態(tài)，從而確定比較適合的發(fā)送傳輸窗口。

經(jīng)典算法是建立在定時(shí)重傳的基礎(chǔ)上的，如果 RUDP 采用這種算法來做擁塞控制，一般的場(chǎng)景是為了保證有序可靠傳輸?shù)耐瑫r(shí)又兼顧網(wǎng)絡(luò)傳輸?shù)墓叫栽瓌t。先逐個(gè)來解釋下這幾部分。

慢啟動(dòng)（slow start）：

當(dāng)連接鏈路剛剛建立后，不可能一開始將 cwnd 設(shè)置得很大，這樣容易造成大量重傳，經(jīng)典擁塞里面會(huì)在開始將 cwnd = 1，然后根據(jù)通信過程的丟包情況來逐步擴(kuò)大 cwnd 來適應(yīng)當(dāng)前的網(wǎng)絡(luò)狀態(tài)，直到達(dá)到慢啟動(dòng)的門限閾值 (ssthresh)，步驟如下：

1）初始化設(shè)置 cwnd = 1，并開始傳輸數(shù)據(jù)；

2）收到回饋的 ACK，會(huì)將 cwnd 加 1；

3）當(dāng)發(fā)送端一個(gè) RTT 后且未發(fā)現(xiàn)有丟包重傳，就會(huì)將 cwnd = cwnd * 2；

4）當(dāng) cwnd >= ssthresh 或發(fā)生丟包重傳時(shí)慢啟動(dòng)結(jié)束，進(jìn)入擁塞避免狀態(tài)。

擁塞避免：

當(dāng)通信連接結(jié)束慢啟動(dòng)后，有可能還未到網(wǎng)絡(luò)傳輸速度的上線，這個(gè)時(shí)候需要進(jìn)一步通過一個(gè)緩慢的調(diào)節(jié)過程來進(jìn)行適配。一般是一個(gè) RTT 后如果未發(fā)現(xiàn)丟包，就將 cwnd = cwnd + 1。一但發(fā)現(xiàn)丟包和超時(shí)重傳，就進(jìn)入擁塞處理狀態(tài)。

擁塞處理：

擁塞處理在 TCP 里面實(shí)現(xiàn)很暴力，如果發(fā)生丟包重傳，直接將 cwnd = cwnd / 2，然后進(jìn)入快速恢復(fù)狀態(tài)。

快速恢復(fù)：

通過確認(rèn)丟包只發(fā)生在窗口一個(gè)位置的包來確定是否進(jìn)行快速恢復(fù)，如圖 6 中描述，如果只是 104 發(fā)生了丟失，而 105 和 106 是收到了的，那么 ACK 總是會(huì)將 ACK 的 base = 103，如果連續(xù) 3 次收到 base 為 103 的 ACK，就進(jìn)行快速恢復(fù)，也就是立即重傳 104，而后如果收到新的 ACK 且 base > 103，將 cwnd = cwnd + 1，并進(jìn)入擁塞避免狀態(tài)。

經(jīng)典擁塞控制是基于丟包檢測(cè)和定時(shí)重傳模式來設(shè)計(jì)的，在三角平衡關(guān)系中是一個(gè)典型的以 latency 換取 quality 的案例，但由于其公平性設(shè)計(jì)避免了過高的 expense，也就會(huì)讓這種傳輸方式很難壓榨網(wǎng)絡(luò)帶寬，很難保證網(wǎng)絡(luò)的大吞吐量和小時(shí)延。

9.3 BBR 擁塞算法

對(duì)于經(jīng)典擁塞算法的延遲和帶寬壓榨問題 Google 設(shè)計(jì)了基于發(fā)送端延遲和帶寬評(píng)估的 BBR 擁塞控制算法。

這種擁塞算法致力于解決兩個(gè)問題：

1）在一定丟包率網(wǎng)絡(luò)傳輸鏈路上充分利用帶寬；

2）降低網(wǎng)絡(luò)傳輸中的 buffer 延遲。

BBR 的主要策略是周期性通過 ACK 和 NACK 返回來評(píng)估鏈路的 min_rtt 和 max_bandwidth。最大吞吐量（cwnd）的大小就是：cwnd = max_bandwidth / min_rtt。

傳輸模型如下：

BBR 整個(gè)擁塞控制是一個(gè)探測(cè)帶寬和 Pacing rate 的狀態(tài)，有 4 個(gè)狀態(tài)：

1）Startup：啟動(dòng)狀態(tài)（相當(dāng)于慢啟動(dòng)），增益參數(shù)為 max_gain??= 2.85；

2）DRAIN：滿負(fù)荷傳輸狀態(tài)；

3）PROBE_BW：帶寬評(píng)估狀態(tài)，通過一個(gè)較小的 BBR 增益參數(shù)來遞增（1.25）或者遞減 (0.75)；

4）PROBE_RTT：延遲評(píng)估狀態(tài)，通過維持一個(gè)最小發(fā)送窗口（4 個(gè) MSS）進(jìn)行的 RTT 采樣。

那么這幾種狀態(tài)是怎么來回切換的呢？以下是 QUIC 中 BBR 大致的步驟如下：

1）初始化連接時(shí)會(huì)設(shè)置一個(gè)初始的 cwnd = 8，并將狀態(tài)設(shè)置 Startup；

2）在 Startup 下發(fā)送數(shù)據(jù)，根據(jù) ACK 數(shù)據(jù)的采樣周期性判斷是否可以增加帶寬，如果可以，將 cwnd = cwnd *max_gain。如果時(shí)間周期數(shù)超過了預(yù)設(shè)的啟動(dòng)周期時(shí)間或者發(fā)生了丟包，進(jìn)行 DRAIN 狀態(tài)；

3）在 DRAIN 狀態(tài)下，如果 flight_size(發(fā)送出去但還未確認(rèn)的數(shù)據(jù)大小) >cwnd, 繼續(xù)保證 DRAIN 狀態(tài)，如果 flight_size

4）在PROBE_BW狀態(tài)下，如果未發(fā)生丟包且flight_size cwnd，將cwnd = cwnd * 1.25，如果發(fā)生丟包，cwnd = cwnd * 0.75；

5）在 Startup/DRAIN/PROBE_BW 三個(gè)狀態(tài)中，如果持續(xù) 10 秒鐘的通信中沒有出現(xiàn) RTT <= min_rtt，就會(huì)進(jìn)入到 PROBE_RTT 狀態(tài)，并將 cwnd = 4 *MSS；

6）在 PROBE_RTT 狀態(tài)，會(huì)在收到 ACK 返回的時(shí)候持續(xù)判斷 flight_size >= cwnd 并且無丟包，將本次統(tǒng)計(jì)的最小 RTT 作為 min_rtt，進(jìn)入 Startup 狀態(tài)。

BBR 通過以上幾個(gè)步驟來周期性計(jì)算 cwnd，也就是網(wǎng)絡(luò)最大吞吐量和最小延遲，然后通過 pacing rate 來確定這一時(shí)刻發(fā)送端的碼率，最終達(dá)到擁塞控制的目的。

BBR 適合在隨機(jī)丟包且網(wǎng)絡(luò)穩(wěn)定的情況下做擁塞，如果在網(wǎng)絡(luò)信號(hào)極不穩(wěn)定的 Wi-Fi 或者 4G 上，容易出現(xiàn)網(wǎng)絡(luò)泛洪和預(yù)測(cè)不準(zhǔn)的問題，BBR 在多連接公平性上也存在小 RTT 的連接比大 RTT 的連接更吃帶寬的情況，容易造成大 RTT 的連接速度過慢的情況。BBR 擁塞算法在三角平衡關(guān)系中是采用 expense 換取 latency 和 quality 的案例。

9.4 WebRTC GCC

說到實(shí)時(shí)音視頻傳輸就必然會(huì)想到開源實(shí)時(shí)音視頻工程WebRTC，在 WebRTC 中對(duì)于視頻傳輸也實(shí)現(xiàn)了一個(gè)擁塞控制算法 (GCC)，WebRTC 的 GCC 是一個(gè)基于發(fā)送端丟包率和接收端延遲帶寬統(tǒng)計(jì)的擁塞控制，而且是一個(gè)盡力可靠的傳輸算法，在傳輸?shù)倪^程中如果一個(gè)報(bào)文重發(fā)太多次后會(huì)直接丟棄，這符合視頻傳輸?shù)膱?chǎng)景（更多 WebRTC 文章點(diǎn)此進(jìn)入）。

借用一張圖來看個(gè)究竟：

（本圖來自：《WebRTC基于GCC的擁塞控制(上) - 算法分析》一文）

GCC 的發(fā)送端會(huì)根據(jù)丟包率和一個(gè)對(duì)照表來 pacing rate，當(dāng) loss < 2% 時(shí)，會(huì)加大傳輸帶寬，當(dāng) loss >=2% &&loss <10%，會(huì)保持當(dāng)前碼率，當(dāng) loss>=10%，會(huì)認(rèn)為傳輸過載，進(jìn)行調(diào)小傳輸帶寬。

GCC 的接收端是根據(jù)數(shù)據(jù)到達(dá)的延遲方差和大小進(jìn)行 KalmanFilter 進(jìn)行帶寬逼近收斂，具體的細(xì)節(jié)不介紹了，請(qǐng)查看：《WebRTC視頻接收緩沖區(qū)基于KalmanFilter的延遲模型》。

這里值得一說的是 GCC 引入接收端對(duì)帶寬進(jìn)行 KalmanFilter 評(píng)估是一個(gè)非常新穎的擁塞控制思路，如果實(shí)現(xiàn)一個(gè)盡力可靠的 RUDP 傳輸系統(tǒng)不失為是一個(gè)很好的參考。

但這種算法也有個(gè)缺陷，就是在網(wǎng)絡(luò)間歇性丟包情況下，GCC 可能收斂的速度比較慢，在一定程度上有可能會(huì)造成 REMB 很難反饋給發(fā)送端，容易出現(xiàn)發(fā)送端流控失效。GCC 在三角平衡關(guān)系算一個(gè)以 quality 和 expense 換取 latency 的案例。

9.5 弱窗口擁塞機(jī)制

其實(shí)在很多場(chǎng)景是不用擁塞控制或者只要很弱的擁塞控制即可，例如：師生雙方書寫同步、實(shí)時(shí)游戲，因?yàn)楸旧淼膫鬏數(shù)臄?shù)據(jù)量不大，只要保證足夠小的延時(shí)和可靠性就行，一般會(huì)采用固定窗口大小來進(jìn)行流控，我們?cè)谙到y(tǒng)中一般采用一個(gè) cwnd =32 這樣的窗口來做流控，ACK 確認(rèn)也是通過整個(gè)接收窗口數(shù)據(jù)狀態(tài)反饋給發(fā)送方，簡(jiǎn)單直接，也很容易適應(yīng)弱網(wǎng)環(huán)境。

10、傳輸路徑

RUDP 除了優(yōu)化連接、壓榨帶寬、適應(yīng)弱網(wǎng)環(huán)境等以外，它也繼承了 UDP 天然的動(dòng)態(tài)性，可以在中間應(yīng)用層鏈路上做傳輸優(yōu)化，一般分為多點(diǎn)串聯(lián)優(yōu)化和多點(diǎn)并聯(lián)優(yōu)化。我們具體來說一說。

10.1 多點(diǎn)串聯(lián) relay

在實(shí)時(shí)通信中一些業(yè)務(wù)場(chǎng)景對(duì)延遲非常敏感，例如：實(shí)時(shí)語音、同步書寫、實(shí)時(shí)互動(dòng)、直播連麥等，如果單純的服務(wù)中轉(zhuǎn)或者 P2P 通信，很難滿足其需求，尤其是在物理距離很大的情況下。

在解決這個(gè)問題上 SKYPE 率先提出全球 RTN（實(shí)時(shí)多點(diǎn)傳輸網(wǎng)絡(luò)），其實(shí)就是在通信雙方之間通過幾個(gè) relay 節(jié)點(diǎn)來動(dòng)態(tài)智能選路，這種傳輸方式很適合 RUDP，我們只要在通信雙方構(gòu)建一個(gè) RUDP 通道，中間鏈路只是一個(gè)無狀態(tài)的 relay cache 集合，relay 與 relay 之間進(jìn)行路由探測(cè)和選路，以此來做到鏈路的高可用和實(shí)時(shí)性。

如下圖：

通過多點(diǎn) relay 來保證 RUDP 進(jìn)行傳輸優(yōu)化，這類場(chǎng)景在三角平衡關(guān)系里是典型的用 expense 來換取 latency 的案例。

10.2 多點(diǎn)并聯(lián) relay

在服務(wù)與服務(wù)進(jìn)行媒體數(shù)據(jù)傳輸或者分發(fā)過程中，需要保證傳輸路徑高可用和帶寬并發(fā)，這類使用場(chǎng)景也會(huì)使用傳輸雙方構(gòu)建一個(gè) RUDP 通道，中間通過多 relay 節(jié)點(diǎn)的并聯(lián)來解決。

如下圖所示：

這種模型需要在發(fā)送端設(shè)計(jì)一個(gè)多點(diǎn)路由表探測(cè)機(jī)制，以此來判斷各個(gè)路徑同時(shí)發(fā)送數(shù)據(jù)的比例和可用性，這個(gè)模型除了鏈路備份和增大傳輸并發(fā)帶寬外，還有個(gè)輔助的功能，如果是流媒體分發(fā)系統(tǒng)，我們一般會(huì)用 BGP 來做中轉(zhuǎn)，如果節(jié)點(diǎn)與節(jié)點(diǎn)之間可以直連，這樣還可以減少對(duì) BGP 帶寬的占用，以此來減少成本。

11、本文小結(jié)

到這里 RUDP 的介紹也就結(jié)束了，說了些細(xì)節(jié)和場(chǎng)景相關(guān)的事，也算是個(gè)入門級(jí)的科普文章。RUDP 的概念從提出到現(xiàn)在也差不多有 20 年了，很多從業(yè)人員希望通過一套完善的方案來設(shè)計(jì)一個(gè)通用的 RUDP，我個(gè)人覺得這不太可能，就算設(shè)計(jì)出來了，估計(jì)和現(xiàn)在 TCP 差不多，這樣做的意義不大。

RUDP 的價(jià)值在于根據(jù)不同的傳輸場(chǎng)景進(jìn)行不同的技術(shù)選型，可能選擇寬松的擁塞方式、也可能選擇特定的重傳模式，但不管怎么選，都是基于 expense(成本)、latency（時(shí)延）、quality（質(zhì)量）三者之間來權(quán)衡，通過結(jié)合場(chǎng)景和權(quán)衡三角平衡關(guān)系 RUDP 或許能幫助開發(fā)者找到一個(gè)比較好的方案。

12、本文作者

袁榮喜：學(xué)霸君資深架構(gòu)師，16 年的 C 程序員，擅長(zhǎng) P2P 通信網(wǎng)絡(luò)、TCP/IP 通信協(xié)議棧和鑒權(quán)加密技術(shù)，2015 年加入學(xué)霸君，負(fù)責(zé)構(gòu)建學(xué)霸君的智能路由實(shí)時(shí)音視頻傳輸系統(tǒng)和網(wǎng)絡(luò)，解決音視頻通信的實(shí)時(shí)性的問題。

作者的另一篇文章《P2P技術(shù)如何將實(shí)時(shí)視頻直播帶寬降低75%？》也寫的不錯(cuò)，有興趣的讀者可繼續(xù)前往閱讀。

附錄：更多網(wǎng)絡(luò)編程文章

[1] 網(wǎng)絡(luò)編程基礎(chǔ)資料：

《TCP/IP詳解?-?第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》

《TCP/IP詳解?-?第17章·TCP：傳輸控制協(xié)議》

《TCP/IP詳解?-?第18章·TCP連接的建立與終止》

《TCP/IP詳解?-?第21章·TCP的超時(shí)與重傳》

《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)）》

《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》

《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》

《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》

《理論聯(lián)系實(shí)際：Wireshark抓包分析TCP 3次握手、4次揮手過程》

《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》

《UDP中一個(gè)包的大小最大能多大？》

《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介》

《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》

《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》

《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》

《高性能網(wǎng)絡(luò)編程(一)：單臺(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》

《高性能網(wǎng)絡(luò)編程(二)：上一個(gè)10年，著名的C10K并發(fā)連接問題》

《高性能網(wǎng)絡(luò)編程(三)：下一個(gè)10年，是時(shí)候考慮C10M并發(fā)問題了》

《高性能網(wǎng)絡(luò)編程(四)：從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》

《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》

《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》

《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》

《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》

《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》

《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》

《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》

《網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》

《網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》

《網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》

《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說UDP有時(shí)比TCP更有優(yōu)勢(shì)》

>>?更多同類文章 ……

[2] NIO異步網(wǎng)絡(luò)編程資料：

《Java新一代網(wǎng)絡(luò)編程模型AIO原理及Linux系統(tǒng)AIO介紹》

《有關(guān)“為何選擇Netty”的11個(gè)疑問及解答》

《開源NIO框架八卦——到底是先有MINA還是先有Netty?》

《選Netty還是Mina：深入研究與對(duì)比（一）》

《選Netty還是Mina：深入研究與對(duì)比（二）》

《NIO框架入門(一)：服務(wù)端基于Netty4的UDP雙向通信Demo演示》

《NIO框架入門(二)：服務(wù)端基于MINA2的UDP雙向通信Demo演示》

《NIO框架入門(三)：iOS與MINA2、Netty4的跨平臺(tái)UDP雙向通信實(shí)戰(zhàn)》

《NIO框架入門(四)：Android與MINA2、Netty4的跨平臺(tái)UDP雙向通信實(shí)戰(zhàn)》

《Netty 4.x學(xué)習(xí)（一）：ByteBuf詳解》

《Netty 4.x學(xué)習(xí)（二）：Channel和Pipeline詳解》

《Netty 4.x學(xué)習(xí)（三）：線程模型詳解》

《Apache Mina框架高級(jí)篇（一）：IoFilter詳解》

《Apache Mina框架高級(jí)篇（二）：IoHandler詳解》

《MINA2 線程原理總結(jié)（含簡(jiǎn)單測(cè)試實(shí)例）》

《Apache MINA2.0 開發(fā)指南（中文版）[附件下載]》

《MINA、Netty的源代碼（在線閱讀版）已整理發(fā)布》

《解決MINA數(shù)據(jù)傳輸中TCP的粘包、缺包問題（有源碼）》

《解決Mina中多個(gè)同類型Filter實(shí)例共存的問題》

《實(shí)踐總結(jié)：Netty3.x升級(jí)Netty4.x遇到的那些坑（線程篇）》

《實(shí)踐總結(jié)：Netty3.x VS Netty4.x的線程模型》

《詳解Netty的安全性：原理介紹、代碼演示（上篇）》

《詳解Netty的安全性：原理介紹、代碼演示（下篇）》

《詳解Netty的優(yōu)雅退出機(jī)制和原理》

《NIO框架詳解：Netty的高性能之道》

《Twitter：如何使用Netty 4來減少JVM的GC開銷（譯文）》

《絕對(duì)干貨：基于Netty實(shí)現(xiàn)海量接入的推送服務(wù)技術(shù)要點(diǎn)》

《Netty干貨分享：京東京麥的生產(chǎn)級(jí)TCP網(wǎng)關(guān)技術(shù)實(shí)踐總結(jié)》