tcp学习笔记

关于tcp运输连接的有趣问题

• 为什么client最后还要发一次确认呢?

主要是为了防止已失效的连接请求报文段突然又传送到了server,因而产生错误。
原理:所谓”已失效的连接请求报文段”是这样产生的.考虑一种正常情况,client发出连接请求,但因连接请求报文丢失而未收到确认.于是A再重传一次连接请求.后来受到了确认,建立了连接.数据传输完毕后,就释放了连接.client发送了两个连接请求报文段,其中第一个丢失,第二个到达了server,没有”已失效的连接请求报文段”
现在假定出现一种异常情况,即A发出的第一个连接请求报文段并没有丢失,而是在某些网络结点长时间滞留了,以致延误到连接释放以后的某个时间才到达server.本来这是一个早已失效的报文段,但server收到此失效的连接请求报文段后,就误认为是client又发出一次新的连接请求,于是就向client发出确认报文段,同意建立连接.假定不采用报文握手,那么只要server发出确认,新的连接就建立了.
由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会想server发送数据.但server却以为新的运输连接已经建立了,并一直等待client发送数据,server的许多资源就这样浪费了.
采用三报文握手的方法,可以防止上述现象的发生.例如在刚才异常的情况下,client不会向server的确认发出确认.由于server收不到确认,就知道client并没有要求建立连接.

• 为什么client在TIME_WAIT状态必须等待2MSL的时间呢?

MSL最长报文段寿命(Maximun Segment Lifetime)

1.为了保证client发送的最后一个ACK报文段能够到达server.这个ACK报文段有可能丢失,因而使处在LAST_ACK状态的server收不到对已发送FIN+ACK报文段的确认.client会超市重传这个FIN+ACK报文段,而client就能在2MSL时间内收到这个重传的FIN+ACK报文段.接着client重传一次确认,重新启动2MSL计时器.最后,client和server都正常进入到CLOSED状态.如果client在TIME_WAIT状态不等待一段时间,而是在发送万ACK报文段后立即释放连接,那么就无法收到server重传FIN+ACK报文段,因而也不会再发送一次确认报文段.这样,server就无法正常步骤进入CLOSED状态.
2.防止”已失效的连接请求报文段”出现在本连接中.client在发送万最后一个ACK报文段后,再经过2MSL时间,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失.这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段.

注意：在服务器发送了FIN-ACK之后，会立即启动超时重传计时器。客户端在发送最后一个ACK之后会立即启动时间等待计时器。