回顾 TCP 建立连接：
假如你对一个女孩子告白，大概流程只有三步：
具体的 TCP 建立连接的内容你可以参考这一篇：
TCP 连接过程
哈哈，我曾把完整的镜子打碎… 就这样你们的爱情走向失败。
TCP 断开连接：
相爱容易，分手难。 相爱只需要三步，而分手则需要四步：
这个过程就和CP断开连接过程很像，下面具体解析TCP断开连接流程：
过程：
A发送完数据后发送 FIN 报文给B，表示想断开连接。B收到报文给A一个应答表示收到断开请求，然后再通知应用程序发送剩余数据，处理现场信息，关闭相关资源，并进入 CLOSE_WAIT（等待关闭状态）。然后再发送 FIN 报文给A 表示可以断开连接。然后等待A的应答报文。A收到后发送 ACK 应答报文，并进入TIME-WAIT 状态，等待 2MSL，如果在这个时间段内没收到 B 发来的报文则进入完全关闭状态（CLOSE）
TIME_WAIT 等待的 2MSL是报文在网络上生存的最长时间，超过这个阈值，报文则被丢弃。通常 MSL 的时间大于 TTL （Time To Live 数据包在网络传输的生存时间，通常每经历一个路由则TTL减一）衰减到0的时间 。需要等待那么久的时间，对于高并发的服务器来说岂不是百害而无一利？？？ 那为啥不直接进入CLOSE状态呢？
理由 1 ： 确认被关闭方能够顺利进入CLOSED状态。
由于网络原因导致 ACK无法顺利发送到B：
对于B 来说： “自信”的认为A 没收到我在LAST-ACK状态发送的 FIN+ACK报文，则会重新发一份给A。
对于A来说：当收到B重新发送的FIN+ACK报文后，发送响应的ACK应答，就“自私”的进入CLOSED，会导致B无法接收到对应的ACK信号，无法进入CLOSED状态。
理由 1 ： 防止请求失效。
防止请求失效的数据包与正常连接的数据包发生混淆而发生异常。
总结： 简单的介绍了TCP断开连接的过程，以及相应状态的解读。解决为啥四次连接的问题等。
