A. 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实时大数据传输之痛》。
B. 拥塞算法
基于包丢失检测的 Reno、NewReno 或者 cubic 为代表，其主要问题有 Buffer bloat 和长肥管道两种。和这些算法不同，bbr 算法会以时间窗口内的最大带宽 max_bw 和最小 RTT min_rtt，并以此计算发送速率和拥塞窗口
RTProp : round-trip propagation time BtlBW : bottleneck bandwidth，bbr 算法关于拥塞窗口的核心就是计算 BtlBW 和 RTprop，根据这两者值计算 BDP
bbr 算法输出 pacing_rate 和 cwnd 两个数据。pacing_rate 决定发包速率，cwnd 为窗口大小
TCP Tahoe 和 Reno
这两个算法是根据其第一次加入到4.3BSD的时间回溯命名的，两个名字对应自其第一次出现时BSD的代号，而代号分别取自太浩湖（Lake Tahoe）和其附近的城市里诺市
• Tahoe：如果收到三次重复确认——即第四次收到相同确认号的分段确认，并且分段对应包无负载分段和无改变接收窗口——的话，Tahoe算法则进入快速重传，将慢启动阈值改为当前拥塞窗口的一半，将拥塞窗口降为1个MSS，并重新进入慢启动阶段
• Reno：如果收到三次重复确认，Reno算法则进入快速重传，只将拥塞窗口减半来跳过慢启动阶段，将慢启动阈值设为当前新的拥塞窗口值，进入一个称为“快速恢复”的新设计阶段
Fast recovery
是Reno算法新引入的一个阶段，在将丢失的分段重传后，启动一个超时定时器，并等待该丢失分段包的分段确认后，再进入拥塞控制阶段。如果仍然超时，则回到慢启动阶段
TCP Vegas
至1990年代中期，TCP量度延迟和RTT都是以传输缓存中最后一个被传送的分段包为准。vegas通过度量传输缓存中每个传送分段包来代替只量度一个分段包，通过每次度量的平均值来增加拥塞窗口。该算法取名自内华达州最大的城市拉斯维加斯。不过由于一些资源公平性原因，该算法并没有在彼得森的实验室之外广泛部署。一些研究认为该算法和其他拥塞算法混合使用，可能会导致性能竞争不及其他算法。在各种TCP拥塞算法的比较研究中，Vegas被认为是最平滑的控制算法，其次为CUBIC
TCP New Reno
TCP New Reno是对TCP Reno中快速恢复阶段的重传进行改善的一种改进算法，其定义于RFC 6582，覆盖了原有在RFC 3782和RFC 2582的旧定义。
在Reno的快速恢复中，一旦出现3次重复确认，TCP发送方会重发重复确认对应序列号的分段并设置定时器等待该重发分段包的分段确认包，当该分段确认包收到后，就立即退出快速恢复阶段，进入拥塞控制阶段，但如果某个导致重复确认的分段包到遇到重复确认期间所发送的分段包存在多个丢失的话，则这些丢失只能等待超时重发，并且导致拥塞窗口多次进入拥塞控制阶段而多次下降。而New Reno的快速恢复中，一旦出现3次重复确认，TCP发送方先记下3次重复确认时已发送但未确认的分段的最大序列号，然后重发重复确认对应序列号的分段包。如果只有该重复确认的分段丢失，则接收方接收该重发分段包后，会立即返回最大序列号的分段确认包，从而完成重发；但如果重复确认期间的发送包有多个丢失，接收方在接收该重发分段后，会返回非最大序列号的分段确认包，从而发送方继续保持重发这些丢失的分段，直到最大序列号的分段确认包的返回，才退出快速恢复阶段。
New Reno在低错误率时运行效率和“选择确认”（Selective ACKnowledgement，SACK）相当，在高错误率仍优于Reno
TCP Hybla
TCP Hybla旨在消除由于高延迟地面线路或者卫星无线链路下导致的RTT过长而对TCP链接的影响。它通过对拥塞窗口动态分析来修改，来减少对RTT的性能依赖
TCP BIC 和 CUBIC
TCP BIC（Binary Increase Congestion control）旨在优化高速高延迟网络（即根据RFC 1072所定义的“长肥网络”（long fat network，LFN））的拥塞控制，其拥塞窗口算法使用二分搜索算法尝试找到能长时间保持拥塞窗口最大值的值。Linux内核在2.6.8至2.6.18使用该算法作为默认TCP拥塞算法。
CUBIC则是比BIC更温和和系统化的分支版本，其使用三次函数代替二分算法作为其拥塞窗口算法，并且使用函数拐点作为拥塞窗口的设置值。Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法
TCP Westwood和Westwood+
TCP Westwood改良自New Reno，不同于以往其他拥塞控制算法使用丢失来测量，其通过对确认包测量来确定一个“合适的发送速度”，并以此调整拥塞窗口和慢启动阈值。其改良了慢启动阶段算法为“敏捷探测（Agile Probing）”，和设计了一种持续探测拥塞窗口的方法来控制进入“敏捷探测”，使链接尽可能地使用更多的带宽。Westwood+使用更长的带宽估计间隔和优化的滤波器来修正Westwood对ACK压缩场景对带宽估计过高的问题。通过以上改良，TCP Westwood系列算法在有线网络和无线网络的拥塞控制上获取平衡，尤其研究中针对于无线通信网络上
Compound TCP
复合TCP（Compound TCP）是微软自己实现的TCP拥塞控制算法，通过同时维护两个拥塞窗口，来实现在长肥网络有较好的性能而又不损失公平性。该算法在Windows Vista和Windows Server 2008开始广泛部署，并通过补丁的方式回溯支持到Windows XP和Windows Server 2003。在Linux上也有一个旧版本的移植实现
TCP PRR
TCP PRR（TCP Proportional Rate Rection ）是旨在恢复期间提高发送数据的准确性。该算法确保恢复后的拥塞窗口大小尽可能接近慢启动阈值。在Google进行的测试中，能将平均延迟降低3~10%，恢复的超时减少5%。PRR算法之后作为Linux内核3.2版本的默认拥塞算法
TCP BBR
TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是由Google设计，于2016年发布的拥塞算法。以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR则基于模型主动探测。该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。该算法认为随着网络接口控制器逐渐进入千兆速度时，与缓冲膨胀相关的延迟相比丢包更应该被认为是识别拥塞的主要决定因素，所以基于延迟模型的拥塞控制算法（如BBR）会有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法，例如CUBIC
QUIC Quick UDP Internet Connections
QUIC旨在提供几乎等同于TCP连接的可靠性，但延迟大大减少。它主要通过两个理解HTTP流量的行为来实现这一点：
第一个变化是在连接创建期间大大减少开销。由于大多数HTTP连接都需要TLS，因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。 当客户端打开连接时，服务器响应的数据包包括将来的数据包加密所需的数据。
QUIC使用UDP协议作为其基础，不包括丢失恢复。相反，每个QUIC流是单独控制的，并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务
QUIC包括许多其他更普通的更改，这些更改也可以优化整体延迟和吞吐量
每个数据包是单独加密的，因此加密数据时不需要等待部分数据包。 在TCP下通常不可能这样做，其中加密记录在字节流中，并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商，但QUIC旨在通过单个握手过程完成这些
QUIC的另一个目标是提高网络切换期间的性能，例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。 当这发生在TCP上时，一个冗长的过程开始了：每个现有连接一个接一个地超时，然后根据需要重新创建。期间存在较高延迟，因为新连接需要等待旧连接超时后才会创建。 为解决此问题，QUIC包含一个连接标识符，该标识符唯一地标识客户端与服务器之间的连接，而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新创建连接，因为即使用户的IP地址发生变化，原始连接ID仍然有效
QUIC在应用程序空间中实现，而不是在操作系统内核中实现。当数据在应用程序之间移动时，这通常会由于上下文切换而调用额外的开销。 但是在QUIC下协议栈旨在由单个应用程序使用，每个应用程序使用QUIC在UDP上托管自己的连接
Chromium的网络堆栈同时打开QUIC和传统TCP连接，并在QUIC连接失败时以零延迟回退到TCP连接
C. 常见的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本身携带的信息就可以使得发送方有足够的信息来知道需要重传哪些包，而不需要重传哪些包。
D. 浅谈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变化：
E. 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开始开始。
F. tcp如何实现拥塞控制
TCP拥塞控制是传输控制协议（英语：Transmission Control Protocol，缩写TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控制措施。它使用一套基于线增积减模式的多样化网络拥塞控制方法（包括慢启动和拥塞窗口等模式）来控制拥塞。在互联网上应用中有相当多的具体实现算法。
在TCP中，拥塞窗口（congestion window）是任何时刻内确定能被发送出去的字节数的控制因素之一，是阻止发送方至接收方之间的链路变得拥塞的手段。他是由发送方维护，通过估计链路的拥塞程度计算出来的，与由接收方维护的接收窗口大小并不冲突。
1、慢开始算法：
简单的说，开始传输时，传输的数据由小到大递增到一个值(即发送窗口由小到大(指数增长)逐渐增大到拥塞窗口的数值)。
2、拥塞避免算法：
数据发送出去，并发到接收方发回来的确认收到，拥塞窗口每次值加1地线性增大。
3、快重传算法：
数据传输时(数据被分成报文，每个报文都有个序号)，中间的一部分丢失接收方没收到，接收方连续接到后面的数据，则发回对丢失前的数据的重复确认，这样发送方就知道有部分数据丢失了，于是从丢失出重传数据。
4、快恢复算法：
快恢复是与快重传配合的算法，在发生数据丢失时，发送方收到接收方发回的三个重复确认信息时，就把每次传输的数据量减为原来的一半，拥塞窗口也修改为这个值,然后又开始拥塞避免的算法。