视频直播技术详解之推流和传输

大家好，又见面了，我是你们的朋友全栈君。

声明：本文为CSDN原创投稿文章，未经许可，禁止任何形式的转载。 作者：七牛云 责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008申请入群，备注姓名 公司 职位。

七牛云于6月底发布了一个针对视频直播的实时流网络LiveNet和完整的直播云解决方案，很多开发者对这个网络和解决方案的细节和使用场景非常感兴趣。

结合该实时流网络LiveNet和直播云解决方案的实践，我们将用七篇文章，更系统化地介绍当下大热的视频直播各环节的关键技术，帮助视频直播创业者们更全面、深入地了解视频直播技术，更好地技术选型。

本系列文章大纲如下：

（一）采集 （二）处理 （三）编码和封装 （四）推流和传输 （五）现代播放器原理 （六）延迟优化 （七）SDK性能测试模型

在上一期的处理篇中，我们介绍了讲解编码和封装。本篇是《解密视频直播技术》系列之四：推流和传输。推流是直播的第一公里，直播的推流对这个直播链路影响非常大，如果推流的网络不稳定，无论我们如何做优化，观众的体验都会很糟糕。所以也是我们排查问题的第一步，如何系统地解决这类问题需要我们对相关理论有基础的认识。

推送协议

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

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

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达成协议
• 独立作战，无法和社区一起演进

传输网络

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

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

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

互联网起源于美国军方的一个内部网络，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，逻辑上每个节点提供的服务对等，不需要按区域设计复杂的网络拓扑结构，节点上线后不需要复杂的开局过程，直接上线注册节点信息，就可以对用户提供服务了,结合虚拟化技术前后时间理论上可以控制在一天之内。

回归本质：LiveNet

我们知道最早的互联网就是网状拓扑结构，后来才慢慢加入了骨干网来解决各种各样的问题，我们是时候该回归本质，拥抱下一代Live分发网络：LiveNet。总结前面的讨论，我们发现Live时代我们需要的内容分发网络是：

• 对Cache的要求没有以前那么高
• 对实时性的要求非常高
• 对节点运维的要求高，要更智能，尽量减少人工干预
• 对扩容这种运维事件响应度要求非常高

要做到如上几点，我们需要：

• 去中心化，网状拓扑
• 全球全网调度
• 节点无状态，节点对等
• 智能运维

以上这些就是LiveNet设计时候的斟酌，让运维更自动化，系统运行高度自治，依赖机器计算而不是人工判断，下面分别介绍一下。

去中心，网状拓扑

网状拓扑结构是设计的根本和基础，只有看清了我们对Cache需求的降低，网状拓扑结构才更有优势。

全球全网调度

基于全球一张网，不在受限于区域网络调度，将调度的范围从区域网络扩展到全球，全网内的节点都可以响应用户的请求，参与链路路由，不再先由人工假设选定一部分节点进行路由，去掉人工干预，让整个系统更智能。

节点无状态，节点对等

LiveNet节点无状态和节点对等都方便了运维，去掉了区域概念后的全球一张网让整个拓扑结构变的异常复杂，如果各个节点间有先后依赖关系，势必让运维成为噩梦，需要专有的服务编排系统，同时也给扩容带来困难，需要运维人员设计复杂的扩容方案，需要预演多次才敢在复杂的网络拓扑中扩容。当时如果节点本身对等且无状态，则运维和扩容都变的容易很多。

但整个系统在运行过程中还是会一些状态和数据需要保持，比如某些Live内容需要落地回放的需求，这些通过久经考验的七牛云存储来存储。

智能运维

智能运维建立在以上的「网状拓扑结构的对等网络」的基础上会变的容易的多。可以方便的下线有问题的节点而不影响整个LiveNet网络，可以方便快速的上线新节点，提升系统容量。通过节点的数据分析可以更好的了解整个网络的整体状态。

下面列举部分LiveNet采用的智能运维方案，让内容分发网络再次升级，以符合Live时代的要求。

• 监控节点健康状况，实时下线有问题的节点
• Failover机制，保证服务一直可用
• 快速扩容

LiveNet VS P2P

最后我们和P2P网络做一个对比：

我们发现P2P方案，节点的可控性和链路的稳定性上还有很大提升空间，比较适合在实时性要求不高的场景使用、适合长尾需求，在Live的场景下面多是对实时性要求比较高的重度用户，无法忍受频繁的FailOver和节点质量参差不齐带来的网络抖动，但是如果是文件分发就比较适合用这种混合方案，可以有效降低CDN厂商成本，利用共享经济提高资源利用率。

这篇介绍了推送和传输网络部分，我们已经把流媒体送到了观众的终端中，下一步就是把它展现在屏幕上了，想了解这部分内容请继续关注我们的下一篇内容。

2016年9月22日-23日，[SDCC 2016大数据技术&架构实战峰会](http://bss.csdn.net/m/topic/sdcc_invite/hangzhou /)将在杭州举行，两场峰会大牛讲师来自阿里、京东、苏宁、唯品会、美团点评、游族、饿了么、有赞、Echo等知名互联网公司，共同探讨海量数据下的应用监控系统建设、异常检测的算法和实现、大数据基础架构实践、敏捷型数据平台的构建及应用、音频分析的机器学习算法应用，以及高可用/高并发/高性能系统架构设计、电商架构、分布式架构等话题与技术。 9月5日~18日是八折优惠票价阶段，5人以上团购或者购买两场峰会通票更有特惠，限时折扣，预购从速。（票务详情链接）。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/162845.html原文链接：https://javaforall.cn