🌐 音频传输协议
RTP、WebRTC、HLS...就像不同的快递方式
📦 先理解：两种"快递方式"
网络传输的基础：TCP vs UDP
所有网络传输都建立在这两种方式之上，就像所有快递都分为"签收"和"不签收"：
📬
TCP = 顺丰签收
✅ 保证送达
✅ 保证顺序
✅ 丢了会重发
👍 可靠，不丢件
👎 慢，要等确认
📮
UDP = 扔信箱
❌ 不保证送达
❌ 不保证顺序
❌ 丢了就丢了
👍 快，不等待
👎 可能丢包
💡 实时语音为什么用UDP？
打电话时，如果一个字没听清，你会说"啥？再说一遍"，而不是等快递员把丢的那个字补发过来。
实时性比完整性更重要——所以语音/视频通话都用UDP！
🔧 主流音频传输协议
RTP
实时传输协议
VoIP的基础协议，在UDP上加了时间戳和序号，让接收方知道顺序。
<50ms
延迟
UDP
基于
用于：
📞 VoIP电话
📹 视频会议
WebRTC
网页实时通信
浏览器内置！不用装插件就能视频通话，自动处理NAT穿透、加密、回声消除。
<500ms
延迟
P2P
连接
用于：
💬 微信网页版
🎮 Discord
📹 Google Meet
RTMP
直播推流协议
Adobe开发的直播协议，主播推流到服务器用这个。基于TCP，稳定可靠。
1-3s
延迟
TCP
基于
用于：
🎬 OBS推流
📺 B站直播
🎮 斗鱼/虎牙
HLS
HTTP直播流
苹果发明的，把视频切成小片用HTTP传输。兼容性最好，CDN友好。
10-30s
延迟
HTTP
基于
用于：
📱 手机视频
🎵 网易云音乐
📺 YouTube
WebSocket
双向实时通道
浏览器和服务器之间的"电话线"。虽然基于TCP很可靠，但一旦丢包会**卡顿等待**，不适合极高要求的实时通话。
较低
延迟
TCP
基于
用于：
🤖 智能音箱
💬 文字聊天
🎮 游戏信令
💡 深度思考：为什么不用 WebSocket 打电话？
WebSocket 看起来又快又稳，但它基于 TCP，有一个致命弱点：队头阻塞。
• 想象一下：你在看直播，WebSocket 就像是一个严格的列队。如果中间第 5 个包丢了，TCP 会暂停所有后续包（6, 7, 8...）的播放，直到第 5 个包重传成功。这会导致画面/声音突然卡死，然后快速快进。
• 相比之下：WebRTC (UDP) 就像“本来就是糊弄”。第 5 个包丢了？没关系，直接扔掉，继续播第 6 个。虽然瞬间有点瑕疵，但绝不卡顿，保证了流畅性。
⏱️ 延迟对比一览
| 协议 | 延迟 | 可靠性 | 适合场景 |
|---|---|---|---|
| 📡 RTP | <50ms | 可能丢包 | 实时通话 |
| 🌐 WebRTC | <500ms | 自动补偿 | 浏览器通话 |
| 📺 RTMP | 1-3s | 可靠 | 直播推流 |
| 🍎 HLS | 10-30s | 非常可靠 | 点播/大规模直播 |
| 🔌 WebSocket | 较低 (有抖动) | 可靠 (会卡顿) | 信令/文字/IoT |
🎯 什么场景用什么协议？
📞
语音通话
WebRTC / RTP
延迟要低
📹
视频会议
WebRTC
P2P省带宽
🎬
直播推流
RTMP
稳定可靠
📺
直播观看
HLS / DASH
兼容性好
🎵
音乐播放
HLS / HTTP
质量优先
🤖
智能设备
WebSocket
灵活可控
🎬 直播的完整链路
🎤 主播
→
OBS推流
→
RTMP
→
🖥️ 服务器
↓ 转码分发
🖥️ CDN
→
HLS
→
📱 观众A
💻 观众B
📺 观众C
💡 为什么推流用RTMP，观看用HLS？
RTMP延迟低，适合主播实时上传；HLS兼容性好，任何设备都能看，还能利用CDN缓存。
✅ 本章小结
- TCP vs UDP：TCP可靠但慢，UDP快但可能丢包
- RTP：VoIP基础，给UDP加时间戳
- WebRTC：浏览器内置，P2P实时通信
- RTMP：直播推流，TCP可靠
- HLS：直播观看/点播，兼容性最好
- WebSocket：双向通道，IoT常用