tcp关闭的四次挥手
tcp关闭通信本质是双方的sock结构体的删除，计算机里有明确的先后顺序。
你想想，在客户端/服务端模式，正常情况下，服务器作为服务的，它是有求必应，怎么想，主动想关闭的一方应该客户端吧，服务端还要持续接受其他客户端请求呢。
所以结论：客户端主动发起关闭。
先看三次挥手关闭情况：
客户端主动关闭的话，即开始准备删除sock结构体，应该怎么做呢？我们之前一直在“一去一来”的通信，那么客户端想关闭肯定先不发信息了吧，即关闭自己的发送端，第一次挥手的FIN出现了。
接下来，服务端接收到FIN，没有回数据时，是可以结束了，直接回ACK(tcp的确认机制)+FIN，即第二次挥手FIN。此时不能删除sock结构体，因为为了防止结束的包中途丢失(tcp要确保的可靠机制)，所以此时服务端还不能结束，服务端要等客户端对这个FIN回一个ACK后即第三次挥手，服务端删掉sock结构体了。
客户端同样为了确保第三次的挥手的不丢包，如果丢了要重传的，所以这就是要等待一段时间即TIME_WAIT。
再看四次挥手关闭情况：
本来三次就行，但万一客户端想关闭第一次挥手嘛，服务端还在传上次没传完的数据，那么服务端需要等待传完后才能挥手，但基于tcp确认重传机制，在客户端第一次挥手后服务端不立马回个ACK，客户端会以为第一次挥手丢失了，一直重传，我们不希望看到，所以要就把上面情况的第二次挥手拆成了先ACK然后再FIN就两次挥手了，后面不变。
TIME_WAIT还有一个重要原因——使网络中这个连接所发送的数据包完全消耗殆尽。因为如果没有等待耗尽，你立马建立第二次连接，这个旧数据包会导致新连接(四元组相同)的新旧数据包混乱。
