UDP 与 QUIC¶

学习目标¶

学完本章后，学习者应该能够：

理解 UDP 的特点和适用场景。
知道 UDP 为什么需要应用层处理丢包、乱序和重传。
理解 QUIC 的基本目标和它与 HTTP/3 的关系。
能判断什么时候不应该用 UDP。

UDP 的特点¶

UDP 是无连接、不保证可靠、不保证顺序的传输协议。

特点：

头部简单。
无连接握手。
延迟低。
不保证送达。
不保证顺序。
不做拥塞控制。

UDP 不是“更快的 TCP”，而是把可靠性、顺序、拥塞控制等责任交给应用层。

UDP 适用场景¶

常见场景：

DNS 查询。
实时音视频。
游戏同步。
指标或日志采样上报。
自定义可靠协议的底层传输。

如果业务不能接受丢包、乱序、重复，就要在应用层补机制，或者直接使用 TCP / HTTP / gRPC。

QUIC 与 HTTP/3¶

QUIC 是基于 UDP 的传输协议，目标是改善 TCP + TLS + HTTP/2 的一些问题。

它提供：

内置 TLS 加密。
更快连接建立。
多路复用。
减少队头阻塞。
连接迁移。

HTTP/3 基于 QUIC。对后端工程师来说，先理解它解决的问题即可，不必一开始深入所有细节。

Go 后端实际应用例子¶

例子一：UDP 指标上报要能接受丢失¶

func SendMetric(addr string, msg []byte) error {
    conn, err := net.Dial("udp", addr)
    if err != nil {
        return err
    }
    defer conn.Close()

    _, err = conn.Write(msg)
    return err
}

这类上报适合“不要求每条都到达”的场景。如果是订单状态、账单、审计日志，就不应该用裸 UDP。

例子二：应用层加序号¶

type Packet struct {
    Seq  uint64
    Body []byte
}

如果应用需要识别乱序或重复，就要增加序号、ACK、重传、超时和窗口等机制。复杂度会迅速接近重新实现一部分可靠传输。

常见误区¶

误区一：UDP 一定比 TCP 快。

UDP 少了连接和可靠性机制，但应用如果自己补可靠性，复杂度和成本会回来。

误区二：UDP 不会拥塞。

UDP 本身不做拥塞控制，不代表网络不会拥塞。应用不控制发送速率可能伤害自己和别人。

误区三：QUIC 就是普通 UDP。

QUIC 基于 UDP，但在应用层实现了加密、可靠传输、多路复用和拥塞控制等能力。

线上问题案例¶

某服务用 UDP 上报业务关键事件，后来发现少量事件丢失导致统计对不上。根因是 UDP 不保证到达，网络抖动时数据包丢失，应用没有 ACK 和重试。

修复方式是把关键事件改为 Kafka / HTTP / gRPC 等可靠链路，UDP 只保留用于可丢弃指标采样。

实战任务¶

判断下面场景是否适合 UDP，并说明原因：

用户登录审计日志。
实时游戏位置同步。
支付结果通知。
QPS 采样指标上报。

参考答案

用户登录审计日志和支付结果通知通常不适合裸 UDP，因为它们要求可靠、可追溯、可重试。实时游戏位置同步可以考虑 UDP，因为旧位置丢失后新位置更有价值，低延迟比绝对可靠更重要。

QPS 采样指标上报可以考虑 UDP，因为少量丢失通常不影响趋势判断。但如果指标用于结算、审计或告警闭环，就需要更可靠的传输方式。

面试题¶

1. UDP 和 TCP 最大区别是什么？¶

参考答案

TCP 是面向连接、可靠、有序的字节流协议；UDP 是无连接、不保证可靠、不保证顺序的数据报协议。

TCP 帮应用处理重传、排序、流量控制和拥塞控制；UDP 更轻量，但这些能力需要应用自己决定是否实现。

2. 什么场景适合 UDP？¶

参考答案

适合 UDP 的场景通常能接受少量丢包，或者更看重低延迟和实时性，例如 DNS、实时音视频、游戏同步、指标采样上报。

如果业务需要强可靠、严格顺序、审计追踪，通常不应该直接使用裸 UDP。

3. QUIC 解决了哪些问题？¶

参考答案

QUIC 基于 UDP，在传输层之上实现加密、可靠传输、多路复用、拥塞控制和连接迁移。它可以减少连接建立成本，并缓解 TCP 层面的队头阻塞。

HTTP/3 基于 QUIC，用来改进 HTTP/2 在部分网络场景下的表现。