RTC 如何成为流媒体时代的实时基础设施
内容提要
RTC正从应用能力演变为流媒体底层基础设施。相比HLS等延迟较高的点播架构，RTC基于UDP，以时效优先，通过抖动缓冲、FEC和拥塞控制保障交互体验。SFU等媒体服务器架构支撑大规模并发，并与CDN分工协作。RTC还承载状态同步，需借助边缘计算降低延迟。150毫秒是体验阈值，未来实时能力将成为业务基线。
延伸解读
RTC 与 CDN：分工而非替代
文章指出，RTC 不会取代 CDN，而是与 CDN 在同一业务链路中分工协作。典型架构中，主播端用 RTC 或 SRT/RTMP 低延迟上行，服务器处理后，一路走 RTC 下行给需要强交互的观众，另一路转封装为 HLS 通过 CDN 分发给只观看的海量用户。关键是根据用户角色的真实需求分配延迟预算，而非统一低延迟或统一点播。
状态同步：RTC 的隐藏价值
许多团队只把 RTC 当音视频通道，低估了其能力。文章强调，实时业务中屏幕画面与后台数据库状态必须严格对齐。通过 RTC 的数据通道，将带时间戳的元数据、业务事件与控制指令与媒体流复用同一链路，使 UI 状态更新与画面渲染锁定在同一时间轴。因此，成熟的 RTC 平台往往具备信令、数据通道、白板、消息、录制等能力，它们不是附加功能，而是实时体验成立的必要组件。
边缘计算：突破物理延迟的必选项
无论协议多精简，最终都会撞上光速。如果主播信号需跨越半个地球到中心机房处理再折返，物理往返就会吃掉大半延迟预算。边缘计算让用户连接在几十公里内的边缘节点完成终止与处理，将媒体流物理传输距离从数千公里压缩为本地骨干网几跳。对于全球部署的业务，这往往不是优化项，而是能否做的前提。
150 毫秒：体验的心理阈值
文章引用国际电信标准组织的结论：单程延迟在 150 毫秒以内时，对话感觉接近面对面；150 到 400 毫秒之间，参与者会意识到不自然但仍可接受；超过 400 毫秒，对话退化为轮流发言。对产品而言，这条线是体验分野。低于 150 毫秒后，用户不再感到在操作工具，而是感觉与对方同处一空间。因此工程师宁愿砍码率也要守住延迟。
Q&A
RTC 和传统流媒体协议（如 HLS）在延迟上为什么有本质区别？
传统流媒体协议如 HLS、DASH 基于 HTTP，将视频切成 2 到 6 秒的分片，延迟被结构性地锁死在至少一个分片长度以上，端到端五到十秒是常态。而 RTC 基于 UDP，以时效性优先，不追求完整重传，而是跳过过期数据，从而将延迟降到交互级别。
RTC 在传输层用了哪些关键技术来保证弱网下的交互体验？
RTC 使用抖动缓冲（jitter buffer）平抑网络到达时间的波动；用前向纠错（FEC）和选择性重传（NACK）在丢包和延迟之间做权衡；用带宽估计与拥塞控制（如 GCC 类算法）实时调整码率、分辨率和帧率，让画面在弱网下降质但不中断。
SFU 是什么？它为什么能支撑大规模 RTC 并发？
SFU（选择性转发单元）是一种媒体服务器架构，它只接收主讲端上传的一路或几路高质量码流，然后按每个订阅者的网络状况，只转发其真正需要的那一层，全程不做重新编码。这个不转码的特性把服务器成本从按人数做编解码压到了按人数做转发，使规模化在商业上成立。
RTC 和 CDN 是替代关系吗？它们在实际业务中如何分工？
不是替代关系，而是合流。典型现代直播架构中，主播端用 RTC 或 SRT/RTMP 做低延迟上行，服务器处理后，一路走 RTC 下行给需要强交互的观众，另一路转封装为低延迟 HLS 或普通 HLS，通过 CDN 分发给只观看的海量长尾用户。关键是把延迟预算按用户角色的真实需求来分配。
为什么说 RTC 承载的不只是音视频，而是状态同步？
因为实时业务中，屏幕上看到的画面必须与后台数据库状态严格对齐。如果状态更新滞后，体验可信度就会崩塌。解决方式是把带时间戳的元数据、业务事件、控制指令，直接通过 RTC 的数据通道与媒体流复用同一条链路传输，让 UI 层的状态更新与画面渲染锁定在同一个时间轴上。
为什么 RTC 必须依赖边缘计算？
因为物理距离无法突破光速。如果信号必须跨越半个地球到中心机房处理再折返，仅物理往返就会吃掉大半延迟预算。边缘计算让用户连接在几十公里内的边缘节点完成终止与处理，把媒体流的物理传输距离从数千公里压缩为本地骨干网上的几跳，对于全球部署的业务，这往往是能不能做的前提。
150 毫秒延迟阈值对用户体验意味着什么？
单程延迟在 150 毫秒以内时，对话感觉接近面对面；150 到 400 毫秒之间，参与者会开始意识到不自然但仍可接受；超过 400 毫秒，对话退化为轮流发言。跌到 150 毫秒以下后，界面会消失，用户感觉与对方同处一个空间，这种心理转变是任何分辨率提升都换不来的。
