计算机网络4TCP的四次挥手详解

我们主要介绍了TCP三次握手建立连接的过程，这一篇，我们主要介绍TCP的四次挥手。TCP的四次挥手，实际上讲的是TCP的连接释放。同介绍TCP建立连接过程一样，我们这一篇同样结合图片来看。以下是TCP四次挥手的示意图：TCP连接释放的过程如图，在断开连接前，客户机A和服务器B都处于ESTABLISHED（已建立连接）状态。当数据传输完毕后，客户机A会先向TCP发出连接释放报文段，并停止发送数据，主动关闭TCP连接。这个过程大致如下：客户机A把连接释放报文段首部的FIN（终止位）置1，其序号seq=u，序号位等于前面已传送过的数据的最后一个字节的序号+1。这个时候，A进入了FIN-WAIT-1(终止等待1）状态，等待B的确认。（注：TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号）。服务器B收到连接释放报文段后，同样会返回一个确认报文段。确认号是ack=u+1，而这个报文段自己的序号是v，等于B前面已传送过的数据的最后一个字节的序号加1。发送完确认报文段后，服务器B就会进入CLOSE-WAIT（关闭等待）状态。TCP服务器进程这时应通知高层应用进程，因此从A到B这个方向的连接就释放了。但是此时TCP连接尚未完全关闭，仍处于一个半关闭（half-close)状态。简单地说，此时，客户机A已经没有数据要发送给服务器B了，但是B若发送数据，A仍要接收数据。这个状态可能会持续一段时间。客户机A收到来自服务器B的确认报文段后，就会进入FIN-WAIT-2（终止等待2）状态，等待来自服务器B的连接释放报文段。我们回到服务器B这边，若B同样已经不需要向A传送数据了，上层应用程序就会通知TCP释放连接。这时，服务器B发出连接释放报文段是FIN置1。我们先假设B现在的序号为w，确认号则为上次已发送过的确认号ack=u+1。然后B就LAST-ACK（最后确认）状态，等待A的确认。客户机A收到B的连接释放报文段后，需要返回确认报文段。在确认报文段中，把ACK置1，确认号为ack=w+1。而自己的序号为seq=u+1。（根据TCP标准，前面发送过的FIN报文段需要消耗一个序号）。然后进入TIME-WAIT（时间等待）状态。注意，这个时候TCP连接还未结束，还需要时间等待计数器（TIME-WAITtimer）设置的时间2MSL后，A才会重新进入CLOSED状态。时间MSL叫做最长报文段寿命，1MSL大概为2分钟。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。那么问题来了，在客户机A返回确认报文段，进入TIME-WAIT状态后，为什么不能马上结束TCP的连接，而是还需要再等待2MSL的时间才能正式结束TCP连接呢？这里主要有两个原因：是为了保证A发送的最后一个确认报文段能到达B。若这个ACK报文段在传输过程中丢失，处于LAST-ACK状态的服务器B收不到A已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，A在2MSL中收到这个重发的FIN+ACK报文段，会再一次重传一次确认报文段，并重新启动2MSL计时器。直至最后B正常收到确认报文段，两边重新进入CLOSE状态。如果A在TIME-WAIT状态不等待一段时间，而是发送完ACK后立即释放连接，在发生上述情况后，服务器B就无法正常进入CLOSE状态。同样，防止我们介绍TCP三次握手中提到的“已失效的连接请求报文段”的出现。A发送完最后一个确认报文段后，经过2MSL后，可以使本连接持续时间内产生的所有报文段都从网络中消失。这样，就可以保证下一个新的连接中，不会出现这种旧的连接请求报文段。以上，就是我们常说的TCP的四次挥手，也就是TCP的连接释放过程。另外，除了时间等待计时器外，TCP还有一个保活计时器（keepalivetimer)。这个计时器又有什么用呢？我们设想这样一种情况，客户机A已经主动和服务器B建立了TCP连接。但是后来客户机发生了故障，连接中断，但是却没来得及发送出终止连接的报文。若是让服务器端B一直处于等待状态，显然是对服务器端的资源是一种极大的浪费。应此，会使用到保活计时器。服务器每接收到一次客户机的数据，就重新设置保活计时器。计时器一般设置为两个小时，若两个小时没有接收到客户机传输的报文段，服务器端会发送一个探测报文段，并已75分钟的频率连续发送10次。在发送10次探测报文段发出后，仍无客户机的响应，服务器会认为客户机出现故障，接着就关闭这个连接。想要了解更多TCP/IP知识点，

转载请注明：http://www.twoac.com/wyzl/13440.html

上一篇文章： 计算机网络与存储概论SOHO网络的特点与

下一篇文章： 没有了