那个叫“四次挥手”的温柔告别——TCP连接的分手仪式，我真服了！
哎呦喂,说到TCP四次挥手，我真的是又爱又恨！就像跟一个处了很久的网友说再见，明明已经没啥可聊的了，但程序上还得走完那套流程，少一步都不行，你说气不气人？今天咱就掰开揉碎聊聊这个网络世界最著名的“分手仪式”，顺便带点我自己的小情绪，嘿嘿。
第一次挥手：主动方说“我不玩了”
你想想啊,当客户端觉得数据传完了，想断开连接了，它会先给服务器发一个FIN包，嘴里念叨着：“嘿，哥们儿，我这边数据发完了，准备撤了哈！”这时候客户端就进入了FIN_WAIT_1状态，跟那种提出分手后等着对方回应的心情一模一样，忐忑不安有没有？啊，这种状态其实挺煎熬的，毕竟你也不知道对方是爽快答应还是缠着不放。
第二次挥手：被动方回“收到，我明白”
服务器收到FIN包后,必须得回一个ACK包，意思就是：“行，我知道了，你等着啊，我这边还没收拾完呢！”这时候服务器进入CLOSE_WAIT状态，而客户端进入FIN_WAIT_2，你瞧，这跟现实中的分手多像啊——一方说“我们分手吧”，另一方说“嗯，我知道了”，但就是迟迟不办手续，吊着你！我跟你讲，这个CLOSE_WAIT状态是最容易出问题的，如果服务器一直不处理，那连接就卡在这儿了，像那种说好分手却还藕断丝连的，拖泥带水，烦死了！
第三次挥手：被动方说“我也准备好了，咱撤吧”
等服务器把自己的数据也发送完毕,它才会发出FIN包给客户端，意思是：“好啦好啦，我这边也搞定了，咱们这就彻底拜拜？”这时候服务器进入LAST_ACK状态，客户端呢，还在FIN_WAIT_2里眼巴巴等着呢，这个过程真的考验耐心，我就遇到过客户端等不到服务器最后的FIN，直接超时重传的，那场面，啧啧，就像分手后对方半天不回消息，你急得连发好几条“在吗”一样，尴尬不尴尬？
第四次挥手：主动方最后确认“好，就这么定了”
客户端收到服务器的FIN包之后,还得再回一个ACK包，然后进入TIME_WAIT状态，这里划重点！—要等2MSL（最长报文段寿命的两倍）时间才能彻底关闭连接，为啥要等这么久？怕最后一个ACK包丢了呗！要是丢了，服务器会重发FIN，客户端就能再回应，你看，这多像分手后还要给对方留一段冷静期，防止对方反悔来找你，哈哈，这个设计真的绝了！不过说真的，TIME_WAIT太多的话，服务器端口会被占满，就像手机通讯录里存了一堆前任的联系方式，占地方又舍不得删，真是愁死个人！
四次挥手对比三次握手的那些个事儿
你可能要问了,为啥建立连接要三次握手，断开连接非要四次呢？嘿，这不是明摆着的事儿吗——建立连接时，服务器可以SYN和ACK一起发，而断开时，服务器收到FIN后可能还有数据要传，所以ACK和FIN得分开发，这就变成了“你一句，我一句，你再一句，我最后一句”的四次对话，就像谈恋爱，开始的时候可以一见钟情立刻在一起，但结束的时候总得各自收拾好心情，对不对？
实战踩坑与情绪吐槽
说到这个,我还真遇到过糟心事，有一次调试程序，发现服务器上一堆TIME_WAIT状态的连接，直接把端口给耗尽了，真是气到跺脚！后来改了系统参数才解决，还有那个CLOSE_WAIT，要是服务端代码没写好忘了关闭连接，那连接数就像滚雪球一样越积越多，最后服务器直接瘫痪，那叫一个崩溃！我跟你们说，这些状态要是处理不好，比感情里的纠缠还让人头疼。
网络安全的那些事儿
当然啦,四次挥手也跟网络安全脱不了干系，恶意攻击者可能会故意发送伪造的FIN包试图切断别人的连接，也就是所谓的“TCP RST攻击”变种，让人防不胜防，还有人利用TIME_WAIT状态来做端口扫描探测，想想都觉得背后发凉，咱们搞网络安全的，就得把这些协议细节摸得透透的，不然哪天被人钻了空子，哭都来不及！
好了好了,今天关于TCP四次挥手的“爱恨情仇”就唠到这，说到底，这个协议设计得还是挺巧妙的，虽然过程曲折，但保证了数据的可靠传输，你们在学习网络的时候，有没有也被这些状态机折磨过？反正我是从最初的懵圈到现在的豁然开朗，中间没少掉头发！
如果你也对网络知识、网络安全有兴趣，欢迎加我QQ一起交流探讨，咱们一起把这些硬骨头啃下来！学习网络安全不能闭门造车，多交流才能进步神速呀！
