在网络编程和协议学习的过程中，我们经常听到 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 的运行流程
握手：
Client 发起连接，带上 TLS 初始握手数据。
Server 回复 TLS 数据，确认连接建立。
1 RTT 完成加密建连，甚至 0 RTT 直接开始传数据。
数据传输：
基于 UDP 包，但 QUIC 内部有序列号、确认号，保证可靠性。
每条流独立传输，不会因丢一个包阻塞整个连接。
重传与拥塞控制：
内置 TCP 类似的机制，但更灵活，能快速更新。
4. QUIC 的应用场景
HTTP/3：目前 Chrome、Safari、Firefox、YouTube、Facebook 都在用。
实时通信：比如视频会议、在线游戏，比 TCP 延迟更低。
弱网环境：移动网络频繁切换时，QUIC 比 TCP 更稳定。