1 各種流控演算法

說到流控演算法，業內人士腦海中應該立刻就能夠浮現出下面的名詞：

• TCP，擁塞控制，滑動視窗；
• QUIC，BBR；
• WebRTC，GCC，TransportCC
• UDT；
• KCP；
• ……

流控演算法領域，公說公有理，婆說婆有理，各家都把自家演算法誇的天花亂墜，也都能給出漂亮資料，總之看官絕大部分也沒有條件去充分驗證，那麼結果基本上就是，弱水三千我只取一瓢。

2 P2P的流控

2.1 流控的目的

很少有使用者願意眼睜睜看著自己裝置上的程式在上傳資料，但是P2P就是幹這個事情的，想要使用者不反感是不可能的，那麼只能讓使用者別發現，或者說別在意。只要不那麼佔用使用者裝置的CPU資源，別的程式執行不卡，也沒有佔滿使用者的上行頻寬，讓使用者上不了網，玩不了遊戲，那麼使用者基本不會發現，也不會在意。那麼P2P的上傳端要控制連線的數量和上傳頻寬，下載端也要控制好下載的速率。

眾所周知中國的網路環境，使用者的上下行頻寬不對稱。使用者的頻寬特別是上行頻寬很寶貴，在幾年前，基本可以認為使用者的平均上行頻寬是512kbps，也就是64K Byte/S，這兩年個人使用者的頻寬降價提速，應該能達到1～2Mbps。這些資料就是P2P的底線，過了這個底線，使用者就不幹了。

平均水平是一回事，但是具體到每個使用者就不一樣了，有高有低，一概而論很容易出問題，因此流控演算法應運而生。

2.2 演算法

搜狐視訊P2P採用的流控演算法很簡單，但是可以看到市面上流行的各種流控演算法的元素，目前也沒法證明有多高效。
演算法思想：

• 主要目標是估算某個Peer的可用頻寬，從而換算為每秒可以請求的任務數；
• 計算Peer最近若干個請求的平均Rtt，這裡可以選擇算數平均或者TCP的估算演算法；
• 為每個Peer設定一個初始視窗大小W，頻寬=W/Rtt，每秒請求數=頻寬/每個請求的大小，但是設定上限；
• 類似慢啟動，如果當前任務都在規定時間(Rtt的一個倍數)得到了響應，那麼視窗增加，否則視窗減小；
• 統計丟包率；
• 根據丟包率和Rtt計算出Peer的一個分值，並根據分值給Peer排序，分值較高的Peer將優先分配更多的任務。

可以看到，一旦發生了輕微的擁塞，那麼P2P就會試圖避讓，減小視窗，降低每秒請求數，跟GCC異曲同工，並不強求爭搶速度，跟某些P2P軟體相比，顯得很君子，目的也是盡力不讓使用者反感。

這裡主要是針對搜狐影音Peer的流控演算法，對Flash Peer來說，由於使用了RTMFP協議，實現了RFC7016規定的類似TCP的流控演算法，H5的P2P則使用了WebRTC的資料通道，也有類似的流控演算法。

除此之外，需要給上層提供限制下載、上傳速度的介面，這樣可以確保萬無一失。

另外，科普一下公式:頻寬=W/Rtt
W上面叫視窗，實際上是通道的容量，換個專業的稱呼叫頻寬時延積，也就是一個端到端的通道上能夠容納的已經發出但是沒有到達目的還沒有確認的包的量。
這個公式有很多變種，例如服務端QPS=併發/平均請求時間，很多服務端程式設計師工作幾年仍然無法理解併發和QPS的區別。