TCP释放连接四次握手

（1）四次握手过程

　　假设主机A为客户端，主机B为服务器，释放连接的过程如下：

　　1）关闭客户端到服务器的连接：首先客户端发送一个FIN，用来关闭客户端到服务端的数据传输，然后等待服务端的确认，其终止标识符为FIN=1，序号seq=u

　　2）服务器收到这个FIN，它发送一个ACK，确认号ack收到的序号加1.

　　3）关闭服务器到客户端的连接：发送一个FIN给客户端

　　4）客户端收到FIN后，并发回一个ACK报文确认，并将确认号seq设置为收到序号加1.

    首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭

  

                       

　　主机A发送FIN后，进入终止等待状态， 服务器B收到主机A连接释放报文段后，就立即给主机A发送确认，然后服务器B就进入close-wait状态，此时TCP服务器进程就通知高层应用进程，因而从A到B的连接就释放了。此时是“半关闭”状态。即A不可以发送给B，但是B可　以发送给A。
　　此时，若B没有数据报要发送给A了，其应用进程就通知TCP释放连接，然后发送给A连接释放报文段，并等待确认。A发送确认后，进入time-wait，注意，此时TCP连接还没有释放掉，然后经过时间等待计时器设置的2MSL后，A才进入到close状态。

 

（2）为什么要等待2MSL呢?
    MSL即Maximum Segment Lifetime，也就是最大报文生存时间，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。引用《TCP/IP详解》中的话：“它(MSL)是任何报文段被丢弃前在网络内的最长时间”。RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。

    TCP的TIME_WAIT状态需要等待2MSL，当TCP的一端发起主动关闭，在发出最后一个ACK包后，即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态，必须在此状态上停留两倍的MSL时间，等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。

    概括原因如下：

    ①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失，那么B会超时重传，然后A再一次确认，同时启动2MSL计时器，如此下去。如果没有等待时间，发送完确认报文段就立即释放连接的话，B就无法重传了（连接已被释放，任何数据都不能出传了），因而也就收不到确认，就无法按照步骤进入CLOSE状态，即必须收到确认才能close。
    ②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL，那些在这个连接持续的时间内，产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点，但是呢，经过2MSL这些无效报文段就肯定可以发送到目的地，不会滞留在网络中。这样的话，在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。
可以看出：B结束TCP连接的时间比A早一点，因为B收到确认就断开连接了，而A还得等待2MSL.

 

（3）为什么TCP释放连接需要四次？

      TCP建立连接要进行三次握手，而断开连接要进行四次。这是由于TCP的半关闭造成的。因为TCP连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个FIN来向另一方通告将要终止这个方向的连接。

     注意：

     1）发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送)，但是还可以接收数据。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据，比如：如主机A收到主机B的FIN断开TCP连接请求，只是表示主机B已经发送完数据，主机A收到FIN后作出应答，并终止这个方向的数据传输，此时处于半关闭状态。但是主机A仍然可以发送数据的，只有当主机A发送完数据并发送FIN给主机B时，主机B才停止这个方向的数据传输，并关闭TCP连接。

     2）在很多时候，TCP连接的断开都会由TCP层自动进行，例如你CTRL+C终止你的程序，TCP连接依然会正常关闭，你可以写代码试试。

转载于:https://www.cnblogs.com/echon/p/8547734.html