網(wǎng)絡(luò)擁塞是基于IP協(xié)議的數(shù)據(jù)報(bào)交換網(wǎng)絡(luò)中常見(jiàn)的一種網(wǎng)絡(luò)傳輸問(wèn)題，它對(duì)網(wǎng)絡(luò)傳輸?shù)馁|(zhì)量有嚴(yán)重的影響，網(wǎng)絡(luò)擁塞是導(dǎo)致網(wǎng)絡(luò)吞吐降低，網(wǎng)絡(luò)丟包等的主要原因之一，這些問(wèn)題使得上層應(yīng)用無(wú)法有效的利用網(wǎng)絡(luò)帶寬獲得高質(zhì)量的網(wǎng)絡(luò)傳輸效果。特別是在通信領(lǐng)域，網(wǎng)絡(luò)擁塞導(dǎo)致的丟包，延遲，抖動(dòng)等問(wèn)題，嚴(yán)重的影響了通信質(zhì)量，如果不能很好的解決這些問(wèn)題，一個(gè)通信產(chǎn)品就無(wú)法在現(xiàn)實(shí)環(huán)境中正常使用。在這方面WebRTC中的網(wǎng)絡(luò)擁塞控制算法給我們提供了一個(gè)可供參考的實(shí)現(xiàn)，本篇文章會(huì)盡量詳細(xì)的介紹WebRTC中的擁塞控制算法---GCC的實(shí)現(xiàn)方式。

?

相關(guān)閱讀推薦

《聊聊WebRTC網(wǎng)關(guān)服務(wù)器1：如何選擇服務(wù)端端口方案？》

《聊聊WebRTC網(wǎng)關(guān)服務(wù)器2：如何選擇PeerConnection方案？》

?

WebRTC簡(jiǎn)介

WebRTC是一個(gè)Web端的實(shí)時(shí)通信解決方案，它可以做到在不借助外部插件的情況下，在瀏覽器中實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)的實(shí)時(shí)通信。WebRTC已經(jīng)由W3C和IETF標(biāo)準(zhǔn)化，最早推出和支持這項(xiàng)技術(shù)的瀏覽器是Chrome, 其他主流瀏覽器也正在陸續(xù)支持。Chrome中集成的WebRTC代碼已全部開(kāi)源，同時(shí)Chrome提供了一套LibWebRTC的代碼庫(kù)，使得這套R(shí)TC架構(gòu)可以移植到其他APP當(dāng)中，提供實(shí)時(shí)通信功能。

GCC算法概述

本文主要介紹的是WebRTC的擁塞控制算法，WebRTC的傳輸層是基于UDP協(xié)議，在此之上，使用的是標(biāo)準(zhǔn)的RTP/RTCP協(xié)議封裝媒體流。RTP/RTCP本身提供很多機(jī)制來(lái)保證傳輸?shù)目煽啃?#xff0c;比如RR/SR, NACK，PLI，FIR, FEC，REMB等，同時(shí)WebRTC還擴(kuò)展了RTP/RTCP協(xié)議，來(lái)提供一些額外的保障，比如Transport-CCFeedback, RTP Transport-wide-cc extension，RTP abs-sendtime extension等，其中一些后文會(huì)詳細(xì)介紹。

GCC算法主要分成兩個(gè)部分，一個(gè)是基于丟包的擁塞控制，一個(gè)是基于延遲的擁塞控制。在早期的實(shí)現(xiàn)當(dāng)中，這兩個(gè)擁塞控制算法分別是在發(fā)送端和接收端實(shí)現(xiàn)的，接收端的擁塞控制算法所計(jì)算出的估計(jì)帶寬，會(huì)通過(guò)RTCP的remb反饋到發(fā)送端，發(fā)送端綜合兩個(gè)控制算法的結(jié)果得到一個(gè)最終的發(fā)送碼率，并以此碼率發(fā)送數(shù)據(jù)包。下圖便是展現(xiàn)的該種實(shí)現(xiàn)方式：

從圖中可以看到，Loss-Based Controller在發(fā)送端負(fù)責(zé)基于丟包的擁塞控制，它的輸入比較簡(jiǎn)單，只需要根據(jù)從接收端反饋的丟包率，就可以做帶寬估算；上圖右側(cè)比較復(fù)雜，做的是基于延遲的帶寬估計(jì)，這也是本文后面主要介紹的部分。在最近的WebRTC實(shí)現(xiàn)中，GCC把它的兩種擁塞控制算法都移到了發(fā)送端來(lái)實(shí)現(xiàn)，但是兩種算法本身并沒(méi)有改變，只是在發(fā)送端需要計(jì)算延遲，因而需要一些額外的feedback信息，為此WebRTC擴(kuò)展了RTCP協(xié)議，其中最主要的是增加了Transport-CC Feedback，該包攜帶了接收端接收到的每個(gè)媒體包的到達(dá)時(shí)間。

基于延遲的擁塞控制比較復(fù)雜，WebRTC使用延遲梯度來(lái)判斷網(wǎng)絡(luò)的擁塞程度，延遲梯段的概念后文會(huì)詳細(xì)介紹；

其算法分為幾個(gè)部分：

到達(dá)時(shí)間濾波器

過(guò)載檢測(cè)器

速率控制器

在獲得兩個(gè)擁塞控制算法分別結(jié)算到的發(fā)送碼率之后，GCC最終的發(fā)送碼率取的是兩種算法的最小值。下面我們?cè)敿?xì)介紹WebRTC的擁塞控制算法GCC。

?

（一）基于丟包的帶寬估計(jì)

基于丟包的擁塞控制比較簡(jiǎn)單，其基本思想是根據(jù)丟包的多少來(lái)判斷網(wǎng)絡(luò)的擁塞程度，丟包越多則認(rèn)為網(wǎng)絡(luò)越擁塞，那么我們就要降低發(fā)送速率來(lái)緩解網(wǎng)絡(luò)擁塞；如果沒(méi)有丟包，這說(shuō)明網(wǎng)絡(luò)狀況很好，這時(shí)候就可以提高發(fā)送碼率，向上探測(cè)是否有更多的帶寬可用。實(shí)現(xiàn)該算法有兩點(diǎn)：一是獲得接收端的丟包率，一是確定降低碼率和提升碼率的閾值。

WebRTC通過(guò)RTCP協(xié)議的Receive Report反饋包來(lái)獲取接收端的丟包率。Receive Report包中有一個(gè)lost fraction字段，包含了接收端的丟包率，如下圖所示。

另外，WebRTC通過(guò)以下公式來(lái)估算發(fā)送碼率，式中 As(tk)?即為?tk?時(shí)刻的帶寬估計(jì)值，fl(tk)即為?tk?時(shí)刻的丟包率：

簡(jiǎn)單來(lái)說(shuō)，當(dāng)丟包率大于10%時(shí)則認(rèn)為網(wǎng)絡(luò)有擁塞，此時(shí)根據(jù)丟包率降低帶寬，丟包率越高帶寬降的越多；當(dāng)丟包率小于2%時(shí)，則認(rèn)為網(wǎng)絡(luò)狀況很好，此時(shí)向上提高5%的帶寬以探測(cè)是否有更多帶寬可用；2%到10%之間的丟包率，則會(huì)保持當(dāng)前碼率不變，這樣可以避免一些網(wǎng)絡(luò)固有的丟包被錯(cuò)判為網(wǎng)絡(luò)擁塞而導(dǎo)致降低碼率，而這部分的丟包則需要通過(guò)其他的如NACK或FEC等手段來(lái)恢復(fù)。

?

（二）基于延遲梯度的帶寬估計(jì)

WebRTC實(shí)現(xiàn)的基于延遲梯度的帶寬估計(jì)有兩種版本：

最早一種是在接受端實(shí)現(xiàn)，評(píng)估的帶寬結(jié)果通過(guò)RTCP REMB消息反饋到發(fā)送端。在此種實(shí)現(xiàn)中，為了準(zhǔn)確計(jì)算延遲梯度，WebRTC添加了一種RTP擴(kuò)展頭部abs-send-time, 用來(lái)表示每個(gè)RTP包的精確發(fā)送時(shí)間，從而避免發(fā)送端延遲給網(wǎng)絡(luò)傳播延遲的估計(jì)帶來(lái)誤差。這種模式也是RFC和google的paper中描述的模式。

在新近的WebRTC的實(shí)現(xiàn)中，所有的帶寬估計(jì)都放在了發(fā)送端，也就說(shuō)發(fā)送端除了做基于丟包的帶寬估計(jì)，同時(shí)也做基于延遲梯度的帶寬估計(jì)。為了能夠在接受端做基于延遲梯度的帶寬估計(jì)，WebRTC擴(kuò)展了RTP/RTCP協(xié)議，其一是增加了RTP擴(kuò)展頭部，添加了一個(gè)session級(jí)別的sequence number, 目的是基于一個(gè)session做反饋信息的統(tǒng)計(jì)，而不緊緊是一條音頻流或視頻流；其二是增加了一個(gè)RTCP反饋信息transport-cc-feedback，該消息負(fù)責(zé)反饋接受端收到的所有媒體包的到達(dá)時(shí)間。接收端根據(jù)包間的接受延遲和發(fā)送間隔可以計(jì)算出延遲梯度，從而估計(jì)帶寬。

? ??

關(guān)于如何根據(jù)延遲梯度推斷當(dāng)前網(wǎng)絡(luò)狀況， 后面會(huì)分幾點(diǎn)詳細(xì)展開(kāi)講， 總體來(lái)說(shuō)分為以下幾個(gè)步驟：

到達(dá)時(shí)間濾波器

過(guò)載檢測(cè)器

速率控制器

其過(guò)程就是，到達(dá)時(shí)間濾波器根據(jù)包間的到達(dá)時(shí)延和發(fā)送間隔，計(jì)算出延遲變化，這里會(huì)用到卡爾曼濾波對(duì)延遲變化做平滑以消除網(wǎng)絡(luò)噪音帶來(lái)的誤差；延遲變化會(huì)作為過(guò)載檢測(cè)器的輸入，由過(guò)載檢測(cè)器判斷當(dāng)前網(wǎng)絡(luò)的狀態(tài)，有三種網(wǎng)絡(luò)狀態(tài)返回overuse/underuse/normal，檢測(cè)的依據(jù)是比較延遲變化和一個(gè)閾值，其中該閾值非常關(guān)鍵且是動(dòng)態(tài)調(diào)整的。最后根據(jù)網(wǎng)絡(luò)狀態(tài)的變化，速率控制器根據(jù)一個(gè)帶寬估計(jì)公式計(jì)算帶寬估計(jì)值。

?

（三）到達(dá)時(shí)間濾波器

前面多次提到WebRTC使用延遲梯度來(lái)判斷網(wǎng)絡(luò)擁塞狀況，那什么是延遲梯度，為什么延遲梯度可以作為判斷網(wǎng)絡(luò)擁塞的依據(jù)，我們?cè)谶@里詳細(xì)介紹，首先來(lái)看以下，延遲梯度是怎樣計(jì)算出來(lái)的：

1.?????延遲梯度的計(jì)算

如上圖所示，用兩個(gè)數(shù)據(jù)包的到達(dá)時(shí)間間隔減去他們的發(fā)送時(shí)間間隔，就可以得到一個(gè)延遲的變化，這里我們稱這個(gè)延遲的變化為單向延遲梯度（one way delay gradient），其公式可記為：

那么為什么延遲梯度可以用來(lái)判斷網(wǎng)絡(luò)擁塞的呢，如下面兩圖所示：

左邊這幅圖的場(chǎng)景是理想狀況下的網(wǎng)絡(luò)傳輸，沒(méi)有任何擁塞，按我們上面提到的公式（2）來(lái)計(jì)算，這種場(chǎng)景下，所計(jì)算到的延遲梯度應(yīng)該為0。而右邊這幅圖的場(chǎng)景則是發(fā)送擁塞時(shí)的狀況，當(dāng)包在t2時(shí)刻到達(dá)時(shí)，該報(bào)在網(wǎng)絡(luò)中經(jīng)歷過(guò)一次因擁塞導(dǎo)致的排隊(duì)，這導(dǎo)致他的到達(dá)時(shí)間比原本要完，此時(shí)計(jì)算出的延遲梯度就為一個(gè)較大的值，通過(guò)這個(gè)值，我們就能判斷當(dāng)前網(wǎng)絡(luò)正處在擁塞狀態(tài)。

在WebRTC的具體實(shí)現(xiàn)中，還有一些細(xì)節(jié)來(lái)保證延遲梯度計(jì)算的準(zhǔn)確性，總結(jié)如下：

由于延遲梯度的測(cè)量精度很小，為了避免網(wǎng)絡(luò)噪音帶來(lái)的誤差，利用了卡爾曼濾波來(lái)平滑延遲梯度的測(cè)量結(jié)果。

WebRTC的實(shí)現(xiàn)中，并不是單純的測(cè)量單個(gè)數(shù)據(jù)包彼此之間的延遲梯度，而是將數(shù)據(jù)包按發(fā)送時(shí)間間隔和到達(dá)時(shí)間間隔分組，計(jì)算組間的整體延遲梯度。分組規(guī)則是：

發(fā)送時(shí)間間隔小于5ms的數(shù)據(jù)包被歸為一組，這是由于WebRTC的發(fā)送端實(shí)現(xiàn)了一個(gè)平滑發(fā)送模塊，該模塊的發(fā)送間隔是5ms發(fā)送一批數(shù)據(jù)包。

到達(dá)時(shí)間間隔小于5ms的數(shù)據(jù)包被歸為一組，這是由于在wifi網(wǎng)絡(luò)下，某些wifi設(shè)備的轉(zhuǎn)發(fā)模式是，在某個(gè)固定時(shí)間片內(nèi)才有機(jī)會(huì)轉(zhuǎn)發(fā)數(shù)據(jù)包，這個(gè)時(shí)間片的間隔可能長(zhǎng)達(dá)100ms，造成的結(jié)果是100ms的數(shù)據(jù)包堆積，并在發(fā)送時(shí)形成burst，這個(gè)busrt內(nèi)的所有數(shù)據(jù)包就會(huì)被視為一組。

為了計(jì)算延遲梯度，除了接收端要反饋每個(gè)媒體包的接受狀態(tài)，同時(shí)發(fā)送端也要記錄每個(gè)媒體包的發(fā)送狀態(tài)，記錄其發(fā)送的時(shí)間值。在這個(gè)情況下abs-send-time擴(kuò)展不再需要。

?

2.?????transport-cc-feedback消息

該消息是對(duì)RTCP的一個(gè)擴(kuò)展，專門用于在GCC中反饋數(shù)據(jù)包的接受情況。這里有兩點(diǎn)需要注意：

該消息的發(fā)送速率如何確定，按RFC[2]中的說(shuō)明，可以是收到每個(gè)frame發(fā)送一次，另外也指出可以是一個(gè)RTT的時(shí)間發(fā)送一次，實(shí)際WebRTC的實(shí)現(xiàn)中大約估計(jì)了一個(gè)發(fā)送帶寬的5%這樣一個(gè)發(fā)送速率。?

如果這個(gè)數(shù)據(jù)包丟失怎么辦，RFC[2]和WebRTC實(shí)現(xiàn)中都是直接忽略，這里涉及的問(wèn)題是，忽略該包對(duì)計(jì)算延遲梯度影響不大，只是相當(dāng)于數(shù)據(jù)包的分組跨度更大了，丟失的包對(duì)計(jì)算沒(méi)有太大影響，但另一個(gè)問(wèn)題是，發(fā)送端需要計(jì)算接受端的接受速率，當(dāng)feedback丟失時(shí)，會(huì)認(rèn)為相應(yīng)的數(shù)據(jù)包都丟失了，這會(huì)影響接受速率的計(jì)算，這個(gè)值在后續(xù)計(jì)算估計(jì)帶寬中會(huì)用到，從而導(dǎo)致一定誤差。

?

具體消息格式如下：

如上圖所示，紅框之前的字段是RTCP包的通用字段，紅框中的字段為transport-cc的具體內(nèi)容，其中前四個(gè)字段分別表示：

base sequence number：當(dāng)前包攜帶的媒體包的接受信息是從哪個(gè)包開(kāi)始的

packet status count：當(dāng)前包攜帶了幾個(gè)媒體包的接受信息

reference time：一個(gè)基準(zhǔn)時(shí)間，計(jì)算該包中每個(gè)媒體包的到達(dá)時(shí)間都要基于這個(gè)基準(zhǔn)時(shí)間計(jì)算

fb pkt. count：第幾個(gè)transport-cc包

在此之后，是兩類信息：多個(gè)packet chunk字段和多個(gè)recv delta字段。其中pcaket chunk具體含義如下：

如下兩圖所示， 表示媒體包到達(dá)狀態(tài)的結(jié)構(gòu)有兩種編碼方式， 其中 T 表示chunk type；0表示RunLength Chunk, 1表示Status Vector Chunk.

1）Run LengthChunk

這種表示方式是用于，當(dāng)我們連續(xù)收到多個(gè)數(shù)據(jù)包，他們都有相同的到達(dá)狀態(tài)，就可以用這種編碼方式。其中S表示的是到達(dá)狀態(tài)，Run Length表示有多少個(gè)連續(xù)的包屬于這一到達(dá)狀態(tài)。

到達(dá)狀態(tài)有三種：

? ? ?00 Packet not received

? ? ?01 Packet received, small delta?（所謂small detal是指能用一個(gè)字節(jié)表示的數(shù)值）

? ? ?10 Packet received, large ornegative delta?（large即是能用兩個(gè)字節(jié)表示的數(shù)值）

2) Status Vector Chunk

這種表示方式用于每個(gè)數(shù)據(jù)包都需要自己的狀態(tài)表示碼，當(dāng)然還是上面提到的那三種狀態(tài)。但是這里的S就不是上面的意思，這里的S指的是symbol list的編碼方式，s = 0時(shí)，表示symbollist的每一個(gè)bit能表示一個(gè)數(shù)據(jù)包的到達(dá)狀態(tài)，s = 1時(shí)表示每?jī)蓚€(gè)bit表示一個(gè)數(shù)據(jù)包的狀態(tài)。

s = 0?時(shí)

? ? ?0 Packet not received

? ? ?1 Packet received , small detal

s = 1?時(shí)

? ? ??同 Run Length Chunk

?

最后，對(duì)于每一個(gè)狀態(tài)為Packet received 的數(shù)據(jù)包的延遲依次填入|recv delta|字段，到達(dá)狀態(tài)為1的，recv delta占用一個(gè)字節(jié)，到達(dá)狀態(tài)為2的，recv delta占用兩個(gè)字節(jié)可以看出以上編碼的目的是為了盡量減少該數(shù)據(jù)包的大小，因?yàn)槊總€(gè)媒體包都需要反饋他的接受狀態(tài)。

?

（四）過(guò)載檢測(cè)器

到達(dá)時(shí)間濾波器計(jì)算出每組數(shù)據(jù)包的延遲梯度之后，就要據(jù)此判斷當(dāng)前的網(wǎng)絡(luò)擁塞狀態(tài)，通過(guò)和某個(gè)閾值的比較，高過(guò)某個(gè)閾值就認(rèn)為時(shí)網(wǎng)絡(luò)擁塞，低于某個(gè)閾值就認(rèn)為網(wǎng)路狀態(tài)良好，因此如何確定閾值就至關(guān)重要。這就是過(guò)載檢測(cè)器的主要工作，它主要有兩部分，一部分是確定閾值的大小，另一部分就是依據(jù)延遲梯度和閾值的判斷，估計(jì)出當(dāng)前的網(wǎng)絡(luò)狀態(tài)，一共有三種網(wǎng)絡(luò)狀態(tài):?overuse underuse normal，我們先看網(wǎng)絡(luò)狀態(tài)的判斷。

?

1. ?網(wǎng)絡(luò)狀態(tài)判斷

判斷依據(jù)入下圖所示：

其中表示的是計(jì)算出的延遲梯，表示的是一個(gè)判斷閾值，這個(gè)閾值是自適應(yīng)的， 后面還會(huì)介紹他是怎么動(dòng)態(tài)調(diào)整的，這里先只看如何根據(jù)這兩個(gè)值判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)。

從上圖可以看出，這里的判斷方法是：

這樣計(jì)算的依據(jù)是，網(wǎng)絡(luò)發(fā)生擁塞時(shí)，數(shù)據(jù)包會(huì)在中間網(wǎng)絡(luò)設(shè)備中排隊(duì)等待轉(zhuǎn)發(fā)，這會(huì)造成延遲梯度的增長(zhǎng)，當(dāng)網(wǎng)絡(luò)流量回落時(shí)，網(wǎng)絡(luò)設(shè)備快速消耗（轉(zhuǎn)發(fā)）其發(fā)送隊(duì)列中的數(shù)據(jù)包，而后續(xù)的包排隊(duì)時(shí)間更短，這時(shí)延遲梯度減小或?yàn)樨?fù)值。

這里了需要說(shuō)明的是：

• 在實(shí)際WebRTC的實(shí)現(xiàn)中，雖然每個(gè)數(shù)據(jù)包組（前面提到了如何分組）的到達(dá)都會(huì)觸發(fā)這個(gè)探測(cè)過(guò)程，但是使用的m(ti)這個(gè)值并不是直接使用每組數(shù)據(jù)到來(lái)時(shí)的計(jì)算值，而是將這個(gè)值放大了60倍。這么做的目的可能是m(ti)這個(gè)值通常情況下很小，理想網(wǎng)絡(luò)下基本為0，放大該值可以使該算法不會(huì)應(yīng)為太靈敏而波動(dòng)太大。
• 在判斷是否overuse時(shí)，不會(huì)一旦超過(guò)閾值就改變當(dāng)前狀態(tài)，而是要滿足延遲梯度大于閾值至少持續(xù)100ms，才會(huì)將當(dāng)前網(wǎng)絡(luò)狀態(tài)判斷為overuse。

?

2.? 自適應(yīng)閾值

上節(jié)提到的閾值值，它是判斷當(dāng)前網(wǎng)絡(luò)狀況的依據(jù)，所以如何確定它的值也就非常重要了。雖然理想狀況下，網(wǎng)絡(luò)的延遲梯度是0，但是實(shí)際的網(wǎng)絡(luò)中，不同轉(zhuǎn)發(fā)路徑其延遲梯度還是有波動(dòng)的，波動(dòng)的大小也是不一樣的，這就導(dǎo)致如果設(shè)置固定的?太大可能無(wú)法探測(cè)到擁塞，太小又太敏感，導(dǎo)致速率了變化很大。同時(shí)，另外一個(gè)問(wèn)題是，實(shí)驗(yàn)中顯示固定的值會(huì)導(dǎo)致在和TCP鏈接的競(jìng)爭(zhēng)中，自己被餓死的現(xiàn)象（TCP是基于丟包的擁塞控制），因此WebRTC使用了一種自適應(yīng)的閾值調(diào)節(jié)算法，具體如下：

? ? ?（1） 自適應(yīng)算法

上面的公式就是GCC提出的閾值自適應(yīng)算法，其中：

，每組數(shù)據(jù)包會(huì)觸發(fā)一次探測(cè)，同時(shí)更新一次閾值，這里?的意義就是距上次更新閾值時(shí)的時(shí)間間隔。

是一個(gè)變化率，或者叫增長(zhǎng)率，當(dāng)然也有可能是負(fù)增長(zhǎng)，增長(zhǎng)的基值是：當(dāng)前的延遲梯度和上一個(gè)閾值的差值---

。其具體的取值如下：

從這個(gè)式子中可以看出，當(dāng)延遲梯度減小時(shí)，閾值會(huì)以一個(gè)更慢的速率減小； 延遲梯度增加時(shí)，閾值也會(huì)以一個(gè)更慢的速度增加；不過(guò)相對(duì)而言，閾值的減小速度要小于增加速度。

?

（五）速率控制器

速率控制器主要實(shí)現(xiàn)了一個(gè)狀態(tài)機(jī)的變遷，并根據(jù)當(dāng)前狀態(tài)來(lái)計(jì)算當(dāng)前的可用碼率，狀態(tài)機(jī)如下圖所示：

速率控制器根據(jù)過(guò)載探測(cè)器輸出的信號(hào)（overuse underusenormal）驅(qū)動(dòng)速率控制狀態(tài)機(jī)， 從而估算出當(dāng)前的網(wǎng)絡(luò)速率。從上圖可以看出，當(dāng)網(wǎng)絡(luò)擁塞時(shí)，會(huì)收到overuse信號(hào)，狀態(tài)機(jī)進(jìn)入“decrease”狀態(tài)，發(fā)送速率降低；當(dāng)網(wǎng)絡(luò)中排隊(duì)的數(shù)據(jù)包被快速釋放時(shí)，會(huì)受到underuse信號(hào)，狀態(tài)機(jī)進(jìn)入“hold”狀態(tài)。網(wǎng)絡(luò)平穩(wěn)時(shí)，收到normal信號(hào)，狀態(tài)機(jī)進(jìn)入“increase”狀態(tài)，開(kāi)始探測(cè)是否可以增加發(fā)送速率。

在Google的paper[3]中，計(jì)算帶寬的公式如下：

其中??= 1.05，?=0.85。從該式中可以看到，當(dāng)需要Increase時(shí)，以前一次的估算碼率乘以1.05作為當(dāng)前碼率；當(dāng)需要Decrease時(shí)，以當(dāng)前估算的接受端碼率（Rr(ti)）乘以0.85作為當(dāng)前碼率；Hold狀態(tài)不改變碼率。

最后，將基于丟包的碼率估計(jì)值和基于延遲的碼率估計(jì)值作比較，其中最小的碼率估價(jià)值將作為最終的發(fā)送碼率。

?

以上便是WebRTC中的擁塞控制算法的主要內(nèi)容，其算法也一直還在演進(jìn)當(dāng)中，每個(gè)版本都有會(huì)有一些改進(jìn)加入。其他還有一些主題這里沒(méi)有覆蓋到，比如平滑發(fā)送，可以避免突發(fā)流量； padding包等用來(lái)探測(cè)帶寬的策略。應(yīng)該說(shuō)WebRTC的這套機(jī)制能覆蓋大部分的網(wǎng)絡(luò)場(chǎng)景，但是從我們測(cè)試來(lái)看有一些特殊場(chǎng)景，比如抖動(dòng)或者丟包比較高的情況下，其帶寬利用率還是不夠理想，但總體來(lái)說(shuō)效果還是很不錯(cuò)的。

?

另外，想要獲取更多產(chǎn)品干貨、技術(shù)干貨，記得關(guān)注網(wǎng)易云信博客。

?

總結(jié)

以上是生活随笔為你收集整理的小议WebRTC拥塞控制算法：GCC介绍的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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