一句话总结：
三次握手就像约见面——第一次约不到人，第二次对方没回应，第三次确认没收到，最终都会因“失联”放弃！
一、第一次握手（客户端发SYN）没收到回应
情景：你发微信约朋友吃饭（SYN），但对方手机没信号（丢包）。
处理流程：
- 客户端等待：等了几秒没回复（超时时间，通常1~3秒）。
- 重试发SYN：连续重发约5次（不同系统次数不同）。
- 彻底放弃：若始终无回应，报错“连接超时”。
用户感知：浏览器显示“无法连接服务器”。
二、第二次握手（服务器发SYN-ACK）丢失
情景：朋友回复“好呀！”（SYN-ACK），但你的手机欠费（丢包）。
处理流程：
- 客户端继续等：以为对方没回复，继续重发SYN（同第一次握手）。
- 服务器苦等ACK：发送SYN-ACK后，等不到你的确认（ACK），超时后关闭连接。
结果：
- 客户端：多次重试后放弃，报错。
- 服务器：释放为这次连接预留的资源（如内存）。
三、第三次握手（客户端发ACK）丢失
情景：你确认“今晚6点见！”（ACK），但朋友手机没电（丢包）。
处理流程：
- 服务器没收到ACK：以为你没确认，反复重发SYN-ACK（约5次）。
- 客户端以为连接成功：开始发数据（如HTTP请求），但服务器不认（没收到ACK，视连接未建立）。
- 最终超时关闭：服务器放弃重试，连接未建立。
用户感知：网页卡在加载中，最终显示“连接失败”。
四、总结表
| 握手阶段 | 丢失报文 | 客户端行为 | 服务器行为 | 最终结果 |
|---|---|---|---|---|
| 第一次 | SYN | 重发SYN，超时放弃 | 无动作 | 连接失败 |
| 第二次 | SYN-ACK | 重发SYN，超时放弃 | 等待ACK超时，关闭连接 | 双方放弃 |
| 第三次 | ACK | 开始发数据（可能被忽略） | 重发SYN-ACK，超时关闭 | 连接未建立，数据丢失 |
五、为什么设计超时和重传？
- 网络不可靠：Wi-Fi断流、路由器故障、光纤被挖断...总有意外！
- 资源有限：服务器不能无限等待，避免被恶意攻击（如SYN洪水）。
六、现实案例
- Wi-Fi信号差：SYN包发不出去 → 反复重试 → 最终提示“无法连接互联网”。
- 服务器过载：SYN-ACK包处理慢 → 客户端超时放弃 → 用户刷新页面。
总结口诀
“三次握手怕丢包，每次丢失有妙招。
一丢SYN客户端重试，二丢SYN-ACK两边消。
三丢ACK最麻烦，服务器苦等你发飙。
超时重传是底线，网络可靠靠这招！”
