TCP的超时重传，拥塞控制

一：TCP的超时重传

　tcp的超时重传机制是在异常网络状况下，开始出现丢包或者超时的情况下，TCP控制数据传输以保证其承诺的可靠服务。
　为保证能够重传超时时间内未收到确认的TCP报文段，tcp为每一个tcp报文段维护一个重传定时器，该定时器在tcp报文段第一次被发送时启动，如果在规定时间内未收到对方发来的确认应答，tcp模块将重传tcp报文段并且重置定时器，而超时重传策略就是用来确定下次重传的超时时间以及最多执行多少次重传。
　在用tcpdump输出网络传输中的数据包信息时，我们可以保留其时间戳，来观察双方通信过程中超时重传的策略，据观察tcp每次超时重传的时间都增长一倍（如：0.2,0.4,0.8，1.6,3.2s），如果五次之后都失败，那么底层的IP和ARP将开始接管，直到客户端放弃连接为止。这里有两个重要的内核参数：
　/proc/sys/net/ipv4/tcp_retries1:指定在底层IP接管之前tcp最少执行的重传次数，默认值为3；
　/proc/sys/net/ipv4/tcp_retries2:指定连接放弃之前tcp最多可以执行的重传次数，默认值为15（一般对应13~30 min，这个可以通过data命令来查看测量）；
　此外tcp报文段的重传机制也可以发生在超时之前，也就是所谓的快速重传，稍后将对该机制详细讲解。

二：拥塞控制

　　拥塞控制是对网络中的数据包进行流量控制的服务，在对拥塞控制进行学习之前，我们需要先了解几个概念：
　　1.SWND:发送窗口，发送端向网络一次连续写入（收到第一个数据的确认之前）的数据量。因为发送端最终以tcp报文段来发送数据，所以SWND限定了发送端能连续发送的tcp报文段的数量。
　　2.SMSS:发送端连续发送的多个tcp报文段中的数据部分最长的tcp报文段的数据部分的长度。
　　3.RWND:接收通告窗口，接收方可以通过接收通告窗口来控制发送端的SWND,因为SWND太小，会造成明显的网络延迟，太大会造成网络拥塞。
　　4.CWND:拥塞窗口，仅仅有SWND和RWND是显然不够的，所以发送端引入一个拥塞窗口的状态变量，实际的SWND的值是RWND与CWND中的较小值。它是指某一源端在一个RTT时间内最多可以发送的数据包数。
　接下来，我们来讨论慢启动和拥塞避免机制：

　慢启动：

　　在慢启动中，CWND的初始值IW大概为2~4个SMSS，但新的linux内核提高了该初始值，以减少传输滞后，此时发送端最多能发送IW字节的数据，此后发送端每收到一个来自接收方的ack确认，便按照一定的规则或公式增加数值。当每次按照在原来基础上增加此次确认中包含的之前未被确认的字节数（N）与SMSS的最小值时，CWND将按照指数级增长（慢启动算法），这就是所谓的慢启动。当tcp模块刚开始发送数据时并不知道网络状况，需要用一种试探的方式来平缓的增加CWND的值。

　拥塞避免：

　　在慢启动中，我们看到CWND的增长速度实际上是相当快的，因此容易导致网络拥塞，所以tcp拥塞控制定义了一个重要的状态变量：慢启动门限，当CWND的大小超过该值时，tcp拥塞控制将进入拥塞避免阶段。
　　存在两种情况，网络可能采取拥塞控制：
　　　1.当发送端未检测到网络发生拥塞时所采取的积极避拥塞的方法或行为；
　　　2.当可能在慢启动阶段或者拥塞避免阶段发生拥塞时拥塞控制的行为。
　　我们先来讨论第一种情况：
　　针对第一种情况时，只需要改变CWND的增长方式，让其线性增长就可以了，比如我们可以采用如下两种拥塞避免算法：
　　　(1).每个RTT时间里按照慢启动中的算法计算新的CWND的值，而无论该RTT时间内发送端收到多少个确认；
　　　(2).每收到一个对新数据的确认报文段，就按照另一种算法公式来更新CWND的值。
　　现在我们来讨论一下第二种情况：
　　在讨论第二种情况的处理机制之前，我们必须知道发送端是怎么判断拥塞是否发生，其依据有以下两点：
　　　(1).传输超时，也就是说tcp的重传定时器溢出。据个人理解，应该是发送端未收到来自接收方的数据确认报文而一直等待造成重传定时器启动超时重传机制，当启动超时重传机制时重传定时器就处于溢出状态。
　　　(2).接受到重复的确认报文段。比如TCP报文段丢失，或者接收端接收到乱序的TCP报文段并进行重排。
　　那么接下来我们讨论对于第一种情况，如何进入慢启动阶段：
　　　如果发送端检测到拥塞发生是因为传输超时，那么它会执行超时重传并作出如下调整：
　　　
　　其中FlightSize是已经发送但未收到确认的字节数，这样调整之后，CWND将小于SMSS，那么也必然小于新的慢启动门限值ssthresh，故而拥塞控制再次进入慢启动阶段。
　　总结如下：
　　　当 cwnd < ssthresh 时，使用上述的慢开始算法。
　　　当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
　　　当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。
　　接下来我们来讨论快速重传和快速恢复机制：

　快速重传与快速恢复：

　　拥塞控制算法需要判断并确定是否当接收到重复的确认报文段时真的是发生了拥塞或者tcp报文段是否真的丢失了，具体的判断方法是：发送端如果连续收到3个重复的确认报文段，就认为是拥塞发生了。
　　快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。
　　接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认。随后启动快速重传和快速恢复算法来处理拥塞。过程如下：
　　(1).当收到第三个重复的确认报文时，按照上面调整的公式来计算出新的慢启动门限值，然后立即重传丢失的报文段，并按照以下公式来设置CWND的值:
　　
　　至于为什么需要重传，也就是说tcp报文段丢失为什么会造成发送方重复接受到确认报文段，这是由于当各tcp报文段乱序到达接收方时，tcp模块默认采用累积确认机制，也就是说接收方只会重复确认最后一个按序到达的报文段。tcp的选项SACK会告诉发送方哪些报文丢失了，哪些报文重传了，哪些报文已经提前收到等信息。
　　(2).每次收到1个重复的确认时，设置CWND+=SMSS，此时，如果新的拥塞窗口允许发送新的数据包时，就可以继续发送新的tcp报文段了。
　　(3).当接收到新的数据的确认时，设置CWND=ssthresh，即新的慢启动门限值（使其回到拥塞避免阶段而非慢启动阶段）。
　　快速重传和快速恢复完成之后，拥塞控制将恢复到拥塞避免阶段。