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

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

这一系列文章的概要如下:

(1)收藏

(2)治疗

(4)推流和传输

(5)现代球员的原则

(6)延迟优化

(七)SDK性能测试模型

在上一期的processing中，我们介绍了编码和封装的解释。本文是解密视频直播技术系列之四:推流与传输。推流是直播的第一公里，直播的推流对这个直播环节影响很大。如果推流网络不稳定，无论我们怎么优化，观众体验都会很差。所以也是我们调查问题的第一步。如何系统地解决这类问题，需要我们对相关理论有一个基本的了解。

推送协议

我们先介绍一下有哪些推送协议，它们的现状，在直播领域的优缺点。

RTMPWebRTC基于UDP的私有协议

1RTMP

RTMP是实时消息协议的首字母缩写。该协议是基于TCP的协议族，包括RTMP基本协议和RTMPT/RTMPS/RTMPE。RTMP是为实时数据通信而设计的网络协议，主要用于Flash/AIR平台与支持RTMP协议的流媒体/交互服务器之间的音频、视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red 5等。

RTMP是当前主流的流媒体传输协议，广泛应用于直播领域。可以说市面上大部分直播产品都采用了这个协议:

优势

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

缺点基于TCP，传输成本高，在弱网环境丢包率高的情况下问题显著不支持浏览器推送Adobe私有协议，Adobe已经不再更新

2WebRTC

WebRTC，名字来源于Web Real-Time Communication(英文:Web Real-Time Communication)的缩写，是一种支持Web浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源，并在Google、Mozilla和Opera的支持下被纳入万维网联盟W3C推荐标准。

目前主要用在视频会议甚至小麦上。协议层如下:

优势

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

缺点

ICE，STUN，TURN传统CDN没有类似的服务提供

3基于UDP的私有协议

有些直播应用会使用UDP作为底层协议来开发自己的私有协议，因为UDP在弱网环境下的优势可以通过一些定制化的调优来达到更好的弱网优化效果，但也因为是私有协议，必然会存在实际问题:

优势

更多空间进行定制化优化

缺点开发成本高CDN不友好，需要自建CDN或者和CDN达成协议独立作战，无法和社区一起演进

公交网络

我们推送出去的流媒体需要传输给观众，整个环节就是传输网络。类似的货运物流是从出发点到目的地的所有旅程。如果道路的容量不够，就会造成交通堵塞，也就是网络拥堵。这个时候我们会改变行程，也就是所谓的智能调度，但是传输网络会从全局的角度进行调度，所以会比原子世界的调度有更好的效果。想象一下，有一个神在天上俯视着出发地和目的地之间的所有道路信息空，而且是实时的，然后给你一条清晰的道路。多么神奇，但是我们已经在LiveNet中实现了所有这些。

我们先来回顾一下传统的内容分发网络。

为什么会有内容分发网，内容分发网的由来？

互联网起源于美**方的内部网络。蒂姆·伯纳斯·李是互联网的发明者之一。他很早就预见到网络拥塞在不久的将来将成为互联网发展的最大障碍，因此他提出了一个学术问题，以发明一种全新的、根本性的解决问题的方法来实现互联网内容的无拥塞分发。这个学术难题最终催生了一个创新的互联网服务——CDN。当时，伯纳斯-李博士的隔壁是麻省理工学院应用数学教授汤姆·雷顿教授的办公室，他被伯纳斯-李博士的挑战所激起。莱顿终于解决了这个问题，开始了自己的商业计划，成立了Aka***i公司，成为全球第一家CDN公司。

传统CDN架构

上图是典型的CDN系统电影部署图。节点是CDN系统中最基本的部署单元，分为中心节点、区域节点和边缘节点三个层次。顶层是中心节点，中层是区域节点。边缘节点在地理上是分散的，为用户提供最近的内容访问服务。

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

骨干节点中心节点区域节点POP节点边缘节点

从逻辑上讲，骨干节点主要负责边缘节点缺失时的内容分发和回源，而POP节点主要负责为用户提供最近的内容访问服务。但如果CDN网络规模较大，边缘节点直接回归中心节点会给中间层的核心设备带来太大压力，所以在物理上引入区域节点来管理一个地理区域，保存一些热点数据。

直播网络的痛点不同于传统CDN

随着直播时代的到来，直播成为CDN厂商的又一大战场。那么直播时代CDN需要支持什么样的服务呢？

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

CDN的传统链路路由

基于CDN的树形网络拓扑，每层都有GSLB(全局服务器负载均衡)用于同一层多个CDN节点的负载均衡。这有什么好处？

在上面提到的很多CDN应用场景中，网页加速、视频加速、文件传输加速都同时依赖于GSLB和缓存系统。缓存系统是整个CDN系统的成本，设计一个树形结构可以最大程度的节省缓存系统的资金投入。因为只有中心节点需要保留机会的所有缓存副本，所以会逐步减少，在边缘节点只需要少量的热缓存就可以命中大部分CDN访问请求，大大降低了CDN网络的成本，满足了当时CDN用户的需求。可谓双赢。但是在直播时代，直播服务是流媒体服务，很少涉及缓存系统。基本上播出后就可以释放存储资源了。即使由于政策原因有存储需求，存储投入也相对较低，不要求存储在所有节点，只要数据可追溯、可用即可。

让我们来看看树形网络拓扑。用户可以选择的链接数量是有限的。如下图所示，用户在某个区域可以选择的链接数量为:2*5=10。

当用户在某个区域时，GSLB(通常是边缘节点级的智能DNS)会将用户路由到该区域的某个边缘节点，上层会路由到某个区域节点(这里GSLB通常是内部负载均衡器)，最后回到中心节点，中心节点会链接源站。

这里的假设是:

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

但事实真的是这样吗？引入这么多假设真的正确吗？

实际上，即使理论上可以证明上述假设成立，但节点规划和区域配置大多取决于人的设计和规划。我们知道人太多是不靠谱的，而且就算当时的区域规划是正确的，谁又能保证这些静态的网络规划不会因为一根光纤的铺设或者某个IDC的压力过大而改变呢？因此，我们可以跳出树状网络拓扑的束缚，探索一种新的适合直播加速的网络拓扑。

为了摆脱有限链路路由线路的限制并激活组织网络的能力，我们可以把上述节点变成网状网络拓扑:

我们可以看到，一旦把网络结构改成网状结构，用户可选择的链接就会变成:无向图的两个指定点之间的所有路径，学过图论的同学都知道，数量是惊人的。

系统可以通过智能路由选择任何最快的链路，而不依赖于系统部署期间过时的手动规划。无论是部分链路加光纤，还是部分IDC压力过大，都可以实时反映在分拣网络中，帮助用户实时推送最优链路。这时候我们就可以摆脱之前的一些假设，通过机器而不是人类来实时规划网络的链路路由。这种实时的大规模计算任务本来就不是人类的强项，我们应该把它交给更适合的物种。

CDN的扩展

如前所述，中国出海已成大势所趋，CDN海外节点需求日益增加。这种情况下，CDN厂商需要在新的区域部署新的骨干网和边缘节点，需要详细的网络规划。时代变了。原来CDN用户都是企业用户，自己的业务线迭代周期长，规划时间长，留给CDN厂商的时间更多。而互联网公司讲究速度，双周迭代成为常态，这就涉及到成本和响应速度的矛盾。如果提前部署节点，可以更好的服务这些互联网公司，但是有很高的成本压力；反过来，他们也无法应对这些快速成长的互联网公司。

理想情况下，用户提出需求后，客户可以当天在新区域测试新节点，CDN厂商内部评估，当天反馈，当天部署。怎么解决？

答案是基于网状拓扑的对等网络。在网状拓扑中，每个节点都是对等节点，从逻辑上讲，每个节点提供的服务是平等的。不需要按区域设计复杂的网络拓扑。一个节点上线后，不需要复杂的启动过程。您可以通过直接在线注册节点信息来为用户提供服务。结合虚拟化技术，前后时间理论上可以控制在一天之内。

本质:LiveNet

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

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

要做到以上几点，我们需要:

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

这些都是设计LiveNet时的考虑，使得运维更加自动化，系统运行具有高度的自主性，依靠机器计算代替人工判断。下面分别介绍一下。

偏心网状拓扑

网状拓扑是设计的基础和依据。只有当我们清楚地看到我们对缓存需求的减少，网状拓扑才能更有优势。

全球网络调度

基于一个全球网络，不再受限于区域网络调度，调度范围从区域网络扩展到全球。全网所有节点都可以响应用户的请求，参与链路路由，而不是先通过人工假设选择一些节点进行路由，从而消除人工干预，使整个系统更加智能。

节点是无状态和对等的。

Net节点无状态、对等，便于运维。没有区域概念的全局网络使得整个拓扑结构极其复杂。如果节点之间存在相继的依赖关系，运维将成为噩梦，需要专有的服务编排系统，同时也会给扩容带来困难。运维人员需要设计复杂的扩容方案，要排练多次，才敢在复杂的网络拓扑中扩容。如果当时节点是对等的，无状态的，那么运营和扩展就容易多了。

但是，在整个系统的运行过程中，仍然有一些状态和数据需要保存。比如一些直播内容需要在地面回放，这些都是通过久经考验的七牛云存储来存储的。

智能运维

基于上述的“网状拓扑对等网络”，智能运维会容易很多。方便注销有问题的节点而不影响整个LiveNet网络，方便快捷的登录新节点，提高系统容量。通过对节点的数据分析，可以更好地了解整个网络的整体状态。

下面是LiveNet采用的一些智能运维方案，让内容分发网络再次升级，满足直播时代的要求。

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

LiveNet与P2P

最后，我们来和P2P网络做个对比:

Mesh，mesh，tree，对等网络，对等网络，异构网络，自有节点，混合节点，部分自有节点，链路多，特别是稳定链路多，不稳定链路少，稳定扩展周期短，扩展周期短，节点可管理性长，节点可管理性弱，节点质量好，节点质量不均匀，节点质量好。我们发现P2P解决方案，节点的可控性和链路的稳定性都有了很大的提升空，更适合实时性要求不高，长尾要求的场景。直播场景下对实时性要求高的重度用户，大多无法忍受频繁故障切换和节点质量不均衡带来的网络抖动。但如果是文件分发，则更适合使用这种混合方案，利用共享经济可以有效降低CDN厂商的成本，提高资源利用率。