RTC 优先的设计原理
本文档解释了为什么我们的系统采用 RTC 优先 策略，而不是主要基于 WebSockets 搭建。 对于开发者来说，这意味着你将获得一个 低延迟、媒体优先的管道，它已经内置好了，无需从零实现设备采集、编解码器或传输逻辑。
为什么选择 RTC 优先？
- 低延迟： RTC 通过使用 UDP + SRTP 避免了 TCP 的队头阻塞。
- 媒体原生： 可直接访问麦克风、摄像头和屏幕捕获。
- 编解码器集成： 支持 Opus、VP8/VP9/AV1、H.264，并具备硬件加速。
- 同步能力： 音频、视频和数据通道在同一会话中对齐。
- 跨平台： 适用于浏览器、移动端和原生应用。
相比之下，WebSockets 更适合结构化数据交换，但缺乏：
- 原生媒体采集
- 编码/解码支持
- 带宽自适应
- 内置同步
RTC 与 WebSocket 对比
| 功能 | RTC | WebSocket |
|---|---|---|
| 传输协议 | UDP（SRTP、DTLS、ICE、拥塞控制） | TCP（单一有序流） |
| 延迟 | ~50–150ms（为实时优化） | 更高（队头阻塞） |
| 媒体支持 | 原生麦克风/摄像头/屏幕采集 | 无（仅原始二进制/文本） |
| 编码/解码 | 内置编解码器（Opus、VP8、H.264、AV1） | 外部/手动实现 |
| 同步能力 | 多流音视频同步 + 数据通道 | 需要手动实现 |
| 自适应能力 | 带宽估计、自适应码率、前向纠错（FEC） | 不支持 |
| 最佳适用场景 | 通话、直播、AI Agents、实时应用 | 聊天、信令、异步事件 |
我们的系统默认集成了由 Agora RTC 提供支持的 RTC 模块，因此开发者无需操心设备采集、编解码或传输底层实现。
从实际使用角度来看：
- 配置最小化： RTC 开箱即用。
- WebSockets 仍然有用： 非常适合信令、配置或偶发的异步更新。
- RTC 是推荐通道： 在实时、多模态交互中，延迟、同步和质量才是最重要的。
通过采用 RTC 优先，我们能够确保：
- 跨设备和平台的实时性能。
- 一致的开发体验，内置媒体管道。
- 能够灵活扩展异步特性，同时保持 RTC 的保证。
简而言之，开发者可以专注于 构建功能，而不是重新造一套传输栈。
在 GitHub 上编辑
最后更新