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的区别。