UDP 与 QUIC 协议
校招考察频度：☆ 中频（协议演进·传输层创新） 生产导向主线：UDP 常被初学者误解为“不可靠所以没用”。但在现代工业界，UDP 不仅主导了音视频实时通话（WebRTC）、DNS 查询、竞技游戏帧同步，更是下一代互联网协议 HTTP/3（QUIC） 的地基。面试核心：TCP vs UDP 本质权衡、HTTP/2 遇丢包引发的 TCP 队头阻塞，以及 QUIC 如何在 UDP 之上重建可靠性并实现连接迁移与 0-RTT 极速握手。
一、TCP vs UDP 工业级权衡
| 维度 | TCP | UDP | 生产业务选型依据 |
|---|---|---|---|
| 连接机制 | 面向连接（三次握手、四次挥手） | 无连接（发包前不需要打招呼） | UDP 建立连接延迟为 0 |
| 可靠性保证 | 强可靠（序号、ACK 确认、超时重传、滑动窗口流量控制） | 尽力而为（Best-effort），不保证送达、不重传、不保序 | 金融交易/网页文本选 TCP；丢一帧无所谓的音视频通话选 UDP |
| 报文边界 | 面向字节流（无边界，存在粘包/半包问题） | 面向报文（保留消息边界，发多大收多大） | UDP 应用层解析极其简单，无需处理分包粘包 |
| 协议头开销 | 至少 20 字节，带选项可达 60 字节 | 固定的 8 字节（源端口、目的端口、长度、校验和） | IoT 物联网与海量小包场景极度省流量 |
| 拥塞与流控 | 内核强制拥塞控制（丢包主动减速） | 无拥塞控制，应用层爱发多快发多快 | 实时竞技游戏（王者荣耀/吃鸡）宁可丢包也绝不能降速卡顿 |
二、为什么 HTTP/3 选择基于 UDP 的 QUIC？
HTTP/2 虽然在一个 TCP 连接上实现了多个请求流的多路复用（Multiplexing），但它暴露了底层 TCP 的致命弱点：
1. TCP 层的队头阻塞（HOL Blocking）
- 在弱网环境下（如移动设备切换 WiFi），只要 TCP 丢了 1 个数据包，即使其他流的数据包已经全部安全到达网卡，操作系统内核也必须将整个 TCP 连接全部挂起阻塞，等待那个丢失的数据包重传成功后才能向上交付！
- 结果：丢一个包，HTTP/2 上并行的所有 100 个请求同时卡死，性能还不如多个独立的 HTTP/1.1 连接！
2. QUIC 在应用层解决队头阻塞
- QUIC（Quick UDP Internet Connections） 绕过了内核僵化的 TCP 实现，在 用户态基于 UDP 重新实现了可靠传输：
- 独立的 Stream 机制：每个 HTTP 请求对应一个独立的 Stream ID。Stream 1 丢包，内核直接放行后面的包给 Stream 2 处理，彻底解开了流之间的相互影响！
HTTP/2 over TCP:
TCP Packet: [Stream 1 (丢包!)] [Stream 2] [Stream 3]
|
整个 TCP 连接阻塞! 2 和 3 被连累卡死等待重传!
HTTP/3 over QUIC (UDP):
UDP Packet: [Stream 1 帧 (丢包!)]
UDP Packet: [Stream 2 帧 (正常)] ---> 应用层立即处理 Stream 2! 互不干扰!三、QUIC 的两大杀手锏
1. 0-RTT 极速建连
- 传统 HTTPS（TCP + TLS 1.2）需要 3 个 RTT（往返耗时） 才能开始传输首字节数据；即使 TLS 1.3 也需要 2 个 RTT。
- QUIC 将传输层握手与加密层握手合二为一：
- 首次连接：1-RTT 搞定连接与 TLS 1.3 协商。
- 再次访问（Session Resumption）：0-RTT！客户端在发送第 1 个包时就直接夹带加密的 HTTP GET 请求，首字延迟（TTFT）逼近物理光速极限！
2. 连接迁移（Connection Migration）
- 传统 TCP 的连接标识：由四元组唯一确定
{源 IP, 源端口, 目的 IP, 目的端口}。当用户走出家门，手机从 WiFi 切换到 5G 移动蜂窝网络时，手机的 IP 地址发生了改变，原有的所有 TCP 连接全部断开报废，必须重新经历三次握手！ - QUIC 的连接标识：不再绑定 IP 和端口，而是使用随机生成的 64 位 Connection ID。即使手机从 WiFi 切换到 5G 导致源 IP 突变，只要 Connection ID 不变，连接依然无感存活，视频通话与游戏零卡顿、零断线重连。
面试高频追问
- UDP 既然不可靠，为什么实时音视频（如腾讯会议）都用它？
- 音视频对“时延”的要求远远高于“完整性”。如果用 TCP，丢一个音频包就会触发重传等待，导致几十毫秒的声音静音或画面卡顿，随后连续播放变快。
- 用 UDP 配合应用层 FEC（前向纠错，多发 20% 冗余包）和丢包补偿算法，即使丢一帧画面人眼也察觉不到，能换来极其丝滑的低延迟体验。
- HTTP/3 为什么不直接在内核修改 TCP，非要在 UDP 上搞 QUIC？
- 协议僵化（Protocol Ossification）：全球无数的企业路由器、防火墙、运营商网关只认老旧的 TCP 报文格式，在内核修改 TCP 会被中间设备大量误判拦截。
- 升级成本极高：修改 TCP 需要全世界所有操作系统的内核升级（耗时十几年）；而 QUIC 是应用层/用户态实现的，跟随浏览器或 Nginx/Caddy 客户端软件一次发布即可瞬间普及。