TCP的四次挥手过程
客户端和服务端都可以主动释放连接
这里以客户端示例
情景一：服务端有数据存在（四次挥手）
- 客户端发送FIN标识到服务端，告知服务端我要释放连接
- 服务端收到FIN标识，知道了客户端想断开连接，于是马上检查是否还有数据发送给客户端，如果还有数据没有发送，就发送ACK标识告诉客户端：等一会，你还有数据在我这里
- 待所有数据发送完毕后，服务端发送FIN标识给客户端，告诉客户端，现在已经没有数据了，我要关闭连接啦
- 客户端收到服务端的FIN标识，知道服务端现在就要关闭连接了，于是就发送ACK标识，告知服务端：我知道啦，你关吧
- 于是服务器关闭，客户端也关闭了
情景二：没有数据存在（三次挥手）
- 客户端发送FIN标识到服务端，告知服务端我要释放连接
- 服务端收到FIN标识，知道了客户端想断开连接，于是马上检查是否还有数据发送给客户端，发现客户端咋我这里已经没有数据了，就发送FIN，ACK标识告诉客户端：你没有数据在我这里，我要关闭连接啦
- 客户端收到服务端的FIN标识，知道服务端现在就要关闭连接了，于是就发送ACK标识，告知服务端：我知道啦，你关吧
- 于是服务器关闭，客户端也关闭了
为什么要等待2MSL时间
假设当客户端发送最后一次ACK，就不接收任何消息，处于关闭状态，而此时如果服务端没有收到ACK，会怎么样？
服务端角度：给客户端发送消息，没有收到回复，触发重发机制。但是客户端已经把连接关闭了，我的连接怎么办？谁来救救我~~
假设客户端在关闭之前等待指定时间（图中是2MSL），如果在2MSL时间内收到来自服务端重传的报文段，就知道上次的ACK没有到达服务端，于是重新发送ACK，这样可以保证A和B都能正常关闭连接
