tcp为什么要三次握手：为了双向可靠确认，杜绝无效连接

tcp为什么要三次握手，核心目的是在建立连接前，双向验证收发能力正常、同步初始序列号、规避历史失效报文干扰，用最少交互次数实现可靠连接初始化。两次握手只能保证单向通信有效，无法确认客户端接收、服务端发送的双向状态，四次握手会产生冗余交互、浪费网络资源，三次握手是兼顾可靠性与传输效率的最优解，所有tcp可靠传输的基础，都依托于这三次精准的报文交互完成校验。 你可以把tcp连接理解为双向通话，三次握手的本质是双方互相确认“能发、能收”。第一次握手客户端发送SYN报文，仅能证明客户端的发送功能正常，服务端此时只能收到客户端的连接请求，却无法让客户端知晓自己的收发状态，单次交互只能完成单向验证，双向通信的校验完全不完整。 第二次握手由服务端响应SYN+ACK报文，完成服务端发送、客户端接收的校验。此时服务端确认自身收发正常，也确认了客户端发送正常，但客户端只收到了服务端的响应，无法确定自己发出的应答报文能否被服务端成功接收。如果到此止步，也就是两次握手建立连接，会出现致命漏洞：客户端无法判定服务端能否接收后续数据，极易出现连接建立成功，但客户端发送的数据服务端完全收不到的问题。 第三次握手是客户端发送ACK报文，补齐最后一段校验链路，让服务端确认自身接收功能正常。至此客户端、服务端双方都完整验证了对方的发送、接收能力全部正常，同时双方的初始序列号完成同步，后续所有数据传输都能基于序列号完成排序、去重、校验，彻底规避报文乱序、重复传输的问题。 ##三次握手规避历史滞留报文的核心逻辑 网络中存在延迟、丢包、重传机制，旧的失效SYN报文可能延迟很久才到达服务端。如果采用两次握手，服务端收到过期报文就会直接建立连接、占用端口资源，最终生成一个无效、无法通信的闲置连接，持续消耗服务器性能。三次握手可以完美解决这个问题，过期报文触发的服务端响应，客户端收到后会识别出序列号不匹配，直接丢弃报文、不发送第三次ACK，服务端收不到最终确认，就不会建立无效连接。 很多人误以为握手次数越多越可靠，实际四次及以上握手完全没有必要。tcp连接只需完成双向收发校验和序列号同步，三次交互已经覆盖所有核心校验环节，额外的握手报文只会增加网络往返耗时，提升连接建立的延迟，不会提升任何可靠性。 |握手次数|核心缺陷|可靠性表现| |---|---|---| |两次握手|无法验证客户端接收、服务端发送闭环，存在无效连接漏洞|单向可靠，双向通信无保障| |三次握手|无功能缺陷，仅最小网络开销|双向完全可靠，适配所有tcp场景| |四次及以上握手|产生冗余交互，增加连接延迟|可靠性无提升，资源利用率降低| tcp三次握手有明确的适用边界限制，仅适用于面向连接的可靠传输场景。如果是UDP这类无连接传输协议，无需握手校验，直接发送数据即可，强行套用三次握手机制只会浪费网络资源。同时，三次握手无法规避后续传输中的丢包、乱序问题，仅负责连接建立阶段的可靠性校验，数据传输过程的稳定需要依靠滑动窗口、超时重传等后续机制保障。