谁跑在 UDP 上
UDP 无连接、不保证到达与顺序，头只有 8 字节，正因为够轻才被大量协议当作底座：DNS 用小包一问一答，DHCP 靠广播发现地址，QUIC 在用户态自己实现可靠传输，VXLAN 用它封装二层帧，WireGuard 用它承载加密隧道。分清「哪类协议在 UDP 上做了什么」，才能判断故障出在应用、封装还是中间设备。
基本信息
| 协议特征 | 无连接、无序、无重传，头部仅 8 字节，开销小 |
|---|---|
| 适合场景 | 一问一答式短交互、实时媒体、批量小包监控、自建可靠性的场景 |
| 常见承载 | 内网隧道、覆盖网络、服务发现、日志与指标上报 |
| 故障特征 | 丢包不会自动重传，中间设备限速或拦截往往静默生效 |
| 缓冲参数 | net.ipv4.udp_mem、net.core.rmem_max 决定接收能力 |
典型使用场景
- 排查 DNS 偶发超时：确认 53/UDP 是否被限速或丢弃，必要时改用 TCP 回退
- 数据中心 VXLAN 大包丢失：检查底层 MTU 与物理链路丢包
- 音视频卡顿定位：RTP 走 UDP，只能靠丢包率与抖动判断，不能指望重传
- 部署 WireGuard 后性能不达标：确认 51820/UDP 是否被运营商限速或整形
- SNMP 轮询大量设备出现丢包：调整超时与重试，或改用采集器批量拉取
- 自研协议选型：先判断能否直接复用 QUIC 等成熟实现而不是从零造
最小示例
最小示例
tcpdump -nn -i any port 53 -c 5 # 观察 DNS 请求与响应
tcpdump -nn -i any udp port 4789 -c 5 # 观察 VXLAN 封装流量
ss -uanp | head -20 # 列出本机 UDP 套接字
ss -su # UDP 汇总统计，重点看 receive errors
sysctl net.core.rmem_max net.core.rmem_default # UDP 接收缓冲上限
sysctl -w net.ipv4.udp_mem='4096 87380 16777216' # 放宽全局 UDP 内存常见 UDP 协议速查
| 协议 | 端口 | 关键点 |
|---|---|---|
| DNS | 53 | UDP 优先，响应过大被截断时转 TCP |
| DHCP | 67 / 68 | 广播发现，依赖租约与中继代理 |
| QUIC 与 HTTP/3 | 443 | 用户态可靠传输加 TLS 1.3，多路复用无队头阻塞 |
| VXLAN | 4789 | 数据中心 Overlay，用 UDP 封装二层帧 |
| WireGuard | 51820 | 加密 VPN，内核态实现，配置极简 |
| RTP 与 RTCP | 动态端口 | 音视频媒体流，丢包容忍优先于重传 |
| SNMP | 161 / 162 | 设备监控，超时重传由管理端控制 |
UDP 接收缓冲溢出时内核静默丢包：ss -su 的 receive errors 增长就是信号。高并发 DNS、syslog 接收端要同时调大 udp_mem 与应用套接字缓冲。
隧道类 UDP 流量对 MTU 特别敏感：外层封装增加开销，内层必须相应减小 MTU，否则大包会在路径上被丢弃。