直播技术之推流和传输

直播技术之推流和传输

推流和传输。推流是直播的第一千米，直播的推流对这个直播链路影响很是大，若是推流的网络不稳定，不管咱们如何作优化，观众的体验都会很糟糕。因此也是咱们排查问题的第一步，如何系统地解决这类问题须要咱们对相关理论有基础的认识。

推送协议

下面就先介绍一下都有哪些推送协议，他们在直播领域的现状和优缺点。

• RTMP
• WebRTC
• 基于 UDP 的私有协议
• HLS
• FLV

RTMP

RTMP 是 Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于 TCP，是一个协议族，包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE 等多种变种。RTMP 是一种设计用来进行实时数据通讯的网络协议，主要用来在 Flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通讯。支持该协议的软件包括 Adobe Media Server/Ultrant Media Server/red5 等。

RTMP 是目前主流的流媒体传输协议，普遍用于直播领域，能够说市面上绝大多数的直播产品都采用了这个协议。

优势

• CDN 支持良好，主流的 CDN 厂商都支持
• 协议简单，在各平台上实现容易

缺点

• 基于 TCP ，传输成本高，在弱网环境丢包率高的状况下问题显著
  
• 不支持浏览器推送
• Adobe 私有协议，Adobe 已经再也不更新
• 海量并发时也容易出现一些不可预期的稳定性问题

WebRTC

WebRTC，名称源自网页即时通讯（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被归入万维网联盟的 W3C 推荐标准。

目前主要应用于视频会议和连麦中，协议分层以下：

优势

• W3C 标准，主流浏览器支持程度高
• Google 在背后支撑，并在各平台有参考实现
• 底层基于 SRTP 和 UDP，弱网状况优化空间大
• 能够实现点对点通讯，通讯双方延时低

缺点

• ICE,STUN,TURN 传统 CDN 没有相似的服务提供

基于 UDP 的私有协议

有些直播应用会使用 UDP 作为底层协议开发本身的私有协议，由于 UDP 在弱网环境下的优点经过一些定制化的调优能够达到比较好的弱网优化效果，但一样由于是私有协议也势必有现实问题：

优势

更多空间进行定制化优化

缺点

• 开发成本高
• CDN 不友好，须要自建 CDN 或者和 CDN 达成协议
• 独立做战，没法和社区一块儿演进

其余协议

FLV

FLV协议由Adobe公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，因为这种极致的简洁，在延迟表现和大规模并发方面都很成熟。惟一的不足就是在手机浏览器上的支持很是有限，可是用做手机端APP直播协议却异常合适。

HLS

苹果推出的解决方案，将视频分红5-10秒的视频小分片，而后用m3u8索引表进行管理，因为客户端下载到的视频都是5-10秒的完整数据，故视频的流畅性很好，但也一样引入了很大的延迟（HLS的通常延迟在10-30s左右）。相比于FLV， HLS在iPhone和大部分android手机浏览器上的支持很是给力，因此经常使用于QQ和微信朋友圈的URL分享

传输网络

咱们推送出去的流媒体须要传输到观众，整个链路就是传输网络，类比货运物流就是从出发地到目的地见的全部路程了，若是道路的容量不够，会引起堵车也就是网络拥塞，这时咱们会改变路程也就是所谓的智能调度，可是传输网络会站在全局的角度进行调度，因此会比原子世界的调度有更好的效果，能够想象有一个上帝在天空中俯视出发地和目的地间的全部的路况信息，并且仍是实时的，而后给出你一条明路，何等的神奇。

这里先回顾一下传统的内容分发网络。

为何要有内容分发网络，内容分发网络的由来

互联网起源于美国军方的一个内部网络，Tim Berners-Lee 是互联网发明者之一，他很早就预见到在不久的未来网络拥塞将成为互联网发展的最大障碍，因而他提出了一个学术难题，要发明一种全新的、从根本上解决问题的方法来实现互联网内容的无拥塞分发，这项学术难题最终催生出一种革新性的互联网服务——CDN 。当时 Berners-Lee 博士隔壁是 Tom Leighton 教授的办公室，一位麻省理工学院应用数学教授，他被 Berners-Lee 的挑战激起了兴趣。Letghton 最终解决了这个难题并开始本身的商业计划，成立了 Akamai 公司，成为世界上第一家 CDN 公司。

传统 CDN 的架构

上图是一个典型的 CDN 系统的三级部署示意图，节点是 CDN 系统中的最基本部署单元，分为三级部署，中心节点、区域节点和边缘节点，最上面一级是中心节点，中间一级是区域节点，边缘节点地理位置分散，为用户提供就近的内容访问服务。

下面介绍一下 CDN 节点的分类，主要分红两大类，骨干节点和 POP 节点，骨干节点又分为中心节点和区域节点。

• 骨干节点

  • 中心节点

  • 区域节点

• POP节点

  • 边缘节点

逻辑上来说，骨干节点主要负责内容分发和边缘节点未命中时进行回源，POP 节点主要负责提供给用户就近的内容访问服务。但若是 CDN 网络规模较大，边缘节点直接向中心节点回源会给中间层的核心设备形成的压力过大，在物理上引入区域节点，负责一个地理区域的管理，保存部分热点数据。

直播传输网络有别于传统 CDN 的痛点

随着 Live 时代的到来，直播成为当前 CDN 厂商的又一个主要的战场，那么 Live 时代 CDN 须要支持什么样的服务呢？

• 流媒体协议的支持，包括 RTMP，HLS ，HTTP-FLV 等。
• 首屏秒开，从用户点击到播放控制在秒级之内
• 1~3 延迟控制，从推流端到播放端，延迟控制在 1~3 秒之间
• 全球全网智能路由，能够利用整个 CDN 网络内的全部节点为某一单一用户服务，不受地域限制。随着全球一体化进程不断推动，跨区域、跨国家、跨洲的直播正变为常态，极可能主播在欧美，而用户在亚洲。
• 天级别的节点按需增长，中国公司出海已成大势，CDN 须要更多的海外节点，现在比拼的更多的是海外节点能够快速部署，从提出节点增长需求到节点入网提供服务，须要达到一天以内，对 CDN 运维和规划提出很是高的要求。原有的月级别规划和入网知足不了先进的要求。

传统 CDN 的链路路由

CDN 基于树状网络拓扑结构，每一层都有 GSLB (Global Server Load Balancing) 用于同一层内的多个 CDN 节点负载均衡，这样有什么好处呢？

前面提到的众多 CDN 的应用场景中，网页加速、视频加速、文件传输加速，都是同时依赖 GSLB 和 Cache 系统的，Cache 系统是整个 CDN 系统中的成本所在，设计树形结构能够最大化的节省 Cache 系统的资本投入。由于只有中心节点须要保持机会全部的 Cache 副本，向下逐级减小，到了边缘节点只须要少许的热点 Cache 就能够命中大部分 CDN 访问请求，这样极大的下降了 CDN 网络的成本，也符合当时 CDN 用户的需求，可谓共赢。

可是到了 Live 时代，直播业务是流式业务，不多涉及到 Cache 系统，基本都是播完就能够释放掉存储资源，即便由于政策缘由有存储的需求也都是冷存储，对于存储的投入相对很是低廉，并且不要求存储在全部节点中，只要保证数据可回溯，可用便可。

咱们看看树状网络拓扑，用户的链路选择数量是有限的，以下图，用户在某一个区域内可选择的链路数是：2 * 5 = 10

用户在某一区域内，则 GSLB （一般在边缘节点这一层是 Smart DNS）会把用户路由到该区域内的某个边缘节点，上一层又会路由到某个区域节点（这里的 GSLB 一般是内部的负载均衡器），最后又回溯到中心节点，中心节点会连接源站。

这里的假设是：

• 用户能访问的最快节点必定是该区域内的边缘节点，若是该区域没有边缘节点则最快的必定是逻辑相邻的区域内的边缘节点。
• 边缘节点能访问的最快节点必定是该区域内的区域节点，必定不会是其余区域的节点。
• 区域节点到中心节点必定是最快的，这个链路的速度和带宽都是最优的。

但实际真的如此么？引入了如此多的假设真的正确么？

实际上就算理论上咱们能够证实以上假设有效，可是节点规划和区域配置大都依赖于人的设计和规划，咱们知道人可能是不靠谱的，并且就算当时区域规划正确，谁能保证这些静态的网络规划不会由于铺设了一条光纤或者由于某些 IDC 压力过大而发生了改变呢？因此咱们能够跳出树状网络拓扑结构的桎梏，探索新的适合直播加速的网络拓扑结构。

为了摆脱有限的链路路由线路限制，激活整理网络的能力，咱们能够把上述的节点变成网状网络拓扑结构：

咱们看到一旦咱们把网络结构改为了网状结构，则用户的可选择链路变为：无向图的指定两点间的全部路径，学过图论的同窗都知道，数量惊人。

系统能够经过智能路由选择任何一个最快的链路而不用依赖于系统部署时过期的人工规划，不管是某些链路间增长了光纤或者某个 IDC 压力过大均可以实时的反映到整理网络中，帮助用户实时推倒出最优链路。这时咱们能够去掉前面的一些假设，经过机器而不是人类来时实时规划网络的链路路由，这种实时大规模的计算任务天生就不是人类的强项，咱们应该交给更适合的物种。

CDN 的扩容

前面提到中国公司的出海已成大势，CDN 海外节点的需求愈来愈大，遇到这种状况须要 CDN 厂商在新的区域部署新的骨干网和边缘节点，须要作详细的网络规划。时代发生变化，原来 CDN 用户都是企业级用户，自己业务线的迭代周期较长，有较长时间的规划，留给 CDN 厂商的时间也比较多。而互联网公司讲究的是速度，双周迭代已成常态，这里面涉及到成本和响应速度的矛盾，若是提早部署节点能够更好的为这些互联网公司服务，可是有较高的成本压力，反之则没法响应这些快速发展的互联网公司。

理想状况是，用户提出需求，CDN 厂商内部评估，当天给出反馈，当天部署，客户当天就能够测试新区域的新节点。怎么解决？

答案是基于网状拓扑结构的对等网络，在网状拓扑结构中每一个节点都是 Peer ，逻辑上每一个节点提供的服务对等，不须要按区域设计复杂的网络拓扑结构，节点上线后不须要复杂的开局过程，直接上线注册节点信息，就能够对用户提供服务了,结合虚拟化技术先后时间理论上能够控制在一天以内。