1. UDP协议基础：报文结构、与TCP对比、应用场景分析
各位同学好，我是老张。做网络抓包分析十几年了，今天咱们聊聊UDP。说实话，很多刚入行的朋友总觉得UDP简单——不就是发出去不管吗？嗯，这话对了一半。但真要你分析UDP丢包、定位问题的时候，光知道"无连接"三个字可不够。
我个人习惯，学任何协议都先从它的"长相"入手。报文结构就是协议的身份证，看懂了它，你就能明白它为什么快、为什么丢包、为什么适合某些场景。
1.1 UDP报文结构：轻量到极致
UDP的报文头有多简单？我直接给你看结构：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 源端口(16) | 目的端口(16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 长度(16) | 校验和(16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 数据 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+看到了吗？就4个字段，每个16位，总共8字节头部。我当年第一次在Wireshark里看到UDP报文时，第一反应是：就这？
咱们拆开看：
- 源端口（16位）：发送方的端口号。可选，不使用时填0。我在项目中遇到过某些嵌入式设备源端口固定为0，排查时差点以为是攻击流量。
- 目的端口（16位）：接收方的端口号。必填，这是数据分发的依据。
- 长度（16位）：UDP头部+数据的总字节数。最小值是8（只有头部没数据），最大值65535。但实际中受MTU限制，很少有超过1500字节的UDP报文。
- 校验和（16位）：覆盖头部+数据+伪头部。可选字段，IPv4下可以全0（不校验），但IPv6强制要求。我曾经在调试一个视频传输系统时，发现接收端画面偶尔花屏，最后定位到是发送端校验和计算有bug，某些路由器会丢弃校验错误的报文。
我的经验：在Wireshark里看UDP报文时，重点关注"Length"和"Checksum"两个字段。Length异常（比如小于8）说明报文被截断了；Checksum显示"incorrect"说明传输过程中数据损坏了。这两个是判断UDP丢包和乱序的重要线索。
1.2 UDP与TCP对比：一个送快递，一个签合同
我经常跟团队里的新人打比方：TCP像顺丰——要确认收货、要签单、丢了重发、顺序不能乱。UDP像你往楼下扔个纸飞机——扔出去就不管了，到不到、顺序对不对，全看运气。
但别觉得UDP就低级。恰恰相反，很多高性能场景非它不可。咱们看个对比表：
| 特性 | UDP | TCP |
|---|---|---|
| 连接状态 | 无连接，发完即走 | 面向连接，三次握手 |
| 可靠性 | 尽力交付，不保证到达 | 可靠传输，确认重传 |
| 有序性 | 不保证顺序 | 保证字节流顺序 |
| 流量控制 | 无 | 滑动窗口+拥塞控制 |
| 头部开销 | 8字节 | 20-60字节 |
| 传输模式 | 报文边界保留 | 字节流，无边界 |
| 广播/组播 | 原生支持 | 不支持 |
| 典型延迟 | 微秒级 | 毫秒级（握手+确认） |
为什么UDP没有流量控制？说白了，它根本不知道对端能不能收得过来。TCP有滑动窗口，会告诉发送方"慢点，我吃不消了"。UDP不管这些，一股脑全发出去。这在局域网里问题不大，但在公网上，这就是丢包的根源之一。
避坑指南：我曾经接手过一个项目，开发团队在公网上用UDP传输大文件，结果丢包率高达30%。他们以为是网络问题，折腾了两个月。我过去一看，UDP报文大小设成了64KB，直接超过MTU被分片，任何一个分片丢失整个报文就废了。解决方案很简单：把UDP载荷控制在1400字节以内，加上应用层ACK和重传机制。问题一天解决。
1.3 UDP应用场景分析：什么时候该用它？
你想想看，什么场景下"丢了几个包无所谓，但延迟必须低"？我列几个典型的：
- 实时音视频通话：Zoom、语音、VoIP。丢一帧画面最多卡一下，但延迟高了对话就没法进行。我测过，TCP下RTT超过300ms时，视频通话基本不可用；UDP下同样延迟，体验还能接受。
- 在线游戏：FPS射击游戏、MOBA类。玩家的操作指令必须毫秒级送达，丢一个包大不了角色瞬移一下，但延迟高了直接没法玩。
- DNS查询：标准DNS查询默认用UDP 53端口。查询报文就几十字节，用TCP三次握手太浪费。只有响应超过512字节时才会回退到TCP。
- DHCP：设备获取IP地址时，连自己的IP都没有，怎么建立TCP连接？UDP的无连接特性正好解决这个问题。
- SNMP：网络设备监控。监控数据频繁上报，偶尔丢一两个不影响整体统计。
- 流媒体直播：RTSP/RTP协议栈底层走UDP。直播延迟可以做到1-3秒，而基于TCP的HLS延迟通常在10秒以上。
但有些场景千万别用UDP：
- 文件传输（除非你愿意自己实现重传机制）
- 数据库事务
- 网页浏览（HTTP基于TCP）
- 任何要求数据100%完整到达的场景
核心判断标准：问自己两个问题——
- 我能容忍偶尔丢包吗？能 → 考虑UDP；不能 → 用TCP或自己加可靠性层。
- 延迟敏感吗？是 → UDP优势明显；否 → TCP更省心。
1.4 知识体系总览
下面这张图是我自己整理的UDP知识框架，咱们这一章讲的就是最左边的"协议基础"部分。后面几章会逐步展开丢包分析、Wireshark过滤、性能调优等内容。