🌐 TCP vs UDP 传输过程可视化

深入理解两大传输层协议的核心机制与差异

TCP TCP 报文段头部结构（20字节固定 + 可选）
源端口
16 bit
+
目的端口
16 bit
+
序列号 SEQ
32 bit
+
确认号 ACK
32 bit
+
控制位 Flags
SYN/ACK/FIN/RST…
+
窗口大小
16 bit
+
校验和
16 bit
+
数据
可变长

📌 序列号+确认号实现可靠有序传输；窗口大小控制流量；Flags标志位驱动握手/挥手状态机

TCP 完整生命周期动画
① 三次握手
② 数据传输
③ 丢包重传
④ 滑动窗口
⑤ 四次挥手
速度: → 点击"开始演示"查看 TCP 完整流程
阶段一：三次握手 (Three-Way Handshake)
💻
客户端
🖥️
服务端
阶段二：可靠数据传输 + 丢包重传 (Reliability)
💻
客户端
🖥️
服务端
阶段三：滑动窗口流量控制 (Sliding Window)
💻
客户端
🖥️
服务端
阶段四：四次挥手 (Four-Way Teardown)
💻
客户端
🖥️
服务端
📊 滑动窗口状态（发送方缓冲区）
1
2
3
4
5
6
7
8
9
10
已确认 已发未确认 窗口可发 缓冲区
📋 实时日志
TCP 核心机制说明

🤝 三次握手建立连接

  • C→S: SYN(seq=x) — 请求连接
  • S→C: SYN+ACK(seq=y, ack=x+1) — 确认
  • C→S: ACK(ack=y+1) — 握手完成
  • 目的：同步 SEQ 号，验证双向可达
  • 防止历史连接干扰新连接

📦 可靠传输机制

  • 每个报文段携带序列号
  • 接收方发送 ACK 确认
  • 超时未收到 ACK → 重传
  • 快速重传：收到3个重复ACK
  • 保证数据有序、无重、无丢

🪟 滑动窗口流控

  • 发送方维护发送窗口
  • 窗口内的报文无需等ACK就可发
  • 收到ACK后窗口向右滑动
  • 接收方通告窗口大小(rwnd)
  • 防止发送速率超过接收能力

🏁 四次挥手断开连接

  • C→S: FIN — 请求关闭发送
  • S→C: ACK — 确认收到
  • S→C: FIN — 服务端也关闭
  • C→S: ACK — 最终确认
  • TIME_WAIT 等待2MSL保证可靠关闭
UDP UDP 数据报头部结构（固定 8 字节）
源端口
16 bit
+
目的端口
16 bit
+
长度
16 bit
+
校验和
16 bit（可选）
+
数据
可变长

📌 头部极简，仅8字节。无连接状态、无序列号、无确认机制，发完即走，开销极低

UDP UDP 传输特性动画
① 直接发送
② 乱序到达
③ 丢包无重传
④ 广播多播
速度: → 点击"开始演示"查看 UDP 传输特性
特性一：无连接，直接发送 (Connectionless)
📱
发送端
🖥️
接收端
特性二：乱序到达，无确认 (Unordered, No ACK)
📱
发送端
🖥️
接收端
特性三：丢包不重传，高速低延迟 (Best-Effort)
📱
发送端
🖥️
接收端
特性四：支持广播/多播 (Broadcast / Multicast)
📡
发送端
📺
R1
📺
R2
📺
R3
📬 接收端收到的报文顺序
?
?
?
?
?
⚠ 顺序不保证，重复/丢失不处理
📋 实时日志
UDP 核心机制说明

⚡ 无连接极速发送

  • 无握手，应用层直接调用 sendto()
  • 无连接建立开销，延迟极低
  • 适合实时场景（直播、游戏）
  • 头部仅 8 字节，开销极小

📭 无可靠保证

  • 数据包可能丢失，不重传
  • 数据包可能乱序到达
  • 数据包可能重复
  • 可靠性由应用层自行处理

📡 广播 / 多播支持

  • 支持一对多广播通信
  • 支持组播（多播组地址）
  • DNS、DHCP 均基于 UDP
  • TCP 不支持广播/多播

🎯 典型应用场景

  • 视频直播、音频通话（WebRTC）
  • 在线游戏（低延迟优先）
  • DNS 查询（快速一问一答）
  • QUIC 协议（UDP 上的可靠传输）
⚖️ TCP vs UDP 全面对比
特性 🔵 TCP 🟡 UDP
连接方式面向连接（三次握手）无连接
可靠性可靠，保证交付不可靠，尽力交付
有序性保证有序不保证顺序
速度/延迟较慢（握手+确认开销）极快，延迟低
头部大小20~60 字节固定 8 字节
流量控制滑动窗口机制无
拥塞控制慢启动/拥塞避免等无（应用自控）
广播/多播❌ 不支持✅ 支持
连接数一对一一对一/一对多
状态维护有连接状态（复杂）无状态（简单）
数据边界字节流（无边界）数据报（有边界）
系统资源消耗较多消耗少
🎯 使用场景推荐

🔵 适合 TCP 的场景

HTTP/HTTPS 网页 文件传输 FTP/SFTP 邮件 SMTP/IMAP 数据库连接 MySQL SSH 远程登录 API 接口调用 金融交易系统 消息队列 Kafka

🟡 适合 UDP 的场景

视频直播/语音通话 在线游戏 DNS 域名查询 DHCP 地址分配 NTP 时间同步 QUIC (HTTP/3) IoT 传感器数据 视频监控推流
🔄 TCP 连接状态机 vs UDP 状态

TCP 状态机（11个状态）

CLOSED → LISTEN → SYN_SENT → SYN_RCVD → ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → CLOSE_WAIT → LAST_ACK → TIME_WAIT → CLOSED

TIME_WAIT 持续 2×MSL（通常60s），确保对方收到最后ACK

UDP 状态（极简）

CLOSED → bind() → OPEN → 直接收发 → CLOSED

UDP 无状态机，只有端口绑定与否。内核不维护连接上下文，sendto/recvfrom 直接收发。

🔑 QUIC（HTTP/3）在 UDP 上自行实现可靠性和拥塞控制，兼顾速度与可靠

📈 TCP 拥塞控制四阶段（UDP 无此机制）
① 慢启动
cwnd 从 1 开始，每收到一个 ACK cwnd×2 指数增长，直到 ssthresh
② 拥塞避免
超过 ssthresh 后，每 RTT 将 cwnd+1，线性增长，避免网络过载
③ 快速重传
连续收到 3 个重复 ACK，立即重传丢失报文，不等超时，减少等待
④ 快速恢复
快速重传后，ssthresh=cwnd/2，cwnd=ssthresh+3，跳过慢启动直接拥塞避免