TCP三次握手流程详解，为何握手不是两次、四次？

TCP三次握手流程是客户端和服务器通过三次交互确认连接，并协商通信参数的过程。三次握手而非两次或四次的原因在于：三次能可靠验证双方收发能力并完成参数协商，两次无法确保可靠性，四次则冗余。

一、TCP三次握手流程详解

TCP三次握手的核心是通过三次交互，使客户端和服务器确认双方的收发能力正常，并建立可靠的连接。具体流程如下：

第一次握手（SYN）：
客户端发送SYN包（SYN=1, seq=x）到服务器，表示请求建立连接，并进入SYN_SEND状态。
此时，服务器确认了自身接收能力正常（能收到客户端的SYN包），以及客户端发送能力正常（客户端能发送SYN包）。
但客户端无法确认任何信息（如服务器是否收到、自身发送是否成功等）。
第二次握手（SYN+ACK）：
服务器收到SYN包后，响应SYN+ACK包（SYN=1, ACK=1, seq=y, ack=x+1），并进入SYN_RCVD状态。
此时，客户端确认了自身收发能力正常（能收到服务器的SYN+ACK包，说明发送和接收均正常），以及服务器收发能力正常（服务器能发送SYN+ACK包，说明接收和发送均正常）。
但服务器仅确认了自身接收能力正常和客户端发送能力正常，仍需第三次握手确认自身发送能力。
第三次握手（ACK）：
客户端收到SYN+ACK包后，向服务器发送确认包ACK（ACK=1, seq=x+1, ack=y+1），客户端和服务器均进入ESTABLISHED状态，连接建立完成。
此时，服务器确认了自身收发能力正常（能收到客户端的ACK包，说明发送和接收均正常），以及客户端收发能力正常（客户端能发送ACK包，说明接收和发送均正常）。
双方均完成收发能力的验证，连接可靠建立。

二、为何握手不是两次或四次？

TCP三次握手的设计是权衡可靠性和效率的结果，两次无法确保可靠性，四次则冗余。具体原因如下：

1. 两次握手无法可靠验证双方收发能力

第一次握手（SYN）：服务器仅能确认自身接收能力和客户端发送能力，客户端无法确认任何信息。
第二次握手（SYN+ACK）：客户端能确认自身收发能力和服务器收发能力，但服务器无法确认自身发送能力（如SYN+ACK包是否丢失）。
问题：若第二次握手后连接建立，但服务器的SYN+ACK包丢失，客户端认为连接已建立，而服务器未收到ACK包，会认为连接未建立。此时客户端发送数据，服务器会拒绝（因未完成三次握手），导致通信异常。
结论：两次握手无法解决“历史连接”或“丢包”导致的可靠性问题。

2. 三次握手能可靠验证双方收发能力

3. 四次握手冗余且低效

四次握手的可能设计：
第一次：客户端发送SYN。
第二次：服务器发送SYN+ACK。
第三次：客户端发送ACK（确认服务器的SYN+ACK）。
第四次：服务器发送另一个ACK（确认客户端的ACK）。
问题：
第三次握手后，双方已确认收发能力正常，第四次握手无实际意义。
增加一次交互会延长连接建立时间，降低效率。
结论：四次握手是冗余设计，三次已足够可靠。

4. 三次握手的其他作用：协商MSS

MSS（Maximum Segment Size）：TCP报文段中数据部分的最大长度，需双方协商确定。
协商过程：
在三次握手的SYN和SYN+ACK包中，通过TCP Option字段携带MSS信息。
客户端在第一次握手时发送自身支持的MSS，服务器在第二次握手时响应自身支持的MSS。
双方取较小值作为最终MSS，确保后续数据交互高效且避免分片。
重要性：若未协商MSS，一方可能发送过大报文导致分片或丢包，影响通信效率。
三次握手的必要性：MSS协商需在连接建立阶段完成，两次握手无法完成此过程，四次握手则冗余。

三、总结

热门标签