最近和很多實(shí)時(shí)音視頻領(lǐng)域的朋友交流中都有談?wù)摰絉UDP(Reliable UDP)，這其實(shí)是個(gè)老生常談的問(wèn)題，RUDP在很多著名的項(xiàng)目上都有使用，例如google的QUIC和webRTC。在UDP之上做一層可靠，很多朋友認(rèn)為這是很不靠譜的事情，也有朋友認(rèn)為這是一個(gè)大殺器，可以解決實(shí)時(shí)領(lǐng)域里大部分問(wèn)題。作為在教育公司來(lái)說(shuō)，學(xué)霸君在很多實(shí)時(shí)場(chǎng)景下確實(shí)使用RUDP技術(shù)來(lái)解決我們的問(wèn)題，不同場(chǎng)景我們采用的RUDP方式也不一樣。先來(lái)看看學(xué)霸君哪些場(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)WIFI下Pad的720P同屏傳輸系統(tǒng)，采用的是RUDP +GCC實(shí)時(shí)流控技術(shù)。

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

  涉及到實(shí)時(shí)傳輸我們都會(huì)先考慮RUDP，RUDP應(yīng)用在學(xué)霸君核心傳輸體系的各個(gè)方面，但不同的系統(tǒng)場(chǎng)景我們?cè)O(shè)計(jì)了不同的RUDP方式，所以基于那些激烈的討論和我們使用的經(jīng)驗(yàn)我扒一扒RUDP。其實(shí)在實(shí)時(shí)通信領(lǐng)域存在一個(gè)三角平衡關(guān)系：成本，質(zhì)量，時(shí)延三者的制約關(guān)系（圖1）

圖1

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

可靠的概念

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

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

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

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

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

UDP為什么要可靠

說(shuō)到這里可能很多人會(huì)說(shuō)：干嘛那么麻煩，直接用TCP好了！確實(shí)很多人也都是這樣做的，TCP是個(gè)基于公平性的可靠通信協(xié)議，在一些苛刻的網(wǎng)絡(luò)條件下TCP要么不能提供正常的通信質(zhì)量保證，要么成本過(guò)高。為什么要在UDP之上做可靠保證，究其原因就是在保證通信的時(shí)延和質(zhì)量的條件下盡量降低成本，RUDP主要解決以下相關(guān)問(wèn)題：

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

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

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

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

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

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

重傳模式

IP協(xié)議在設(shè)計(jì)的時(shí)候就不是為了數(shù)據(jù)可靠到達(dá)而設(shè)計(jì)的，所以UDP要保證可靠，就依賴于重傳，這也就是我們通常意義上的RUDP行為，在描述RUDP重傳之前先來(lái)了解下RUDP基本框架，如圖：

圖2

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

定時(shí)重傳

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

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

ACK在途中，但是發(fā)送端的時(shí)間已經(jīng)超過(guò)了一個(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%的重復(fù)重傳率，所以在大帶寬模式下一般會(huì)采用請(qǐng)求重傳模式。

請(qǐng)求重傳

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

圖3

這個(gè)反饋過(guò)程最關(guān)鍵的步驟就是回送ACK的時(shí)候應(yīng)該攜帶哪些丟失報(bào)文的信息，因?yàn)閁DP在網(wǎng)絡(luò)傳輸過(guò)程中會(huì)亂序會(huì)抖動(dòng)，接收端在通信的過(guò)程中要評(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<curr_t，再次在ACK攜帶這個(gè)丟包信息，以此類推，直到收到報(bào)文為止。這種方式是由丟包請(qǐng)求引起的重發(fā)，如果網(wǎng)絡(luò)很不好，接收端會(huì)不斷發(fā)起重傳請(qǐng)求，造成發(fā)送端不停的重傳，引起網(wǎng)絡(luò)風(fēng)暴，通信質(zhì)量會(huì)下降，所以我們?cè)诎l(fā)送端設(shè)計(jì)一個(gè)擁塞控制模塊來(lái)限流，這個(gè)后面我們重點(diǎn)分析。除了網(wǎng)絡(luò)風(fēng)暴以外，整個(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ù)同步等。

FEC選擇重傳

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

圖4

在發(fā)送方發(fā)送報(bào)文的時(shí)候，會(huì)根據(jù)FEC方式把幾個(gè)報(bào)文進(jìn)行FEC分組，通過(guò)XOR的方式得到若干個(gè)冗余包，然后一起發(fā)往接收端，如果接收端發(fā)現(xiàn)丟包但能通過(guò)FEC分組算法還原，就不向發(fā)送端請(qǐng)求重傳，如果分組內(nèi)包是不能進(jìn)行FEC恢復(fù)的，就請(qǐng)求想發(fā)送端請(qǐng)求原始的數(shù)據(jù)包。FEC分組方式適合解決要求延時(shí)敏感且隨機(jī)丟包的傳輸場(chǎng)景，在一個(gè)帶寬不是很充裕的傳輸條件下，F(xiàn)EC會(huì)增加多余的冗余包，可能會(huì)使得網(wǎng)絡(luò)更加不好。FEC方式不僅可以配合請(qǐng)求重傳模式，也可以配合定時(shí)重傳模式。

RTT與RTO的計(jì)算

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

圖5

RTT = T2 - T1

這個(gè)計(jì)算方式只是計(jì)算了某一個(gè)報(bào)文時(shí)刻的RTT，但網(wǎng)絡(luò)是會(huì)波動(dòng)的，這難免會(huì)有噪聲現(xiàn)象，所以在計(jì)算的過(guò)程中引入了加權(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í)間還沒(méi)收到確定，那我們就可以再次重傳，則可知：

RTO = SRTT + SRTT_VAR

但一般網(wǎng)絡(luò)在嚴(yán)重抖動(dòng)的情況下還是會(huì)有較大的重復(fù)率問(wèn)題，所以：

RTO = β*(SRTT + RTT_VAR)

1.2 <β<2.0，可以根據(jù)不同的傳輸場(chǎng)景來(lái)選擇β的值。

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

窗口與擁塞控制

窗口

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

圖6

上圖描述的是發(fā)送端從發(fā)送窗口中發(fā)了6個(gè)數(shù)據(jù)報(bào)文給接收端，接收端收到101,102,103,106時(shí)會(huì)先判斷報(bào)文的連續(xù)性并滑動(dòng)窗口開(kāi)始位置到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。如果是盡力可靠和無(wú)序可靠場(chǎng)景，會(huì)將106通知給上層業(yè)務(wù)先進(jìn)行處理。在收到ACK后，發(fā)送端的窗口要滑動(dòng)多少是由自己的擁塞機(jī)制定的，也就是說(shuō)窗口的滑動(dòng)速度受擁塞機(jī)制控制，擁塞控制實(shí)現(xiàn)要么基于丟包率來(lái)實(shí)現(xiàn)，要么基于雙方的通信時(shí)延來(lái)實(shí)現(xiàn)，下面來(lái)看幾種典型的擁塞控制。

經(jīng)典擁塞算法

TCP經(jīng)典擁塞算法分為四個(gè)部分：慢啟動(dòng)、擁塞避免、擁塞處理和快速恢復(fù)，這四個(gè)部分都是為了決定發(fā)送窗和發(fā)送速度而設(shè)計(jì)的，其實(shí)就是為了在當(dāng)前網(wǎng)絡(luò)條件下通過(guò)網(wǎng)絡(luò)丟包來(lái)判斷網(wǎng)絡(luò)擁塞狀態(tài)，從而確定比較適合的發(fā)送傳輸窗口。經(jīng)典算法是建立在定時(shí)重傳的基礎(chǔ)上的，如果RUDP采用這種算法來(lái)做擁塞控制，一般的場(chǎng)景是為了保證有序可靠傳輸?shù)耐瑫r(shí)又兼顧網(wǎng)絡(luò)傳輸?shù)墓叫栽瓌t。先逐個(gè)來(lái)解釋下這幾部分

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

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

1） 初始化設(shè)置cwnd = 1,并開(kāi)始傳輸數(shù)據(jù)

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

3） 當(dāng)一個(gè)發(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)一步通過(guò)一個(gè)緩慢的調(diào)節(jié)過(guò)程來(lái)進(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ù)

快速恢復(fù)是通過(guò)確認(rèn)丟包只發(fā)生在窗口一個(gè)位置的包上來(lái)確定是否進(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í)重傳模式來(lái)設(shè)計(jì)的，在三角平衡關(guān)系中是一個(gè)典型的以Latency換取Quality的案例，但由于其公平性設(shè)計(jì)避免了過(guò)高的Expense,也就會(huì)讓這種傳輸方式很難壓榨網(wǎng)絡(luò)帶寬，很難保證網(wǎng)絡(luò)的大吞吐量和小時(shí)延。

BRR擁塞算法

對(duì)于經(jīng)典擁塞算法的延遲和帶寬壓榨問(wèn)題google設(shè)計(jì)了基于發(fā)送端延遲和帶寬評(píng)估的BBR擁塞控制算法。這種擁塞算法致力于解決兩個(gè)問(wèn)題：

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

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

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

cwnd = max_bandwidth / min_rtt

傳輸模型如下：

圖7

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

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

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

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

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

那么這幾種狀態(tài)是怎么且來(lá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ù)超過(guò)了預(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<cwd,進(jìn)入PROBE_BW狀態(tài)

4） 在PROBE_BW狀態(tài)下，如果未發(fā)生丟包且flight_size<cwnd * 1.25,將維持原來(lái)的cwnd,并進(jìn)入StartUp，如果發(fā)生丟包或者flight_size > cwnd,將cwnd = cwnd * 1.25，如果發(fā)生丟包，cwnd = cwnd * .075

5） 在Startup/DRAIN/PROBE_BW三個(gè)狀態(tài)中，如果持續(xù)10秒鐘的通信中沒(méi)有出現(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并且無(wú)丟包，將本次統(tǒng)計(jì)的最小RTT作為min_rtt,進(jìn)入Startup狀態(tài)。

BBR是通過(guò)以上幾個(gè)步驟來(lái)周期性計(jì)算cwnd，也就是網(wǎng)絡(luò)最大吞吐量和最小延遲，然后通過(guò)pacing rate來(lái)確定這一時(shí)刻發(fā)送端的碼率，最終達(dá)到擁塞控制的目的。BBR適合在隨機(jī)丟包且網(wǎng)絡(luò)穩(wěn)定的情況下做擁塞，如果在網(wǎng)絡(luò)信號(hào)極不穩(wěn)定的WIFI或者4G上，容易出現(xiàn)網(wǎng)絡(luò)泛洪和預(yù)測(cè)不準(zhǔn)的問(wèn)題，BBR在多連接公平性上也存在小RTT的連接比大RTT的連接更吃帶寬的情況，容易造成大RTT的連接速度過(guò)慢的情況。BBR擁塞算法在三角平衡關(guān)系中是采用Expense換取latency和Quality的案例。

webRTC gcc

說(shuō)到音視頻傳輸就必然會(huì)想到webRTC系統(tǒng)，在webRTC中對(duì)于視頻傳輸也實(shí)現(xiàn)了一個(gè)擁塞控制算法(gcc)，webRTC的gcc是一個(gè)基于發(fā)送端丟包率和接收端延遲帶寬統(tǒng)計(jì)的擁塞控制，而且是一個(gè)盡力可靠的傳輸算法，在傳輸?shù)倪^(guò)程中如果一個(gè)報(bào)文重發(fā)太多次后會(huì)直接丟棄，這符合視頻傳輸?shù)膱?chǎng)景，借用weizhenwei同學(xué)一張圖來(lái)看個(gè)究竟：

圖8

gcc的發(fā)送端會(huì)根據(jù)丟包率和一個(gè)對(duì)照表來(lái)pacing rate，當(dāng)loss < 2%時(shí)，會(huì)加大傳輸帶寬，當(dāng)loss >=2% &&loss

gcc的接收端是根據(jù)數(shù)據(jù)到達(dá)的延遲方差和大小進(jìn)行KalmanFilter進(jìn)行帶寬逼近收斂，具體的細(xì)節(jié)不介紹了，請(qǐng)查看http://www.jianshu.com/p/bb34995c549a

這里值得一說(shuō)的是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的案例。

弱窗口擁塞機(jī)制

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

傳輸路徑

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)化。我們具體來(lái)說(shuō)一說(shuō)。

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

在實(shí)時(shí)通信中一些對(duì)業(yè)務(wù)場(chǎng)景對(duì)延遲非常敏感，例如：實(shí)時(shí)語(yǔ)音、同步書寫、實(shí)時(shí)互動(dòng)、直播連麥等，如果單純的服務(wù)中轉(zhuǎn)或者P2P通信，很難無(wú)法滿足其需求，尤其是在物理距離很大的情況下。在解決這個(gè)問(wèn)題上SKYPE率先提出全球RTN（實(shí)時(shí)多點(diǎn)傳輸網(wǎng)絡(luò)），其實(shí)就是在通信雙方之間通過(guò)幾個(gè)relay節(jié)點(diǎn)來(lái)動(dòng)態(tài)智能選路，這種傳輸方式很適合RUDP，我們只要在通信雙方構(gòu)建一個(gè)RUDP通道，中間鏈路只是一個(gè)無(wú)狀態(tài)的relay cache集合，relay與relay之間進(jìn)行路由探測(cè)和選路，以此來(lái)做到鏈路的高可用和實(shí)時(shí)性。如下圖：

圖9

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

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

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

圖10

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

后記

到這里RUDP的介紹也就結(jié)束了，說(shuō)了些細(xì)節(jié)和場(chǎng)景相關(guān)的事，也算是個(gè)入門級(jí)的科普文章。RUDP的概念從提出到現(xiàn)在也差不多有20年了，很多從業(yè)人員這希望通過(guò)一套完善的方案來(lái)設(shè)計(jì)一個(gè)通用的RUDP，我個(gè)人覺(jué)得這不太可能，就算設(shè)計(jì)出來(lái)了，估計(jì)和現(xiàn)在TCP差不多，這樣做的意義不大。RUDP的價(jià)值在于根據(jù)不同的傳輸場(chǎng)景進(jìn)行不同的技術(shù)選型，可能選擇寬松的擁塞方式、也可能選擇特定的重傳模式，但不管怎么選，都是基于Expense(成本)、Latency（時(shí)延）、Quality（質(zhì)量）三者之間來(lái)權(quán)衡，通過(guò)結(jié)合場(chǎng)景和權(quán)衡三角平衡關(guān)系RUDP或許能幫助開(kāi)發(fā)者找到一個(gè)比較好的方案。

袁榮喜：學(xué)霸君資深架構(gòu)師，16年C程序員，Golang愛(ài)好者