全网最强TCP/IP拥塞控制总结( 六 )


我们都知道在移动网络环境下是由终端以无线形式和附近的基站交互数据 , 之后数据传输至核心网 , 最后落到具体的服务器所在的有线网络 , 其中最后一公里的区域属于高延时场景 , 有线网络属于低延时高带宽场景 。
在国外有相关实验证明弱网环境下RTT的变化对于使用传统拥塞控制算法下网络吞吐量的影响 , 数据和曲线如图所示:

全网最强TCP/IP拥塞控制总结

文章插图
 

全网最强TCP/IP拥塞控制总结

文章插图
 
实验含义:RTT的增大影响了比如CUBIC这类拥塞控制算法的慢启动等阶段 , 我们知道慢启动阶段每经过1个RTT周期拥塞窗口cwnd将加倍 , 但是更大的RTT就意味着发送方以很低的速率发送数据 , 更多的时间是空闲的 , 发包的加速度极大降低了 , 所以整个吞吐量就下降很明显 。
看下实验者的原文表述:
The delay before acknowledgment packets are received (= latency) will have an impact on how fast the TCP congestion window increases (hence the throughput).
When latency is high, it means that the sender spends more time idle (not sending any new packets), which reduces how fast throughput grows.
六.强悍的BBR算法BBR算法是个主动的闭环反馈系统 , 通俗来说就是根据带宽和RTT延时来不断动态探索寻找合适的发送速率和发送量 。
看下维基百科对BBR算法的说明和资料:
相关文献:
https://queue.acm.org/detail.cfm?id=3022184
TCP BBR(Bottleneck Bandwidth and Round-trip propagation time)是由Google设计 , 并于2016年发布的拥塞算法 , 以往大部分拥塞算法是基于丢包来作为降低传输速率的信号 , 而BBR基于模型主动探测 。
该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型 。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率 。
该算法认为随着网络接口控制器逐渐进入千兆速度时 , 分组丢失不应该被认为是识别拥塞的主要决定因素 , 所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟 , 可以用BBR来替代其他流行的拥塞算法例如CUBIC 。
Google在YouTube上应用该算法 , 将全球平均的YouTube网络吞吐量提高了4% , 在一些国家超过了14% 。BBR之后移植入Linux内核4.9版本 , 并且对于QUIC可用 。
6.1 丢包反馈策略存在的问题基于丢包反馈属于被动式机制 , 根源在于这些拥塞控制算法依据是否出现丢包事件来判断网络拥塞做减窗调整 , 这样就可能会出现一些问题: