上一篇讲完架构这一篇把镜头拉到链路的最底层**推流协议选型和多档画质**。这两个话题经常被分开讲但它们其实是同一件事的两面协议决定了「丢包时怎么办」编码方式决定了「一次推流能出几档画质」而这两者又共同决定了弱网下观众看到的是什么。我们先把三种主流推流协议的权衡机制讲透再讲清楚「多档画质、服务端免转码」到底是怎么实现的。---## 一、先从「丢包怎么办」看三种协议判断一个协议适不适合互动直播最有效的角度不是背结论而是看它在丢包时做什么选择。### RTMP继承 TCP 的可靠有序RTMP 通常建立在持久 TCP 连接上消息被切成 chunk 并在多个 chunk stream 上复用控制命令和数据用 AMF 序列化音视频消息承载对应的编码数据。RTMPS 是在 TLS 上承载 RTMP提供机密性和完整性但**不消除 TCP 的队头阻塞**。这套设计在它诞生的年代是合理的TCP 的可靠传输省去了协议自己处理丢包重传的麻烦。但代价就是我们上一篇讲过的队头阻塞——任何分节丢失后面已到达的数据都要排队等它重传。今天 RTMP 在生态里的位置已经很单薄播放侧因为浏览器不再原生支持 Flash 播放基本退场仅剩的价值是一些老旧推流工具只认它。而即便是「推流入口」这层价值也在被 SRT 和 WHIP 取代。### SRT为弱网而生的现代化选择SRT 建立在 UDP 之上面向不稳定网络中的低时延可靠传输。理解它要把三个机制分开- **ARQ自动重传请求**接收端根据序列号发现缺包并发送 NAK发送端在数据仍有时效时重传。它解决「怎么恢复丢包」。- **TSBPD基于时间的包交付**依据发送时间戳和协商的 latency 安排包何时交付吸收网络抖动、恢复发送时序。它解决「何时交付」。- **过期包丢弃**启用并满足条件时放弃已来不及按计划交付的数据。它解决「何时停止补救」。latency 这个参数给重传和抖动吸收提供时间预算调大通常提高恢复机会、增加交付等待调小则相反。但它**不是整个 SRT 会话的严格数学时延上界**——握手、网络排队、应用缓冲、断线重连都在它之外。这也解释了为什么 SRT 入库的端到端时延通常比 WHIP 高它是「用延迟换弱网鲁棒性」的有意取舍不是实现缺陷。### WHIP把 WebRTC 标准化成推流协议WHIP 本质上不是全新的传输协议而是给 WebRTC 补上了一套标准化的「推流签约流程」用 HTTP 完成 SDP offer/answer 交换媒体仍走 WebRTC 原生栈- **ICE** 负责打通网络路径含 NAT 穿透的地址协商- **DTLS-SRTP** 负责媒体链路加密注意若媒体在边缘终止 SRTP 后重新加密转发它是逐段保护不等于端到端加密- **RTP** 承载媒体配合 **NACK**选择性重传和可选的 **FEC**前向纠错处理丢包拥塞控制动态调整发送码率。WHIP 没有 SRT 的 TSBPDRTP 接收端通常按**包数或字节数**维护重排历史。这里有个容易搞混的点**包缓存数量不等于时间窗口**——同样 512 个包在不同码率、包长和帧率下覆盖的时间完全不同不能由它直接推出播放等待时延。WHIP 已经正式发布为 RFC 9725不再是草案。---## 二、三者横向对比| 维度 | RTMP | SRT | WHIP || --- | --- | --- | --- || 传输层 | TCP | UDP ARQ | UDP RTPNACK / FEC / 拥塞控制 || 丢包处理 | TCP 必须重传并按序交付可能队头阻塞 | ARQ 恢复TSBPD 定时交付可丢弃过期包 | NACK/FEC 依协商与实现使用jitter buffer 和解码截止策略决定是否等待 || 延迟边界 | 无严格数学上界 | latency 是工程预算不是无条件端到端上界 | 动态缓冲与拥塞控制无无条件数学上界 || 加密 | 本身无加密RTMPS 用 TLS | 可配置 AES payload 加密 | 强制 DTLS-SRTP 链路加密不自动等于 E2EE || 浏览器原生支持 | 已不支持 | 不支持 | 原生支持 || 典型定位 | 历史遗留正在退出 | 弱网上行的现代选择 | 主流实时推流/播放协议 |结论不是「谁打败谁」而是**它们没有脱离实现与网络条件的数学延迟上界。**「TCP 不好、UDP 好」这种粗线条判断会漏掉真正的工程重点——丢包时的取舍策略。---## 三、工程上怎么选统一信号差异化处理一个务实的做法是让 WHIP 和 SRT **共存**服务不同场景- 网络干净、追求最低延迟时优先 **WHIP**- 上行不稳定、需要更强鲁棒性时用 **SRT**用一点延迟换可靠性。两者的原生统计口径并不等价SRT 有 loss / retrans / drop / too-late 等RTP 侧是序列号缺口 / NACK / RTX / FEC所以不能把两边的计数器直接套进同一个公式。正确做法是**在接收端按统一采样窗口、原包身份、恢复结果和播放 deadline 派生产品指标再驱动同一套降级决策。**降级动作分两步代价从低到高1. **先降编码码率**实时生效不中断推流2. **码率降到底仍不达标才降分辨率**砍同播层数需要重启推流有短暂中断。背后的逻辑很直接调码率零代价可以频繁触发调层数有中断代价只有在「压到底都不够」时才动用。同样重要的是**恢复要慢、要稳**——质量指标回落到恢复区间并持续观察一段时间后才逐级恢复避免「加了又砍、砍了又加」的震荡。 采样窗口、降级阈值、恢复阈值、冷却时间都是需要按协议、方向、内容档位和终端能力**配置并由真实网络数据校准的产品参数**不是协议常数。任何把某组实验值讲成「通用阈值」的说法都要警惕。---## 四、多档画质的两种做法服务端转码 vs Simulcast想要「1080P / 720P / 360P 同播」有两条路。**传统做法服务端转码。** 服务端先把收到的流完整解码成原始画面再按每个目标档位重新编码一遍。解码 多次重新编码是相当重的计算负担而且天然带来额外处理延迟费用也按输出档位和时长单独计。**Simulcast推流端一次出多档。** 关键要理解一句话**Simulcast 不是「一份编码、服务端裁剪出多档」而是发送端同时产生多份可独立解码的编码。** 比如一路 1080P 输入开 3 层 Simulcast就产生 1080P、720P、360P 三份独立编码分别以 RTP 发送推流端编码器│├── 主编码器1080P──▶ RTP 流RID high├── 缩放层编码器720P──▶ RTP 流RID mid└── 缩放层编码器360P──▶ RTP 流RID low三条流各自独立、完整可解码服务端按 RID 识别并转发对应层服务端收到每一层时它已经是可直接转发给观众的完整画面**不需要解码、不需要重新编码只做字节转发**。这就是「网络侧不用转码」的技术根因转码的工作量没有消失只是被挪到了推流端的编码器上——**用推流端的编码算力换服务端的转码算力。**---## 五、为什么是 Simulcast不是 SVC懂一点编解码的人会问可分层编码SVC不是更省带宽吗- **SVC 的思路**编码输出包含基础层和一个或多个增强层层之间有依赖关系转发端可按依赖结构选择转发子集通常比多份完全独立编码更省总码率。- **代价是复杂度和兼容性**转发端必须正确处理层标识、依赖关系和切换点接收端也必须支持对应的 codec/profile/scalability mode。H264/HEVC 是否可用 SVC取决于浏览器、系统解码器、协商和产品实现。所以选 Simulcast 还是 SVC**本质是当前终端矩阵下的兼容性取舍不是哪个标准更先进**。选型时应以目标终端矩阵和互操作测试为准而不是听某一家产品的现状。---## 六、无缝切换切换点必须「可独立解码」最后一个关键问题观众从 720P 切到 360P 时怎么切才不花屏答案和点播的码率切换是**同一条原理**独立编码的流只能从一个可解码的接入点开始接入解码器不能从中间任意一点切入。点播里表现为「只在分片边界换档」直播的 Simulcast 分层切换里表现为「等待目标层的随机接入点常见是请求关键帧」观众当前播放 mid 档720P│▼检测到丢包率上升决定降档到 low360P│▼请求或等待 low 层的可用关键帧│▼从该关键帧开始改为转发 low 层数据要注意**关键帧边界本身不等于无条件无缝**。是否无感取决于关键帧等待时间、缓冲状态和 RTP 连续性处理。关键帧请求会消耗码率、存在等待时间所以正确切换能避免引用链损坏和花屏但不保证零等待、零卡顿。顺便借这个原理聊聊向头部点播平台学什么它们的 ABR 决策不只看瞬时网速还看**播放缓冲区还剩多少内容**切换点严格对齐编码阶梯按内容定制。这些思路可以借鉴但**点播和直播的约束差一个数量级**——点播可以攒大缓冲、可以离线反复试验最优编码参数低延迟直播缓冲预算更小、编码必须实时。照抄参数会出问题能真正复用的是决策哲学**以观感为中心而不是以某个单一技术指标为中心。**---## 小结- **三种协议看丢包策略**RTMP 继承 TCP 的队头阻塞SRT 用 ARQ TSBPD 过期丢弃换弱网鲁棒性WHIP 复用 WebRTC/RTP 的反馈、拥塞控制和动态缓冲。- **共存优于二选一**WHIP 追低延迟SRT 保弱网上行两者统计口径不同要在接收端派生统一的产品指标再驱动降级。- **降级有代价梯度**先压码率不中断再砍分辨率短暂中断恢复要慢要稳。- **多档画质靠 Simulcast**发送端出多份独立编码服务端只转发不转码用推流端算力换服务端算力。- **无缝切换的通用原理**在可独立解码、时间线连续的位置切换关键帧是常用但非唯一的手段。下一篇我们讲一个同样容易被忽略、但直接关系业务安全的话题**推拉流的签名、Token 与防盗链**。---**系列导航**- 上一篇[02 · 自建 CDN 架构总览](02-自建CDN架构总览-控制面与媒体面分离.md)- 下一篇[04 · 推拉流安全签名、Token 与防盗链](04-推拉流安全-签名Token与防盗链.md)- 返回[系列导览](README.md) 03-传输协议与多档画质：RTMP / SRT / WHIP 与 Simulcast
上一篇讲完架构这一篇把镜头拉到链路的最底层**推流协议选型和多档画质**。这两个话题经常被分开讲但它们其实是同一件事的两面协议决定了「丢包时怎么办」编码方式决定了「一次推流能出几档画质」而这两者又共同决定了弱网下观众看到的是什么。我们先把三种主流推流协议的权衡机制讲透再讲清楚「多档画质、服务端免转码」到底是怎么实现的。---## 一、先从「丢包怎么办」看三种协议判断一个协议适不适合互动直播最有效的角度不是背结论而是看它在丢包时做什么选择。### RTMP继承 TCP 的可靠有序RTMP 通常建立在持久 TCP 连接上消息被切成 chunk 并在多个 chunk stream 上复用控制命令和数据用 AMF 序列化音视频消息承载对应的编码数据。RTMPS 是在 TLS 上承载 RTMP提供机密性和完整性但**不消除 TCP 的队头阻塞**。这套设计在它诞生的年代是合理的TCP 的可靠传输省去了协议自己处理丢包重传的麻烦。但代价就是我们上一篇讲过的队头阻塞——任何分节丢失后面已到达的数据都要排队等它重传。今天 RTMP 在生态里的位置已经很单薄播放侧因为浏览器不再原生支持 Flash 播放基本退场仅剩的价值是一些老旧推流工具只认它。而即便是「推流入口」这层价值也在被 SRT 和 WHIP 取代。### SRT为弱网而生的现代化选择SRT 建立在 UDP 之上面向不稳定网络中的低时延可靠传输。理解它要把三个机制分开- **ARQ自动重传请求**接收端根据序列号发现缺包并发送 NAK发送端在数据仍有时效时重传。它解决「怎么恢复丢包」。- **TSBPD基于时间的包交付**依据发送时间戳和协商的 latency 安排包何时交付吸收网络抖动、恢复发送时序。它解决「何时交付」。- **过期包丢弃**启用并满足条件时放弃已来不及按计划交付的数据。它解决「何时停止补救」。latency 这个参数给重传和抖动吸收提供时间预算调大通常提高恢复机会、增加交付等待调小则相反。但它**不是整个 SRT 会话的严格数学时延上界**——握手、网络排队、应用缓冲、断线重连都在它之外。这也解释了为什么 SRT 入库的端到端时延通常比 WHIP 高它是「用延迟换弱网鲁棒性」的有意取舍不是实现缺陷。### WHIP把 WebRTC 标准化成推流协议WHIP 本质上不是全新的传输协议而是给 WebRTC 补上了一套标准化的「推流签约流程」用 HTTP 完成 SDP offer/answer 交换媒体仍走 WebRTC 原生栈- **ICE** 负责打通网络路径含 NAT 穿透的地址协商- **DTLS-SRTP** 负责媒体链路加密注意若媒体在边缘终止 SRTP 后重新加密转发它是逐段保护不等于端到端加密- **RTP** 承载媒体配合 **NACK**选择性重传和可选的 **FEC**前向纠错处理丢包拥塞控制动态调整发送码率。WHIP 没有 SRT 的 TSBPDRTP 接收端通常按**包数或字节数**维护重排历史。这里有个容易搞混的点**包缓存数量不等于时间窗口**——同样 512 个包在不同码率、包长和帧率下覆盖的时间完全不同不能由它直接推出播放等待时延。WHIP 已经正式发布为 RFC 9725不再是草案。---## 二、三者横向对比| 维度 | RTMP | SRT | WHIP || --- | --- | --- | --- || 传输层 | TCP | UDP ARQ | UDP RTPNACK / FEC / 拥塞控制 || 丢包处理 | TCP 必须重传并按序交付可能队头阻塞 | ARQ 恢复TSBPD 定时交付可丢弃过期包 | NACK/FEC 依协商与实现使用jitter buffer 和解码截止策略决定是否等待 || 延迟边界 | 无严格数学上界 | latency 是工程预算不是无条件端到端上界 | 动态缓冲与拥塞控制无无条件数学上界 || 加密 | 本身无加密RTMPS 用 TLS | 可配置 AES payload 加密 | 强制 DTLS-SRTP 链路加密不自动等于 E2EE || 浏览器原生支持 | 已不支持 | 不支持 | 原生支持 || 典型定位 | 历史遗留正在退出 | 弱网上行的现代选择 | 主流实时推流/播放协议 |结论不是「谁打败谁」而是**它们没有脱离实现与网络条件的数学延迟上界。**「TCP 不好、UDP 好」这种粗线条判断会漏掉真正的工程重点——丢包时的取舍策略。---## 三、工程上怎么选统一信号差异化处理一个务实的做法是让 WHIP 和 SRT **共存**服务不同场景- 网络干净、追求最低延迟时优先 **WHIP**- 上行不稳定、需要更强鲁棒性时用 **SRT**用一点延迟换可靠性。两者的原生统计口径并不等价SRT 有 loss / retrans / drop / too-late 等RTP 侧是序列号缺口 / NACK / RTX / FEC所以不能把两边的计数器直接套进同一个公式。正确做法是**在接收端按统一采样窗口、原包身份、恢复结果和播放 deadline 派生产品指标再驱动同一套降级决策。**降级动作分两步代价从低到高1. **先降编码码率**实时生效不中断推流2. **码率降到底仍不达标才降分辨率**砍同播层数需要重启推流有短暂中断。背后的逻辑很直接调码率零代价可以频繁触发调层数有中断代价只有在「压到底都不够」时才动用。同样重要的是**恢复要慢、要稳**——质量指标回落到恢复区间并持续观察一段时间后才逐级恢复避免「加了又砍、砍了又加」的震荡。 采样窗口、降级阈值、恢复阈值、冷却时间都是需要按协议、方向、内容档位和终端能力**配置并由真实网络数据校准的产品参数**不是协议常数。任何把某组实验值讲成「通用阈值」的说法都要警惕。---## 四、多档画质的两种做法服务端转码 vs Simulcast想要「1080P / 720P / 360P 同播」有两条路。**传统做法服务端转码。** 服务端先把收到的流完整解码成原始画面再按每个目标档位重新编码一遍。解码 多次重新编码是相当重的计算负担而且天然带来额外处理延迟费用也按输出档位和时长单独计。**Simulcast推流端一次出多档。** 关键要理解一句话**Simulcast 不是「一份编码、服务端裁剪出多档」而是发送端同时产生多份可独立解码的编码。** 比如一路 1080P 输入开 3 层 Simulcast就产生 1080P、720P、360P 三份独立编码分别以 RTP 发送推流端编码器│├── 主编码器1080P──▶ RTP 流RID high├── 缩放层编码器720P──▶ RTP 流RID mid└── 缩放层编码器360P──▶ RTP 流RID low三条流各自独立、完整可解码服务端按 RID 识别并转发对应层服务端收到每一层时它已经是可直接转发给观众的完整画面**不需要解码、不需要重新编码只做字节转发**。这就是「网络侧不用转码」的技术根因转码的工作量没有消失只是被挪到了推流端的编码器上——**用推流端的编码算力换服务端的转码算力。**---## 五、为什么是 Simulcast不是 SVC懂一点编解码的人会问可分层编码SVC不是更省带宽吗- **SVC 的思路**编码输出包含基础层和一个或多个增强层层之间有依赖关系转发端可按依赖结构选择转发子集通常比多份完全独立编码更省总码率。- **代价是复杂度和兼容性**转发端必须正确处理层标识、依赖关系和切换点接收端也必须支持对应的 codec/profile/scalability mode。H264/HEVC 是否可用 SVC取决于浏览器、系统解码器、协商和产品实现。所以选 Simulcast 还是 SVC**本质是当前终端矩阵下的兼容性取舍不是哪个标准更先进**。选型时应以目标终端矩阵和互操作测试为准而不是听某一家产品的现状。---## 六、无缝切换切换点必须「可独立解码」最后一个关键问题观众从 720P 切到 360P 时怎么切才不花屏答案和点播的码率切换是**同一条原理**独立编码的流只能从一个可解码的接入点开始接入解码器不能从中间任意一点切入。点播里表现为「只在分片边界换档」直播的 Simulcast 分层切换里表现为「等待目标层的随机接入点常见是请求关键帧」观众当前播放 mid 档720P│▼检测到丢包率上升决定降档到 low360P│▼请求或等待 low 层的可用关键帧│▼从该关键帧开始改为转发 low 层数据要注意**关键帧边界本身不等于无条件无缝**。是否无感取决于关键帧等待时间、缓冲状态和 RTP 连续性处理。关键帧请求会消耗码率、存在等待时间所以正确切换能避免引用链损坏和花屏但不保证零等待、零卡顿。顺便借这个原理聊聊向头部点播平台学什么它们的 ABR 决策不只看瞬时网速还看**播放缓冲区还剩多少内容**切换点严格对齐编码阶梯按内容定制。这些思路可以借鉴但**点播和直播的约束差一个数量级**——点播可以攒大缓冲、可以离线反复试验最优编码参数低延迟直播缓冲预算更小、编码必须实时。照抄参数会出问题能真正复用的是决策哲学**以观感为中心而不是以某个单一技术指标为中心。**---## 小结- **三种协议看丢包策略**RTMP 继承 TCP 的队头阻塞SRT 用 ARQ TSBPD 过期丢弃换弱网鲁棒性WHIP 复用 WebRTC/RTP 的反馈、拥塞控制和动态缓冲。- **共存优于二选一**WHIP 追低延迟SRT 保弱网上行两者统计口径不同要在接收端派生统一的产品指标再驱动降级。- **降级有代价梯度**先压码率不中断再砍分辨率短暂中断恢复要慢要稳。- **多档画质靠 Simulcast**发送端出多份独立编码服务端只转发不转码用推流端算力换服务端算力。- **无缝切换的通用原理**在可独立解码、时间线连续的位置切换关键帧是常用但非唯一的手段。下一篇我们讲一个同样容易被忽略、但直接关系业务安全的话题**推拉流的签名、Token 与防盗链**。---**系列导航**- 上一篇[02 · 自建 CDN 架构总览](02-自建CDN架构总览-控制面与媒体面分离.md)- 下一篇[04 · 推拉流安全签名、Token 与防盗链](04-推拉流安全-签名Token与防盗链.md)- 返回[系列导览](README.md)