TCP三路握手，本质是一个通信原理相关的问题

在通信系统中，最基本的信息的传递都需要两步，发送方发送的消息和对方的回复确认：A->B Send, B->A Reply(ACK)。如果多接触一下其他行业的通信流程和规范，例如航空、铁路调度，就会明白这一点。

TCP 建联，本质上需要传递两条信息：A->B 的初始 SYN 号，B->A 的初始 SYN 号，那么理论上需要四步通信（ A->B 的初始 SYN 号，B->A 的 ACK ； B->A 的初始 SYN 号，A->B 的 ACK ）；只不过为了效率和性能，中间两条消息可以合并为一条，这便是现在的三路握手的来源。后续的所有报文的传递机制，依然是Send/Ack两步 + 消息合并。

仅有Send没有Reply，属于不可靠传递；Send有单条Reply，可以实现99%的容错。只有发送方才有责任确保消息传递完整性，而且因为两军问题，任何信道不可能实现100%的有效性。所以折衷考虑，一般一条Send只需有一个Reply.

通信技术，关心的是通信的基本单元(单条消息、一个独立的数据包...)，如何尽可能可靠地传递的流程，适用于所有领域，属于通用的泛化的规则。例如上述Send/Reply模型。

而协议，描述的则是消息的内容、格式，以及多条消息之间如何交互，是和应用领域相关的。例如：没有Reply意味着什么，Reply可以是什么样的信息格式，不同的格式代表什么含义，不同的格式下采用什么行为...

例如在航空通信，塔台向客机发送指令的协议：

• 需要先报航班号，采用军队电文报数，之后是方位角、高度、行为等指令；
• 航班必须在相同频率下先回复参数，最后附加航班号

上海管制区PVG进近塔台：东方三两幺拐，航向187度上3000保持！
MU3217机长：航向187度上3000保持，东方三两幺拐！

指令格式可以自定义，但塔台发出的指令，必须有Reply。

再比如在大家关心的计算机网络领域，包括但不限于以下语义及协议：

• 信息包括SYN号，通过SYN号确保报文顺序性，有效性；
• 跳跃ACK号（Reply），语义是“ACK号之前的包对方也都收到了”；

.....

TCP协议还可以定义状态机、定义新的类型字段、新的语义，但是任何一方主动发出的消息，必须有Reply(ACK).

所以，目前中文互联网的所谓“原因分析”都是皮肉之象，比如“防止包乱序及可能的重连”、“确认对方有收和发的能力”.....都不是三路握手的问题的本质。因为混淆了通信技术和TCP协议，甚至对通信基本原理没有任何感知。