拥塞控制

概念：

• 拥塞的定义：太多太快的分组需要网络传输，超过了网络的处理能力
• 拥塞的原因：网络中的某些路由器队列溢出，开始丢包
• 拥塞的表现：
  • 分组丢失，源端超时
  • 在源端收到多个冗余ack
  • 延迟增大
• 拥塞控制的目标：
  • 不拥塞，吞吐大
• 拥塞控制的几个关键问题：
  • 拥塞检测：段超时、冗余ACK、ECN、延迟大
  • 拥塞时或非拥塞时：如何控速
  • 丢失的段什么时机重传

什么是冗余ACK：当某一个包丢包或者暂时迷失在网路中，后续的包先到达目的端，每到达一个seq更大的包，就会返回一次冗余ACK。

拥塞控制算法

Tahoe

拥塞事件：超时，3个冗余ACK

慢启动阶段：

• 每个RTT，发送窗口加倍
• 超时或者收到3个冗余ACK，重发，并把发送窗口设置成1，设置发送窗口i的一半为阈值
• 进入慢启动阶段
• 达到阈值则进入拥塞避免阶段

拥塞避免阶段：

• 每RTT，发送窗口增加1
• 超时或者3个ACk，则重发，并把发送窗口设置为1，进入慢启动阶段

network-tahoe

存在的问题：每次发生网络抖动，例如收到冗余ACK或者超时，则非常悲观的把发送窗口设置为1，导致发送的网络包像脉冲一样，网路有时高负荷，有时利用率低

Reno

慢启动阶段：

• new ACK：每个RTT，发送窗口增倍
• 超时：发送窗口设置为1，阈值为发送窗口一半
• 3个冗余ACK，阈值设置为一半，发送窗口设置为阈值加3，进入快速恢复状态
• 达到阈值，进入拥塞避免阶段

拥塞避免状态：

• new ACK：每RTT加1
• 超时：重传，阈值设置为窗口一半，窗口设置为1
• 3个冗余ACK：阈值设置为一半，窗口设置一半加3，进入快速恢复阶段

快速恢复状态：

• 冗余ACK：发送窗口每RTT加1，重传
• new ACK：进入拥塞避免状态
• 超时：发送窗口设置为1，进入慢启动

存在的问题：

进入快速恢复阶段，收到冗余ACK，只会重传一个包，如果这个包后续的包也发生了丢包，源端又不进行重传，会导致超时，进入慢启动状态

new reno

针对reno存在的问题，New Reno在快速恢复阶段进行了优化

快速恢复阶段：

• 冗余ACK：发送窗口加1
• 部分确认（PACK）
  • 发送确认后的段
  • 有新段可以发送，则发送新段
• 恢复确认（RACK）：收到所有段的确认
  • 进入拥塞避免阶段

存在的问题：

在一定程度上缓解了reno的问题，但是new reno在一个RTT只能恢复一个段的丢失，在网络上丢多个分段的时候，显得利用率不高

SACK

增加SACK包，在快速恢复阶段，在包中带多个分段的信息，

这样源端就可以高吞吐的重传多个分段丢失的包

CUBIC

思想是，考虑到在慢启动阶段通过2倍的速度来逼近阈值，和在拥塞避免阶段通过加1来慢速逼近阈值，CUBIC通过用立方函数，来快速逼近阈值

的出来的流量曲线如下

network-cubic

ECN

Reno系列的算法，都是依赖端对端的反馈，这样显得反馈太慢

通过修改TCP和IP协议，在网路的路由器发生拥塞时，及时反馈源端，显得更有效

缺点：需要修改路由设备

Vegas

基于Reno的算法，是基于超时、冗余ACk，但是网路此时已经出现严重的拥塞，拥塞的控制应该更加敏感

Vegas通过感知延迟的变化，在更早的时刻感知拥塞，更加温和的调节速度，让网路整体上，处于高利用率的状态

慢启动状态：

• 2个RTT增倍窗口
• 计算期望和实际的速度差
• 如果发现实际速度差大于1，设置阈值，并把窗口减少八分之一，进入拥塞避免状态

拥塞避免状态：

• 测量延时
  • cwnd=cwnd+1，Diff<α时
  • cwnd不变 ， α ≤Diff≤ β时
  • cwnd=cwnd-1 ， Diff> β时

网络流量的情况如下：

network-vegas

存在的问题：

对RTT的变化过于敏感，在跟其他算法在竞争网络时，显得过于温和，导致抢不到网络资源

BBR

基于评估网路的流量，来动态调整发送的速率

评估端对端重负载时的最大带宽BtlBW

评估端对端在不拥塞时的最佳延迟：RTprop

BDP = BtlBw * RTprop

源端在注入等待被确认的inflight数据不超过BDP

慢启动阶段：

• 指数型增加发送窗口
• 测量RTprop和BtlBw
• 发现BtlBw无法增加时，进入Drain阶段

Drain：

• 让速率略低于BDP，排空因慢启动阶段注入的过多流量
• 延迟变小后，进入稳定阶段，让速率等于BDP

ProbeBW：

• 周期性探测新的天花板或者退缩为低速的平衡

ProbeRTprop：

• 在稳定阶段抽取2%事件，降低速率，来测试RTprop
• 2%时间，增加速率，测试BtlBw
• 动态调整稳定器的BDP

QUIC

HTTP2存在的问题

• TCP握手次数多，延迟大
• 存在队首阻塞问题，单链接上的多路复用效果差
• 网络迁移问题，在移动IP移动，旧链接和新链接数据无法无缝对接
• 拥塞控制算法落后

HTTP3的思路

• 基于UDP，而不是TCP
• 自实现可靠传输、拥塞控制、流量控制
• 实现连接迁移
• 在用户态实现，不需要更新OS，便于部署推广

QUIC架构

network-quic