谈谈TCP控制那些事( 五 )


这样,在发送端就可以根据回传的SACK来知道哪些数据到了,哪些没有到 。于是就优化了Fast Retransmit的算法 。当然,这个协议需要两边都支持 。在 linux下,可以通过tcp_sack参数打开这个功能(Linux 2.4后默认打开) 。
这里还需要注意一个问题——接收方Reneging,所谓Reneging的意思就是接收方有权把已经报给发送端SACK里的数据给丢了 。这样干是不被鼓励的,因为这个事会把问题复杂化了,但是,接收方这么做可能会有些极端情况,比如要把内存给别的更重要的东西 。所以,发送方也不能完全依赖SACK,还是要依赖ACK,并维护Time-Out,如果后续的ACK没有增长,那么还是要把SACK的东西重传,另外,接收端这边永远不能把SACK的包标记为Ack 。
注意:SACK会消费发送方的资源,试想,如果一个攻击者给数据发送方发一堆SACK的选项,这会导致发送方开始要重传甚至遍历已经发出的数据,这会消耗很多发送端的资源 。详细的东西请参看《TCP SACK的性能权衡》 。
TCP四大定时器重传定时器重传定时器是用来计算TCP报文段的超时重传时间的(至于超时重传时间的确定,这里涉及到一大堆的算法,我这里不细谈了) 。每发送一个报文段就会启动重传定时器,如果在定时器时间到后还没收到对该报文段的确认,就重传该报文段,并将重传定时器复位,重新计算;如果在规定时间内收到了对该报文段的确认,则撤销该报文段的重传定时器 。
坚持定时器专门为对付零窗口通知而设立的 。
主要是为了应付零窗口大小通知可能导致的死锁问题 。如果接收端在向发送端发送了零窗口报文段后不久,接收端的接收缓存又有了一些存储空间,于是接收端向发送端发送了一个非零窗口大小的报文段,然而这个报文段在传送过程中丢失了,发送端没有收到该报文段,就一直等待接收端发送非零窗口的报文通知,而接收端并不知道报文段丢失了,而是觉得已经告诉发送端了,就会一直等待发送端发送数据,如果没有任何措施的话,这话死锁的局面会一直延续下去 。
为了解决这个问题,TCP为每一个连接设有一个坚持定时器(也叫持续计数器) 。只要TCP连接的一方收到对方的零窗口通知,就启动坚持定时器 。若坚持定时器设置的时间到期,就发送一个零窗口控测报文段(该报文段只有一个字节的数据,它有一个序号,但该序号永远不需要确认,因此该序号可以持续重传),之后会出现以下三种情况:

  1. 对方在收到探测报文段后,在对该报文段的确认中给出现在的窗口值,如果窗口值仍未零,则收到这个报文段的一方将坚持定时器的值加倍并重启 。坚持计数器最大只能增加到约60秒,在此之后,每次收到零窗口通知,坚持计数器的值就定位60秒 。
  2. 对方在收到探测报文段后,在对该报文段的确认中给出现在的窗口值,如果窗口不为零,那么死锁的僵局就被打破了 。
  3. 该探测报文发出后,会同时启动重传定时器,如果重传定时器的时间到期,还没有收到接收到发来的响应,则超时重传探测报文 。
保活定时器保活定时器是为了应对两个TCP连接间出现长时间的没有数据传输的情况 。如果客户已与服务器建立了TCP连接,但后来客户端主机突然故障,则服务器就不能再收到客户端发来的数据了,而服务器肯定不能这样永久地等下去,保活定时器就是用来解决这个问题的 。服务器每收到一次客户端的数据,就重新设置保活定时器,通常为2小时,如果2小时没有收到客户端的数据,服务端就发送一个探测报文,以后每隔75秒发送一次,如果连续发送10次探测报文段后仍没有收到客户端的响应,服务器就认为客户端出现了故障,就可以终止这个连接 。
时间等待计时器(2MSL定时器 )2MSL定时器测量一个连接处于TIME—WAIT状态的时间,通常为2MSL(报文段寿命的两倍) 。2MSL定时器的设置主要是为了确保发送的最后一个ACK报文段能够到达对方,并防止之前与本连接有关的由于延迟等原因而导致已失效的报文被误判为有效 。在连接终止期使用,当TCP关闭连接时,并不认为这个连接就真正关闭了,在时间等待期间,连接还处于一种中间过度状态 。这样就可以使重复的fin报文段在到达终点后被丢弃 。
TIME_WAIT 确保有足够的时间让对端收到了ACK,如果被动关闭的那方没有收到 ACK,就会触发被动端重发 FIN 。因为最后一次确认应答 ACK 报文段很有可能丢失,因而使被动关闭方处于在LIST_ACK 状态的,此时被动关闭方会重发这个 FIN+ACK 报文段,在这等待的 2MSL 时间内主动关闭方重新收到这个被动关闭方重发的 FIN+ACK 报文段,因此,主动关闭方会重新发送确认应答信息,从而重新启动 2MSL 计时器,直到通信双方都进入 CLOSED 状态 。如果主动关闭方在 TIME_WAIT 状态不等待一段时间就直接释放连接并进入 CLOSED 状态,那么主动关闭方无法收到来自被动关闭方重发的 FIN+ACK 报文段,也就不会再发送一次确认 ACK 报文段,因此被动关闭方就无法正常进入CLOSED 状态 。


推荐阅读