协议

TCP 三次握手

⚠️ 异常场景:第二次握手丢包
模拟服务端发出 SYN-ACK 但客户端未收到的情况,观察 TCP 如何通过超时重传机制恢复连接。
1️⃣
客户端发送 SYN → 服务端正常收到
SYN=1, seq=100  |  客户端进入 SYN_SENT
✂️
服务端回复 SYN-ACK ← 网络丢包!
SYN=1, ACK=1, seq=300, ack=101  |  报文在途中丢失,客户端收不到
⏱️
客户端等待超时(约 1s),触发超时重传
RTO(Retransmission Timeout)到期,客户端重新发送 SYN=1, seq=100
🔁
服务端再次回复 SYN-ACK
服务端仍处于 SYN_RCVD,收到重传 SYN 后重新回复,流程继续
客户端发送 ACK,连接最终建立
若重传次数超过 SYN_RETRIES(默认 6 次)仍失败,连接彻底放弃,报 ETIMEDOUT
💻
客户端
192.168.1.100
数据报(无连接)
🖥
服务端
93.184.216.34:53
💨 UDP 不握手、不确认、不重传。直接发出数据报,对方能不能收到不管。
延迟极低,适合 DNS 查询、视频直播、在线游戏等对实时性要求高的场景。
维度TCP(当前)UDP(对比)
连接建立三次握手无需握手
可靠性确认 + 重传不保证到达
顺序保证有序乱序可能
速度较慢(开销大)极快(无状态)
适用场景HTTP / 文件传输DNS / 直播 / 游戏
当前步骤解读
客户端随机选择初始序列号(ISN=100),发送 SYN 报文向服务端请求建立连接。此时客户端进入 SYN_SENT 状态,等待服务端响应。
🔧 自定义参数 客户端 ISN = 服务端 ISN = 修改 seq 值后点"应用",动画标签和字段表将自动推导更新