一、写在前边

大家好，我们又见面了，做为一个业余的动画师，上次的用动画的形式讲解 TCP 三次握手过程再各大平台收到了广大读者的喜爱，说文章有趣、有货、有内容，也受到了很多读者的关注。很多读者留言说什么时候用动画讲一讲 TCP 四次挥手的过程，为了应大家的要求，今天我们就生动有趣的用动画给大家分享 TCP 四次挥手（分手）过程。

动画：用动画给面试官解释 TCP 三次握手过程

上次的三次握手动画是给面试官看的，那么今天咱们换种更加有乐趣的方式，用动画和你女(男)朋友讲解 TCP 四次分手过程，讲解完，考验一下你女（男）朋友和不和你分手呢。什么？首先你先有一个女（男）朋友，这一点小鹿早就考虑到了各大单身人士。

获取方式:

如果你没有女朋友，公众号后台回复“女朋友”，即可获取。小鹿不要脸的说，作为一个优秀的动画师，女性读者也是很多的，哈哈，公众号回复“男朋友”，小鹿会给你随机发放一个，嘿嘿，不信你试试。还等什么，把你女（男）朋友拉过来给她（他）讲吧。

二、思维导图

三、为何要进行 TCP 三次握手/四次分手？

TCP 的三次握手和四次分手和你恋爱是一模一样的，从相识到相恋到分手，然后认识另一个女孩再不管重复这个过程就是数据传输在网络中不断建立起三次握手和四次分手过程。

恋爱就恋爱吧，分手就分手吧，握手握来握去，挥手挥来挥去不嫌麻烦吗？

因为上篇文章 TCP 三次握手中的为什么要进行三次握手部分讲解的不怎么详细，小鹿课下就收集了一些资料，做了一个总结，在这里补充下。

3.1 为什么要进行三次握手？

在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。

举个简单易懂的例子，你在微信对一个女孩表白，这条信息由于网络问题延迟发送了。

然后此时你不耐烦了，去和微信另一个女孩表白，然后另一个女孩告诉你同意了，然后你心里很高兴，把高兴的心情分享给了女孩，女孩知道了你和她在一起很高兴，此时三次握完毕，你恋爱了。

突然，到了第二天，发给第一个女孩的信息才收到，女孩认为你要和他表白，此时你已经和另一个女孩恋爱了，然后第一个女孩给你发微信同意了你的表白，但是你不理睬，那个女孩还在苦苦等待你给她分享此时的高兴心情。现在我们发现如果没有分享高兴的心情给女孩（也就是第三次握手过程），那么那个女孩一直等待，白白浪费了心思，所谓的千年都等不了一回。

如果你是客户端，女孩是服务端，服务端收到延迟的报文，以为你要和它连接，所以会给你发送确认同意连接，但你一直不搭理它，所以服务端的资源也就这么白白浪费掉了。所以知道为什么要进行三次握手了吧。

在《计算机网络》书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。

3.2 为什么要 TCP 四次分手？

我们知道，TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议，而且TCP是全双工模式。

对于初学者来说，定义太枯燥、无味，其实意思就是你和你女朋友聊天是面向连接的，只有连接起来才可以通信的，可靠就是你发送的信息可以保证送达到对方，全双工意思就是你不仅可以给你女朋友发消息，而且她也可以给你发信息。

为什么非要进行 TCP 四次分手？我们接着上回说到，你现在和第二个女孩子恋爱了，突然有一天发现第一个女孩子是因为没有收到你的表白而错过了在一起的时机，那么你要和第二个女孩子分手，那过程对应在 TCP 四次分手是怎么样子的？

你要给第二个女孩子微信发消息，我们分手吧，此时第二个女孩子收到消息知道了，非常伤心，就屏蔽了你。但是，此时你还没有屏蔽她，她完全可以给你继续发消息，她给你发消息说，好吧，此时你收到了确认消息，此时是第二次分手过程。那么女孩又给你发送消息，渣男，永远不要来找我。此时你又接收到消息，看到消息之后发了一个拜拜，然后你就直接屏蔽拉黑了对方，此时女孩微信显示你删除了对方，然后就把你也拉黑删除了。那么四次分手到此为止，恭喜你，成功获得下一个女孩子。

上述过程就阐述了为什么要进行 TCP 四次分手，为了能够让对方屏蔽你直至最后双方互相删除掉，然后你又可以和另一个女孩三次握手了。

四、TCP 四次分手过程

初始化状态：客户端和服务端都在连接状态，接下来开始进行四次分手断开连接操作。

第一次分手：第一次分手无论是客户端还是服务端都可以发起，因为 TCP 是全双工的。

假如客户端发送的数据已经发送完毕，发送FIN = 1 告诉服务端，客户端所有数据已经全发完了，服务端你可以关闭接收了，但是如果你们服务端有数据要发给客户端，客户端照样可以接收的。此时客户端处于FIN = 1等待服务端确认释放连接状态。

第二次分手：服务端接收到客户端的释放请求连接之后，知道客户端没有数据要发给自己了，然后服务端发送ACK = 1告诉客户端受到你发给我的信息，此时服务端处于 CLOSE_WAIT 等待关闭状态。

第三次分手：此时服务端向客户端把所有的数据发送完了，然后发送一个FIN = 1，用于告诉客户端，服务端的所有数据发送完毕，客户端你也可以关闭接受数据连接了。此时服务端状态处于LAT_ACK状态，来等待确认客户端是否收到了自己的请求。

第四次分手：此时如果客户端收到了服务端发送完的信息之后，就发送ACK = 1，告诉服务端，客户端已经收到了你的信息。但是我们发现上图中有一个 2 MSL 的延迟等待。

五、为什要有 2 MSL 等待延迟？

对应这样一种情况，最后客户端发送的ACK = 1给服务端的过程中丢失了，服务端没收到，服务端怎么认为的？我已经发送完数据了，怎么客户端没回应我？是不是中途丢失了？然后服务端再次发起断开连接的请求，一个来回就是2MSL，这里的两个来回由那一个来回组成的？

客户端给服务端发送的ACK = 1丢失，服务端等待 1MSL没收到，然后重新发送消息需要1MSL。如果再次接收到服务端的消息，则重启2MSL计时器，发送确认请求。客户端只需等待2MSL，如果没有再次收到服务端的消息，就说明服务端已经接收到自己确认消息；此时双方都关闭的连接，TCP 四次分手完毕。

六、如果双方建立连接，一方出问题怎么办？

如果双方建立连接，一方出问题怎么办？为了防止出现上述恋爱故事中千年等一回的情况，已经建立连接，但是服务端一直等待接收，发送端出现问题一直不能发送。

所以设计一个保活的计时器，如果一方出现问题，另一方过了这个计时器的时间，就发送试探报文，以后每隔 75 秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

小结

今天用动画的形式给你女（男）朋友讲了 TCP 四次分手的过程，文章的内容以及展现形式是最基础的内容。

最后小鹿为大家整理的三次握手和四次分手整张图，如下：

最后希望你和你的女朋友永远三次握手，永不四次分手。

❤️ 不要忘记留下你学习的脚印 [点赞 + 收藏 + 评论]

文章都看完了，为何不妨点个赞呢？嘻嘻，那就说明你很自私，你怕那么好的文章让别人也看到。开个小小玩笑。

其实我也很自私，我把我的一直以来坚持原创的公众号:「小鹿动画学编程」偷偷给你，里边汇聚了小鹿以动画形式讲解的数据结构与算法、网络原理、Web 等技术文章。

作者Info：

【作者】：小鹿

【原创公众号】小鹿动画学编程

【简介】：和小鹿同学一起用动画的方式从零基础学编程，将Web前端领域、数据结构与算法、网络原理等通俗易懂的呈献给小伙伴。公众号回复 “资料” 送一从零自学资料大礼包！

【转载说明】：转载请说明出处，谢谢合作！~