参考资料
前言
之前大致了解了QUIC的特性，为了之后的实现。目前需要补充拥塞控制算法的知识。 拥塞控制算法：Reno，Cubic，BBR
Tahoe
Reno
超时都会转为 慢启动状态。
Reno的问题：收到一个新ACK就退出快速恢复状态。
- 适合单个段被丢弃的情况。
但是，如果出现成串分组被丢失。Reno:
- 丢失段 会被重传，但是之后连续丢失的段 会超时，进入到慢启动状态。
- 后续的发送速率会非常低。
举个例子：
- 发送方发送包 1~5，其中包 2 和包 3 丢失；
- 接收方收到包 4、5 后，持续发送 ACK1（期望包 2），触发 Reno 快速重传包 2；
- 包 2 重传成功后，接收方发送 ACK3（确认包 2，但包 3 仍丢失）—— 这是一个部分 ACK（仅确认了部分数据）；
- Reno 的处理：将
cwnd设为ssthresh并退出快速恢复，进入拥塞避免； - 此时包 3 仍丢失，接收方会继续发送 ACK3，直到再次收到 3 个冗余 ACK 或 RTO 超时，才会重传包 3。这期间会浪费带宽，且
cwnd已被降低，吞吐量下降。
New Reno
举个例子：
- 沿用上述包 2、3 丢失的场景，当 New Reno 收到 ACK3（部分确认）时，会立即重传包 3，并保持在快速恢复阶段；
- 包 3 重传成功后，接收方发送 ACK4（完全确认，恢复确认），此时 New Reno 才退出快速恢复，进入拥塞避免。（超过了发送方进入快速恢复阶段时未被确认的最大数据序号，说明所有的丢失包都接收到了）
收到A的三个冗余ack，发送方记住当前已经发送的 字节y，只有收到字节y+1的确认，才算是RACK。而不是当前 所有已发送但是未发送的字节都得到确认才是 RACK.⭐（当所有 拥塞时候的段 都得到确认后才能够叫做RACK）
缺点：恢复确认阶段，一个RTT只能恢复一段，效率不高。
SACK
- 在 cw 允许条件下，发送段一次发送多个丢失段，
图下图，47410 是 累计确认收到的字节。ack_number = 47411。补充TCP options（12字节）：L 表示TCP options内有效数据总长度，乱序到达的端。 发送放接到SACK后，ScoreBoard记录需要重发的段的序列。
进入快速恢复阶段：
... 待补充
Vegas
Cubic
BBR: BtlBW and RTT based Congestion Control
- BtlBW：瓶颈链路带宽，一对通信主机之间，分得带宽最小的那段链路
- RTT：轻载时，各队列都没有排队（瓶颈链路队列没满，其他肯定没满）情况下的往返延迟之和
- BDP：Bandwidth delay product也就是延迟带宽积，可以表示网络链路中的可容纳的数据量。
- inflght：在链路上传输的数据
基于模型的拥塞控制，将网络模型分为应用受限和带宽受限等阶段；交替测量BtlBW和RTT，计算BDP，反映网络路由和通信量的变化；按照BtlBW控制主机注入速率，按照BDP控制inflight的数量。吞吐量大，延迟低，公平性好
基于丢失的拥塞控制算法的问题
Reno，New Reno，SACK，Cubic 等
原理：丢失=拥塞，拥塞后（慢启动之后cwnd减半）
前提：有线链路多，带宽不大，网络交换节点buffer不大；此时大概率，丢失=拥塞。
大容量buffer在网络交换节点采用，基于丢失的拥塞控制倾向于将通路上（瓶颈链路交换节点）的buffer充满⭐；先拥塞，之后很久才会丢失，时机迟，延迟大。
- 反复丢失（通过丢失尝试通路的带宽上限）带来的吞吐振荡（链路利用率不高）
- 端到端延迟大（buffer满了，排队延迟大）
- 算法侵略性（算法倾向于抢占buffer，造成丢失，再调整）
通信模型
控制思想：
- 源端注入的速率不能超过 BtlBW
- BDP = RTT * BtlBW，从源端注入的等待被确认的inflight数据不超过BDP
如上图，整个通信模型分为三个阶段：
- 应用受限： RTT不变；吞吐量随着应用速率增大而增大。（此时网络的速率取决于发送速率）
- 带宽受限：带宽充满，buffer没满；此时，吞吐量不变，但RTT随着队列中的的分组数量增大而增大。
- 缓冲受限：带宽，buffer都充满，此时发生数据包丢失。吞吐量不可知，RTT极大。
如上图，拥塞发送在绿点，丢失发送在红点。拥塞比丢失来的早。
BBR 拥塞控制思路
- 问题：通过上文的模型已知，参数 BtlBW和RTprop 未得。
- 方法：测量，基于 BtlBW 和 RTprop 进行拥塞控制。
测量 RTprop
显然，只有在应用受限，才能测量 RTprop。
- 握手阶段，低速率情况
- 高速率情况：每一段时间，抽出2%时间，降低到应用受限，测量RTprop。
最近一段时间，最小的往返延迟当做 RTT。
- 只有路由变化，RTprop才会变化
测量 BtlBW
显然，在带宽受限，测量交付速率，将近期最大的交付速率当做 BtlBW
- 连接建立后，不断增加inflight，连续三个RTprop交付速率不增加25%进入带宽受限状态。
