上文中，我们了解到，当两个进程通过TCP建立了连接，那么最终双方都会进入ESTABLISHED状态.那么下面我们来看看，当TCP关闭连接的时候，Client和Server会发生什么变化.
控制位
终止FIN:用来释放一个连接。当FIN为1时，表明此报文段的发送方的数据已发送完毕，并要求释放传输连接。
确认ACK:仅当ACK=1时确认号字段才有效，当ACK=0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1。
TCP的连接释放过程
TCP的4次挥手.jpg
- 客户端A的应用进程向其TCP发出释放报文段，并停止发送数据，主动关闭TCP连接。同时，A将连接释放报文段首部的终止控制位FIN置为1，然后声明序号seq=u（等于前面已发送过的数据的最后一个字节的序号加1）。这时，A进入FIN-WAIT-1(终止等待1)状态，等待B的确认。TCP规定，FIN报文段即使不携带数据，也消耗一个序号。
- B收到连接释放报文段后即发出确认，确认号是ack=u+1,然后声明自己的序号seq=v(等于B前面已传送过的数据的最后一个字节序号+1).随后进入CLOSE-WAIT(关闭等待)状态。随后TCP服务器通知高层应用进程，将A->B这个方向的连接释放，此时，TCP处于半连接的状态(A已经没有数据需要发送了，但是B若发送数据，A仍要接收),此时,B->A这个方向的连接是没有被关闭的，可能会持续一段时间。
- A收到来自B的确认后，进入FIN-WAIT2(终止等待2)状态，等待B发出的连接释放报文段。
- 若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。经过一段时间的传输后，此时B的seq从v变到了w（假定），然后重复上次已发送的确认号ack=u+1。这时B进入LAST-ACK(最后确认)状态，等待A的确认。
- A收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置为1，确认号ack=w+1，自己的序号seq=u+1。然后进入TIME-WAIT(时间等待)状态。此时的TCP连接并没有真正的释放。必须经过时间等待计时器（TIME-WAIT timer)设置的时间2MSL后，A才进入CLOSED状态。时间MSL(最长报文段寿命,RFC793建议为2分钟，Linux为30S)。假设为2分钟，那么4分钟后A进入CLOSED状态。连接释放。
为什么A在TIME-WAIT状态必须等待2MSL的时间呢？
- 为了保证A发送的最后一个ACK报文段能够到达B。这个ACK有可能丢失，因此在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认时，B会进行超时重传这个FIN+ACK报文段，而A就能在2MSL的时间内收到这个重传的FIN+ACK报文段。接着A重传一次ACK报文段，然后刷新2MSL计时器。
- 防止“已失效的连接请求报文段”出现在连接释放过程中。A发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段从网络中消失，这样下一个新的连接就不会出现这种旧的连接请求报文段。
为什么需要四次挥手才能断开连接
因为TCP是全双工的，发送方和接收方都需要FIN报文和ACK报文。
服务器出现大量的CLOSE-WAIT的原因
资源没有得到回收，应检查释放资源的代码是否正确执行。
检查线程有关的配置。
Linux中可以通过netstat -n | awk '/^tcp/{++S[$NF]}END{for(a in S) print a,S[a]}'查看CLOSE-WAIT数量
为什么建立连接是三次握手，关闭连接却是四次挥手呢？
建立连接的过程中，服务器应答是不需要传送数据的，因此SYN+ACK是一起发送的。但是释放连接的时候，服务器可能要向客户端传送数据，这个动作是需要时间的。因此FIN和ACK需要分开发送。
