tcp拥塞控制算法

⑴ TCP拥塞控制及BBR原理分析

导语：TCP拥塞控制不仅仅是网络层的概念，可以将其归属于控制论的范畴。在TCP的演进过程中，出现了很多优秀的思想和算法，以实现网络传输过程中，在公平竞争性的前提下，尽可能地利用带宽资源。本文介绍TCP发展过程中出现的几种拥塞控制算法，并着重介绍BBR的原理。

TCP拥塞控制不仅仅是网络层的概念，可以将其归属于控制论的范畴。在TCP的演进过程中，出现了很多优秀的思想和算法，以实现网络传输过程中，在公平竞争性的前提下，尽可能地利用带宽资源。

公平性是在发生拥塞时各源端（或同一源端建立的不同TCP连接或UDP数据报）能公平地共享同一网络资源（如带宽、缓存等）。处于相同级别的源端应该得到相同数量的网络资源。产生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数据流之间为争抢有限的网络资源发生竞争，争抢能力弱的数据流将受到更多损害。因此，没有拥塞，也就没有公平性问题。

TCP层上的公平性问题表现在两方面：

（1）面向连接的TCP和无连接的UDP在拥塞发生时对拥塞指示的不同反应和处理，导致对网络资源的不公平使用问题。在拥塞发生时，有拥塞控制机制的TCP会按拥塞控制步骤进入拥塞避免阶段，从而主动减小发送到网络的数据量。但对无连接的数据报UDP，由于没有端到端的拥塞控制机制，即使网络出现了拥塞，也不会减少向网络发送的数据量。结果遵守拥塞控制的TCP数据流得到的网络资源越来越少，没有拥塞控制的UDP则会得到越来越多的网络资源。

（2）TCP连接之间也存在公平性问题。产生问题的原因在于使用了不同的拥塞控制算法，一些TCP在拥塞前使用了大窗口尺寸，或者它们的RTT较小，或者数据包比其他TCP大，这样它们也会多占带宽。

拥塞控制主要包括四个过程：1）慢启动；2）拥塞避免；3）拥塞发生；4）快速恢复。

RTT ：数据包从发出去到收到对它的ack的来回时间，采用平滑方式计算RTT

RTO ：重传超时。简单的如RTO=n*RTT, n=3（或其他RTO计算方法）

SACK ：TCP Option携带多组ACK信息

FR ：Fast Retransmission，收到3个p ack后，即可认为发生了丢包。不需要等待RTO超时即可重传丢失的包。

ER ：Early Retransmission，无法产生足够的pack和没有新的数据包可以发送进入网络的情况下，减少触发FR的p ack数量，以达到触发FR的目的。

TLP ：如果发生了尾丢包，由于尾包后面没有更多的数据包，也就没有办法触发任何的pack。实际上，Google统计超过70%的RTO是尾丢包导致没有任何p

ack 。TLP算法是通过发送一个loss probe包，来产生足够的SACK/FACK的信息以触发RF。

Pacing ：控制发送速率，防止bursting

流控 ：Flow control站在单条TCP连接的维度，目的是让发送方发包的速度，不超过接收方收包的能力。所以流控解决的问题是，如何在接收方可承受的范围内，让单条 TCP 连接的速度最大化。通过滑动窗口机制实现。

拥塞控制 ：Congestion control站在整个互联网的维度，让网络里所有TCP连接最大化共享网络通道的同时，尽可能的少出现网络拥塞现象，让网络世界里的每一个参与者既公平又高效。

cwnd ：发送窗口，拥塞窗口；在拥塞控制过程中窗口大小值变化。

rwnd ：接收窗口，通知发送者能够发送的数据大小。

sliding window ：滑动窗口，只是一种抽象机制概念；在发送请求及收到ack的过程中滑动。

历史上出现的各种TCP拥塞控制算法，其本质是针对拥塞控制的四个过程做策略调整。按照算法依据的因素，可以简单的分为以下类型：

因为Reno等算法是后续算法的基础，这里详细的描述下Reno算法的过程。

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

（2）拥塞避免算法 – Congestion Avoidance
当cwnd >= ssthresh时，就会进入“拥塞避免算法”。算法如下：

（3）拥塞状态算法 – Fast Retransmit
Tahoe是等RTO超时，FR是在收到3个plicate ACK时就开启重传，而不用等到RTO超时。拥塞发生时：

（4）快速恢复 – Fast Recovery

Reno算法以其简单、有效和鲁棒性，应用最广泛。该算法所包含的慢启动、拥塞避免和快速重传、快速恢复机制，是现有的众多算法的基础。从Reno运行机制中很容易看出，为了维持一个动态平衡，必须周期性地产生一定量的丢失，再加上AIMD机制--减少快，增长慢，尤其是在大窗口环境下，由于一个数据报的丢失所带来的窗口缩小要花费很长的时间来恢复，这样，带宽利用率不可能很高且随着网络的链路带宽不断提升，这种弊端将越来越明显。另外，丢包并不一定是网络拥塞，可能是网络常态，但是基于丢包的拥塞控制并不能区分。

vegas通过对RTT的非常重的监控来计算一个基准RTT。然后通过这个基准RTT来估计当前的网络实际带宽，如果实际带宽比我们的期望的带宽要小或是要多的活，那么就开始线性地减少或增加cwnd的大小。

中间路由器缓存数据导致RTT变大，认为发生拥塞；RTT不公平性，当不同的数据流对网络瓶颈带宽进行竞争时，具有较小RTT的TCP数据流的拥塞窗口增加速率将会快于具有大RTT的TCP数据流，从而将会占有更多的网络带宽资源。

在发送端做带宽估计，当探测到丢包时，根据带宽值来设置拥塞窗口、慢启动阈值。 那么，这个算法是怎么测量带宽的？每个RTT时间，会测量一次带宽，测量带宽的公式很简单，就是这段RTT内成功被ACK了多少字节。Westwood会根据RTT变化来判断丢包是否是网络拥塞造成的，还是网络常态的丢包。如果时延变化不明显，就认为是非网络拥塞，此时cwnd减少的比较小。

BIC-TCP是Linux 2.6.18默认拥塞控制算法，依赖丢包条件触发。BIC-TCP认为TCP拥塞窗口调整的本质就是找到最适合当前网络的一个发送窗口，为了找到这个窗口值，TCP采取的方式是(拥塞避免阶段)每RTT加1，缓慢上升，丢包时下降一半，接着再来慢慢上升。BIC-TCP的提出者们看穿了事情的本质，其实这就是一个搜索的过程，而TCP的搜索方式类似于逐个遍历搜索方法，可以认为这个值是在1和一个比较大的数(large_window)之间，既然在这个区间内需要搜索一个最佳值，那么显然最好的方式就是二分搜索思想。

BIC-TCP就是基于这样一个二分思想的：当出现丢包的时候，说明最佳窗口值应该比这个值小，那么BIC就把此时的cwnd设置为max_win，把乘法减小后的值设置为min_win，然后BIC就开始在这两者之间执行二分思想--每次跳到max_win和min_win的中点。

BIC也具备RTT的不公平性。RTT小的连接，窗口调整发生的速度越快，因此可能更快的抢占带宽。

CUBIC在设计上简化了BIC-TCP的窗口调整算法，在BIC-TCP的窗口调整中会出现一个凹和凸(这里的凹和凸指的是数学意义上的凹和凸，凹函数/凸函数)的增长曲线，CUBIC使用了一个三次函数(即一个立方函数)，在三次函数曲线中同样存在一个凹和凸的部分，该曲线形状和BIC-TCP的曲线图十分相似，于是该部分取代BIC-TCP的增长曲线。另外，CUBIC中最关键的点在于它的窗口增长函数仅仅取决于连续的两次拥塞事件的时间间隔值，从而窗口增长完全独立于网络的时延RTT，使得连接之间保持良好的RRTT公平性。

来看下具体细节：当某次拥塞事件发生时，Wmax设置为此时发生拥塞时的窗口值，然后把窗口进行乘法减小，乘法减小因子设为β，当从快速恢复阶段退出然后进入到拥塞避免阶段，此时CUBIC的窗口增长开始按照“凹”式增长曲线进行增长，该过程一直持续直到窗口再次增长到Wmax，紧接着，该函数转入“凸”式增长阶段。该方式的增长可以使得窗口一直维持在Wmax附近，从而可以达到网络带宽的高利用率和协议本身的稳定性。

CUBIC窗口的增长函数：W(t) = C * (t-K)3 + Wmax, 其中C和β为常量。

t为当前时间距上一次窗口减小的时间差，而K就代表该函数从W增长到Wmax的时间周期。

通俗一点讲，假如我们知道了Wmax，那么CUBIC的核心思想就是需要在连续两次拥塞期间执行完上面的三次函数增长曲线

BBR通过实时计算带宽和最小RTT来决定发送速率pacing rate和窗口大小cwnd。完全摒弃丢包作为拥塞控制的直接反馈因素。

传统的拥塞控制算法是计算cwnd值来规定当前可以发送多少数据，但是并不关注以什么样的速度发送数据。如果简单而粗暴地将窗口大小（send.cwnd、recv.cwnd的最小值）数据全部突发出去，这往往会造成路由器的排队，在深队列的情况下，会测量出rtt剧烈地抖动。bbr在计算cwnd的同时，还计算了一个与之适配的pacing rate，该pacing rate规定cwnd指示的一窗数据的数据包之间，以多大的时间间隔发送出去。

我们知道，网络工作的最优点是在物理链路延迟状态下，以最大速率传输数据。传统的拥塞控制算法思想是根据数据传输及ACK来确定RTT，但是这个RTT并不是物理链路延时，可能包含了路由器缓存耗时，也可能是拥塞状态下的耗时。传统的带宽计算也是在不断的试探逼近最优发送窗口，并在RTT或者统计周期内计算带宽。这种情况下，RTT并不是真正的物理链路延迟，带宽也有可能是在有路由缓存或丢包状况下计算得到，那么必然得到的不是精准的值。

BBR摒弃了丢包和实时RTT作为拥塞控制因素。引入BDP管道容量来衡量链路传输水平。BBR追求的是在链路最小RTT（物理链路延迟）的状态下，找到最大带宽。

首先我们认为网络最优点是可以达到的。下面描述RTT及收包速率与数据包投递速率的关系。

图中上半部分的过程可以描述为：随着数据包投递速率增加，如果没有超过最优带宽，则RTT不会变化，此时的RTT是物理链路延迟。随着投递速率继续增加，这时中间路由节点可能出现需要缓存数据包的情况，这会导致RTT变大。如果投递速率继续增加，超过路由缓存能力，则可能出现丢包。

图中下半部分的过程可以描述为：随着数据包投递速率增加，如果没有超过最优带宽，则发送方确认接收端收到的数据速率增加。随着投递速率继续增加，因为数据包缓存在中间路由，这些包并不能及时得到ACK，因此发送方得到的ACK速率，即发送发确认接收方收到数据的速率会维持不变。如果投递速率继续增加，超过路由缓存能力，则可能出现丢包。

1）应答了多少数据，记为delivered；
2）应答1）中的delivered这么多数据所用的时间，记为interval_us。
将上述二者相除，就能得到带宽：bw = delivered/interval_us；该计算方法不关注数据包ack及顺序，是纯粹的标量。

我们可以根据图示很容易算出从Delivered为7时的数据包被确认到X被确认为止，一共有12-7=5个数据包被确认，即这段时间网络上清空了5个数据包。我们便很容易算出带宽值了。

当10s内没有发现最小RTTProp时，就要进入ProbeRTT状态。在ProbeRTT状态，仅发4MSS/RTT(接近停止发送)，从而排空链路上的数据包，测量真实的RTTProp。这里带来的一个问题是，在一个RTT时间内以4MSS速率发送可能会造成抖动，特别是长RTT场景。具体的参考willko文章《GBN手札-BBR实时大数据传输之痛》。

⑵ TCP拥塞控制

  在计算机网络中的链路容量（即带宽）、交换节点（如路由器）中的缓存和处理机等，都是网络的资源。在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，从而导致吞吐量将随着输入负荷增大而降低。这种情况就叫做 拥塞 。通俗来说，就跟交通拥堵性质一样。

  网络拥塞的原因有很多，如交换节点的 缓存容量太小、输出链路的容量和处理机的速度 。

   拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致于过载 。拥塞控制是一个 全局性的过程 。涉及网络中所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

  拥塞控制和流量控制的关系密切，但是 流量控制往往是指点对点的通信量控制 ，是个 端对端 的问题。流量控制所要做的就是抑制发送方发送数据的速率，以便使接收端来得及接收。

  TCP进行拥塞控制的算法有四种，即 慢开始（slow-start）、拥塞避免（congestion-avoidance）、快重传（fast retransmit）、快恢复（fast recovery） 。

  为了讨论问题方便，提出以下假定：

  拥塞控制也叫做 基于窗口 的拥塞控制。为此，发送方维持一个叫作 拥塞窗口cwnd （congestion window）的状态变量。 拥塞窗口的大小取决于网络的用谁程度，并且动态的变化。发送方让自己的发送窗口等于拥塞窗口 。

  接收方窗口值rwnd和拥塞窗口值cwnd的区别：

  发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再扩大一些，以便让更多的分组发送出去，如果网络出现了拥塞，就必须将拥塞窗口减小一些，以减少分组的发送。 判断网络拥塞的依据就是出现了超时 。

  慢开始算法的思路：刚开始发送数据时，不一下向网络中注入大量数据，而是先探测一下，即 由小到大逐渐增大发送窗口 ，也就是说， 由小到大逐渐增大拥塞窗口数值 。

  慢开始算法具体规定：刚开始发送数据时，先把拥塞窗口cwnd根据 发送方的最大报文段SMSS （Sender Maximum Segment Size）数值的大小设置为不超过2-4个SMSS的数值。在 每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS的数值 。用这样的方法逐步增大发送方的拥塞窗口rwnd，可以使分组注入到网络中的速率更加合理。

  下面举例说明一下，虽然实际上TCP是用字节数作为窗口大小的单位，但为了方便描述，下面使用报文段的个数来作为窗口的大小的单位，并且假设所有的报文段大小相等。

  所以， 慢开始算法每经过一个传输轮次（transmission round），拥塞窗口cwnd就加倍 。

  注：在TCP实际运行时，发送方只有收到一个确认就可以将cwnd加1并发送新的分组，并不需要等一个轮次所有的确认都收到后再发送新的分组。

  从上面可以看出，慢开始算法虽然起始的窗口很小，但是每过一个轮次，窗口大小翻倍，呈指数爆炸增长，所以必须要对其进行一个限制，防止其增长过大引起网络拥塞。这个限制就是 慢开始门限ssthresh 状态变量。慢开始门限ssthresh的用法如下：

  拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有 “加法增大”AI （Additive Increase）的特点。这表明在拥塞避免阶段，拥塞窗口cwnd 按线性规律增长 ，比慢开始算法的拥塞窗口增长速率缓慢得多。

  下面用一个具体的例子来说明拥塞控制的过程，下图假设TCP发送窗口等于拥塞窗口，慢开始初始门限设置为16个报文段，即ssthresh = 16。

  在拥塞避免阶段，拥塞窗口是按照线性规律增大的，这常称为 加法增大AI 。无论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前拥塞窗口的一半，这叫做 乘法减小 MD （Multiplication Decrease）。

  当网络频繁出现拥塞时，ssthresh 值就下降的很快，以大大减少注入网络中的分组数。

   快恢复算法 ，如果发送方连续接收到3个冗余ACK，发送方知道现在只是丢失了个别的报文段，此时调整门限值 ssthresh为当前拥塞窗口的一半，同时设置拥塞窗口 cwnd为新的门限值（发生报文段丢失时拥塞窗口的一半），而不是从1开始。

   TCP对这种丢包事件的行为，相比于超时指示的丢包，不那么剧烈 ，所以对于连续收到3个冗余ACK，拥塞窗口不会从1开始开始。

⑶ tcp如何实现拥塞控制

TCP拥塞控制是传输控制协议（英语：Transmission Control Protocol，缩写TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控制措施。它使用一套基于线增积减模式的多样化网络拥塞控制方法（包括慢启动和拥塞窗口等模式）来控制拥塞。在互联网上应用中有相当多的具体实现算法。

在TCP中，拥塞窗口（congestion window）是任何时刻内确定能被发送出去的字节数的控制因素之一，是阻止发送方至接收方之间的链路变得拥塞的手段。他是由发送方维护，通过估计链路的拥塞程度计算出来的，与由接收方维护的接收窗口大小并不冲突。

1、慢开始算法：

简单的说，开始传输时，传输的数据由小到大递增到一个值(即发送窗口由小到大(指数增长)逐渐增大到拥塞窗口的数值)。

2、拥塞避免算法：

数据发送出去，并发到接收方发回来的确认收到，拥塞窗口每次值加1地线性增大。

3、快重传算法：

数据传输时(数据被分成报文，每个报文都有个序号)，中间的一部分丢失接收方没收到，接收方连续接到后面的数据，则发回对丢失前的数据的重复确认，这样发送方就知道有部分数据丢失了，于是从丢失出重传数据。

4、快恢复算法：

快恢复是与快重传配合的算法，在发生数据丢失时，发送方收到接收方发回的三个重复确认信息时，就把每次传输的数据量减为原来的一半，拥塞窗口也修改为这个值,然后又开始拥塞避免的算法。

⑷ 常见的tcp拥塞控制有哪几种算法

慢启动：最初的TCP在连接建立成功后会向网络中发送大量的数据包，这样很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此新建立的连接不能够一开始就大量发送数据包，而只能根据网络情况逐步增加每次发送的数据量，以避免上述现象的发生。具体来说，当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(Round Trip Time,RTT)呈指数级增长，事实上，慢启动的速度一点也不慢，只是它的起点比较低一点而已。我们可以简单计算下：
开始 ---> cwnd = 1
经过1个RTT后 ---> cwnd = 2*1 = 2
经过2个RTT后 ---> cwnd = 2*2= 4
经过3个RTT后 ---> cwnd = 4*2 = 8
如果带宽为W，那么经过RTT*log2W时间就可以占满带宽。
拥塞避免：从慢启动可以看到，cwnd可以很快的增长上来，从而最大程度利用网络带宽资源，但是cwnd不能一直这样无限增长下去，一定需要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。
上面讨论的两个机制都是没有检测到拥塞的情况下的行为，那么当发现拥塞了cwnd又该怎样去调整呢？
首先来看TCP是如何确定网络进入了拥塞状态的，TCP认为网络拥塞的主要依据是它重传了一个报文段。上面提到过，TCP对每一个报文段都有一个定时器，称为重传定时器(RTO)，当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传，当发生超时时，那么出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：
1.把ssthresh降低为cwnd值的一半
2.把cwnd重新设置为1
3.重新进入慢启动过程。
从整体上来讲，TCP拥塞控制窗口变化的原则是AIMD原则，即加法增大、乘法减小。可以看出TCP的该原则可以较好地保证流之间的公平性，因为一旦出现丢包，那么立即减半退避，可以给其他新建的流留有足够的空间，从而保证整个的公平性。
其实TCP还有一种情况会进行重传：那就是收到3个相同的ACK。TCP在收到乱序到达包时就会立即发送ACK，TCP利用3个相同的ACK来判定数据包的丢失，此时进行快速重传，快速重传做的事情有：
1.把ssthresh设置为cwnd的一半
2.把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)
3.重新进入拥塞避免阶段。
后来的“快速恢复”算法是在上述的“快速重传”算法后添加的，当收到3个重复ACK时，TCP最后进入的不是拥塞避免阶段，而是快速恢复阶段。快速重传和快速恢复算法一般同时使用。快速恢复的思想是“数据包守恒”原则，即同一个时刻在网络中的数据包数量是恒定的，只有当“老”数据包离开了网络后，才能向网络中发送一个“新”的数据包，如果发送方收到一个重复的ACK，那么根据TCP的ACK机制就表明有一个数据包离开了网络，于是cwnd加1。如果能够严格按照该原则那么网络中很少会发生拥塞，事实上拥塞控制的目的也就在修正违反该原则的地方。
具体来说快速恢复的主要步骤是：
1.当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络。
2.再收到重复的ACK时，拥塞窗口增加1。
3.当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。
快速重传算法首次出现在4.3BSD的Tahoe版本，快速恢复首次出现在4.3BSD的Reno版本，也称之为Reno版的TCP拥塞控制算法。
可以看出Reno的快速重传算法是针对一个包的重传情况的，然而在实际中，一个重传超时可能导致许多的数据包的重传，因此当多个数据包从一个数据窗口中丢失时并且触发快速重传和快速恢复算法时，问题就产生了。因此NewReno出现了，它在Reno快速恢复的基础上稍加了修改，可以恢复一个窗口内多个包丢失的情况。具体来讲就是：Reno在收到一个新的数据的ACK时就退出了快速恢复状态了，而NewReno需要收到该窗口内所有数据包的确认后才会退出快速恢复状态，从而更一步提高吞吐量。
SACK就是改变TCP的确认机制，最初的TCP只确认当前已连续收到的数据，SACK则把乱序等信息会全部告诉对方，从而减少数据发送方重传的盲目性。比如说序号1，2，3，5，7的数据收到了，那么普通的ACK只会确认序列号4，而SACK会把当前的5，7已经收到的信息在SACK选项里面告知对端，从而提高性能，当使用SACK的时候，NewReno算法可以不使用，因为SACK本身携带的信息就可以使得发送方有足够的信息来知道需要重传哪些包，而不需要重传哪些包。

⑸ 浅谈TCP（2）：流量控制与拥塞控制

上文 浅谈TCP（1）：状态机与重传机制 介绍了TCP的状态机与重传机制。本文介绍 流量控制 （Flow Control，简称流控）与 拥塞控制 （Congestion Control）。TCP依此保障网络的 QOS （Quality of Service）。

根据前文对TCP超时重传机制的介绍，我们知道Timeout的设置对于重传非常重要：

而且，这个超时时间在不同的网络环境下不同，必须动态设置。为此，TCP引入了 RTT （Round Trip Time，环回时间）：一个数据包从发出去到回来的时间。这样，发送端就大约知道正常传输需要多少时间，据此计算 RTO （Retransmission TimeOut，超时重传时间）。 听起来似乎很简单：在发送方发包时记下t0，收到接收方的Ack时记一个t1，于是RTT = t1 – t0。然而，这只是一个采样，不能代表网络环境的普遍情况。

RFC793 中定义了一个 经典算法 ：

经典算法描述了RTO计算的基本思路，但还有一个重要问题：RTT的采样取“ 第一次 发Seq+收Ack的时间”，还是“ 重传 Seq+收Ack的时间”？

如图：

问题的本质是： 发送方无法区分收到的Ack对应第一次发的Seq还是重传的Seq （进入网络就都一样了）。针对该问题， Karn / Partridge 算法选择回避重传的问题： 忽略重传的样本，RTT的采样只取未产生重传的样本 。

简单的忽略重传样本也有问题：假设当前的RTO很小，突然发生网络抖动，延时剧增导致要重传所有的包；由于忽略重传样本，RTO不会被更新，于是继续重传使网络更加拥堵；拥堵导致更多的重传，恶性循环直至网络瘫痪。Karn / Partridge算法用了一个取巧的办法： 只要一发生重传，就将现有的RTO值翻倍（指数回退策略），待网络恢复后再仿照经典算法逐渐平滑以降低RTO 。

该算法已经做到可用，然而网络抖动对性能的影响比较大。

前面两种算法均使用加权移动平均算法做平滑，这种方法的最大问题是：很难发现RTT值上的较大波动，因为被平滑掉了（1 - a比较小，即最新RTT的权重小）。针对该问题， Jacobson / Karels 算法引入了最新采样的RTT值和平滑过的SRTT值的差距做因子，即 DevRTT （Deviation RTT，RTT的偏离度），同时考虑SRTT带来的惯性和DevRTT带来的波动：

Linux 2.6采用该算法计算RTO，默认取α = 0.125, β = 0.25, μ = 1, ∂ = 4（玄学调参，你懂的）。

TCP使用 滑动窗口 （Sliding Window）做流量控制与 乱序重排 。乱序重排在TCP的重传机制中已经介绍，下面介绍流量控制。

TCP头里有一个字段叫Window（或Advertised Window）， 用于接收方通知发送方自己还有多少缓冲区可以接收数据 。 发送方根据接收方的处理能力来发送数据，不会导致接收方处理不过来，是谓流量控制 。暂且把Advertised Window当做滑动窗口，更容易理解滑动窗口如何完成流量控制，后面介绍拥塞控制时再说明二者的区别。

观察TCP协议的发送缓冲区和接收缓冲区：

假设位置序号从左向右增长（常见的读、写缓冲区设计），解释一下：

据此在接收方计算 AdvertisedWindow ，在发送方计算 EffectiveWindow ：

AdvertisedWindow衡量接收方还能接收的数据量，发送方要根据AdvertisedWindow决定接下来发送的数据量上限，即EffectiveWindow（可能为0）。

由于乱序问题的存在，LastByteRcvd可能指向Seq(LastByteSent)，而Seq(LastByteAcked + 1)至Seq(LastByteSent - 1)都还在路上 ，即将到达接收方，最好的情况是不丢包（丢包后会重传）， 则LastByteRcvd之后、接收缓冲区边界之前的空间就是发送方下一次发送数据的长度上限 （重传不属于下一次发送），因此， AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd - LastByteRead) 。

LastByteRcvd还可能指向Seq(LastByteAcked)（一个新包都没有收到） ，显然AdvertisedWindow的公式不变， 而Seq(LastByteAcked + 1)至Seq(LastByteSent)都还在路上 ，未来将到达接收方，进入接收缓冲区，则“还在路上的Seq(LastByteAcked + 1)至Seq(LastByteSent)”不应超过接收缓冲区的剩余空间AdvertisedWindow（目前等于MaxRcvBuffer），这要求的是上一次发送满足LastByteSent - LastByteAcked ≤ AdvertisedWindow， 那么LastByteSent之后、接收缓冲区剩余空间边界之前的空间就是发送方窗口内剩余可发送数据的长度上限 ，因此， EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked) 。

以下是一个发送缓冲区的滑动窗口：

上图分为4个部分：

其中， #2 + #3 组成了滑动窗口，总大小不超过AdvertisedWindow，二者比例受到接收方的处理速度与网络情况的影响（如果丢包严重或处理速度慢于发送速度，则 #2:#3 会越来越大）。

以下是一个AdvertisedWindow的调整过程，EffectiveWindow随之变化：

上图，我们可以看到一个处理缓慢的Server（接收端）是怎么把Client（发送端）的发送窗口size给降成0的。对于接收方来说，此时接收缓冲区确实已经满了，因此令发送方的发送窗口size降为0以暂时禁止发送是合理的。那么，等接收方的接收缓冲区再空出来，怎么通知发送方新的window size呢？

针对这个问题，为TCP设计了ZWP技术（Zero Window Probe，零窗通告）：发送方在窗口变成0后，会发ZWP的包给接收方，让接收方来Ack他的Window尺寸；ZWP的重传也遵循指数回退策略，默认重试3次；如果3次后window size还是0，则认为接收方出现异常，发RST重置连接（<font color="red"> 部分文章写的是重试到window size正常？？？ </font>）。

注意：只要有等待的地方都可能出现DDoS攻击，Zero Window也不例外。一些攻击者会在和服务端建好连接发完GET请求后，就把Window设置为0，于是服务端就只能等待进行ZWP；然后攻击者再大量并发发送ZWP，把服务器端的资源耗尽。（<font color="red"> 客户端等待怎么耗服务端？？？ </font>）

为什么要进行拥塞控制？假设网络已经出现拥塞，如果不处理拥塞，那么延时增加，出现更多丢包，触发发送方重传数据，加剧拥塞情况，继续恶性循环直至网络瘫痪。可知，拥塞控制与流量控制的适应场景和目的均不同。

拥塞发生前，可避免流量过快增长拖垮网络；拥塞发生时，唯一的选择就是降低流量 。主要使用4种算法完成拥塞控制：

算法1、2适用于拥塞发生前，算法3适用于拥塞发生时，算法4适用于拥塞解决后（相当于拥塞发生前）。

在正式介绍上述算法之前，先补充下 rwnd （Receiver Window，接收者窗口）与 cwnd （Congestion Window，拥塞窗口）的概念：

介绍流量控制时，我们没有考虑cwnd，认为发送方的滑动窗口最大即为rwnd。实际上， 需要同时考虑流量控制与拥塞处理，则发送方窗口的大小不超过 min{rwnd, cwnd} 。下述4种拥塞控制算法只涉及对cwnd的调整，同介绍流量控制时一样，暂且不考虑rwnd，假定滑动窗口最大为cwnd；但读者应明确rwnd、cwnd与发送方窗口大小的关系。

慢启动算法 （Slow Start）作用在拥塞产生之前： 对于刚刚加入网络的连接，要一点一点的提速，不要妄图一步到位 。如下：

因此，如果网速很快的话，Ack返回快，RTT短，那么，这个慢启动就一点也不慢。下图说明了这个过程：

前面说过，当cwnd >= ssthresh（通常ssthresh = 65535）时，就会进入 拥塞避免算法 （Congestion Avoidance）： 缓慢增长，小心翼翼的找到最优值 。如下：

慢启动算法主要呈指数增长，粗犷型，速度快（“慢”是相对于一步到位而言的）；而拥塞避免算法主要呈线性增长，精细型，速度慢，但更容易在不导致拥塞的情况下，找到网络环境的cwnd最优值。

慢启动与拥塞避免算法作用在拥塞发生前，采取不同的策略增大cwnd；如果已经发生拥塞，则需要采取策略减小cwnd。那么，TCP如何判断当前网络拥塞了呢？很简单， 如果发送方发现有Seq发送失败（表现为“丢包”），就认为网络拥塞了 。

丢包后，有两种重传方式，对应不同的网络情况，也就对应着两种拥塞发生时的控制算法：

可以看到，不管是哪种重传方式，ssthresh都会变成cwnd的一半，仍然是 指数回退，待拥塞消失后再逐渐增长回到新的最优值 ，总体上在最优值（动态）附近震荡。

回退后，根据不同的网络情况，可以选择不同的恢复算法。慢启动已经介绍过了，下面介绍快速恢复算法。

如果触发了快速重传，即发送方收到至少3次相同的Ack，那么TCP认为网络情况不那么糟，也就没必要提心吊胆的，可以适当大胆的恢复。为此设计 快速恢复算法 （Fast Recovery），下面介绍TCP Reno中的实现。

回顾一下，进入快速恢复之前，cwnd和sshthresh已被更新：

然后，进入快速恢复算法：

下面看一个简单的图示，感受拥塞控制过程中的cwnd变化：

⑹ TCP拥塞控制算法之NewReno和SACK

改进原因分析
TCP Reno 提出的快速恢复算法提高了丢失报文后的吞吐量和顽健性，但是：

仅考虑了每次拥塞发生时只丢失一个报文的情形。
实际网络中，一旦发生拥塞，路由器会丢弃大量的报文，即一次拥塞中丢失多个报文的情形很普遍。

下图是Reno算法中快速恢复状态和拥塞避免状态之间的相互转换：

所以，网络在一次拥塞中丢弃了多个报文，被TCP Reno错误地分析为传输中发生了多次拥塞。过度的窗口减小导致了传输超时的发生。因此为了提高一次拥塞中丢弃多个报文情形下TCP的性能，必须使TCP终端减少盲目削减发送窗口的行为。

New Reno：基于Reno算法的改进
NewReno TCP在Reno TCP的基础上对快速恢复算法进行修改，只有一个数据包丢失的情况下，其机制和Reno是一样的；当同时有多个包丢失时就显示出了它的优势。

Reno快速恢复算法中发送方收到一个新的ACK就退出快速恢复状态，New Reno算法中只有当所有报文都被应答后才退出快速恢复状态。

NewReno TCP添加了恢复应答判断功能，以增强TCP终端通过ACK报文信息分析报文传输状况的能力。
使TCP终端可以把一次拥塞丢失多个报文的情形与多次拥塞的情形区分开来，进而在每一次拥塞发生后拥塞窗口仅减半一次，从而提高了TCP的顽健性和吞吐量。

两个概念：部分应答（PACK）、恢复应答（RACK）

记TCP发送端恢复阶段中接收到的ACK报文（非冗余ACK）为ACKx，记在接收到ACKx时TCP终端已发出的序列号（SN）最大的报文是PKTy，如果ACKx不是PKTy的应答报文，则称报文ACKx为部分应答（Partial ACK，简称PACK）；若ACKx恰好是PKTy的应答报文则称报文ACKx为恢复应答（Recovery ACK，简称RACK）。

举例来理解：
如果4、5、6号包丢了，现在只重传4，只收到了4的ACK，后面的5、6没有确认，这就是部分应答Partial ACK。如果收到了6的ACK，则是恢复应答Recovery ACK。

TCP发送端接收到恢复应答表明：经过重传，TCP终端发送的所有报文都已经被接收端正确接收，网络已经从拥塞中恢复。

NewReno发送端在收到第一个Partial ACK时，并不会立即结束Fast-recovery，而会持续地重送Partial ACK之后的数据包，直到将所有遗失的数据包重送后才结束Fast-recovery。收到一个Partial ACK时，重传定时器就复位。这使得NewReno的发送端在网络有大量数据包遗失时不需等待Timeout就能更正此错误，减少大量数据包遗失对传输效果造成的影响。

NewReno大约每一个RTT时间可重传一个丢失的数据包，如果一个发送窗口有M个数据包丢失，TCP NewReno的快速恢复阶段将持续M个RTT。

改进的快速恢复算法具体步骤：

快速恢复是基于数据包守恒的原则，即同一时刻能在网络中传输的数据包是恒定的，只有当旧数据包离开网络后，才能发送新数据包进入网络。一个重复ACK不仅意味着有一个包丢失了，还表示有发送的数据包离开了网络，已经在接收区的缓冲区中，不再占用网络资源，于是将拥塞窗口加一个数据包大小。

Reno和NewReno算法仍存在的问题？
虽然NewReno可以解决大量数据包遗失的问题，但是NewReno在每个RTT时间只能一个数据包遗失的错误。为了更有效地处理大量数据包遗失的问题，另一个解决方法就是让传送端知道哪些已经被接收端收到，但用此方法必须同时修改传送端和接收端的传送机制。

缺乏SACK算法时发送端只能选择两种恢复策略：

TCP SACK在TCP Reno基础上增加了：

当一个窗口内有多个数据包丢失时：

减少了时延，提高了网络吞吐量，使更快地从拥塞状态恢复。

SACK中加入了一个SACK选项（TCP option field），允许接收端在返回Duplicate ACK时，将已经收到的数据区段（连续收到的数据范围）返回给发送端，数据区段与数据区段之间的间隔就是接收端没有收到的数据。发送端就知道哪些数据包已经收到，哪些该重传，因此SACK的发送端可以在一个RTT时间内重传多个数据包。

整个TCP选项长度不超过40字节，实际最多不超过4组边界值。

通过一个wireshark示例来说明接收端的SACK行为:

上图中ACK确认序列号为12421，SACK的块左边界值为13801，SACK的块右边界值为15181。明确了这三个参数的数值，我们基本上就可以计算出被丢弃的数据报的序列号和长度了。通过上图所示的带有SACK的数据报文，我们可以知道被丢弃的数据报文的TCP序列号为12422，其数据长度为13801-12421=1380B。

改进的快速恢复算法：

【参考文献】：
吴文红，李向丽.TCP拥塞控制机制定量性能分析.计算机工程与应用.2008,44(18)
孙伟，温涛，冯自勤，郭权.基于TCP NewReno的稳态吞吐量分析模型.计算机研究与发展.2010
陈琳，双雪芹.TCP网络拥塞控制算法比较研究.长江大学学报.2010,3
许豫飞，TCP拥塞控制算法集齐性能评估.北京邮电大学.2005,3
刘拥民，年晓红.对SACK拥塞控制算法的研究.信息技术.2003,9
焦程波，窦睿彧，兰巨龙.无线网络中选择性重传机制性能分析与改进.计算机应用研究.2007.3
James F.Kurose,Keith W.Ross，Computer Networking A Top-Down Approach Sixth Edition.机械工业出版社

原文： https://blog.csdn.net/m0_38068229/article/details/80417503

⑺ 在TCP的拥塞控制中,什么是慢开始、拥塞避免、快重传和快恢复算法

慢开始：在主机刚刚开始发送报文段时可先将拥塞窗口cwnd设置为一个最大报文段MSS的数值。在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个MSS的数值。

拥塞避免：当拥塞窗口值大于慢开始门限时，停止使用慢开始算法而改用拥塞避免算法。

快重传算法：发送端只要一连收到三个重复的ACK即可断定有分组丢失了，就应该立即重传丢手的报文段而不必继续等待为该报文段设置的重传计时器的超时。

接下来执行的不是慢启动算法而是拥塞避免算法。这就是快速恢复算法。.

防止拥塞的方法

（1）在传输层可采用：重传策略、乱序缓存策略、确认策略、流控制策略和确定超时策略。

（2）在网络层可采用：子网内部的虚电路与数据报策略、分组排队和服务策略、分组丢弃策略、路由算法和分组生存管理。

（3）在数据链路层可采用：重传策略、乱序缓存策略、确认策略和流控制策略。

⑻ TCP拥塞控制

我们看到TCP连接的双方都包含一个接收缓冲区，一个发送缓冲区和几个变量（LastByteRead，rwnd等）。 TCP拥塞控制机制运行在发送者对拥塞窗口的跟踪上。 拥塞窗口（表示为cwnd）对TCP发送方可以发送到网络的速率施加约束。具体而言，发送者的未确认数据量不得超过cwnd和rwnd之间的较小值：

ssthresh 慢启动阈值（show start threshold）

别被“慢启动”这个名字所迷惑了，实际上这是cwnd增长最快的阶段。

在慢启动状态下，cwnd的值从1 MSS开始，并且当每个被传输的报文段第一次ACK时，cwnd都会+1MSS

在进入拥塞避免状态时，cwnd的值大约是上次遇到拥塞时的值的一半

在慢启动阶段每个RTT都会将cwnd值加倍，而在拥塞避免阶段TCP采用更保守的方法，并且每个RTT只增加cwnd一个MSS的值[RFC 5681]。 这可以通过几种方式实现。 一种常见的方法是TCP发送器在新的确认到达时通过MSS字节（MSS / cwnd）增加cwnd。 例如，如果MSS是1,460字节而cwnd是14,600字节，则在RTT内发送10个段。 每个到达的ACK（假设每个段一个ACK）将拥塞窗口大小增加1/10MSS，因此，当10个段都ACK后，cwnd才累计增加了一个MSS。

在快速恢复中，对于导致TCP进入快速恢复状态的丢失段的每个重复ACK，cwnd的值增加1 MSS。 最终，当丢失的段的ACK到达时，TCP在 放空cwnd 后进入拥塞避免状态。 如果发生超时事件，则执行与慢启动和拥塞避免相同的操作后，快速恢复将转换为慢启动状态：cwnd的值设置为1 MSS，ssthresh的值设置为值的一半。

快速恢复是TCP [RFC 5681]的推荐但不是必需的组件。 有趣的是，早期版本的TCP（称为TCP Tahoe）无条件地将其拥塞窗口切换为1 MSS，并在超时指示或三重复ACK指示丢失事件后进入慢启动阶段。 较新版本的TCP，TCP Reno，整合了快速恢复。

TCP tahoe 无快速恢复
TCP reno 有快速恢复

忽略连接开始时的初始慢启动时段并假设丢失由三次重复ACK而不是超时触发的，TCP的拥塞控制包括每个RTT 1个MSS的cwnd线性（附加）增加然后减半 （三次重复ACK事件）的cwnd的（乘法减少）。 出于这个原因，TCP拥塞控制通常被称为加法增加，乘法减少（AIMD）形式的拥塞控制。AIMD拥塞控制引起了“锯齿”行为，如图3.54所示，这也很好地说明了我们早期对TCP“探测”带宽的直觉 - TCP线性增加了它的拥塞窗口大小（以及它的传输速率），直到 发生三重复ACK事件。 然后它将拥塞窗口大小减少两倍，然后再次开始线性增加，探测是否有额外的可用带宽。

如前所述，许多TCP实现使用Reno算法[Padhye 2001]。已经提出了Reno算法的许多变体[RFC 3782; RFC 2018]。 TCP Vegas算法[Brakmo 1995; Ahn 1995]试图在保持良好吞吐量的同时避免拥挤。 Vegas的基本思想是（1）在发生丢包之前检测源和目的地之间的路由器中的拥塞，以及（2）当检测到即将发生的丢包时，线性地降低速率。通过观察RTT预测即将发生的分组丢失。数据包的RTT越长，路由器的拥塞就越大。 Linux支持许多拥塞控制算法（包括TCP Reno和TCP Vegas），并允许系统管理员配置将使用哪个版本的TCP。 Linux版本2.6.18中的TCP的默认版本设置为CUBIC [Ha 2008]，这是为高带宽应用程序开发的TCP版本。有关TCP的许多风格的最新调查，请参阅[Afanasyev 2010]。 TCP的AIMD算法是基于大量的工程洞察力和运营网络中的拥塞控制实验而开发的。