随着直播场景的不断延伸，对于直播效果的优化也渐渐成为了直播平台和直播技术服务商的升级重点。在直播中，经常会遇到对延迟有要求或者网络环境较差的场景。因此基于RTC协议的移动直播技术的使用也变得频繁起来。今天智密科技就来为大家分析一下在移动直播中选择传统的RTMP协议还是RTC协议
RTMP协议
RTMP （Real Time Messaging Protocol）基于 TCP 的流媒体传输协议，最大的特点是与 CDN 的强绑定，需要借助 CDN 的负载均衡系统将内容推送到接近用户的边缘节点，使用户就近取得所需内容，提高用户访问的响应速度和成功率，解决因分布、带宽、服务器性能带来的访问延迟问题。更多适用于站点加速、点播、短视频等场景。
对于初次通过 CDN 服务来实现音视频通信的开发者来说，技术指标应主要关注延时、卡顿率、下载速度、打开速度、回源率、宽带冗余提升率等几个维度。
有研究表明，在 0.1s 以下的延迟，用户几乎是无感知的；1s 左右的延迟，用户会明显注意到延时的发生，但在该时间内思维依然是连贯的；超过 10s 的延时，用户会失去等待的耐心。在所有关键技术指标中，控制延时是 CDN 最需要提升的。
以直播场景为例，延时主要看 2 个核心指标：首播时间和再缓存时间。首播时间即从打开到看到视频画面的时间，会受域名解析、连接、第一包时间的影响，首播时间控制在 1 秒内算是不错的效果。其次是再缓冲时间，是用户观看视频时的卡顿时间。由于实际服务中视频长度不一，一般会做播放的体验统计，主要监测的是卡顿率。行业内而言，直播首播时间 300ms，卡顿率在 15% 以下算是优质的通信服务。
目前的 CDN，通常有 3-5 秒的延迟，在浏览图片、短视频等内容时用户感知不明显，对于不需要实时强互动的直播，比如体育赛事网络直播、演唱会网络直播、新闻现场直播，延迟是可以接受的，并不会影响用户体验。
RTC 协议
说到 RTC（Real Time Communication）实时音视频通信，它最大的特点就是低延时和无卡顿。从功能流程上说，它包含了采集、编码、前后处理、传输、解码、缓冲、渲染等诸多环节，RTC 不是靠“优化”各环节去实现的实时互动，而是依靠推流端实时的传输机制。
很多实时音视频服务专业厂商使用的就是 WebRTC 标准，这是一种基于浏览器的实时通信的开源解决方案，使用 UDP 私有协议来进行媒体推流，而不需要创建离散的媒体段；并且它是面向无连接的，没有 TCP 连接断开时的挥手确认连接关闭的机制，基于这两点，WebRTC 能够做到毫秒级的低延迟，远远低于基于 RTMP 协议的 CDN 分发的延迟。而且，它直接通过浏览器就可以完成推流和播放，对于开发者接入来说实在太方便。
正常网络及弱网环境下的效果质量
测试场景
主播推流，观众通过 CDN 观看。在主播端进行各种弱网限制，观察观众播放的效果质量。本文档弱网环境只针对上行，下行网络为无损状态。
参数配置
为了避免受不同源的影响，使用 RTMP 和 RTC 推流时都固定使用 V2TXLivePusher 推同一个本地视频。
视频参数：
参数类型 | 配置信息 |
分辨率 | 720 × 1280 |
码率 | 1800 kbps |
帧率 | 15 |
几种弱网场景下关键指标的对比
帧率
编辑
卡顿率
附录：网络参数说明
参数 | 说明 |
帧率 | 每秒钟渲染帧数 |
丢包率 | 50% 代表发送了10个数据包中会丢失5个 |
时延 | 200ms 时延代表 SDK 发送的包，会经过 200ms 后才被网络发送出去 |
限速 | 800kbps 代表每秒钟最多发送 800kb 的数据 |
卡帧率 | 渲染间隔大于 200ms 表示卡顿，卡顿率等于卡顿时间总和除以总播放时长 |
