3. UDP协议深度解析：UDP报文格式与TCP对比
各位同学，今天我们聊聊UDP协议。说实话，UDP在FPGA设计里出现的频率非常高。我做过不少网络加速项目，UDP解析引擎几乎是标配。为什么？因为它简单、轻量、延迟低。你想想看，在硬件里实现一个复杂的TCP状态机，那资源消耗可不是闹着玩的。
3.1 UDP报文格式——四个字段搞定一切
UDP报文头只有8个字节，就四个字段。每个字段2字节，整齐得很。我刚开始学的时候觉得这也太简单了吧？后来发现，简单恰恰是它的优势。
| 字段 | 长度（字节） | 描述 |
|---|---|---|
| 源端口 | 2 | 发送方的端口号，可选（可为0） |
| 目的端口 | 2 | 接收方的端口号，必须填写 |
| 长度 | 2 | UDP头部+数据的总长度（字节） |
| 校验和 | 2 | 覆盖头部和数据的校验值，可选（IPv4中可为0） |
3.2 逐个字段拆解
源端口（Source Port）
这个字段标识发送方的应用程序。嗯，这里要注意：在UDP里，源端口可以填0。什么意思？就是发送方不关心回复，比如一些单向的日志上报。我在项目中遇到过，有些嵌入式设备为了省资源，直接把源端口写成0，结果对端防火墙给拦了……所以，能填还是填上吧。
目的端口（Destination Port）
这个字段必须填。接收方根据目的端口把数据交给对应的应用程序。比如DNS用53，DHCP用67/68，NTP用123。在FPGA里做UDP解析，我们通常先提取目的端口，然后查表决定数据往哪送。
长度（Length）
这个字段有点意思。它表示UDP头部+数据的总长度。最小值是8（只有头部，没有数据）。最大值是65535。但实际中，受限于MTU，很少有超过1500字节的UDP报文。
避坑指南： 我曾经在解析UDP长度字段时犯过一个低级错误——直接用长度字段的值去控制FIFO的读操作。结果发现，如果长度字段被篡改或者计算错误，整个解析逻辑就崩了。后来我加了一个校验：长度必须等于IP头中总长度减去IP头部长度。双重验证，稳得很。
校验和（Checksum）
UDP校验和覆盖的范围比较特殊：它不光校验UDP头部和数据，还校验一个“伪头部”。伪头部包含源IP、目的IP、协议类型和UDP长度。说白了，就是把IP层的部分信息也拉进来一起算。为什么这么做？为了防止IP地址被篡改后UDP报文被误投。
在IPv4中，校验和是可选的（可以全0）。但在IPv6中，校验和是强制的。我个人习惯：不管IPv4还是IPv6，一律计算校验和。省得后面排查问题时抓瞎。
3.3 UDP与TCP的对比——选谁？看场景
很多初学者会问：UDP和TCP到底选哪个？我的回答是：看你的应用场景。下面这张表是我自己总结的，你直接拿去用。
| 对比项 | UDP | TCP |
|---|---|---|
| 连接状态 | 无连接，发完就走 | 面向连接，三次握手 |
| 可靠性 | 不可靠，丢包不重传 | 可靠，确认重传机制 |
| 有序性 | 不保证顺序 | 保证数据按序到达 |
| 流量控制 | 无 | 有滑动窗口机制 |
| 拥塞控制 | 无 | 有慢启动、拥塞避免 |
| 头部开销 | 8字节 | 20-60字节 |
| 传输效率 | 高，低延迟 | 相对较低 |
| 典型应用 | 视频流、DNS、游戏 | 网页、文件传输、邮件 |
为什么FPGA里常用UDP？说白了，TCP的状态机太复杂了。你要在硬件里实现一个完整的TCP协议栈，光是状态机就得几十个状态。而且TCP的确认重传机制需要缓存大量数据，这对FPGA的BRAM资源是个考验。
个人经验： 我做过一个100Gbps的网络加速卡，客户要求低延迟。我们最终选了UDP+应用层重传的方案。为什么？因为TCP的拥塞控制在高速场景下会频繁触发，导致吞吐量上不去。而UDP配合硬件校验，延迟能控制在微秒级。当然，代价是应用层得自己处理丢包。
3.4 UDP在FPGA中的典型应用场景
- 高速数据采集：比如ADC采样数据直接打包成UDP发出去，延迟越低越好
- 视频传输：丢几帧没关系，但延迟必须低
- 控制面通信：比如交换机内部的协议报文，用UDP简单高效
- 物联网设备：资源受限，跑TCP太吃力
3.5 核心知识体系
下面这张图是我画的UDP解析引擎的核心结构，你一看就明白。
重要提醒： 在FPGA里实现UDP解析时，一定要注意时钟域处理。MAC层和UDP解析层可能在不同的时钟域。我曾经因为忽略了跨时钟域同步，导致校验和计算偶尔出错，排查了整整两天。所以，该用FIFO的地方别省，该打两拍的地方别偷懒。
好了，UDP协议的核心内容就这些。记住：UDP的简单是它的最大优势，也是它的最大劣势。在FPGA设计里，我们利用它的简单实现高速处理，同时通过应用层补偿它的不可靠性。这就是工程中的权衡之道。