1. QUIC 协议基础回顾：从 TCP 到 QUIC 的演进

各位同学好，我是你们的讲师。今天咱们开始第一讲，聊聊 QUIC 协议的基础。说实话，我接触 QUIC 也有五六年了，从它还是 Google 内部实验项目的时候就开始关注。那时候很多人觉得它是个「玩具」，现在呢？HTTP/3 都标准化了，CDN 厂商全在推。嗯，变化真快。

这一章我们不讲太深，先把地基打牢。我会带着大家从 TCP 的痛点出发，看看 QUIC 是怎么一步步「进化」过来的，以及它和 HTTP/3 到底是什么关系。

先问一个问题：TCP 用了这么多年，为什么突然要换？

我个人习惯把 TCP 的问题归纳为「三座大山」：

连接建立慢：三次握手 + TLS 握手，至少 2-RTT 才能发数据。移动网络下，这 2 个往返可能就 200ms 出去了。
队头阻塞（HOL）：TCP 是严格有序的，一个包丢了，后面所有包都得等着。我在项目中遇到过，一个视频流因为一个丢包，整个画面卡住 2 秒，用户体验极差。
连接迁移困难：TCP 靠 IP:Port 标识连接。你从 WiFi 切到 4G，IP 变了，连接就断了。这在移动端简直是噩梦。

核心矛盾：TCP 是为「有线、稳定、低延迟」网络设计的。而今天的网络是「无线、高丢包、频繁切换」的。用旧时代的协议解决新时代的问题，注定要打补丁。

QUIC 的演进路径其实很有意思。我简单梳理一下：

说白了，QUIC 不是凭空冒出来的。它把 TCP 的可靠性、TLS 的安全性、UDP 的低延迟，以及 HTTP/2 的多路复用，全部揉在一起，在用户态实现了一个全新的传输协议。

QUIC 的特性很多，但最核心的就三个。我一个个说。

这是 QUIC 最吸引人的特性之一。什么叫 0-RTT？就是客户端第一次连接后，第二次再连，可以直接发数据，不需要握手。

为什么会这样？因为 QUIC 把连接信息和加密状态缓存到了客户端。下次连接时，客户端直接带着「上次的凭证」发请求，服务端验证通过就处理。

避坑指南：我曾经在生产环境遇到过 0-RTT 重放攻击的问题。简单说，攻击者截获了 0-RTT 数据包，重复发送给服务端。如果你的接口不是幂等的，就会出大问题。解决方案是：对非幂等请求禁用 0-RTT，或者使用 QUIC 的 replay protection 机制。

这个特性我特别喜欢。QUIC 用 Connection ID（连接 ID）来标识连接，而不是 IP:Port。所以当你从 WiFi 切到 4G 时，IP 变了，但 Connection ID 没变，连接还在。

你想想看，这在移动端有多重要。用户在地铁上，信号断断续续，WiFi 和蜂窝网络来回切换。用 TCP，每次切换都要重连，重连就要重新握手。用 QUIC，连接无缝迁移，用户根本感觉不到。

HTTP/2 也有多路复用，但它有个致命问题：TCP 层面的队头阻塞。因为 HTTP/2 的多个流共享一个 TCP 连接，一旦某个流丢包，TCP 会阻塞所有流。

QUIC 怎么解决的？它在 UDP 之上自己实现了多流机制。每个流独立传输，一个流丢包只影响它自己，其他流照常跑。

一句话总结：TCP 的多路复用是「伪并行」，QUIC 的多路复用是「真并行」。

很多人搞混这两个概念。我直接说结论：

它们的关系，就像 TCP 和 HTTP/2 的关系。HTTP/3 跑在 QUIC 之上，QUIC 为 HTTP/3 提供传输服务。

我记得有一次面试，候选人说「QUIC 就是 HTTP/3」。我纠正了他：QUIC 可以跑任何应用层协议，比如 DNS over QUIC、SMB over QUIC。HTTP/3 只是 QUIC 最著名的「用户」而已。

注意：虽然 QUIC 和 HTTP/3 是分开的，但在实际部署中，它们通常一起出现。你配置 Nginx 或 Caddy 的 HTTP/3 支持时，底层会自动启用 QUIC。

下面这张图，我把本章的核心逻辑画出来了。你可以把它当作「QUIC 入门地图」：

好了，第一讲的内容就这些。我们回顾一下重点：