1. UDP 协议基础：为什么日志传输偏爱它？
好，咱们直接进入正题。UDP 协议，全称是 User Datagram Protocol，中文叫用户数据报协议。很多刚接触网络编程的朋友，一听到 UDP 就觉得它“不可靠”，下意识想避开。但在我眼里，UDP 恰恰是日志传输场景下的“隐形冠军”。
为什么这么说？你想想看，日志传输最怕什么？不是丢几条日志，而是传输本身把业务系统拖垮了。我见过太多因为 TCP 重传导致的生产事故了。嗯，咱们先不急着下结论，先把 UDP 的底裤扒干净。
1.1 UDP 协议原理：无连接就是最大的优势
UDP 的原理，说白了就四个字：无连接。它不像 TCP 那样需要三次握手建立连接，也不需要四次挥手断开连接。发送方直接把数据包扔到网络上，至于对方收没收到，UDP 不管。
我个人习惯把 UDP 比作“寄明信片”——你写好内容，贴上邮票，丢进邮筒。邮局尽力送达，但不保证不丢件，也不给你回执。而 TCP 呢，更像是“寄挂号信”，每一封都要签收确认，丢了还得重寄。
核心要点：UDP 的“不可靠”是设计上的取舍，不是缺陷。它用可靠性换取了低延迟和低开销。
我在项目中遇到过这样一个场景：某次线上排查问题，需要实时采集所有业务节点的访问日志。如果用 TCP，每个节点都要维护长连接，连接数一多，内核开销直接飙升。换成 UDP 后，每个节点只管发，接收端只管收，CPU 占用率降了 40%。
1.2 UDP 报文结构：轻量到令人发指
咱们来看看 UDP 的报文头，你就知道它为什么快了。UDP 头部只有 8 个字节，结构极其简单：
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| 源端口 | 目的端口 |
+--------+--------+--------+--------+
| 报文长度 | 校验和 |
+--------+--------+--------+--------+
| 数据部分（可选） |
+-----------------------------------+就四个字段：
- 源端口（16位）：发送方的端口号，用于对方回复时使用。如果不需要回复，可以填 0。
- 目的端口（16位）：接收方的端口号，这是必须填的。
- 报文长度（16位）：整个 UDP 报文（头部+数据）的字节数，最小是 8（只有头部）。
- 校验和（16位）：可选字段，用于检测数据在传输过程中是否损坏。如果设为 0，表示不校验。
对比一下 TCP 头部，20 个字节起步，还有各种标志位、序号、确认号……UDP 这 8 个字节的头部，简直就是一股清流。
避坑指南：我曾经在项目中犯过一个低级错误——把 UDP 报文长度字段理解错了。注意，这个长度是 UDP 头部 + 数据部分的总长度，不是纯数据长度。如果你自己构造 UDP 包，这个字段算错了，接收端会直接丢弃。
1.3 UDP 与 TCP 对比：一张表说清楚
很多教科书喜欢列一堆对比项，我挑几个日志传输场景下最关键的维度，咱们直接看表：
| 对比维度 | UDP | TCP |
|---|---|---|
| 连接状态 | 无连接，发完即走 | 面向连接，需三次握手 |
| 头部开销 | 8 字节 | 20~60 字节 |
| 可靠性 | 尽力交付，不保证 | 确认重传，保证到达 |
| 有序性 | 不保证顺序 | 保证按序到达 |
| 流量控制 | 无 | 滑动窗口机制 |
| 拥塞控制 | 无 | 有，慢启动/拥塞避免 |
| 传输模式 | 报文边界保留 | 字节流，无边界 |
| 适用场景 | 实时性高、允许丢包 | 要求完整、可靠传输 |
看到这里你可能会问：TCP 这么“完美”，为什么日志传输还要用 UDP？
原因很简单——日志传输对丢包容忍度极高，但对延迟和资源消耗极其敏感。你想想，1000 条日志里丢个三五条，对整体分析几乎没影响。但如果因为 TCP 的拥塞控制导致发送端被限速，那实时性就全毁了。
注意：UDP 没有拥塞控制，这意味着如果网络出现拥塞，UDP 流量会“抢占”TCP 的带宽。在生产环境中，一定要给 UDP 日志传输做带宽限制，否则会影响其他业务。我见过有人直接把日志服务器网卡打爆的案例。
1.4 UDP 在日志传输中的优势：实战视角
好了，理论说完了，咱们聊聊实战。为什么我坚持用 UDP 做日志传输？三个核心优势：
- 零连接维护成本：日志采集端通常是海量的（成百上千个节点）。如果用 TCP，每个节点都要和日志服务器建立连接，服务器端需要维护大量的连接状态。UDP 无状态，服务器只管收，压力小得多。
- 发送端无阻塞：TCP 发送数据时，如果接收端处理不过来，发送端会被迫阻塞（背压）。日志采集是异步的，发送端阻塞会导致业务线程卡住。UDP 没有这个问题，数据扔出去就完事。
- 天然支持广播/组播：有些场景下，你需要把同一份日志发送到多个接收端（比如同时发给实时分析和离线存储）。UDP 组播可以做到一份数据，多个接收，网络开销极低。
我记得有一次帮客户做日志系统选型，对方坚持用 TCP，理由是“不能丢数据”。结果上线第一天，业务高峰期日志采集线程就把业务线程堵死了。后来换成 UDP + 本地缓存兜底，问题迎刃而解。
下面这张图，是我自己总结的 UDP 日志传输架构，你可以看看整体流程：
看到这个架构图了吗？整个链路非常清爽。业务应用产生日志，采集器拿到后直接通过 UDP 扔出去，接收端无状态监听端口，收一条处理一条。没有握手，没有重传，没有连接池，没有心跳保活。
当然，UDP 也不是银弹。它最大的短板就是丢包不可控。所以在实际部署中，我通常会加一个本地文件缓存作为兜底——UDP 发送失败时，日志先写本地文件，等网络恢复后再补发。这个方案我们会在后面的章节详细讲。
个人经验：如果你对日志完整性要求极高（比如金融交易审计），建议用 TCP 或者可靠 UDP 协议（比如 QUIC）。但如果是运维监控、业务追踪、性能分析这类场景，UDP 绝对是性价比最高的选择。
好了，UDP 协议基础就聊到这里。记住一句话：UDP 不是不可靠，而是把可靠性交给了上层应用。在日志传输这个场景下，这种设计恰恰是最合理的。