四次挥手的流程
1、主动关闭方发送FIN连接释放报文段
客户端调用 close 方法，告诉服务器自己要主动关闭连接，会发送一个 FIN 报文给服务端，客户端进入FIN-WAIT-1状态。
2、被动关闭方发送对FIN的ACK普通确认报文段
由于此时服务器数据很可能还没有发完，需要继续向客户端发送未完成的数据，又不能让客户端等太久，所以先向客户端发送ACK 确认报文段，服务端进入 CLOSE_WAIT，客户端收到ACK之后进入FIN-WAIT-2状态。
3、被动关闭方发送FIN连接释放报文段
当服务器数据发送完毕之后。发送 FIN 报文给客户端，然后进入LAST-ACK 状态，等待客户端的 ACK。(同前面一样如果 FIN 段没有携带数据，也需要消耗一个序列号)
4、主动关闭方发送对FIN的ACK普通确认报文段
客户端收到服务端的 FIN 报文以后，回复 ACK 报文用来确认第三步里的 FIN 报文，随后进入TIME_WAIT状态（主动关闭连接的一方才有 TIME_WAIT 状态），等待 2 个 MSL （MSL：最长报文段寿命）以后进入 CLOSED状态。服务端收到 ACK 以后进入CLOSED状态。正常情况下服务器结束TCP连接的时间要比客户端早一些。
面试题
为什么建立连接是三次握手，关闭连接确是四次挥手呢？
建立连接的时候将四次握手合并成了三次（SYN+ACK合并为一次），
关闭连接操作时无法优化成三次，理由如下：
服务器收到对方的FIN报文时，很可能还有数据没发完，需要等到数据发送完毕之后才向客户端发送FIN报文，但是又不能让客户端等太久，就先发ACK告诉客户端—我收到了你的FIN释放连接请求，客户端收到ACK之后便不会重复发送断开连接的请求。
等到服务器数据传输完毕后，才会发FIN释放连接报文，这样保证传输完毕后才断开连接。
另外，如果服务端确定没有数据需要发给客户端，那么当然是可以把 FIN 和 ACK 合并成一个包，四次挥手的过程就成了三次。
为什么 TIME_WAIT 等待的时间是 2MSL？
MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
最大生存时间怎么来的?
报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃，这就限制了报文的最长存活时间。
MSL 与 TTL 的区别：MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。
1、保证服务端的连接能够正确关闭
客户端是发出了第四次握手的报文后进入的TIME_WAIT。如果第四次握手中，客户端发给服务器的ACK报文丢失了，服务器就会发送超时重发 FIN报文给客户端，客户端要保证极端情况下也能接受到服务器的超时重发FIN报文，所以设置成2MSL。
2MSL 的时长相当于允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样服务器重发的 FIN 会在第 2 个 MSL 内到达。
客户端四次挥手的最后一个 ACK 报文如果在网络中被丢失了，此时如果客户端 TIME-WAIT 过短或没有，则就直接进入了 CLOSE 状态了，那么服务端则会一直处在 LASE-ACK 状态而没有正确关闭，这就糟了。
当客户端再次发起建立连接的 SYN 请求报文后，由于服务端处于LAST_ACK而非LINSTEN状态，所以会发送 RST 报文给客户端，连接建立的过程就会被终止导致无法正常的建立连接。
2、防止收到历史数据，从而导致数据错乱的问题。
客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的历史数据。
举个栗子，服务端向客户端发送的最后一个数据包因为网络延迟原因久久未到，而此时发送该包时的tcp连接已经断开，并且端口被复用开启了另一个tcp连接，由于TIME_WAIT 等待的时间不足，此包还未过期，客户端就会以为是此tcp连接的包而接收，导致数据混乱。
补充：
如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。
那允许报文丢失一次够吗？为什么不是 4 或者 8 MSL 的时长呢？
因为一个丢包率达到百分之一的糟糕网络，连续两次丢包的概率只有万分之一，这个概率实在是太小了，忽略它比解决它更具性价比。
因为TIME_WAIT 状态会消耗系统资源。如果TIME_WAIT 状态过多，占满了所有端口资源，则会导致无法创建新连接。
客户端受端口资源限制：如果客户端 TIME_WAIT 过多，就会导致端口资源被占用，因为端口就65535个，被占满就会导致无法创建新的连接； 服务端受系统资源限制：当服务端出现大量 TIME_WAIT 时，系统资源被占满时，会导致处理不过来新的连接；