TCP、UDP 与 QUIC：为什么 HTTP/3 要基于 UDP

前言

TCP 和 UDP 都是传输层协议，都能解决：

1	把数据交给目标主机上的哪个进程。

但它们的取舍完全不同：

1 2	TCP：连接、可靠、有序、字节流 UDP：无连接、不保证可靠、不保证有序、数据报

再往后看，HTTP/3 又选择基于 QUIC，而 QUIC 基于 UDP。

这篇文章就围绕三件事展开：

TCP 和 UDP 到底差在哪。
为什么 DNS、音视频、游戏常用 UDP。
为什么 QUIC / HTTP/3 会基于 UDP。

1. TCP 和 UDP 都属于传输层

IP 只能找到目标主机。

传输层要进一步解决：

1	目标主机上的哪个进程？

这就是端口的作用。

TCP 有端口：

1
2
3

443：HTTPS
80：HTTP
22：SSH

UDP 也有端口：

1 2	53：DNS 443：QUIC / HTTP/3

所以 TCP 和 UDP 的共同点是：

1	都通过端口把数据交给具体进程。

区别在于它们提供的传输能力不同。

2. TCP 的取舍：可靠、有序、成本更高

TCP 提供的是：

面向连接
可靠传输
有序交付
字节流
流量控制
拥塞控制

TCP 会做很多事情：

三次握手建立连接
用 Seq / ACK 确认数据
丢包后重传
乱序后重排
重复数据去重
滑动窗口提高效率
流量控制保护接收方
拥塞控制保护网络
四次挥手关闭连接

这让 TCP 很适合：

网页请求
文件下载
接口请求
邮件
SSH

这些场景通常要求：

1
2
3

数据完整
顺序正确
不能悄悄丢一段

代价是：

连接建立有成本
协议机制更复杂
延迟相对更高
丢包时可能阻塞后续数据

3. UDP 的取舍：简单、低延迟、应用自己控制

UDP 更简单。

UDP 报文主要包含：

源端口
目标端口
长度
校验和

UDP 不做：

不三次握手
不保证送达
不保证顺序
不自动重传
不做 TCP 那种流量控制
不做 TCP 那种拥塞控制

它更像：

1	我把这个数据报发出去，后面你自己决定怎么处理。

这不是“低级版 TCP”，而是另一种取舍。

UDP 的优势是：

开销小
延迟低
数据报边界清晰
应用层控制空间更大

4. 字节流和数据报的区别

TCP 是字节流协议。

应用写入：

1 2	write("Hello") write("World")

接收方可能读到：

1	HelloWorld

也可能分几次读到：

1 2	Hel loWorld

TCP 不保留应用消息边界。

UDP 是数据报协议。

应用发送：

1
2
3

send("A")
send("B")
send("C")

接收方看到的是一个个数据报：

1
2
3

A
B
C

但这些数据报可能：

1
2
3

丢失
乱序
重复

所以：

1 2	TCP 保证连续字节流 UDP 保留数据报边界，但不保证可靠

5. 为什么 DNS 常用 UDP

DNS 查询通常很小。

比如：

1 2	问：example.com 的 IP 是什么？答：93.184.216.34

如果每次 DNS 查询都走 TCP，需要：

三次握手
发送查询
接收响应
关闭或复用连接

成本更高。

UDP 可以直接：

1 2	发一个查询数据报收一个响应数据报

延迟更低，开销更小。

但 DNS 不是只能用 UDP。

这些情况可能用 TCP：

响应太大
区域传送
DNS over TCP
一些安全或可靠性需求

6. 为什么音视频常用 UDP

实时音视频更怕：

1
2
3

卡顿
延迟
等待重传

如果某一小段语音丢了，等它重传回来可能已经过时。

比如：

1 2	第 10 帧丢了第 11、12、13 帧到了

TCP 为了保证有序，可能会卡住后面的数据，等待第 10 帧重传。

但实时音视频可能更愿意：

1 2	跳过第 10 帧继续播放第 11、12、13 帧

所以音视频常用 UDP，然后在应用层自己做：

抖动缓冲
丢包补偿
前向纠错
关键帧
码率调整
选择性重传

也就是说：

UDP 不是让应用什么都不管，而是把“哪些要补、哪些要跳过”的选择权交给应用。

7. 为什么游戏常用 UDP

游戏同步也很重视实时性。

比如玩家位置：

1
2
3

第 1 次位置：x = 10
第 2 次位置：x = 12
第 3 次位置：x = 15

如果第 1 次位置丢了，但第 2、第 3 次到了，旧位置可能已经没价值。

TCP 为了补旧包而卡住新状态，反而会让游戏体验更差。

所以游戏常用 UDP，把可靠性和同步策略交给应用层自己控制。

8. HTTP/2 的问题：TCP 层队头阻塞

HTTP/2 已经支持应用层多路复用。

它可以在一条 TCP 连接里同时传多个 HTTP Stream：

1
2
3

Stream 1：HTML
Stream 3：CSS
Stream 5：JS

这些 Stream 可以交错发送。

但底层还是 TCP。

TCP 是可靠、有序的字节流。

一旦某个 TCP 包丢了：

包 1 到了
包 2 丢了
包 3 到了
包 4 到了

TCP 必须等包 2 重传成功，才能继续向上交付包 3、包 4。

所以：

1 2	HTTP/2 解决了应用层请求排队但仍受 TCP 层队头阻塞影响

9. QUIC 为什么基于 UDP

如果 QUIC 基于 TCP，就很难绕开 TCP 的有序字节流限制。

TCP 的核心逻辑在操作系统内核里：

连接管理
可靠传输
拥塞控制
有序交付

应用层很难改变 TCP 的行为。

UDP 很薄，只提供：

1
2
3

端口
数据报
校验和

所以 QUIC 选择基于 UDP，在用户态自己实现：

连接管理
可靠传输
多路复用
拥塞控制
TLS 加密
连接迁移

这句话很重要：

UDP 不可靠，但 QUIC 在 UDP 之上自己实现可靠。

10. QUIC 怎么改进多路复用

HTTP/2 的多个 Stream 共用一条 TCP 字节流。

如果 TCP 层丢包，所有 Stream 都可能被影响。

QUIC 也有 Stream，但 QUIC 的 Stream 在传输层实现。

如果某个 Stream 丢包：

1
2
3

Stream 1 丢了一个包
Stream 3 正常
Stream 5 正常

QUIC 可以只阻塞 Stream 1，不影响 Stream 3、Stream 5 继续交付。

所以：

1 2	HTTP/2：应用层多路复用，但底层是 TCP 单字节流 HTTP/3：基于 QUIC，让传输层也支持更独立的多路复用

11. QUIC 建连为什么更快

HTTPS over TCP 通常需要：

TCP 三次握手
  ↓
TLS 握手
  ↓
HTTP 请求

连接握手和加密握手是两套流程。

QUIC 把传输握手和 TLS 1.3 加密握手整合在一起。

所以新连接通常可以更快开始传输数据。

对于已经连接过的服务，还可以使用 0-RTT：

更快发送早期数据

不过 0-RTT 有重放风险，不是所有请求都适合。

12. QUIC 为什么移动网络切换更稳

TCP 连接通常由四元组标识：

源 IP
源端口
目标 IP
目标端口

如果你从 Wi-Fi 切到 4G：

源 IP 变了

TCP 连接通常就断了，需要重连。

QUIC 使用 Connection ID 标识连接。

即使网络切换导致 IP 和端口变化，只要 Connection ID 还有效，QUIC 就可以尝试保持连接迁移。

这对移动设备很重要。

13. 为什么不是所有东西都用 QUIC

QUIC 很强，但不是没有成本。

它带来：

实现复杂
服务器和客户端都要支持
运维、观测、调试更复杂
某些网络设备可能限制 UDP
CPU 加密和协议处理成本更高

所以现实中常见是：

1	HTTP/1.1、HTTP/2、HTTP/3 共存

浏览器会根据服务端支持情况协商使用哪个版本。

14. TCP、UDP、QUIC 对比

对比	TCP	UDP	QUIC
所在层次	传输层	传输层	基于 UDP 的传输协议
连接	面向连接	无连接	有连接概念
可靠性	保证可靠	不保证	自己实现可靠
顺序	保证字节流有序	不保证	Stream 内有序，Stream 间更独立
数据形态	字节流	数据报	Stream + 数据报底座
多路复用	TCP 本身不懂 HTTP Stream	无	原生支持多 Stream
加密	依赖 TLS	无内置	集成 TLS 1.3
典型场景	HTTP/1.1、HTTP/2、文件传输	DNS、音视频、游戏	HTTP/3

15. 一句话总结

可以这样记：

1
2
3

TCP：帮你把可靠、有序做好，但成本更高。
UDP：只负责把数据报尽快发出去，可靠性由应用决定。
QUIC：基于 UDP，自己实现可靠、多路复用、加密和连接迁移。

HTTP 演进也可以这样看：

1
2
3

HTTP/1.1：多个请求容易排队
HTTP/2：应用层多路复用，但受 TCP 队头阻塞影响
HTTP/3：基于 QUIC，把多路复用、可靠性和加密搬到 UDP 之上重新实现

最短记法：

QUIC 不是相信 UDP 可靠，而是利用 UDP 简单，把现代传输能力自己做了一遍。