tcp如何实现拥塞控制(tcp拥塞控制算法)

最初的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制，流控制是一种局部控制机制，其参与者仅仅是发送方和接收方，它只考虑了接收端的接收能力，而没有考虑到网络的传输能力；而拥塞控制则注重于整体，其考虑的是整个网络的传输能力，是一种全局控制机制。拥塞控制机制使得TCP连接在网络发生拥塞时回退（back off），也就是说TCP源端会对网络发出的拥塞指示（congestion notification）（例如丢包、重复的ACK等）作出响应。针对TCP在控制网络拥塞方面的不足，后来又提出了“慢启动”（Slow Start）和“拥塞避免”（Congestion Avoidance）算法。TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过大地减小发送窗口尺寸的现象，这样TCP的拥塞控制就由这4个核心部分组成。 近几年又出现TCP的改进版本如NewReno和选择性应答（selective acknowledgement，SACK）等。

TCP window机制
TCP的拥塞控制 1.拥塞：即对资源的需求超过了可用的资源。若网络中许多资源同时供应不足，网络的性能就要明显变坏，整个网络的吞吐量随之负荷的增大而下降。拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。流量控制：指点对点通信量的控制，是端到端正的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。拥塞控制代价：需要获得网络内部流量分布的信息。在实施拥塞控制之前，还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制。这样就产生了额外的开销。拥塞控制还需要将一些资源分配给各个用户单独使用，使得网络资源不能更好地实现共享。2. 几种拥塞控制方法慢开始( slow-start )、拥塞避免( congestion avoidance )、快重传( fast retransmit )和快恢复( fast recovery )。2.1 慢开始和拥塞避免发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。慢开始算法：当主机开始发送数据时，如果立即所大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。另，慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量（如何设置ssthresh）。慢开始门限ssthresh的用法如下：当 cwnd < ssthresh 时，使用上述的慢开始算法。当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。如下图，用具体数值说明了上述拥塞控制的过程。现在发送窗口的大小和拥塞窗口一样大。<1>. 当TCP连接进行初始化时，把拥塞窗口cwnd置为1。前面已说过，为了便于理解，图中的窗口单位不使用字节而使用报文段的个数。慢开始门限的初始值设置为16个报文段，即 cwnd = 16 。<2>. 在执行慢开始算法时，拥塞窗口 cwnd 的初始值为1。以后发送方每收到一个对新报文段的确认ACK，就把拥塞窗口值另1，然后开始下一轮的传输（图中横坐标为传输轮次）。因此拥塞窗口cwnd随着传输轮次按指数规律增长。当拥塞窗口cwnd增长到慢开始门限值ssthresh时（即当cwnd=16时），就改为执行拥塞控制算法，拥塞窗口按线性规律增长。<3>. 假定拥塞窗口的数值增长到24时，网络出现超时（这很可能就是网络发生拥塞了）。更新后的ssthresh值变为12（即变为出现超时时的拥塞窗口数值24的一半），拥塞窗口再重新设置为1，并执行慢开始算法。当cwnd=ssthresh=12时改为执行拥塞避免算法，拥塞窗口按线性规律增长，每经过一个往返时间增加一个MSS的大小。强调：“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。2.2 快重传和快恢复如果发送方设置的超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。这时，TCP马上把拥塞窗口 cwnd 减小到1，并执行慢开始算法，同时把慢开始门限值ssthresh减半。这是不使用快重传的情况。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认。快重传算法还规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待M3设置的重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。与快重传配合使用的还有快恢复算法，其过程有以下两个要点：<1>. 当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。请注意：接下去不执行慢开始算法。<2>. 由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。下图给出了快重传和快恢复的示意图，并标明了“TCP Reno版本”。区别：新的 TCP Reno 版本在快重传之后采用快恢复算法而不是采用慢开始算法。也有的快重传实现是把开始时的拥塞窗口cwnd值再增大一点，即等于 ssthresh + 3 X MSS 。这样做的理由是：既然发送方收到三个重复的确认，就表明有三个分组已经离开了网络。这三个分组不再消耗网络 的资源而是停留在接收方的缓存中。可见现在网络中并不是堆积了分组而是减少了三个分组。因此可以适当把拥塞窗口扩大了些。在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。采用这样的拥塞控制方法使得TCP的性能有明显的改进。接收方根据自己的接收能力设定了接收窗口rwnd，并把这个窗口值写入TCP首部中的窗口字段，传送给发送方。因此，接收窗口又称为通知窗口。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口rwnd 。发送方窗口的上限值 = Min [ rwnd, cwnd ]当rwnd < cwnd 时，是接收方的接收能力限制发送方窗口的最大值。 当cwnd < rwnd 时，则是网络的拥塞限制发送方窗口的最大值。

导语：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的来回时间，采用平滑方式计算RTTRTO：重传超时。简单的如RTO=n*RTT, n=3（或其他RTO计算方法）SACK：TCP Option携带多组ACK信息FR：Fast Retransmission，收到3个dup ack后，即可认为发生了丢包。不需要等待RTO超时即可重传丢失的包。ER：Early Retransmission，无法产生足够的dupack和没有新的数据包可以发送进入网络的情况下，减少触发FR的dup ack数量，以达到触发FR的目的。TLP：如果发生了尾丢包，由于尾包后面没有更多的数据包，也就没有办法触发任何的dupack。实际上，Google统计超过70%的RTO是尾丢包导致没有任何dupack。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 RetransmitTahoe是等RTO超时，FR是在收到3个duplicate ACK时就开启重传，而不用等到RTO超时。拥塞发生时：（4）快速恢复 – Fast RecoveryReno算法以其简单、有效和鲁棒性，应用最广泛。该算法所包含的慢启动、拥塞避免和快速重传、快速恢复机制，是现有的众多算法的基础。从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（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的。为了通过IP数据报实现可靠性传输，需要考虑很多事情，侧如数据的破坏、丢包、重复以及分片顺序混乱等问题。如不能解决这些问题，也就无从谈起可靠传输。TCP通过校验和、序列号、确认应答、重发控制、连接管理、以及窗口控制等机制来实现可靠性传输。TCP建立连接的实质是，主机A和主机B告知彼此的第一个发送字节的初始序列号，建立连接后对每一个发送的字节都需要以初始序列号为基点进行编号，需要对方来确认每一个字节编号都已经成功接收，双方初始序列号是由操作系统动态生成的随机的值，一般每个TCP 会话都会有不一样的初始序列号，占四个字节。TCP通过肯定的确认应答(ACK) 实现可靠的数据传输。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端。反之，则数据丢失的可能性很大。在一定时间内没有等到确认应答，发送端就可以认为数据已经丢失，并进行重发由此，即使产生了丢包，仍然能够保证数据能够到达对端，实现可靠传输。如果数据被重发之后若还是收不到确认应答，则进行再次发送。此时确认应答的时间将会以2倍、4信的指数函数延长。达到一定次数后，如果任没有任何确认应答返回，就会判断为网络发生异常，强制关闭连接，并且通知应用通信异常强行终止。发送端根据自己的实际情况发送数据。但是，接收端可能收到的是一个毫无关系的数据包又可能会在处理其他问题上花费一些时间。因此在为这个数据包做其他处理时会耗费一些时间，甚至在高负荷的情况下无法接收任何数据。如此一来，如果接收端将本应该接收的数据丢弃的话，就又会触发重发机制，从而导致网络流量的无端浪费。为了防止这种现象的发生，TCP 提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量。这就是所谓的流控制。它的具体操作是，接收端主机向发送端主机通知自己可以接收数据的大小，于是发送端会发送不超过这个限度的数据。该大小限度就被称作窗口大小。在前面6.4.6 节中所介绍的窗口大小的值就是由接收端主机决定的。TCP 首部中，专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放人这个字段中通知给发送端。这个字段的值越大，说明网络的吞吐量越高。不过，接收端的这个缓冲区一旦面临数据溢出时，窗口大小的值也会随之被设置为一个更小的值通知给发送端，从而控制数据发送量。也就是说，发送端主机会根据接收端主机的指示，对发送数据的量进行控制。这也就形成了一个完整的TCP 流控制(流量控制)。因为 TCP 的窗口控制，收发主机之间即使不再以一个数据段为单位发送确认应答，也能够连续发送大量数据包。然而，如果在通信刚开始时就发送大量数据，也可能会引发其他问题。一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。在网络出现拥堵时，如果突然发送一个较大量的数据，极有可能会导致整个网络的瘫痪。TCP 为了防止该问题的出现，在通信一开始时就会通过一个叫做慢启动的算法得出的数值，对发送数据量进行控制。首先，为了在发送端调节所要发送数据的量，定义了一个叫做“拥塞窗口”的概念。于是在慢启动的时候，将这个拥塞窗口的大小设置为1个数据段发送数据，之后每收到一次确认应答(ACK)，拥塞窗口的值就加1MSS。在发送数据包时，将拥塞窗D的大小与接收端主机通知的窗口大小做比较，然后按照它们当中较小那个值，发送比其还要小的数据量。如果重发采用超时机制，那么拥塞窗口的初始值可以设置为1以后再进行慢启动修正。有了上述这些机制，就可以有效地减少通信开始时连续发包导致的网络拥堵，还可以避免网络拥塞情况的发生。慢启动算法的基本思想是当TCP开始在一个网络中传输数据或发现数据丢失并开始重发时，首先慢慢的对网路实际容量进行试探，避免由于发送了过量的数据而导致阻塞。主机发送了一个报文后就要停下来等待应答，每收到一个应答，拥塞窗口就增加一段长度，直至等于设定的阈值。比如我们可以先让发送方发一个包，等这个包被 ack 之后，我们再发 2 个包，这 2 个被 ack 之后再发 4 个包，以此类推，让一次所发的包数量慢慢增加，这就是慢启动。谈 TCP 离不开 窗口的概念，有 congestion window，receive window，sliding window 等等。window 是以 tcp segment 数量为单位，我们可以说当前 window 值由几个 tcp 包构成，而当我们说 window size 的时候，又是在说一个 window 所包含的字节数。window size 除了和 tcp segment 的数量有关之外，还和单个 tcp segment 的最大 size 有关，即 MSS 值。发送方的 Window 大小称之为 CWND（congestion window），接收方的 Window 大小称之为 RWND（receiver window，或 advertised window）。CWND 表示当前发送方可以发送多少个 TCP 包，而 RWND 表示当前接收方还能接收多少个 TCP 包。值得注意的是，CWND 是一个发送方本地的值，并不会在网络上传输。而 RWND 则是由接收方告知发送方的，是存在于 TCP 包的协议中，会通过网络传输。比如，A主机发送给B window 大小为8192，意思是：B主机最多可以连续发送8192 字节给A主机（一般来说，8192字节就是A主机的接收缓冲区大小），如果B主机不小心发送超过8192字节，如果application 没有及时取走，则超过 8192 自己数据可能会因为A主机的接收缓冲区满而被丢弃，所以B主机会严格遵守A的 RWND 的大小，如果A主机通告它的window大小为 0，则B主机一定不会发送数据。TCP首部中 Window Size 占两个byte，最大值为65535。MTU： Maximum Transmit Unit，最大传输单元，即物理接口（数据链路层）提供给其上层（通常是IP层）最大一次传输数据的大小；以普遍使用的以太网接口为例，缺省MTU=1500 Byte，这是以太网接口对IP层的约束，如果IP层有<=1500 byte 需要发送，只需要一个IP包就可以完成发送任务；如果IP层有> 1500 byte 数据需要发送，需要分片才能完成发送，这些分片有一个共同点，即IP Header ID相同。MSS：Maximum Segment Size ，TCP提交给IP层最大分段大小，不包含TCP Header和 TCP Option，只包含TCP Payload ，MSS是TCP用来限制application层最大的发送字节数。如果底层物理接口MTU= 1500 byte，则 MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte，如果application 有2000 byte发送，需要两个segment才可以完成发送，第一个TCP segment = 1460，第二个TCP segment = 540。Persist Timer: 用于周期探测对方receiver window size 是否依然为0的定时器。比如，A主机通告它的window大小为 0，则B一定不会发送数据。B主机也不会一直等下去，如果一直等下去则会发生死锁。为了防止这种情况的死锁发生，发送者使用了一个持续计时器（persiet timer）来周期性的询问接收者是否已增加了窗口。从发送者发出的这些段称为窗口探测（window probes）。在iOS设备上抓包比较方便，除了常用的，如：Charles、Paw 等软件外，我们还可以使用tcpdump。以下是抓包的步骤：（待续）

我们看到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算法是基于大量的工程洞察力和运营网络中的拥塞控制实验而开发的。