服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。
从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。
为什么客户端在TIME-WAIT阶段要等2MSL？
为的是确认服务器端是否收到客户端发出的 ACK 确认报文，当客户端发出最后的 ACK 确认报文时，并不能确定服务器端能够收到该段报文。
所以客户端在发送完 ACK 确认报文之后，会设置一个时长为 2MSL 的计时器。
MSL 指的是 Maximum Segment Lifetime：一段 TCP 报文在传输过程中的最大生命周期。
2MSL 即是服务器端发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。
服务器端在 1MSL 内没有收到客户端发出的 ACK 确认报文，就会再次向客户端发出 FIN 报文：
如果客户端在 2MSL 内，再次收到了来自服务器端的 FIN 报文，说明服务器端由于各种原因没有接收到客户端发出的 ACK 确认报文。
客户端再次向服务器端发出 ACK 确认报文，计时器重置，重新开始 2MSL 的计时。
否则客户端在 2MSL 内没有再次收到来自服务器端的 FIN 报文，说明服务器端正常接收了 ACK 确认报文，客户端可以进入 CLOSED 阶段，完成“四次挥手”。
所以，客户端要经历时长为 2SML 的 TIME-WAIT 阶段;这也是为什么客户端比服务器端晚进入 CLOSED 阶段的原因。
这里同样有个动态过程的图示：
好了，我们的文章到这就……
唉，不对，就这么完了，这会我好像知道了，但过会儿那就说不定了。
没关系，我苦思冥想，找了两个大白话的例子，保准你忘不了。
大白话说三次握手在二十年前的农村，电话没有普及，手机就更不用说了，所以，通信基本靠吼。
老张和老王是邻居，这天老张下地了，结果家里有事，热心的邻居老王赶紧跑到村口，开始叫唤老王。
老王：老张唉！我是老王，你能听到吗？
老张一听，是老王的声音：老王老王，我是老张，我能听到，你能听到吗？
老王一听，嗯，没错，是老张：老张，我听到了，我有事要跟你说。
"你老婆要生了，赶紧回家吧！"
老张风风火火地赶回家，老婆顺利地生了个带把的大胖小子。
握手的故事充满了幸福和美满。
假如博主有一个女朋友——只是“假如”，该死的，这不争气的眼泪，怎么止不住地滴在键盘上。
由于博主上班九九六，下班肝博客，导致没有时间陪女朋友，女朋友忍无可忍。
女朋友：臭男人，最近你都不理我，你是不是不爱我了？你是不是外面有别的狗子了？我要和你分手？
沙雕博主一愣，怒火攻心：分手就分手，不陪你闹了，等我把东西收拾收拾。
沙雕博主小心翼翼地装起了自己的青轴机械键盘。
哼，蠢女人，我已经收拾完了，我先滚为敬，再见！
女朋友：滚，滚的远远的，越远越好，我一辈子都不想再见到你。
唉，挥手的故事总充满了悲伤和遗憾！
好了，白话纯属娱乐！看在博主费了不少脑子的份上，点个赞再走呗！！
参考：
【1】：两张动图-彻底明白TCP的三次握手与四次挥手
【2】：35 张图解：被问千百遍的 TCP 三次握手和四次挥手面试题
【3】：三次握手+四次挥手，一文搞定所有！