TCP流量控制与拥塞控制



一、TCP建立连接后，通信双方都同时可以进行数据的传输；在保证 可靠性上，采用 超时重传和捎带确认机制；在 流量控制上，采用 滑动窗口协议，协议中规定，窗口内未经确认的分组需要进行重传；在 拥塞控制上，采用 慢启动算法。

（一）拥塞控制：

1、 TCP慢启动、拥塞避免、快速重传、快速回复

    为了防止网络的拥塞现象，TCP提出了一系列的拥塞控制机制。最初由V. Jacobson在1988年的论文中提出的TCP的拥塞控制由“慢启动(Slow start)”和“拥塞避免(Congestion avoidance)”组成，后来TCP Reno版本中又针对性的加入了“快速重传(Fast retransmit)”、“快速恢复(Fast Recovery)”算法，再后来在TCP NewReno中又对“快速恢复”算法进行了改进，近些年又出现了选择性应答( selective acknowledgement,SACK)算法，还有其他方面的大大小小的改进，成为网络研究的一个热点。

    TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制，在之前我们还讨论过TCP还有一个对端通告的接收窗口(rwnd)用于流量控制。窗口值的大小就代表能够发送出去的但还没有收到ACK的最大数据报文段，显然窗口越大那么数据发送的速度也就越快，但是也有越可能使得网络出现拥塞，如果窗口值为1，那么就简化为一个停等协议，每发送一个数据，都要等到对方的确认才能发送第二个数据包，显然数据传输效率低下。TCP的拥塞控制算法就是要在这两者之间权衡，选取最好的cwnd值，从而使得网络吞吐量最大化且不产生拥塞。

    由于需要考虑拥塞控制和流量控制两个方面的内容，因此TCP的真正的发送窗口=min(rwnd, cwnd)。但是rwnd是由对端确定的，网络环境对其没有影响，所以在考虑拥塞的时候我们一般不考虑rwnd的值，我们暂时只讨论如何确定cwnd值的大小。关于cwnd的单位，在TCP中是以字节来做单位的，我们假设TCP每次传输都是按照MSS （ 最大报文段长度MSS选项是TCP协议定义的一个选项，MSS选项用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度。 ）大小来 发送数据的，因此你可以认为cwnd按照数据包个数来做单位也可以理解，所以有时我们说cwnd增加1也就是相当于字节数增加1个MSS大小。

     慢启动：最初的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流量控制的目的是限制发送端的发送速率，使得接收方能够及时接收。TCP主要是通过滑动窗口来实现流量控制的。实际上，发送窗口swnd的大小不仅受接收窗口rwnd的大小的限制，还受拥塞窗口cwnd窗口的限制，为了实现点到点的流量控制，本文假设拥塞窗口足够大（即网络链路比较流畅），仅考虑发送窗口swnd受接收窗口rwnd的限制。

    窗口由左臂和右臂组成。左臂右移称为关闭，右臂左移称为收缩，右臂右移称为打开。

    1、发送窗口和接收窗口的移动操作

    1）接收窗口：当接收方收到发送方的更多的字节时（不包括重复的报文段），接收窗口关闭，当接收缓存中的字节被接收进程pull时，接收窗口打开，通常接收窗口不会发送收缩操作。

    2）发送窗口：发送窗口的关闭、收缩和打开受接收方的控制。当一个有效的确认时，发送窗口关闭；当接收方通告发送方允许的窗口大小可以更大时，发送窗口会打开；当接收方通告发送方允许的窗口大小更小时，发送窗口就收缩，但是TCP强烈不建议发送窗口收缩。

    注意：TCP窗口的单位是字节，不是报文段。所以TCP窗口中，每一格对应1B。

    利用滑动窗口进行流量控制过程

       

    上图中，在发送端与接收端建立连接时，接收端告诉发送端当前接收窗口rwnd=400，所以发送端最多能够发送400B，假设每一个报文段为100B。发送端连续发送4个报文段，分别是1-100,101-200,201-300,301-400,401-500，发送后数据段101-200在路上丢失了，其他几个报文都被接收了，并放入到接收缓存中，接收方便向发送方发送1-200报文段的ACK，并期望收到序号为201对应的报文段，同时设置接收窗口大小rwnd=300,发送端便重传序号201对应的报文段。当接收端收到该报文段后，并向发送端发送前500个报文的ACK，并期望收到序号为501的报文段，并设置接收窗口rwnd=100，发送端收到该ACK报文段后，便向接收端发送序号为501-600的报文段，接收端收到该报文段后，发送ACK报文段，并设置rwnd=0，意在通知发送端不要暂时再发送数据段。

    

    2、糊涂窗口综合症

    当发送应用程序产生数据的速度很慢，或接收应用程序消耗数据的速度很慢，或者两者都有，都会使得发送数据的报文段很小，使得网络效率非常低，这个问题称为糊涂窗口综合症SWS(silly window syndrome)。

    1）发送方产生的症状

    如果发送方应用程序产生数据的速度很慢，例如一次只产生1B，那么就有可能产生糊涂窗口综合症。解决的方法是防止发送TCP一次只发送1B。必须让发送TCP等待，并把数据收集成较大的数据块后再发送。

    发送TCP需要等待多长时间再发送呢？

    如果等待时间过长，则会延迟整个过程。如果等待时间过短，最后很可能还是发送一个个小报文段。Nagle提出了一种解决的方法，我们称之为Nagle算法，步骤如下：

    1.发送TCP把它从应用程序收到的第一块数据发送出去，哪怕只有一个字节；

    2.在发送了第一个报文段后，发送TCP先把发送应用程序后续到达的数据字节缓存起来，直到收到接收端发来的ACK，或者已积累了足够的数据，发送TCP就可以发送这个报文段了。

    注意：足够的数据指的是数据达到0.5*MSS（最大报文段长度的一半）或者发送窗口大小的一半时。

    2）接收方产生的症状

    如果接收端应用程序pull速度很慢，例如一次只消耗1B的数据，若TCP接收方的缓存已满，而应用程序一次只能从接收缓存中读取1B，然后向发送方发送ACK，并把窗口设置为1B（因为从接收缓存中取出了1B），但发送方的缓存中有很多数据，这样发送方有只能一次发送1B，接收方发回确认，仍然将窗口设置为1B，这样进行下去，网络的效率非常低，此时可以采取两种解决方法：

    方法1：采用Clark解决方法，该方法是：接收端只要有数据到达就向发送端发送零值窗口ACK报文段，直到缓存中有足够大的空间可以放入1MSS报文段，或者至少有一半的缓存空间空闲。只要出现这两种情况之一，接收端就向发送端发送非零值窗口ACK报文。

    方法2：推迟确认。当报文段到达时并不立即发送确认，接收方在对收到的报文段进行确认之前一直等待，直至接收缓存有足够的空间为止。推迟发送确认防止了发送TCP滑动它的窗口。推迟确认的另外一个优点：减少了网络的通信量；对应的缺点是：如果推迟的时间比较长，会使得发送方以为发送的报文丢失，而产生不必要的重传。

    总之，发送方和接收方可以配合解决该问题。总体的思想是：发送方不发送很小的报文段的同时，接收方也不要在缓存刚刚有了一点小空间就急忙把这个很小的窗口大小信息通知发送方。