深入理解 TCP 拥塞控制

随着网络技术的飞速发展，越来越多的工作依赖网络完成，基于互联网的实时通信系统的质量和实时性也很大程度也依赖于网络质量。然而，在 Internet 的 TCP/IP 体系结构中，拥塞的发生是其固有的属性。网络拥塞是指用户对网络资源（包括链路带宽、存储空间和处理器处理能力等）的需求超过了固有的处理能力和容量, 相比 UDP，TCP 自身具有拥塞控制机制，并且需要保障数据可靠传输，这会对基于 TCP 的音视频实时传输造成一定的困扰。本文将深入讲解 TCP 的拥塞控制机制以及如何基于 TCP 传输来设计一个实时音视频系统。

PART 01 TCP 拥塞控制简介

TCP/IP 协议栈开始广泛运行后，网络开始遭受拥塞崩溃；即数据发送主机会以建议允许的速度将其数据包发送到互联网，当某些路由器发生拥塞，导致数据包被丢弃；对于 TCP 这种有重传机制的传输协议，当发生数据丢失时，重传数据将延长数据到达的时间；同时，高频率的重传，也将导致网络的拥塞得不到缓解，从而引发更多的拥塞。为了避免这类问题，1980 年代后期，TCP 拥塞控制被引入到网络协议中。

从广义上讲，TCP 拥塞控制的是让每个源确定网络中有多少可用容量，以便它知道可以安全传输多少数据包，防止过多的数据注入到网络中，使网络中的路由或者链路不至于过载。在网络中发生拥塞时，拥塞控制减少向网络中发送数据的速度，防止造成恶性循环；同时在网络空闲时，提高发送数据的速度，最大限度地利用网络资源。当然，确定可用网络容量并非易事，不断有新的 TCP 连接的加入和减少；更糟糕的是，可用带宽会随着时间的推移而变化，这意味着任何给定的源都必须能够调整它在传输中的数据包数量。

PART 02 TCP 拥塞控制算法分类

理论上，拥塞控制有两种实现方式：

• 端到端拥塞控制：在这种拥塞控制方法中，由发送端自己来判断是否拥塞，然后调整传输速率；

• 网络辅助的拥塞控制：由网络中的路由器来告诉发送方，网络的拥塞情况。

通过网络层反馈拥塞信息实现拥塞控制的方法，需要得到网络设备的支持，改造底层硬件；现在常用的 TCP 协议大都采用的是端到端拥塞控制，即由发送端自己来判断是否拥塞；若发送端检测到这种现象，就应该降低发送数据的速率，若没有，则可以慢慢提高速率。拥塞控制算法需要解决以下三个问题：

• TCP 如何限制数据的发送速率；

• TCP 如何检测网络中是否拥塞；

• TCP 采用什么算法来调整速率（什么时候调整，调整多少）。

TCP 拥塞控制算法发展的过程当中出现了以下几种不一样的思路：

• 基于丢包的拥塞控制：将丢包视为出现拥塞，采取缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减少，如 Tahoe、Reno、BIC-TCP、Cubic 等；

• 基于时延的拥塞控制：将时延增长视为出现拥塞，延时增长时增大拥塞窗口，延时减少时减少拥塞窗口，如 Vegas、Westwood 等；

• 基于链路容量的拥塞控制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时出现了拥塞，如 BBR；

• 基于学习的拥塞控制：没有特定的拥塞信号，而是借助评价函数，基于训练数据，使用机器学习的方法造成一个控制策略，如 Remy。

PART 03 常见 TCP 拥塞控制算法

TCP Reno

Reno 算法所包含的慢启动、拥塞避免和快速重传、快速恢复机制，是现有的众多基于丢包的拥塞控制算法的基础。发送方维持一个叫做拥塞窗口 cwnd（congestion window）的状态变量和慢开始门限 ssthresh 状态变量。ssthresh 的用法如下：

当 cwnd<ssthresh 时，使用慢开始算法。

当 cwnd>ssthresh 时，改用拥塞避免算法。

当 cwnd=ssthresh 时，慢开始与拥塞避免算法任意。

（1）慢热启动算法 – Slow Start

连接建好的开始先初始化 cwnd = 1，表明可以传一个 MSS 大小的数据。

• 每当收到一个 ACK，cwnd++; 呈线性上升。

• 每当过了一个 RTT，cwnd = cwnd*2; 呈指数上升。

（2）拥塞避免算法 – Congestion Avoidance

当 cwnd >= ssthresh 时，就会进入“拥塞避免算法”。算法如下：

• 收到一个 ACK 时，cwnd = cwnd + 1/cwnd

• 当每过一个 RTT 时，cwnd = cwnd + 1

（3）拥塞状态算法 – Fast Retransmit

Reno 在收到 3 个 duplicate ACK 时就开启重传，而不用等到 RTO 超时。拥塞发生时：

• cwnd = cwnd/2

• sshthresh = cwnd

（4）快速恢复 – Fast Recovery

cwnd = sshthresh + 3 * MSS （3 的意思是确认有 3 个数据包被收到了）

• 重传 Duplicated ACKs 指定的数据包；

• 如果再收到 duplicated Acks，那么 cwnd = cwnd +1；

• 如果收到了新的 Ack，那么，cwnd = sshthresh ，然后进入拥塞避免算法。

BIC-TCP 和 CUBIC

TCP-Reno 在大拥塞窗口环境下，由于一个数据包的丢失所带来的窗口缩小要花费很长的时间来恢复（每次仅增加 1），这样，带宽利用率不可能很高且随着网络的链路带宽不断提升，这种弊端将越来越明显。为了改善 Reno 拥塞避免阶段的表现，BIC-TCP 提出这样一个二分思想的：当出现丢包的时候，说明最佳窗口值应该比这个值小，那么 BIC 就把此时的 cwnd 设置为 max_win，把乘法减小后的值设置为 min_win，然后 BIC 就开始在这两者之间执行二分思想--每次跳到 max_win 和 min_win 的中点。

BIC-TCP 在高速网络中具有良好的可扩展性、自身竞争流之间的公平性和低窗口振荡的稳定性。然而，BIC-TCP 的拥塞控制窗口增长仍然可能会过大，特别是在短 RTT 或低速网络下。此外，在拥塞窗口控制的几个不同阶段(二进制搜索增加、最大探测、Smax 和 Smin)增加了协议实现和性能分析的复杂性。

CUBIC 是 BIC-TCP 的改进算法，CUBIC 算法通过寻找一个新的窗口增长函数，三次方函数，在保持 BIC-TCP 的优势的同时(特别是它的稳定性和可伸缩性)，同时简化了窗口控制的复杂度。CUBIC 窗口控制函数如下：

其中，W(t)是在时间 t 时，窗口的大小，C 为 CUBIC 参数，t 为上次减窗经过的时间，K 为上述函数在没有进一步损失事件时将 W 增加到 Wmax 所需要的时间周期，当发生拥塞事件时，CUBIC 将当前 cwnd 设置为 Wmax * β，乘法减小系数；由此可知 K 是：

通过下图可以看出，

• 当 cwnd < Wmax. CUBIC 在凸函数区域，即拥塞避免区间，cwnd 的增长随时间的增加而变小；

• 当 cwnd>=Wmax. CUBIC 在凹函数区域，即新的 Wmax 探测区域，当距离上次发生拥塞事件越久，cwnd 增长越快。

TCPW (TCP Westwood)

基于丢包的拥塞控制方法把数据包的丢失解释为网络发生了拥塞，而假定链路错误造成的分组丢失是忽略不计的，然而在高速网络中，这种假设是不成立的，当数据传输速率比较高时，或者在无线网络环境下，链路错误是不能忽略的。此时的丢包并不一定代表网络发生拥塞。同时，基于丢包的拥塞控制方法倾向于填满缓冲区，当瓶颈链路的缓冲区很大时，需要很长时间才能将缓冲区中的数据包排空，造成很大的网络延时，这种情况称之为缓冲区膨胀。

不同于基于丢包的拥塞控制，TCPW 发送端监控 ACK 报文的接收速率，进而估算当前连接可达到的数据发送速率（可用带宽）。当发送端检测到丢包时（超时或者 3 个重复 ACK），发送端根据估算的发送速率设置拥塞窗口大小（cwnd）和慢启动阈值（ssthresh）。

TCPW 评估当前采样点的带宽如下：

其中，dk 代表发送数据的数量，tk, tk-1 代表当前收到 ACK 包的时间和收到上一个 ACK 的时间；为了去除 ACK 带来的速率采样噪声，TCPW 对采样的速率应用一个低通滤波器来获得可用带宽的低频部分，得到如下的一个离散时间滤波器：

为了方便理解，假设 tk – tk-1 是一个常量；当前的带宽评估可以可以简化为：

可以认为，当前评估带宽是，之前评估带宽和最近 2 次评估带宽的一个平滑值；当发生 ACK 丢的情况，认为当前采样时间的带宽为 0，可以看出，TCPW 会把当前带宽认为是在上一个评估带宽上做了一次乘法减小。

TCP-Westwood 避免太过保守的减低窗口操作，与基于丢包的拥塞控制算法相比，TCP-Westwood 更适合于无线链路类的 TCP 连接。TCPW 早在 1990 年代末就提出了 google BBR 类似的想法，通过不断的测量带宽和最小 RTT 来估算网络的容量，最终将发生数据收敛。

BBR

BBR 是由 Google 设计，并于 2016 年发布的拥塞算法，以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而 BBR 基于模型主动探测。

因为最优带宽和延迟无法同时测量（btlBw 的测量会造成存在网络缓存增加 RTT，而 RTprop 的测量要求网络缓存为空），所以分别估计带宽（btlBw）和延迟（RTprop），最后计算出 cwnd。同时增加变量 pacing rate（btlBw * 增益系数），用于控制发送端的发送速率，以解决发送端突发造成的网络排队问题。

TCP BBR 一方面能够提升丢包环境下的发送速率，充分利用网络带宽，同时，也能够降低网络链路 buffer 的使用率，从而降低传输延时。TCP BBR 不仅适合 TCP 场景，同时 QUIC 也使用了 BBR 作为拥塞控制算法。

PART 04 实时多媒体 QoS 与 TCP 拥塞控制

虽然现在的实时多媒体通讯大部分都是基于 UDP 协议来实现，但是也存在一些情况，需要通过 TCP 来传输音视频；例如 UDP 端口屏蔽。相对于 UDP 数据传输的丢包，乱序， TCP 网络下的传输数据延时大，队头阻塞等问题，为实时音视频传输也带来了更大的挑战。

实时多媒体的一些特点：

• 对于视频高清的需求，大码率场景下，单位吞吐大幅增加，单帧大小大幅增加，导致网络丢包数大幅增加，

• 实时通信对低延迟的要求，导致对数据传输的实时性的要求高。

为了更好的提升实时多媒体 QoS，在 TCP 环境下，设置拥塞控制和流量控制，需要考虑到以下一些的方面：

• 快速地检测到网络的拥塞事件发生；

• 精准的控制编码码率，特别是对视频关键帧的编码，避免出现大的网络冲击；

• 更积极的网络探测，对网络带宽的充分利用，可以带来更好的音视频体验；

• 通过 simulcast 和 SVC, 在带宽不足的情况下，尽量保证音视频的实时性和流畅度；

• 尽量避免发送无效数据冲击网络，例如 FEC、NACK。

PART 05 总结

拥塞控制应该是 TCP 中相对比较复杂的一个部分了，通过介绍 TCP 拥塞控制设计思想以及一些常用拥塞控制算法的设计思路，希望大家能对 TCP 拥塞控制有更好的了解。