【网络编程】TCP、UDP、KCP、QUIC 全面解析

在网络编程和协议学习的过程中，我们经常听到 TCP、UDP、KCP、QUIC 这几个名字。TCP 和 UDP 大家比较熟悉，而 KCP 和 QUIC 则常常让人摸不着头脑：它们到底是什么？和 TCP/UDP 有什么关系？应用场景又在哪里？本文将系统梳理这几个协议，重点解释 KCP 和 QUIC 的原理与运行流程。

一、TCP 与 UDP 回顾

1. TCP（Transmission Control Protocol）

特点：

• 面向连接：通信前必须"三次握手"建立连接。

• 可靠传输 ：通过 确认机制（ACK） 和 重传机制 保证数据不会丢。

• 有序性：接收端收到的数据严格按照发送顺序排列。

• 字节流：应用层看到的是一条连续的字节流，而不是一段一段的消息。

核心机制：

• 三次握手：确保双方收发能力正常，并同步初始序列号。

• 滑动窗口：决定发送端可以连续发多少数据而不用等待确认。

• 超时重传：一段时间没收到 ACK，就认为丢了，重新发。

• 流量控制：根据接收方缓冲区大小，避免"塞爆"。

• 拥塞控制：根据网络情况（丢包、延迟），动态调整发送速度（慢启动、拥塞避免、快速恢复等）。

应用场景：

网页浏览（HTTP/1.1、HTTP/2）、文件传输（FTP）、邮件（SMTP/IMAP）、数据库交互。

缺点：

• 不保证可靠性，需要上层协议（比如 KCP、QUIC）自己补全。

• 在复杂网络环境（丢包严重、延迟波动）下，应用必须实现一整套可靠机制。

👉 小结：UDP 就像"快递丢了不管"，快但不稳；适合追求低延迟、能容忍少量丢包的应用。

2. UDP（User Datagram Protocol）

特点：

• 无连接：直接发，不需要握手。

• 不可靠：不保证数据一定到达，不保证顺序。

• 报文传输：一发一收，应用收到的数据就是一个完整报文，不会被拼接或拆分。

机制：

• 没有流量控制、没有拥塞控制；

• 丢包、乱序需要应用自己处理；

• 头部开销小（只有 8 字节），更轻量。

应用场景：

• 实时性要求高：语音通话（VoIP）、视频会议（Zoom、Teams）、在线游戏、直播。

• 广播/多播：如 DHCP、组播视频流。

缺点：

• 不保证可靠性，需要上层协议（比如 KCP、QUIC）自己补全。

• 在复杂网络环境（丢包严重、延迟波动）下，应用必须实现一整套可靠机制。

👉 小结：UDP 就像"快递丢了不管"，快但不稳；适合追求低延迟、能容忍少量丢包的应用。

二、KCP 协议

1. KCP 是什么？

KCP 是一个 基于 UDP 的可靠传输协议库，由开源社区开发，目标是：

• 在不改变 UDP 基础的前提下，提供类似 TCP 的可靠性，

• 并且比 TCP 更灵活，能调节"延迟 vs 吞吐"。

• 用于需要低延迟、可控性强的场景，比如 内网穿透（frp）、游戏加速器、实时应用。

一句话：KCP 就是"用 UDP 自己实现了一套 TCP，但更灵活可调"。

2. KCP 的核心机制

• 滑动窗口：和 TCP 类似，保证数据有序收发。

• UNA（Unacknowledged Number）+ ACK：确认机制，告诉对方哪些包收到了，哪些还没到。

• 快速重传：比 TCP 更激进，丢包时无需等超时，减少等待延迟。

• 流模式/报文模式：

  • 流模式：像 TCP 一样，数据看作连续字节流。

  • 报文模式：像 UDP 一样，保留消息边界，一次 send 对应一次 recv。

3. KCP 的运行流程

• kcp_create：创建一个会话，绑定到某个 UDP socket。

• kcp_input：接收 UDP 收到的数据包，交给 KCP 协议层解析（分 ACK、DATA）。

• kcp_update：定时调用，驱动协议逻辑（发送、重传、窗口滑动、超时检测）。

• kcp_send：应用层发送数据，KCP 会负责分片、编号、缓存。

• kcp_recv：应用层接收数据，KCP 会自动重组有序数据，交付给应用。

总结：KCP 就是"用 UDP 自己实现了一套 TCP，但更灵活可调"。

4. KCP 的详细逻辑

• 发送端 ：应用层调用 kcp_send → 数据被拆分成片段 → 进入发送队列 → kcp_update 驱动发送 → 等待对方 ACK。

• 接收端 ：UDP 收到数据 → kcp_input 解析 → 按序放入接收缓冲 → 有序数据进入接收队列 → 应用层 kcp_recv 拿到完整数据。

• 重传机制：既有超时重传（RTO），也有快速重传（fastresend），保证低延迟场景下更快恢复。

• 窗口管理：动态调节发送和接收窗口，避免对方来不及处理。

5. 总结

• KCP 相当于 "用户态的 TCP"，但比 TCP 更灵活、更可调。

• 它依赖应用层定时驱动（kcp_update），不像 TCP 那样完全交给内核。

• 在低延迟、对网络质量敏感的场景（游戏、语音、远程访问）里，KCP 往往比 TCP 表现更好。

三、QUIC 协议

1. QUIC 是什么？

QUIC（Quick UDP Internet Connections）是 Google 提出的基于 UDP 的新一代传输协议 ，后来被 IETF 标准化为 RFC 9000。

它的目标就是：

• 保留 TCP 的可靠性（丢包重传、有序交付）；

• 结合 UDP 的灵活性（没有三次握手、内核限制少）；

• 直接集成了 TLS 加密（默认就是 HTTPS 的安全等级）；

• 针对现代网络（WiFi、4G/5G、移动切换）优化。

2. QUIC 的核心原理

要理解 QUIC，我们把它和 TCP 对比：

(1) 建立连接更快

• TCP：需要三次握手 + TLS 握手 → 至少 2-3 个 RTT（往返时延）。

• QUIC：握手时就内置 TLS，1 RTT 就能建立安全连接，有时甚至 0 RTT（之前有缓存时）。

👉举例：你点开一个 HTTPS 网站，用 TCP+TLS 可能要 100ms 才能真正开始传数据；用 QUIC 可能只要 30-50ms。

(2) 多路复用，避免队头阻塞

• TCP：一个连接里只有一条数据流，如果一个包丢了，后面的数据都得等（队头阻塞）。

• QUIC：一个连接里可以开很多条独立的流，某条流丢了包，不影响别的流继续传。

👉举例：你在看视频（流1），同时加载弹幕（流2），TCP 下弹幕丢了包，视频也得卡住；QUIC 下只影响弹幕，不影响视频。

(3) 内置加密

• TCP：需要额外结合 TLS 才能安全。

• QUIC：协议本身就强制加密（TLS 1.3），没有"明文 QUIC"。

(4) 支持快速切换网络

• TCP：换 WiFi、切 4G → 连接断开，需要重建。

• QUIC：连接 ID 跟 IP、端口解耦，切网络时还能继续用，不用重连。

👉举例：你在地铁上看视频，4G 信号掉了切到 WiFi，TCP 需要重新建立连接，QUIC 可以无感知继续播。

3. QUIC 的运行流程

1. 握手：

   • Client 发起连接，带上 TLS 初始握手数据。

   • Server 回复 TLS 数据，确认连接建立。

   • 1 RTT 完成加密建连，甚至 0 RTT 直接开始传数据。

2. 数据传输：

   • 基于 UDP 包，但 QUIC 内部有序列号、确认号，保证可靠性。

   • 每条流独立传输，不会因丢一个包阻塞整个连接。

3. 重传与拥塞控制：

   • 内置 TCP 类似的机制，但更灵活，能快速更新。

4. QUIC 的应用场景

• HTTP/3：目前 Chrome、Safari、Firefox、YouTube、Facebook 都在用。

• 实时通信：比如视频会议、在线游戏，比 TCP 延迟更低。

• 弱网环境：移动网络频繁切换时，QUIC 比 TCP 更稳定。

0voice · GitHub