1. 流媒体基础与低延迟概述
大家好，欢迎来到这门课。我是你们的老朋友，一个在流媒体领域摸爬滚打了十几年的工程师。
咱们开门见山。这门课叫《从零构建低延迟流媒体系统》，第一件事，得把「流媒体」和「低延迟」这两个词掰扯清楚。别觉得基础，我见过太多人把 HLS 延迟降到 5 秒就欢呼「低延迟」了——嗯，在云游戏场景里，5 秒够你死三回了。
1.1 什么是流媒体？
流媒体，说白了就是「边下边播」。你不需要等整个视频文件下载完，只要拿到一小段数据就能开始播放。传统的下载播放，你得等一个 2GB 的 MP4 文件全部落盘；流媒体不一样，服务器把视频切成一个个小片段，客户端拿到第一个片段就开播，后面的片段在后台继续拉。
这个机制听起来简单，但实现起来坑不少。我早期做过一个点播项目，用户反馈「怎么播到一半卡住了？」查了半天，原来是切片时长设得太长，客户端缓存策略又激进，结果内存爆了。所以你看，切片大小、缓存策略、网络抖动，这些都会直接影响用户体验。
1.2 低延迟的定义与指标
聊低延迟之前，得先定个标准。到底多少算「低」？不同场景差别很大。
我个人习惯把延迟分成两个维度来考量：
- 端到端延迟（End-to-End Latency）：从摄像头采集到观众屏幕显示，中间经过编码、传输、解码、渲染的总耗时。这是最核心的指标。
- 首屏时间（Time to First Frame）：用户点击播放，到屏幕上出现第一帧画面的时间。这个指标直接影响用户留存——你想想看，如果点开一个直播，黑屏超过 3 秒，你还有耐心等吗？
不同场景对这两个指标的要求完全不同。我整理了一张表，方便你对照：
| 应用场景 | 端到端延迟要求 | 首屏时间要求 | 典型协议 |
|---|---|---|---|
| 传统直播（体育、新闻） | 10-30 秒 | < 3 秒 | HLS, DASH |
| 互动直播（连麦、带货） | < 3 秒 | < 1 秒 | WebRTC, SRT |
| 云游戏 | < 100 毫秒 | < 500 毫秒 | WebRTC, 自研 UDP |
| 远程协作（会议、医疗） | < 200 毫秒 | < 1 秒 | WebRTC |
1.3 低延迟的应用场景
咱们挑三个典型场景聊聊，看看低延迟到底有多重要。
1.3.1 直播
传统直播用 HLS，延迟通常在 15-30 秒。这在「看球赛」场景下还能忍——反正你也就比现场慢半拍。但到了「直播带货」就不行了。主播喊「3、2、1，上链接！」结果观众那边延迟了 10 秒，链接早被抢光了。所以现在主流直播平台都在推低延迟方案，LL-HLS 能把延迟压到 3-5 秒，WebRTC 甚至能到 1 秒以内。
1.3.2 云游戏
这是对延迟最苛刻的场景。你按一下键盘，画面要在 100 毫秒内响应，否则玩家就会觉得「手感不好」。我参与过一个云游戏项目，初期用 SRT 协议，延迟在 150 毫秒左右，测试玩家反馈「像在泥潭里走路」。后来换成 WebRTC + 自研 FEC 策略，延迟降到 60 毫秒，玩家才说「嗯，能玩了」。你看，60 毫秒的差距，就是「能玩」和「不能玩」的分界线。
1.3.3 远程协作
视频会议、远程手术、协同设计，这些场景要求延迟低于 200 毫秒，否则对话就会「抢话」——你这边刚开口，对方那边已经说完了，整个交流节奏全乱。WebRTC 是这类场景的标配，因为它天然支持双向通信和低延迟。
1.4 主流低延迟协议对比
协议选型是架构师的核心决策之一。选错了，后面改起来成本极高。我把自己用过的几个主流协议做个对比，希望能帮你少走弯路。
1.4.1 WebRTC
WebRTC 是目前低延迟领域的「王者」。它基于 UDP，天然支持 P2P，延迟可以做到 100 毫秒以内。但它的缺点也很明显：
- 架构复杂：需要部署 STUN/TURN 服务器处理 NAT 穿透
- 抗丢包能力弱：纯 UDP 在弱网下容易丢包，需要自己实现 FEC 或 NACK
- 大规模分发困难：P2P 模式不适合万人同时观看的场景
我曾经在一个项目中用 WebRTC 做万人直播，结果 TURN 服务器带宽直接被打满，成本飙升。后来改成了 WebRTC + CDN 混合架构，才把成本降下来。
1.4.2 SRT
SRT 是 Haivision 开源的协议，基于 UDP 但加入了 ARQ（自动重传）机制。它的优势是：
- 抗丢包能力强：适合卫星链路、公共互联网等不稳定环境
- 延迟可控：通常 200-500 毫秒
- 配置简单：不需要 STUN/TURN
但 SRT 的延迟比 WebRTC 高，而且浏览器原生不支持，需要借助插件或转码。我一般用它做「推流端到服务器」的传输，而不是直接到观众端。
1.4.3 LL-HLS
LL-HLS 是 Apple 在 2019 年推出的低延迟版本 HLS。它把传统的 6 秒切片缩小到 1-2 秒，并引入了「部分片段」的概念，让播放器可以更早开始播放。延迟能降到 3-5 秒。
它的优势是兼容性好——所有 Apple 设备原生支持，CDN 也广泛支持。但 3-5 秒的延迟对于互动场景还是不够用。我个人的建议是：如果目标用户以 iOS 为主，且对延迟要求不高，LL-HLS 是个稳妥的选择。
1.4.4 HESP
HESP 是 Harmonic 推出的协议，号称「WebRTC 级别的延迟，HLS 级别的兼容性」。它通过 HTTP/2 的 Server Push 和特殊的切片策略，把延迟压到了 1 秒以内。但它的生态还不够成熟，目前主要用在专业广播领域。
为了让你更直观地对比，我画了一张协议对比图：