TCP三次握手和四次挥手的过程详解

前言TCP 是面向连接的可靠传输协议连接建立依靠三次握手连接断开依靠四次挥手。这两个机制是网络面试高频考点也是后端、网络开发必须吃透的基础。很多人只会死记流程却不明白核心目的为什么不能两次握手为什么关闭连接需要四次而不是三次本文结合报文标志位、交互流程、常见误区完整讲解。前置知识TCP 核心标志位SYN同步用于建立连接协商初始序列号ACK确认确认收到对方报文FIN结束代表一方不再发送新数据seq序列号ack确认应答号一、TCP 三次握手建立连接作用客户端与服务端建立TCP连接。目标双方确认自身发送、接收功能正常协商彼此的初始序列号ISN协商窗口大小、MSS等连接参数角色定义Client客户端主动发起连接Server服务端监听端口被动等待连接完整流程第一次握手Client → Server客户端主动发送SYN1携带客户端初始序列号seqx。含义客户端请求建立连接我的起始序列号是x。客户端进入SYN_SENT状态。第二次握手Server → Client服务端收到SYN报文回复SYN1ACK1seqy服务端自己的初始序列号ackx1确认收到客户端SYN应答号 对方seq 1服务端进入SYN_RCVD状态。第三次握手Client → Server客户端收到服务端SYNACK报文回复ACK1acky1确认收到服务端的同步报文seq x1客户端进入ESTABLISHED连接建立服务端收到这条ACK后也进入ESTABLISHED连接正式打通可以传输业务数据。简单形象理解客户端“能听到我吗我想建立连接”第一次握手服务端“收到我也能联系你我同意建立连接”第二次握手客户端“收到你的确认我们开始通信”第三次握手经典问题为什么不能两次握手假设只有两次握手客户端发SYN → 服务端回复SYNACK连接建立。存在重大漏洞历史延迟的SYN报文客户端很早之前发送的连接请求网络延迟很久才到达服务端。服务端收到后直接建立连接并分配资源。但客户端早已放弃这条旧请求不会收发数据。服务端持续维持一条无效连接白白占用内存、端口资源造成服务器资源耗尽。三次握手机制下服务端必须等待客户端第三条ACK报文才会正式建立连接。过期的SYN到达后服务端回复SYNACK但客户端不会响应服务端超时后自动释放资源避免资源浪费。二、TCP四次挥手断开连接TCP是全双工通信双方可以独立收发数据。任意一方想要关闭连接只能关闭自己的发送通道不能直接强制对方停止发送数据。因此断开连接需要四次交互。完整流程初始状态双方都处于 ESTABLISHED第一次挥手Client → Server客户端不再发送数据发送FIN1sequ客户端进入FIN_WAIT_1含义客户端不再发送新数据但仍然可以接收服务端还未发完的数据。第二次挥手Server → Client服务端收到FIN回复ACK1acku1服务端进入CLOSE_WAIT客户端收到ACK进入FIN_WAIT_2重点此时单向通道关闭客户端不能发数据但是服务端如果还有剩余数据依然可以继续发给客户端。第三次挥手Server → Client当服务端所有数据全部发送完毕没有数据要传输了发送FIN1seqv服务端进入LAST_ACK含义服务端数据发送完成我也要关闭连接。第四次挥手Client → Server客户端收到FIN回复ACK1ackv1客户端进入TIME_WAIT状态服务端收到这条ACK立刻进入CLOSED连接关闭。客户端需要等待2MSL时间之后才最终切换到 CLOSED。通俗理解客户端我不再发消息给你了第一次挥手服务端收到我知道你不发了但是我还有消息先传给你第二次挥手服务端我的消息全部发完了我也要结束对话第三次挥手客户端收到结束通信第四次挥手关键问题1为什么挥手需要四次握手只需要三次建立连接时服务端的SYN同步和ACK确认可以合并成一条报文所以第二次握手合并两个动作。关闭连接时服务端收到客户端FIN后不能立刻发送FIN。需要先回复ACK继续传输残留数据等数据传输完毕才能发送FIN。ACK 和 FIN 无法合并因此必须分成两条报文总共四次交互。关键问题2客户端为什么要有 TIME_WAIT2MSL两个核心作用保证服务端能够正常收到最后的ACK报文如果客户端第四条ACK报文丢失服务端处于LAST_ACK状态会重传FIN报文。客户端处在TIME_WAIT期间依然可以正常回复ACK。如果客户端直接关闭端口立刻释放收到重传FIN报文时只能返回RST服务端无法正常关闭。防止旧连接残留报文干扰新连接等待足够长的时间确保网络中这条连接所有滞留数据包全部消失避免旧报文被新建立的连接错误接收。MSL报文最大生存时间Linux默认一般60s2MSL就是两倍时长。三、状态流转汇总便于排查网络问题握手相关状态LISTEN服务端端口监听等待连接SYN_SENT客户端发送SYN等待服务端应答SYN_RCVD服务端收到SYN等待客户端第三次ACKESTABLISHED正常数据传输状态挥手相关状态FIN_WAIT_1主动关闭方发送FIN等待ACKFIN_WAIT_2收到ACK等待对方发送FINCLOSE_WAIT被动关闭方收到FIN等待自身业务数据发送完毕LAST_ACK被动关闭方发送FIN等待最后的ACKTIME_WAIT主动关闭方等待2MSLCLOSED连接完全关闭四、生产环境常见现象服务器大量 CLOSE_WAIT典型原因服务端代码收到对方关闭请求程序没有调用socket关闭连接没有发送FIN。代码层面socket资源泄漏。大量 TIME_WAIT短连接高频创建销毁连接大量主动关闭连接产生TIME_WAIT。解决方案开启端口复用、调整tcp_tw_reuse内核参数。SYN_RECV 大量堆积可能遭遇SYN洪水攻击或者服务端连接队列溢出。五、总结三次握手核心协商序列号、验证双向收发能力防御过期连接请求SYN与ACK报文可以合并。四次挥手核心TCP全双工两个方向通道独立关闭ACK和FIN无法合并。TIME_WAIT 不是多余设计是保障连接可靠关闭、隔离旧数据包的关键机制。面试高频两大思考题两次握手为什么不行挥手为什么四次掌握背后逻辑不要死记硬背。拓展建议学习后可以使用tcpdump/ Wireshark 抓包实际观察SYN、ACK、FIN报文直观验证握手与挥手流程理论结合抓包更容易理解。