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两步 + 消息合并。
采用单条回复，可以实现99%的容错，但因为两军问题，任何信道不可能实现100%的有效性。
通信技术，关心的是一条消息如何被正确传递。例如上述Send/Reply模型，描述通信的最基本单元-单条消息的传递流程。适用于所有领域，属于通用的泛化的规则。
而协议，描述的则是消息的内容、格式，以及多条消息之间如何交互，是和应用领域相关的。例如：没有Reply意味着什么，Reply可以是什么样的信息格式，不同的格式代表什么含义，不同的格式下采用什么行为…
例如在航空通信，塔台向客机发送指令的协议：
- 需要先报航班号，采用军队电文报数，之后是方位角、高度、行为等指令；
- 航班必须在相同频率下先回复参数，最后附加航班号
上海管制区PVG进近塔台：东方三两幺拐，航向187度上3000保持！
MU3217机长：航向187度上3000保持，东方三两幺拐！
指令格式可以自定义，但塔台发出的指令，必须有Reply。
再比如在大家关心的计算机网络领域，包括但不限于以下语义及协议：
- 信息包括SYN号，通过SYN号确保报文顺序性，有效性；
- 跳跃ACK号（Reply），语义是“ACK号之前的包对方也都收到了”；
…..
所以，目前中文互联网的所谓“原因分析”都是皮肉之象，比如“防止包乱序及可能的重连”、“确认对方有收和发的能力”…..都不是三路握手的问题的本质。因为混淆了通信技术和TCP协议，甚至对通信基本原理没有任何感知。