流媒体传输系统
本章目标
学完本章，你应该能够：
- 对比 RTMP / HLS / DASH / WebRTC / SRT 的延迟与适用场景；
- 解释自适应码率（ABR）的工作原理与常见算法；
- 理解 CDN「秒开」与多层分发架构；
- 为社团直播选择合适协议与低延迟方案。
1. 流媒体协议对比
| 协议 | 传输层 | 典型端到端延迟 | 特点 | 适用 |
|---|---|---|---|---|
| RTMP | TCP | 2–5 秒 | 推流经典，曾被 Flash 广泛支持 | 采集推流、传统直播 |
| RTSP/RTP | UDP/TCP | 1–2 秒 | 监控/会议常用，控制能力强 | 安防、视频会议 |
| HLS | HTTP | 6–30 秒（传统） | 苹果主导，兼容性极佳 | 大规模分发、iOS |
| DASH | HTTP | 6–30 秒（传统） | 开放标准，多 DRM | 跨平台分发 |
| WebRTC | UDP(SRTP) | 0.2–0.5 秒 | 浏览器原生、双向 | 连麦、超低延迟互动 |
| SRT | UDP | 0.5–2 秒 | 抗丢包、弱网稳定 | 远程推流、专业传输 |
| LL-HLS/LL-DASH | HTTP | 2–5 秒 | HLS/DASH 的低延迟版 | 兼顾兼容与低延迟 |
协议选择逻辑
- 社交/电商直播连麦 → WebRTC 或低延迟 RTMP（WebRTC 做观众侧互动）。
- 大规模观众分发 → HLS / DASH（配合 CDN）。
- 跨公网稳定推流 → SRT 或 RIST（抗丢包、端到端加密）。
- 防盗链 → 加密 HLS（AES-128 / AES-256）或带鉴权令牌的 DASH。
2. CDN 架构与「秒开」原理
- 分层架构：源站 → 中心节点 → 边缘节点，越靠近用户命中率越高。
- 缓存策略：TTL、热点预缓存（预热）、URL 规范化以提高命中率。
- 「秒开」关键：
- 多码率预分段，首屏只拉最低必要片段；
- TCP 连接复用、TLS 复用；
- HttpDNS 避免本地 DNS 劫持与解析慢；
- 智能调度把用户导向最近/最空闲边缘节点。
3. 自适应码率技术（ABR）
ABR 把视频切成 2–10 秒的小段，并生成多档码率：
- 算法类型：
- 基于缓冲区：缓冲多则升档，缓冲少则降档。
- 基于吞吐量：按实测带宽选择。
- 混合型 / AI 驱动：综合缓冲、带宽、码率切换成本做决策。
- 挑战：频繁档位抖动伤害观感；初始档位选择影响首屏；弱网下的欠载（卡顿）与浪费平衡。
4. 直播系统架构设计
- 最小可用系统：编码器 → 流媒体服务器（如 Nginx-RTMP、SRS、media-server）→ CDN → 播放器 SDK。
- 大型平台：多层分发、负载均衡、协议转换网关（RTMP 收流转 HLS/DASH）、地理级调度。
- 监控告警：推流状态、节点健康、卡顿率/首帧时长等体验指标、自动故障转移。
5. 校园实践案例
社团迎新直播：平衡「低延迟」与「覆盖」
- 推流：OBS 用 RTMP/SRT 推到自建或云服务（SRT 抗校园网抖动）。
- 分发：服务端转封装为 HLS（LL-HLS），经 CDN 覆盖手机/网页观众。
- 互动连麦：嘉宾端用 WebRTC 接入，延迟 < 1 秒。
- 秒开优化：开启 CDN 预热、清单文件短 GOP、播放器预加载首段。
课程总结 / 核心要点
关键结论
- RTMP 适合推流，HLS/DASH 适合大规模分发，WebRTC/SRT 适合低延迟。
- ABR 靠「多码率分片 + 清单文件 + 客户端决策」实现自适应，核心矛盾是抖动 vs 卡顿。
- CDN 通过「边缘缓存 + 智能调度 + HttpDNS + 预加载」实现秒开。
- 社团直播常采用 SRT/RTMP 推流 → HLS/LL-HLS 分发 → WebRTC 连麦 组合。