3. UDP协议详解：UDP特点、UDP与TCP对比、UDP应用场景、UDP编程模型
聊到网络编程，TCP和UDP就像一对性格迥异的兄弟。TCP稳重可靠，UDP轻快直接。今天咱们就好好聊聊UDP——这个看起来简单，实则暗藏玄机的协议。
3.1 UDP的核心特点
UDP的全称是User Datagram Protocol，用户数据报协议。说白了，它就是个“只管发，不管到”的协议。
- 无连接：发数据前不需要握手，直接开干
- 不可靠：数据丢了？不重传。乱序了？不调整
- 面向报文：应用层给多少数据，UDP就原封不动发出去
- 速度快：没有确认机制，没有流量控制，延迟极低
- 支持广播和多播：这是TCP做不到的
我个人的理解：UDP就像寄明信片——贴上邮票扔进邮筒，至于对方收不收得到，那就看运气了。而TCP呢，像寄挂号信，每封信都要签收确认。
3.2 UDP与TCP的对比
很多初学者会问：“既然TCP那么可靠，为什么还要用UDP？”这个问题问得好。咱们直接看对比表：
| 特性 | UDP | TCP |
|---|---|---|
| 连接状态 | 无连接 | 面向连接 |
| 可靠性 | 不可靠 | 可靠（确认重传） |
| 有序性 | 不保证 | 保证有序 |
| 传输速度 | 快 | 相对慢 |
| 数据边界 | 保留消息边界 | 字节流，无边界 |
| 头部开销 | 8字节 | 20字节 |
| 广播/多播 | 支持 | 不支持 |
我记得刚入行时，有个项目要用UDP传文件。我当时想：“这不靠谱吧？”结果被老工程师一句话点醒：“你想想看，视频通话能接受重传吗？画面卡住等重传，那还叫实时通话吗？”
避坑指南：我曾经在一个项目中，用UDP传关键业务数据，结果丢包率高达5%。后来老老实实加了应用层确认机制。记住：UDP不保证可靠，但你可以自己在应用层实现可靠性。
3.3 UDP的应用场景
UDP适合哪些场景？说白了，就是那些“可以容忍少量丢包，但不能容忍延迟”的场景。
- 视频直播/视频会议：丢几帧画面没关系，卡顿才要命
- 在线游戏：尤其是FPS游戏，玩家位置信息必须实时更新
- DNS查询：一个请求一个响应，用TCP反而浪费
- DHCP：设备刚开机还没IP，只能用广播，UDP天然支持
- SNMP：网络设备监控，轻量级查询
- VoIP：语音通话，偶尔丢几个字不影响理解
嗯，这里要注意：并不是所有实时场景都适合UDP。比如金融交易系统，虽然要求低延迟，但数据绝对不能丢。这种场景下，很多人会选择在UDP之上自己实现可靠传输协议。
3.4 UDP编程模型
UDP的编程模型比TCP简单得多。核心就几个API：
// 服务端
int sockfd = socket(AF_INET, SOCK_DGRAM, 0); // 创建UDP套接字
bind(sockfd, (struct sockaddr*)&servaddr, sizeof(servaddr)); // 绑定端口
recvfrom(sockfd, buf, sizeof(buf), 0, (struct sockaddr*)&cliaddr, &len); // 接收数据
sendto(sockfd, buf, n, 0, (struct sockaddr*)&cliaddr, len); // 发送数据
// 客户端
int sockfd = socket(AF_INET, SOCK_DGRAM, 0);
sendto(sockfd, buf, strlen(buf), 0, (struct sockaddr*)&servaddr, sizeof(servaddr));
recvfrom(sockfd, buf, sizeof(buf), 0, NULL, NULL); // 不关心发送方地址看到没？服务端不需要listen，不需要accept。客户端不需要connect。直接发就完事了。
注意：UDP的recvfrom一次只能接收一个数据报。如果发送方发了100字节，接收方只给了50字节的缓冲区，那剩下的50字节就丢了。这和TCP的流式传输完全不同。
下面我用一张图来展示UDP的通信流程，这样更直观：
这张图很清楚地展示了UDP的核心思想：服务端和客户端之间没有“连接”这个概念。服务端bind之后就在那等着，谁来数据都收。客户端想发就发，不需要提前打招呼。
小技巧：在实际项目中，我习惯在UDP数据包的前4个字节放一个序列号。这样接收方可以检测丢包和乱序。虽然UDP本身不保证，但应用层可以自己做简单的可靠性控制。
最后说一句：UDP编程虽然简单，但用好它并不容易。你需要自己处理丢包、乱序、流量控制等问题。不过正是这种“自由”，让UDP在很多高性能场景下大放异彩。