7.慢启动与拥塞避免
在局域网中，通信双方通过指定窗口大小来控制着数传的速度，但是当通信双方中间存在多个路由器时，这样的机制就会出现一些问题。路由器要根据目的地址进行路由转发，转发之前需要对数据包进行缓存，这就造成了通信过程中的延迟，在通信量较大或网络状况不好时，因为延迟增加导致通信双方并不能及时知道对方的应答，之前我们提到的超时重传机制就会对之前的数据进行重发，这就加重路由器的缓存压力，而且还是一种恶性循环，因为网络状况不好导致更多数据重发，更多的数据重发导致更加恶化的网络状况，这种情况下，路由器很有可能因为内存空间原因导致崩溃，整个链路就会中断。因此为了应对这种由于网复杂性导致的延迟情况，提出了一种“慢启动”机制，由发送报文的一方主动减小发送速率。
（1）慢启动
具体做法是设置一个类似“发送窗口”的“拥塞窗口（CWND，Congestion Window）”，拥塞窗口大小初始值为MSS（最大数据段大小），待收到对方的确认后再逐渐增大。“慢启动”机制的具体步骤是：
①在一个TCP传输连接建立时，发送端将“拥塞窗口”初始化为MSS，即CWND = MSS。然后发送一个大小为MSS的数据段。
②如果在超时重传定时器溢出之前发送端收到了该数据段的确认，则发送端将“拥塞窗口”大小增加一个MSS，即CWND = 2MSS，然后发送2MSS大小的数据。
③同样地，在超时重传定时器溢出之前发送端收到了该数据段的确认，则将“拥塞窗口”大小增加两个MSS，即CWND = 4MSS，然后发送4MSS大小的数据。后面发送过程依此类推，每次都是在原来的基础上翻倍。
此外，“拥塞窗口”的增加也要上限，不能无限制增加，因此引入“慢启动阈值（Slow Start Threshold, SSTHRESH）”，其初始值为64KB。上述考虑的都是成功状态下的做法，当发生一次数据丢失时，SSTHRESH设置为当前的一半，而CWND又重新设置为1MSS，按照“慢启动”机制继续执行，当CWND再次增长到SSTHRESH便采用“拥塞避免”方案。
（2）拥塞避免
“拥塞窗口”不可能无限制增长，当CWND再次大于或等于SSTHRESH时，执行“拥塞避免”机制。其具体的做法是：
当CWND第二次大于SSTHRESH时，让“拥塞窗口”大小每经过一个RTT时间仅加1个MSS，此时CWND以线性增加。当再次发生数据丢失时，又会把SSTHRESH减为当前CWND的一半，同时把CWND置1，重新进入“慢启动”策略中。
8.快速重传与快速恢复
滑动窗口机制使得发送端不必在每次发送一个报文段之后等待确认，而可以发送多个报文段直至等于窗口大小，接收端可以在接收到多个报文段之后只返回最后一个报文段的确认即可。但是存在一个问题，如果在传输过程中，多个报文段中最后一个没有丢失，而中间的某个报文段丢失了，接收端要如何处理？假设现在发送端连续发出了M1、M2、M3、M4、M5五个报文段，发送过程中M2报文段出现了丢失，接收端没有收到M2，却收到了M4和M5，这样的话接收端需要通知发送端对从M2开始往后的M3、M4、M5都要进行重传，这样一来就会造成一些重复的操作，并增加了网络资源的浪费。因此需要提供一种机制——快速重传：当接收端收到M3之后，发现未收到M2，那么迅速通知发送端重新从M2开始发送，这样一来，如果发送端在未发出M4之前收到了接收端的通知，那么就会哦立即停止M4、M5数据的发送，并从M2开始重新进行发送。
快速重传的实现方法是：当接收端收到M3时，返回针对M1的确认，如果下一个报文段时M4，仍旧返回针对M1的确认，如果下一个报文段是M5，仍旧返回针对M1的确认，此时发送端连续收到3个针对M1的确认，就认为M2在传输过程中丢失，然后从M2开始重新进行数据的发送。
快速恢复的思想是：接收端在收到第三个重复确认后，把当前的CWND值设置为当前SSTHRESH值的一半，以减轻网络负担，然后执行“拥塞避免”策略，使CWND的值线性增长，以避免再次出现网络拥塞。
9.TCP 坚持定时器
滑动窗口机制使得通信的双方通过调整窗口的大小来控制传输流量，而在通信报文段的你来我往的过程中，相互都了解了彼此的窗口大小，但是有一种情况：即当接收端窗口大小为0时，发送端就必须止发送，这样的话，发送端就无法知道接收端何时能够接收数据，除非接收端发送一个非0窗口通告，但是这个通告丢失了会怎么样？发送端还是无法知道接收端是否可以接收数据。
因此，在发送端设置了一个坚持定时器，当定时器溢出时，发送端会发送一个“零窗口探查”报文段，当接收端收到此报文段后，如果可以接收数据，就返回一个包含窗口通告值的确认，如果不能接收数据，仍旧返回一个窗口为0的确认。当接收端收到一个非0窗口通告，则立即停止窗口探查。此外，对于每次发送“零窗口探查”报文段的时间间隔（即坚持定时器的溢出值）也是有要求的，每一次的时间间隔都是在前一次时间间隔的两倍。
注意：“零窗口探查”机制不同于“超时重传”机制之处在于，“零窗口探查”会一直坚持下去，而“超时重传”会在一定时间后重置连接。这是因为在“零窗口探查”中通信时正常的，只是对方一直回复窗口为0的确认，而在“超时重传”中多次重传都没有收到回复，表明连接已经出现了问题。
10.TCP 保活机制
之前我们讨论的都是客户端和服务器之间的数据传输，那么当TCP连接建立之后，即双方都处于ESTABLISHED的状态，如果几小时、几天设置是几个月、几年都没有进行数据的传输，那么服务器如何知道客户端是否在线？因此，在很多TCP/IP的实现中，加入了保活机制，即在服务端维护一个保活定时器，一般定时时间设置为2小时，当定时器溢出时，服务端会自动发送一个保活探查报文，此时客户端会有4种情况：
①客户端正常运行，且与服务端之间连接正常。当客户端收到探查报文后，返回一个确认，服务端收到确认后，重置保活定时器，如果在这之前有数据流动，都会将定时器重置。
②客户端已经崩溃，并且关闭或者正在重新启动。此时，客户端无法收到报文，也不能回复确认。而服务端会再发送9个探查报文，每个报文间隔75s，如果还未收到客户端响应，那么就认为可客户端已经关闭和终止此连接。
③客户端崩溃并已经重新启动。此时客户端会收到探查报文，但它会判断此连接无效，并向服务端返回一个复位报文。服务端收到复位报文后，关闭此连接。
④客户机正常运行，但是网络出现故障。处理步骤和②相同。
网友评论