传输控制协议拥塞控制（传输控制协议拥塞控制）
传输控制协议拥塞控制
次浏览
更新时间：2023-05-28
基本信息
| 外文名 | TCP congestion algorithm |
拥塞成因
端到端TCP拥塞控制的本质思想是通过调整发送端的发送速率来控制网络的负荷量。具体地说，TCP不断地通过加大发送的速率来对当前网络的实际承载能力进行探测，并随时准备对网络发回的拥塞信息做出响应，即迅速减小向网络中发送信息的速率，并在新的起点上继续对网络进行试探。
那么，是什么原因导致数据吞吐量如此严重的下降呢？原来在TCP的控制机制里面只考虑到了接收端的接收能力，但是受很多因素的影响无法考虑另一个很重要的方面，那就是网络自己的传输能力不足，从而造成了整个网络崩溃的发生。
就互联网体系结构而言，网络拥塞必然会发生。因为在没有进行任何预先请求（Prior Request）和协商（Prior Consult）许可机制的共享资源网络中，几个数据分组可能会同时到达中间节点，并希望经同一个输出端口同时转发。显然，不是所有数据分组都可以同时进行转发，必须有一个服务顺序。网络中间节点上的缓存队列为等候服务的数据分组提供一定的过载保护。然而如果此种状态具有一定的持续性，当中间节点的缓存队列空间耗尽时，中间节点只有将后到的数据分组丢弃。从表面上看，增大缓存队列容量就可以防止由于网络拥塞引起的数据分组丢弃，但随着缓存队列容量的增加，端到端的往返时延（RTT）也相应增大。而数据分组的传输持续时间是有限的，同时需要重传超时的数据分组。
正是由于这部分数据分组浪费大量的网络可用带宽，过大的缓存队列容量反而可能妨碍网络拥塞的恢复。网络拥塞导致的直接结果是数据分组丢失率不断提高、端到端时延不断加大，甚至有可能使整个网络系统陷入瘫痪。当网络处于拥塞状态时，即便只是微量的负载增量都可能使网络的有效吞吐量急剧下降。网络处于拥塞崩溃状态时对互联网产生的威胁可以追溯到其早期的发展中。
为了最大限度地利用资源，网络工作在轻度拥塞状态时是较为理想的，但是如果没有一定的拥塞控制机制加以约束和限制，必将增加滑向重度拥塞状态的可能性。网络拥塞控制是确保网络鲁棒性的关键因素，拥塞控制算法最基本和最重要的要求就是防止网络出现拥塞崩溃，使网络运行在轻度拥塞的最佳状态，这样拥塞控制模型或算法既能保证网络效率，又不会出现网络欠载或过载，同时又能保证流量间的公平性。
网络产生拥塞的根本原因是“供求关系”失衡，即网络负载大于网络资源容量和处理能力，结果导致数据包时延增加，丢失概率增大，应用系统性能下降等。
产生拥塞的原因可以归结为以下几方面。
（1）瓶颈链路缓存容量不足。多个分组同时到达路由器，并期望经同一个输出端口转发时，分组序列自动进入中间节点的缓存等待处理。如果这种情况持续发生，当缓存空间被耗尽时，如果几个输入数据流共同需要同一个输出端口，那么这些数据流在输出端口上排队等待。如果没有足够的存储空间，数据包就会被丢弃，这对突发数据流更是如此。
要求所有信源发送的速率R必须小于或等于信道容量C。如果R大于C，则在网络低速链路处就会形成带宽瓶颈，一旦链路满足不了所有通过它的源端带宽的需求时，网络就会发生拥塞。
（3）处理器处理能力受限。如果网络设备在执行排队缓存、更新路由表等功能时，处理速度跟不上高速链路，也会产生拥塞。虽然拥塞源于资源短缺，但增加资源并不能避免拥塞的发生，有时甚至会加重拥塞程度。当增加路由器缓存时，表面上看可以防止与缓解由于拥塞引起的分组丢弃，但随着缓存的增加，端到端的时延也相应增大。因为分组的持续时间（life-time）是有限的，超时的分组同样需要重传，因此，过大的缓存空间有可能使总延迟超过端系统重传计时器的值，从而导致分组重传，这些分组白白浪费了网络的可用带宽，反而会加剧网络拥塞。
（4）从应用的角度来看，多条流入线路可能会分组到达，并需用同一输出线路。此时，如果路由器没有足够的内存来存放所有这些分组，那么有的分组就会丢失。
因此，为了解决网络拥塞问题，除了适当地增加缓存容量、尽可能地增加链路带宽和提高处理器的能力以外，还需要采用拥塞控制机制。
算法改进
1985年Nagle报告了由于传输控制协议（TCP）中没必要的重传所引发的网络拥塞崩溃。
1986年10月，从美国劳伦斯伯克利国家实验室（Lawrence Berkeley National Laboratory，LBL，简称伯克利国家实验室，隶属于美国能源部，从事非绝密级的科学研究，坐落在加州大学伯克利分校的中心校园内，位于伯克利山的山顶，现由美国能源部委托加州大学代为管理）到加州大学伯克利分校（University of California，Berkeley，简称UC Berkeley）的数据吞吐量从32Kbps下降到40bps（具体内容请参考V.Jacobson的论文Congestion Avoidance and Control）。这是被明确记载并研究的第一次网络拥塞崩溃事件。从这以后，TCP的研究课题就开始多了一个方向，那就是拥塞控制，因为拥塞控制算法对保证互联网的稳定性具有十分重要的作用，其中以V. Jacobson的那篇论文为标志开创了互联网拥塞控制领域的工作。
这个事件的发生，也使得研究人员重新认识TCP传输的性能瓶颈。随着技术的发展，网络在日常生活中成了必需品。越来越深入的研究发现，单纯提高网络的传输带宽，并不能提高网络传输性能。因此，如何提高网络传输性能，成了一个重要的研究课题。目前的研究主要涉及以下两个主要方面：一方面，从网络本身出发，努力提高网络的带宽，如目前在大型数据中心广泛采用的万兆以太网、光纤网络等；另一方面各种传输控制理论层出不穷，尽量占用可用带宽。
拥塞崩溃的发生严重降低网络的性能，自此，人们在拥塞控制领域开展了大量的研究工作。1986年Jacobson最早提出拥塞避免机制，并在其1988年的论文中做了详细讨论，慢启动、快速重传及拥塞避免算法构成了AIMD（Additive Increase Multiplieative Decrease）机制的基础。1997年，这些算法合并作为RFC公布。在此基础上后人经过十几年的讨论和研究，TCP的拥塞控制机制得到很大改进。
最初由V. Jacobson在1988年的论文中提出的TCP的拥塞控制由“慢启动（Slow start）”和“拥塞避免（Congestion avoidance）”组成，后来TCP Reno版本中又针对性地加入了“快速重传（Fast retransmit）”、“快速恢复（Fast Recovery）”算法，再后来在TCP NewReno中又对“快速恢复”算法进行了改进，出现了选择性应答（selective acknowledgement，SACK）算法，还有其他方面大大小小的改进。拥塞控制机制成为网络研究的一个热点。
算法发展
1994年，Brakmo提出了一种新的拥塞控制机制TCP Vegas，从数据包传输时间的角度来进行拥塞控制。但是，由于和已经广泛使用的控制机制之间出现了竞争问题，因此并没有得到广泛的应用。
从此，TCP的拥塞控制进入了新的阶段，百花齐放，出现了很多研究热点，其中比较集中的方面有：“慢启动”过程的改进，基于速率的拥塞控制，ECN，针对特殊网络（无线网络和卫星网络）的拥塞控制。最初提出了HSTCP，后来又出现了TCP BIC、TCP CUBIC、FAST TCP、TCPWestwood等一系列的改进，比较具有代表性的方案主要有针对高速网络的TCP BIC/CUBIC、High Speed TCP、Scalable TCP、MulTCP和针对媒体应用的TFRC等。该类算法沿用TCP Reno“丢包即拥塞”的传统假设，只是对AIMD的拥塞控制窗口调节过程进行了优化。尽管这些优化改进在某种程度上提高了TCP Reno的拥塞控制协议性能，但是Reno算法在无线网络中的传输性能问题同时也被继承了下来，限制了该类方案在无线网络环境中的部署和应用。
另一类拥塞控制方案采用数据包在网络瓶颈节点缓冲区中的排队延迟（即由拥塞造成的网络延迟增加量），作为网络拥塞的信号。当网络中的分组数量超出了网络瓶颈节点的传输能力时，网络转发节点并不会马上将多余的分组丢弃，而是将其暂时保存在自身的缓冲区中进行排队等待。数据包在转发节点的缓冲区中堆积排队，将会引起网络端到端延迟的增加，基于延迟的拥塞控制方案就根据延迟的增加量，设计不同的算法来控制网络拥塞。典型的基于延迟的拥塞控制方案主要有TCP vegas和FAST TCP等。
为了综合利用这两类拥塞控制方案的优势，研究人员们提出了混合型拥塞控制方案，比较典型方案的有针对无线网络的TCP Veno、TCP Westwood/Westwood+方案，以及针对高速网络的Compound TCP、H-TCP、TCP Illinois、UDT和针对媒体传输应用的TFRC Veno等。
概念术语
（1）拥塞窗口（cwnd）：拥塞控制的关键参数，控制源端在拥塞情况下一次最多能发送多少个数据包。
（3）通告窗口（awnd）：接收方TCP缓存当前的大小，此窗口就是TCP内核的缓冲区大小，通常要求其为MSS的偶数倍。
（4）慢启动阈值（ssthresh）：拥塞控制中用来限制发送窗口大小的阈值，它是慢启动阶段与拥塞避免阶段的分界点，初始值设为65535B或awnd的大小。
（5）往返时延（RTT）：从发送端发送数据开始，到发送端接收到来自接收端的确认（接收端接收到数据后便立即发送确认），总共经历的时延。
（6）超时重传计时器（RTO）：描述数据包从发送到失效的时间间隔，是源端用来判断数据包是否丢失和网络拥塞的重要参数，通常设为2RTT或5RTT。
TCP实现
Tahoe
Tahoe算法是TCP的早期版本。它的核心思想：让cwnd以指数增长方式迅速逼进可用信道容量，然后慢慢接近均衡。Tahoe 包括3 个基本的拥塞控制算法：“慢启动”、“拥塞避免”和“快速重传”。同时Tahoe算法实现了基于往返时间的重传超时估计。
（1）TCP Tahoe在连接建立后，cwnd初始化为一个报文段，开始慢启动，如果没有丢包和拥塞发生，直到cwnd等于ssthresh，然后进入拥塞避免。
（2）若重传定时器超时，cwnd重新设置为一个报文段大小，重新开始慢启动，同时ssthresh为当前cwnd的一半。
（3）若发送端收到3个重复ACK，不等到重传定时器超时就执行快速重传，即立刻重传丢失的报文段。
重传超时估计是对重传定时器的超时时间取值的估计。重传定时器是判断报文段丢失的依据，发送端发送一个报文段同时启动重传定时器，如果重传定时器超时，但发送端还没有收到接收端的ACK，就判断该报文段丢失，重传丢失报文段并重新启动重传定时器。每一个TCP连接都维护一个变量，用于计算往返时间RTT。TCP采用动态重传超时估计，即以往返时间RTT为基础来确定重传超时时间。其中最常用的是设置重传超时时间为往返时间RTT的两倍，即
重传超时时间= 2×RTT
另外，往返时间RTT的计算也是动态的，通常可以按下列式子计算:
RTT=a×最近RTT+（1-a）×当前RTT
其中，a的取值为0～1，一般取值0.8～0.9。
在检测到报文段丢失后，希望能迅速地将该报文段重传，减少不必要的等待时间，提高TCP的吞吐量。如果设置重传超时时间等于往返时间RTT，那么当网络中的时延变化引起当前往返时间RTT值略大时，就会使重传超时时间小于往返时间RTT，导致不必要的重传，因此一般使用重传超时时间为往返时间RTT的两倍。
Tahoe算法的不足之处在于，收到3个重复ACK或在超时的情况下，Tahoe设置cwnd为1，然后进入慢启动阶段。这一方面会引起网络的激烈振荡，另一方面大大降低了网络的利用率。
Reno
针对Tahoe算法的不足，提出了Reno算法，主要有两方面改进：一是对于收到连续3个重复的ACK确认，算法不经过慢启动，而直接进入拥塞避免阶段；二是增加了快速重传和快速恢复机制。Reno算法以其简单、有效和鲁棒性好成为TCP控制算法的主流，被广泛应用。
TCP Reno在TCP Tahoe版本上加入“快速恢复”算法。TCP Reno中，如果发送端收到3个重复ACK，不必等到重传定时器超时，就会执行快速重传，然后执行快速恢复算法，进入拥塞避免。
图1 TCP Reno状态转换图
（1）首先发送端在检测到丢包或拥塞后，重传从数据丢失到检测到丢失这段时间发送端发送的所有报文段，但是其中有些报文段被接收端正确收到，可以不必重传。
（2）其次，准确测量往返时间RTT是很重要的。理论上往返时间RTT的测量比较简单，是指报文段从发出到ACK返回发送端的时间，但是由于TCP是使用一个ACK确认所有已经收到的报文段的“累积”确认方式，往返时间RTT的估值在实际中往往比较复杂，因此准确测量往返时间RTT也是研究问题之一。
（3）Reno算法的另一个不足之处在于，它不能有效地处理多个报文分组从同一数据窗口丢失的情况。
NewReno
TCP NewReno的主要改进在于一个窗口内多个报文段丢失的问题。这样可以避免TCP Reno中的多次重传超时。另外，TCP NewReno算法在快速恢复中引入了部分确认（Partial ACK）。它在快速恢复阶段到达并且确认新数据，但它只确认进入快速重传之前发送的一部分数据。
部分确认是指在快速恢复阶段对新报文段的确认（不包括还在传输中未接收到的数据）。在Reno中，部分确认导致离开快速恢复状态，即发送端收到一个不重复的ACK就退出快速恢复阶段。在NewReno中，只有当所有报文段的ACK都收到后才退出快速恢复。
具体来说，就是重传定时器溢出或者重复地确认ACK到达时，TCP Reno会退出快速恢复状态，等待，但是TCP NewReno并不退出快速恢复状态，而是按以下步骤执行。
（1）重传紧接着那个部分确认ACK之后的报文段，拥塞窗口减去部分确认ACK的大小；
（2）对于得到确认的新数据，设置cwnd等于其加上SMSS：
（3）对于第一个或每一个Partial ACK，重传定时器复位。
举例说明，序号为1的报文段丢失了，TCP发送端又发送了序号为2、3、4、5的报文段之后才收到3个重复的ACK。进入快速重传，重传序号为1及其之后的报文段，然后进入快速恢复，等待序号为1的报文段的ACK。此时，TCP发送端记录序号为5，就是说TCP发送端希望收到序号为6的ACK。如果收到序号为6的ACK，那么这个ACK就确认了重传之前的所有报文段。
但是如果收到序号小于6的ACK，那么这个ACK只是确认了重传之前的部分报文段，也就说明此时丢失了多个报文段，这个ACK就是部分确认的ACK。例如，收到序号为3的ACK，那么能够确定序号为1的丢失的报文段和序号为2的报文段重传后都被接收到，也说明序号为3的报文段也丢失了，需要重传。
如果执行TCP Reno算法，收到部分确认的ACK即序号为3的ACK就退出快速恢复回到拥塞避免，然后收到3个重复的序号为3的ACK再进入快速重传，重传序号为3的报文段再进入快速恢复。这样TCP发送端不仅增加了发送的时间，而且拥塞窗口一直重复地减半，如果丢失的报文段更多的话，整个TCP的吞吐量就会变得很低。
如果执行TCP NewReno算法，收到部分确认的ACK即序号为3的ACK就继续进行快速重传，重传序号为3的报文段，然后继续快速恢复，如果还有报文段丢失，那么重复这个过程。这样TCP发送端发送时间缩短，而且避免了拥塞窗口不必要的减小。
SACK
TCP SACK（Selective Acknowledgement）也是对TCP Reno的改进，当检测到拥塞后，不必重传从数据丢失到检测到丢失这段时间发送端发送的所有报文段，而是对这些报文段进行有选择的确认和重传，避免不必要的重传。
在连接建立阶段，发送端和接收端进行“协商”，确定是否使用SACK选项。SACK选项需要在TCP报文段中设置标识位，标识接收端最近收到的序列号连续的三个报文段。如果使用SACK选项，那么在数据传输中，当接收端缓存队列中出现序号不连续的报文段时，就向发送端发送标识SACK选项的重复ACK。发送端得知哪些报文段已经被接收，哪些报文段丢失，从而选择性地重传丢失的报文段。
SACK选项已经成为Linux系统的标准选项，在目前的系统部署中，这个标准选项通常都已经选中。
Vegas
1994年，Brakmo提出了TCP Vegas算法。TCP Vegas是一种截然不同的拥塞控制算法，它采用一种更巧妙的带宽估计策略，根据期望的流量速率与实际速率的差估计网络瓶颈处的可用带宽。
TCP Vegas改进了其中三种算法，简要介绍如下。
（1）新的快速重传算法。它将引发重传的重复ACK数量从三个减少为两个或者一个，因此TCP能够对报文段丢失做出更快速的反应。
（2）新的拥塞避免算法。它改变了其他实现版本中通过报文段丢失来检测网络拥塞的基本思想，而是通过观察已发送报文段的往返时间RTT的变化来判断网络的拥塞状况，即如果观察到往返时间RTT变大，认为网络开始拥塞，因此减小拥塞窗口；相反，则认为网络畅通，增大拥塞窗口。
（3）新的慢启动算法。改进后每隔一个往返时间RTT内拥塞窗口增大一倍，在这之间窗口固定不变。
由于TCP Vegas只和往返时间RTT的改变有关，所以往返时间RTT的准确度非常重要。实际过程中采取了许多措施来保证往返时间RTT测量的精确度，如细粒度的时间计算等。同时，TCP报文段大小也会对往返时间RTT有一定影响。
Veno
有线网络主要是由于拥塞产生数据包的丢失，称为拥塞丢包。无线网络存在高误码率，无线信道由于噪声、链路错误而产生频繁的数据包丢失，称为随机丢包。在无线网络中，TCP错误地将随机丢包当成拥塞丢包，采取不必要的拥塞控制，降低数据发送速率，引起吞吐量下降。如何区分拥塞丢包和随机丢包并采取相应的策略是无线网络中TCP的研究重点。
TCP Veno是基于Reno、Vegas这两个版本提出的。它通过对拥塞避免、快速重传和快速恢复的改进，判断无线网络中的拥塞状况，采取不同的拥塞控制策略，提升无线网络的性能。当TCP Veno认为网络的丢包是由于高误码率造成的时候，就采用改进的拥塞控制机制；相反，当网络的状态处于拥塞时，就采用传统的TCP拥塞控制机制。TCP Veno提升了TCP在单跳无线网络中的性能，大量研究已经表明，TCP Veno在蜂窝通信网络中性能得到较好的提升。
Vegas通过计算期望吞吐量和实际吞吐量的差值来估计网络瓶颈处的可用带宽。Veno采用这种策略来判断网络中连接是否处于拥塞状态。
Veno在发送端测量两个速率，一个是发送速率的期望值（Expected），另一个是发送速率的实际值（Actual），计算公式如下：
Expected = cwnd/BaseRTT
Actual=cwnd/RTT
式中，cwnd是当前的发送窗口大小，BaseRTT是测量到往返时延中的最小值，RTT是最近一次测量到的往返时延值，两者间的差值定义为Diff：
Diff = Expected - Actual
当RTT>BaseRTT时，表明网络的瓶颈带宽处堆积了数据包。如果用N来表示该处堆积的数据包个数，则有如下表达式：
RTT = BaseRTT +N/Actual
上式右侧表示网络瓶颈处的数据包堆积会引起往返时延的增加。重新整理后，可得到如下表达式：
N= Actual×(RTT-BaseRTT) = Diff×BaseRTT
TCP Veno中设置一个阈值b，通过比较N和b判断是否发生了拥塞，即区分随机丢包和拥塞丢包。如果N超过阈值b，认定原因是拥塞丢包；反之，则认定为随机丢包。经过实验证明，阈值b取3比较合理。
（1）TCP Veno的拥塞避免算法采取如下策略：
当cwnd>ssthresh时，即进入拥塞避免阶段时，
如果N<b，发生随机丢包，则每收到1次新的ACK，使cwnd=cwnd+1/cwnd；
否则N≥b，发生拥塞丢包，则每2次收到新的ACK，使cwnd=cwnd+1/cwnd。
在发生随机丢包和拥塞丢包两种不同情况下，TCP Veno对cwnd的线性增加采取不同的控制策略。如果判断发生随机丢包，则cwnd线性增加的程度和TCP Reno一样；如果判断发生拥塞丢包，则cwnd线性增加的程度减缓。因为在预测网络中可能存在拥塞时，减缓cwnd的线性增加，即减缓数据传输速率的增加，可使得连接能够尽可能长时间地处于较大的窗口值，从而提高TCP的效率。
（2）TCP Veno的快速重传和快速恢复算法采取如下策略：
如果N<b，此时发生随机丢包，则使ssthresh=cwnd×(4/5)，cwnd=ssthresh+3；
否则N≥b，表示发生拥塞丢包，则使ssthresh=cwnd/2，cwnd=ssthresh+3。
TCP发送端确认数据包丢失依据两种情况：一是重传定时器超时；二是收到3个及以上重复的ACK。快速重传是指收到3个重复ACK就确认数据包丢失，然后重传丢失的数据包并调整cwnd和ssthresh的大小，快速重传之后执行快速恢复。所以如果判断发生随机丢包，则只是适度降低阈值ssthresh，可以使连接从一个较大的窗口值开始执行拥塞避免，提高TCP吞吐量；若判断发生拥塞丢包，则将阈值ssthresh减半，减小窗口缓解拥塞。
无线环境的高误码率对TCP性能产生很大影响。因为高误码率引起数据包丢失，通常被认为是拥塞，采取拥塞控制机制，但是实际网络中并没有拥塞产生。所以频繁的拥塞控制降低了传输速率，导致吞吐量下降。TCP Veno采取测量网络拥塞状况的方法，判断拥塞丢包还是随机丢包，采取不同的拥塞控制机制。新的拥塞控制机制针对随机丢包尽量保持传输速率，适当减小拥塞窗口，提升吞吐量。
BIC
BIC的提出者们发现了TCP拥塞窗口调整的一个本质问题：那就是找到最适合当前网络的一个发送窗口。为了找到这个窗口值，一般拥塞控制算法采取的策略是缓慢探测，也就是每个RTT加1，缓慢上升，丢包时下降一半，接着再来慢慢上升。BIC算法的提出者们则直指事情的本质，认为这是一个搜索过程，可以认为这个值是在1和一个比较大的数之间，那么显然最好的方式就是二分搜索。
基于这样一个二分思想，BIC算法这样操作的：当出现丢包的时候，说明最佳窗口值应该比这个值小，那么BIC就把此时的cwnd设置为max_win，把乘法减小后的值设置为min_win，然后BIC就开始在这两者之间执行二分思想——也就是跳到max_win和min_win的中点。
BIC算法主要有以下两个不足之处。首先，就是抢占性较强，在小链路带宽时延短的情况下，比起标准的TCP Reno，BIC的增长函数的抢占性强。它在探测阶段相当于重新启动了一个慢启动算法，而TCP在处于稳定后窗口就一直是线性增长的。其次，BIC的的窗口控制阶段较为复杂，增加了算法上的实现难度，同时增加了分析协议性能的模型的复杂度。
CUBIC
在BIC提出后不久，北卡罗来纳州立大学的研究人员根据BIC的一些缺点，再次提出了CUBIC算法，CUBIC不是简单地修正BIC存在的问题，而是对整个算法都做了较大的调整。
CUBIC在设计上简化了BIC的窗口调整算法，CUBIC的模型使用了一个三次函数（即立方函数）。在三次函数曲线中同样存在一个凹和凸的部分，该曲线形状和BIC模型的曲线图十分相似。另外，CUBIC中最关键的点在于它的窗口增长函数仅仅取决于连续的两次拥塞事件的时间间隔值，从而窗口增长完全独立于网络的往返时延RTT。由此CUBIC的RTT独立性质使得CUBIC能够在多条共享瓶颈链路的TCP连接之间保持良好的RTT公平性。鉴于CUBIC更出色的表现，在Linux 2.6.18版本后，CUBIC取代了BIC，成为默认的TCP算法。
当然，CUBIC也有其缺点，例如，在凸增长阶段的快速增长可能导致网络流量的突发性，从而造成一定的丢包。
FAST
TCP Vegas由于使用排队延迟作为网络拥塞的唯一标识信号，因此在应对无线网络的随机丢包问题上有着先天的优势。但是对于高延迟带宽积（Bandwidth Delay Product，BDP）的高速网络，TCP Vegas每个RTT最多增加1的拥塞窗口增长速度过于缓慢。针对这一问题，加州理工学院的Steven Low教授提出了一种改进的Delay Based TCP拥塞控制算法，称为FAST TCP （FAST AQM Scalable TCP）。和TCP Vegas相同，FAST TCP也使用网络的排队延迟作为链路拥塞的唯一标识信号，并使用如下方程对发送端的拥塞控制窗口进行调节。
其中，a和g为预设参数，根据网络带宽的不同a的设置范围为20～200，而1>g>0。
根据上面的公式可知，FAST TCP在网络排队延迟增大时也会自适应地降低连接的数据传输速率。相比TCP Vegas，FAST TCP每次最多可以将拥塞控制窗口增加g·a，因此更加适合高速网络的应用场景。
Fast TCP后来没有对开源社区做贡献了，因为Steven Low自己创办了公司，把Fast TCP变成了商业产品，所以后续的学术研究就比较少了。Fast TCP是从TCP Vegas的思想发展而来，利用网络延时进行拥塞判断。基于延迟的算法是对整个网络的拥塞控制有好处的，但是相对当前基于丢包的算法来说，两者不公平。所以估计Steven Low后面也做了很多的改进。
Compound
Compound TCP是微软亚洲研究院的谭焜博士提出的一种混合型TCP拥塞控制算法。该算法的设计思想是结合基于时延的算法和基于丢包的算法的优点，在充分利用高速网络带宽的同时，仍然保持和传统TCP Reno算法的公平性。
Compound TCP的拥塞控制模块中包含有两个不同的拥塞控制窗口，即基于丢包的w窗口和基于延迟的w窗口，而算法的数据包发送速率则由两个窗口的总和w=w+w控制。w窗口的更新方法和TCP Reno相同，遵循AIMD算法。而w则利用网络的排队延迟作为拥塞控制信号，依靠一种延迟控制的高速TCP算法进行窗口更新，其更新过程为
w=w+a×w– 1, if diff <g
w=w–x×diff, if diff ≥g
w*(1 –b) –w/2, if loss
其中，a，b，g，ξ均为预设的参数，diff采用和TCP Vegas相同的计算方法。从式中可以看出，当diff小于一定值时，Compound TCP会像HighSpeed TCP一样以指数形式增加其拥塞控制窗口，而当diff达到一定阈值时，又会像TCP Vegas一样在拥塞丢包发生前将窗口降低。采用这种方法，Compound TCP除了可以在高速网络中保持较高的传输速率之外，还可以在低速网络中兼顾同TCP Reno的公平性。
