RTMP+CDN 技术特点与适用场景
RTMP （Real Time Messaging Protocol）基于 TCP 的流媒体传输协议，最大的特点是与 CDN 的强绑定，需要借助 CDN 的负载均衡系统将内容推送到接近用户的边缘节点，使用户就近取得所需内容，提高用户访问的响应速度和成功率，解决因分布、带宽、服务器性能带来的访问延迟问题。更多适用于站点加速、点播、短视频等场景。
对于初次通过 CDN 服务来实现音视频通信的开发者来说，技术指标应主要关注延时、卡顿率、下载速度、打开速度、回源率、宽带冗余提升率等几个维度。
有研究表明，在 0.1s 以下的延迟，用户几乎是无感知的；1s 左右的延迟，用户会明显注意到延时的发生，但在该时间内思维依然是连贯的；超过 10s 的延时，用户会失去等待的耐心。在所有关键技术指标中，控制延时是 CDN 最需要提升的。
以直播场景为例，延时主要看 2 个核心指标：首播时间和再缓存时间。首播时间即从打开到看到视频画面的时间，会受域名解析、连接、第一包时间的影响，首播时间控制在 1 秒内算是不错的效果。其次是再缓冲时间，是用户观看视频时的卡顿时间。由于实际服务中视频长度不一，一般会做播放的体验统计，主要监测的是卡顿率。行业内而言，直播首播时间 300ms，卡顿率在 15% 以下算是优质的通信服务。
目前的 CDN，通常有 3-5 秒的延迟，在浏览图片、短视频等内容时用户感知不明显，对于不需要实时强互动的直播，比如体育赛事网络直播、演唱会网络直播、新闻现场直播，延迟是可以接受的，并不会影响用户体验。
而在线视频会议、在线教育、电商直播、远程医疗会诊这些对互动有非常高要求的场景，RTMP+CDN 的模式与这些场景对于低延时、无卡顿的要求有一定差距。这时，选择 RTC 技术才能更好地满足开发者的需求。
RTC 技术特点与适用场景
说到 RTC（Real Time Communication）实时音视频通信，它最大的特点就是低延时和无卡顿。从功能流程上说，它包含了采集、编码、前后处理、传输、解码、缓冲、渲染等诸多环节，RTC 不是靠“优化”各环节去实现的实时互动，而是依靠推流端实时的传输机制。
很多实时音视频服务专业厂商使用的就是 WebRTC 标准，这是一种基于浏览器的实时通信的开源解决方案，使用 UDP 私有协议来进行媒体推流，而不需要创建离散的媒体段；并且它是面向无连接的，没有 TCP 连接断开时的挥手确认连接关闭的机制，基于这两点，WebRTC 能够做到毫秒级的低延迟，远远低于基于 RTMP 协议的 CDN 分发的延迟。而且，它直接通过浏览器就可以完成推流和播放，对于开发者接入来说实在太方便。
因此，WebRTC 标准针对有高互动性要求的直播场景尤为适宜。以直播连麦为例，主播端把通信直播流发到观众端，同时也可以把观众端拉上麦，实现主播和观众的互动。使用 WebRTC，内容实时传输，主播和观众可以进行音视频连麦互动，实时沟通，延时一般低至 400ms 以内。
通信云服务商融云相关解决方案
基于 WebRTC 标准的融云实时音视频服务，拥有超低延迟的优势，同时也支持将 RTC 音视频流合流（MCU）转码为 RTMP，并推流到第三方 CDN 上，保留了标准协议普遍被 CDN 网络支持的好处。目前，融云音视频通话，可做到全球端到端延时小于 400ms，最低延时 66ms；低延时互动直播的直播推流可以做到主播观众间延迟在 300ms 左右，保障端到端之间延迟无感知的实时互动。
CDN vs RTC 选型还需看价格服务综合比
一套实时音视频通信能力的搭建，除了要根据场景选择适合的技术外，还要看价格、服务的综合性价比。通常来说，使用 RTC 技术的成本比 RTMP+CDN 高。因为，从实践来看，UDP 传输比 TCP 传输对资源消耗要多，而且重传、封包、FEC 冗余计算等都会额外增加计算量，在多进程模式下可能还会遇到内存资源的过多消耗，这些都导致开发及使用成本的增加。
开发者选型中，性价比需综合技术特点、适用场景、价格和服务四个方面的全面考量。服务在产品上线前后的开发阶段和运营阶段，都要发挥重要作用。目前，开发者服务做得比较好的厂商比如融云，会与开发者共建开发文档，技术手册短视频化，提供场景化的 Demo，以及在官网搭建开发者专区，帮助开发者更便捷、更快速的理解 SDK。
融云全新升级的实时音视频服务，提出“以一套 SDK 解决所有通信场景”，使用融云 RTC 的开发者，同时可以用融云 IM 作为信令通道，而不用自己重新搭建或选择第三方信令通道，这样可以大大提升开发效率，减少 SDK 文档学习时间。
总体而言，RTC 低延迟直播是未来发展的趋势，而 RTMP 在当前依然拥有价格上的优势，而两者作为音视频领域的实用技术，无论是适用场景、还是贴近开发的服务都越来越多样化，开发者未来选型之路也将更顺畅。
