現有市場上的主流直播在傳輸方面，大部分使用TCP傳輸，也有部分使用UDP傳輸（類似上行使用rtc，然后在源站或者媒體服務器轉換為rtmp協議再進行推流）。通常來說，udp效率更高一些，但由于自身無連接缺少確認機制，缺少丟包重傳，所以通常開發者會增加冗余來對抗網絡的不穩定性，這也造成了流量費用的增加；TCP自身做了重傳，確保可靠和順序性，所以在對實時性要求并不高的直播，使用TCP是個很好的選擇。

網易云信直播sdk目前使用了TCP進行傳輸，而且基于此從編碼動態適配，發送隊列調整，協議優化，socket等做了全流程的優化，確保我們在限帶寬，丟包，時延，抖動，無論單項，還是復雜網絡，都有不輸于競品的體驗。

?

●●●

優化的細節指標

在不犧牲卡頓率的情況下，提升帶寬利用率8成以上，碼流更平穩。

?

●●●

優化的理論基礎

為了防止網絡的擁塞現象，TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由“慢啟動(Slow start)”和“擁塞避免(Congestion avoidance)”組成，后來TCP Reno版本中又針對性的加入了“快速重傳(Fast retransmit)”、“快速恢復(Fast Recovery)”算法，再后來在TCP NewReno中又對“快速恢復”算法進行了改進，近些年又出現了選擇性應答( selective acknowledgement,SACK)算法，還有其他方面的大大小小的改進，包括google優化后的BBR算法（目前移動端無法使用），成為大家研究的一個熱點。

? ? ??

? ? ? ? ? ? ? ? ? ? ?

快速重傳：

快速重傳算法要求首先接收方收到一個失序的報文段后就立刻發出重復確認，而不要等待自己發送數據時才進行捎帶確認。接收方成功的接受了發送方發送來的M1、M2并且分別給發送了ACK，現在接收方沒有收到M3，而接收到了M4，顯然接收方不能確認M4，因為M4是失序的報文段。如果根據可靠性傳輸原理接收方什么都不做，但是按照快速重傳算法，在收到M4、M5等報文段的時候，不斷重復的向發送方發送M2的ACK,如果接收方一連收到三個重復的ACK,那么發送方不必等待重傳計時器到期，由于發送方盡早重傳未被確認的報文段。

快速恢復：

當發送發連續接收到三個確認時，就執行乘法減小算法，把慢啟動開始門限（ssthresh）減半，但是接下來并不執行慢開始算法。

此時不執行慢啟動算法，而是把cwnd設置為ssthresh的一半， 然后執行擁塞避免算法，使擁塞窗口緩慢增大。

TCP的擁塞控制主要原理依賴于一個擁塞窗口(cwnd)來控制，TCP還有一個對端用的接收窗口(rwnd)用于流量控制。窗口值的大小就代表能夠發送出去的但還沒有收到ACK的最大數據報文段，顯然窗口越大那么數據發送的速度也就越快，但是也有越可能使得網絡出現擁塞，如果窗口值為1，那么就簡化為一個停等協議，每發送一個數據，都要等到對方的確認才能發送第二個數據包，顯然數據傳輸效率低下。TCP的擁塞控制算法就是要在這兩者之間權衡，選取最好的cwnd值，從而使得網絡吞吐量最大化且不產生擁塞。

由于需要考慮擁塞控制和流量控制兩個方面的內容，因此TCP的真正的發送窗口=min(rwnd, cwnd)。但是rwnd是由對端確定的，網絡環境對其沒有影響，所以在考慮擁塞的時候我們一般不考慮rwnd的值，我們暫時只討論如何確定cwnd值的大小。關于cwnd的單位，在TCP中是以字節來做單位的，我們假設TCP每次傳輸都是按照MSS大小來發送數據的，因此你可以認為cwnd按照數據包個數來做單位也可以理解，所以有時我們說cwnd增加1也就是相當于字節數增加1個MSS大小。

●●●

優化的具體內容

TCP的慢啟動，擁塞避免，快速重傳機制告訴我們，在應用層擁堵之前，會快速降低擁塞窗口大小，導致tcp通道可發送帶寬會快速降低，這個時候如果不快速降低數據流量， 會大量丟包重傳， 應用層會進入擁堵狀態，導致惡化。

我們通過觀測若干系統反饋的socket 健康指標，一旦發現該socket進入快速重傳，我們會提前降低視頻的編碼參數；同時如果周期一直健康狀況良好，我們測算的可發送帶寬也大于實際發送大小，我們會緩慢提升視頻的編碼參數；整個調優會基于快降慢升，音頻優先的原則來實施。

? ??

【推薦閱讀】Android短視頻中如何實現720P磨皮美顏錄制

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的网易云信直播sdk的整体传输优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。