随着网络技术的飞速发展，越来越多的工作依赖网络实现，基于互联网的实时通信零碎的品质和实时性也很大水平也依赖于网络品质。然而，在 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 来估算网络的容量，最终将产生数据收敛。BBRBBR 是由 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 拥塞管制有更好的理解。