详解TCP连接的释放

数据传输结束后，通信的双方都可以释放连接，并停止发送数据。假设现在双端都处于ESTABLISHED状态

1.客户端A的TCP进程先向服务端发出连接释放报文段，并停止发送数据，主动关闭TCP连接。释放连接报文段中FIN=1，序号为seq=u，该序号等于前面已经传送过去的数据的最后一个字节的序号+1。这时，A进入FIN-WAIT-1(终止等待1)状态，等待B的确认。TCP规定：FIN报文段即使不携带数据，也要消耗掉一个序号，这是TCP连接释放的第一次挥手。

2.B收到连接释放报文段后即发出确认释放连接的报文段，该报文段中，ACK=1，确认号为ack=u+1，其自己的序号为v，该序号等于B前面已经传送过的数据的最后一个字节的序号+1。然后B进入CLOSE-WAIT(关闭等待)状态，此时TCP服务器进程应该通知上层的应用进程，因而A到B这个方向的连接就释放了，这时TCP处于半关闭状态，即A已经没有数据要发了。但B若发送数据，A仍要接收，也就是说B到A这个方向的连接并没有关闭，这个状态可能会持续一些时间。这是TCP连接释放的第二次挥手。

3.A收到B的确认后，就进入了FIN-WAIT-2(终止等待2)，等待B发出连接释放报文段，如果B已经没有要向A发送的数据了，其应用进程就通知TCP释放连接。这是B发出的连接释放报文段中，FIN=1，确认号还必须重复上次已发送过的确认号，即ack=u+1，序号seq=w，因为在半关闭状态可能又发送了一些数据，因此该序号为半关闭状态发送的数据的最后一个字节的序号+1.这时B进入LAST-ACK(最后确认)，等待A的确认，这是TCP连接的第三次挥手。

4.A收到B的连接释放请求后，必须对此发出确认。确认报文段中，ACK=1，确认号ack=w+1，而自己的序号seq=u+1，而后进入TIME-WAIT(时间等待)状态。这时候，TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL(Maximum Segment Lifetime最大报文寿命)后，A才进入CLOSED状态。RFC(Requests for Comments 请求注解文档)建议设为2分钟，因此从A进入TIME-WAIT状态后，要经过4分钟才能进入到CLOSED状态，而B只要收到了A的确认后，就进入了CLOSED状态。二者都进入了CLOSED状态后，连接就完全释放了，这是TCP连接的第四次挥手。

1.双方主动关闭TCP连接释放流程

	与可以双方同时建立TCP传输连接一样，TCP传输连接关闭也可以由双方同时主动进行(正常情况下都是由一方发送第一个FIN数据段进行主动连接关闭，另一方被动接受连接关闭)



	当两端对于的网络应用层进程同时调用CLOSE原语，发送FIN数据段执行关闭命令时，两端均从ESTABLISHED状态转变为FIN WAIT 1状态。任意一方收到对端发来的FIN数据段后，其状态均由FIN-WAIT-1转变为CLOSING状态，并发送最后的ACK数据段。当收到最后的ACK数据段后，状态转变为TIME_WAIT，在等待2MSL后进入到CLOSED状态，最终是否整个TCP传输连接。

2.为什么A在TIME-WAIT状态必须等待2MSL时间呢？

	1.为了保证A发送的最后一个ACK报文段能够到达B。该ACK报文段很有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B可能会重传这个FIN+ACK报文段，而A就在这2MSL时间内收到这个重传的FIN-ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入CLOSED状态。如果A在TIME-WAIT状态不等待一段时间就直接释放连接，到CLOSED状态，那么就无法收到B重传的FIN+ACK报文段，也就不会再发送一次确认ACK报文段，B就无法正常进入CLOSED状态。

	2.防止已失效的请求连接出现在本连接中。在连接处于2MSL等待时，任何迟到的报文段将被丢弃，因为处于2MSL等待的、由该socket(IP和端口对)定义的连接在这个时间内将不能被再用，这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。

PS：当客户端执行主动关闭并进入TIME-WAIT是正常的，服务端执行被动关闭，不会进入TIME-WAIT状态，这说明如果终止了一个客户程序，并立即重启该客户程序，则新的客户程序将不再重用相同的本地端口，而是使用新的端口，这不会带来什么问题，因为客户端使用本地端口，而并不关心这个端口是多少。

但对于服务器来说，情况就不同了，服务器总是用我们熟知的端口，那么在2MSL时间内，重启服务器就会出错，为了避免这个错误，服务器给出了一个平静时间的概念，就是说在2MSL时间内，虽然可以重启服务器，但是这个服务器还是要平静地等待2MSL时间的过去才能进行下一次连接。