教学目标
📖 课前导入
上节课我们学了TCP——三次握手、确认重传、流量控制。它保证了数据的完整，但也带来了额外的开销和延迟。
但想想看：你在看视频直播时，偶尔花屏一下无所谓，如果为了重传一帧画面而卡顿2秒，体验反而更差。你玩在线游戏时，角色位置每秒更新60次，丢了一次立刻会有新的数据覆盖。
这些场景需要UDP协议——轻量、快速、简单到极致！
🎯 本课目标：理解UDP的特点和报文结构，掌握TCP与UDP的全面对比，能判断具体场景该选TCP还是UDP，了解QUIC等基于UDP的新技术。
📚 一、UDP协议概述
UDP的核心特点
UDP（User Datagram Protocol，用户数据报协议）是一种无连接的、不可靠的传输协议。它几乎只是在IP协议上加了端口号和简单校验——是传输层最"轻"的协议。
无连接
不需要握手，拿起来就发
类比：寄明信片，写好就投
速度快
没有握手/确认/重传开销
TCP要7步，UDP 1步搞定
不可靠
不保证到达、不保证顺序
"尽最大努力交付"
面向数据报
保留消息边界，整包收发
发1包收1包，不会粘包
UDP vs TCP 通信过程对比
// TCP发送数据（7步）
1. SYN →
2. ← SYN+ACK
3. ACK →
4. 数据 →
5. ← ACK
6. FIN →
7. ← FIN+ACK
// UDP发送数据（1步）
1. 数据 → 完事！
不需要建立连接
不需要确认接收
不需要断开连接
不关心对方是否收到
📚 二、UDP报文结构
UDP首部格式（仅8字节！）
TCP首部至少20字节（含序号/确认号/窗口/标志位等），UDP只有8字节——简洁到极致！
源端口 / 目的端口 —— 各16位（0~65535）
标识发送方/接收方的应用进程。源端口可选（可填0）。如DNS目的端口=53。
长度 —— 16位
整个UDP数据报长度（首部8 + 数据），最小值8，最大值65535字节（约64KB）。
校验和 —— 16位
检测传输错误（含伪首部）。检测到错误只丢弃，不会重传。IPv4中可选，IPv6中强制。
📚 三、TCP与UDP全面对比 ⭐⭐必考
| 对比项 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接（直接发送） |
| 可靠性 | 可靠（确认、重传、排序） | 不可靠（尽最大努力交付） |
| 传输方式 | 面向字节流（可能粘包） | 面向数据报（不粘包） |
| 首部大小 | 20~60字节 | 8字节 |
| 速度/延迟 | 较慢（握手+确认开销） | 快（零额外开销） |
| 通信模式 | 仅一对一 | 一对一、广播、组播 |
| 流量/拥塞控制 | ✅ 滑动窗口 + 慢启动 | ❌ 无（可能冲垮网络） |
| 典型应用 | HTTP/FTP/SMTP/SSH | DNS/DHCP/直播/游戏/VoIP |
如何选择TCP还是UDP？——一句话口诀
"数据不能丢 → TCP；延迟不能高 → UDP"
选TCP：数据完整 > 速度
- • 文件传输FTP（不能丢一个字节）
- • 网页HTTP（页面必须完整加载）
- • 邮件SMTP（邮件不能缺内容）
- • 远程登录SSH（每个命令都要执行）
选UDP：速度/实时性 > 完整
- • 视频直播（丢帧好过卡顿）
- • DNS查询（一问一答，失败重试）
- • 在线游戏FPS（位置信息每秒60次更新）
- • DHCP（客户端还没IP，只能广播）
📚 四、UDP的典型应用场景
🌐 DNS域名解析（端口53）
一问一答，快速简单。查询失败直接重试即可。
特例：DNS区域传送（大数据量）会切换到TCP。
📡 DHCP动态配置（端口67/68）
客户端还没IP地址，无法建TCP连接。所以DHCP用UDP广播获取IP。
🎥 实时音视频 RTP（端口动态）
视频通话、直播用UDP+RTP。丢1-2帧画面看不出来，但重传导致的卡顿一眼就能发现。
🎮 在线游戏（自定义端口）
FPS/MOBA每秒更新几十次位置数据，丢一次无所谓，新数据马上覆盖。延迟>50ms就能感觉卡。
📊 SNMP网络管理（端口161/162）
轻量收集设备状态信息（CPU、内存、接口流量），不需要可靠传输。
⏰ NTP时间同步（端口123）
网络时间协议，简单快速地同步设备时钟。精度要求高但数据量极小。
📚 五、新趋势：基于UDP的QUIC协议
QUIC——UDP的华丽变身
Google发明的QUIC协议基于UDP，但在应用层实现了类似TCP的可靠传输、加密和多路复用。
HTTP/3就是基于QUIC的，已被Chrome、Edge等主流浏览器支持。你现在访问的很多网站已经在用QUIC了！
0-RTT连接建立
首次连接1-RTT，重连0-RTT——比TCP+TLS的3-RTT快得多。
内置TLS加密
加密是QUIC的标配，不像TCP需要额外叠加TLS层。
解决队头阻塞
TCP一个包丢了后面全等。QUIC多流独立，一个流丢包不影响其他流。
本质：QUIC在UDP上用应用层代码实现了比TCP更好的可靠传输——"站在UDP肩膀上超越TCP"。
TCP与UDP对比实验
使用Wireshark分别抓取HTTP（TCP三次握手+数据）和DNS（UDP直接发送）的数据包，对比首部结构和通信效率
使用Wireshark分别抓取HTTP（TCP三次握手+数据）和DNS（UDP直接发送）的数据包，对比首部结构和通信效率
✅ 课堂小测
随堂测验
第 1/7 题UDP首部的大小是多少字节？
📋 本课小结
UDP：无连接、不可靠、面向数据报、首部仅8字节。"寄明信片"模型。
核心差异：TCP=可靠但慢（7步），UDP=不可靠但快（1步）。
选择口诀：数据不能丢→TCP，延迟不能高→UDP。
UDP应用：DNS(53)、DHCP(67/68)、直播RTP、游戏、SNMP(161)、NTP(123)。
新趋势：QUIC(HTTP/3)基于UDP实现可靠+加密+多路复用，超越传统TCP。
🤔 课后思考与实践
动手实验
- 用Wireshark抓取一次DNS查询（过滤
udp.port==53），观察UDP首部的4个字段。 - 再抓取一次HTTP请求（过滤
tcp.port==80），对比TCP首部和三次握手过程。 - 在Chrome中按F12→网络→Protocol列，看看有多少请求已经在使用h3(QUIC)。
思考题
- UDP"不可靠"为什么不是缺点？在什么场景下"不可靠"反而是优点？
- 如果应用需要在UDP上实现可靠传输，该怎么做？（提示：参考QUIC的做法）
- TCP的粘包问题是什么？为什么UDP不会有粘包问题？