"Live video technology explain" series of five: plug flow and transport

Seven cattle cloud released a live video solutions for real-time streaming of live network LiveNet and complete cloud solution to the end of June, many developers and network solutions for the details and usage scenarios are very interested.

Seven cattle combined real-time streaming network LiveNet practice and live cloud solutions, we use eight articles, more systematic introduction to the current hot key technologies of all aspects of live video, live video to help entrepreneurs are more comprehensive, in-depth understanding of live video technology, better technology selection.

 

This series of articles following outline:

(A) opening

(B) Acquisition

(C) processing

(D) encoding and encapsulation

(E) transmitting plug flow and

(F) the principles of modern players

(Vii) delay optimization

(Viii) SDK Performance Test Model

 

On a processing chapter, we introduce the explanation coding and packaging. Benpian is "live video decryption technology" series of five: plug flow and transport. Streaming is the first kilometer live, live Streaming influence is very large for this live link, network instability if plug flow, whatever we do to optimize the audience's experience will be very bad. So is our first step in troubleshooting the problem, how to solve these problems systematically need to recognize that we have the basis of relevant theories.

Push agreement

Here to tell us about what are the push that agreement, their status and the advantages and disadvantages in the field of live broadcast.

• RTMP

• WebRTC

• UDP-based proprietary protocols

 

1. RTMP

 

RTMP is Real Time Messaging Protocol (real-time messaging protocol) acronym. The protocol is based on the TCP, is a family of protocols, including protocols and RTMP substantially RTMPT / RTMPS / RTMPE other variants. RTMP is a network protocol designed for real-time data communication, mainly used between streaming Flash / AIR platform and support RTMP protocol / server interaction for audio, video and data communications. Support the protocol software includes Adobe Media Server / Ultrant Media Server / red5 like.

RTMP is the mainstream media streaming protocol, widely used in the field of live, we can say the market most of the live products are using this protocol.

 

advantage

• CDN support good, mainstream CDN vendors support

• Protocol is simple, easy to implement across platforms

 

Shortcoming

• Based on the TCP, high transmission costs, environmental problems in a case where the network packet loss rate significantly weak

• Unsupported Browser push

• Adobe proprietary protocol, Adobe is no longer updated

 

2. WebRTC

 

WebRTC, instant messaging name from the web page: Abbreviations (English Web Real-Time Communication), is a web browser to support real-time voice conversations or video conversation API. It is on June 1, 2011 and be included in the open source W3C Recommendation World Wide Web Consortium at Google, Mozilla, Opera support.

 

Mainly used in video conferencing and even wheat, the protocol layering as follows:

 

 

advantage

• W3C standards and high level of support major browsers

• Google in the back support, and there is a reference in the platform

• SRTP based underlayer and UDP, weak network optimization where a large space

• It can point to point communication, low latency communication parties

 

Shortcoming

• ICE, STUN, TURN traditional CDN does not provide similar services

 

 

3. UDP-based proprietary protocols

 

Some live applications use UDP as the underlying protocol to develop their own proprietary protocol, because UDP advantages in a weak network environment through a number of customized tuning can achieve better network optimization weak effect, but also because it will also be a private agreement there are practical problems:

 

advantage

• More space customized optimization

 

Shortcoming

• High development costs

• CDN unfriendly, need or self-built CDN and CDN agreement

• Independent operations, not evolution and communities together

 

transporting network

We pushed out streaming media to be transferred to the audience, the entire link is the transmission network, is to see the analogy freight logistics from origin to destination all away, and if the capacity of the road is not enough, will cause traffic jam that is network congestion, then we will change from so-called intelligent scheduling, but the transmission network will be scheduled from the overall point of view, it will have better results than scheduling atomic world, the top conceivable that there is a God of departure and destination in the sky All traffic information between, but also real-time, and then gives you a clear way, what's the magic, but those of us in the LiveNet have been achieved.

 

Here first look at the traditional content delivery networks.

 

1. Why have the origin of the content delivery network, content distribution networks

 

An internal network of Internet originated in the United States military, Tim Berners-Lee is the inventor of one of the Internet, he was already foreseen in the near future network congestion will become the biggest obstacle to development of the Internet, and he made an academic problem, to invent a new method to solve the problem fundamentally to achieve congestion-free Internet content distribution, the academic problems eventually gave birth to a revolutionary Internet service --CDN. At that time, Dr. Berners-Lee is next door to the office of professor Tom Leighton, a professor of applied mathematics at MIT, he was Berners-Lee's challenge intrigued. Letghton finally solved the problem and start your own business plan, set up a company Akamai, to become the world's first CDN company.

 

2. The traditional CDN architecture

 

 

The figure is a schematic view of a typical three deployment system CDN, CDN nodes are the most basic unit for deployment system, the deployment is divided into three, the central node, the node area and the edge node, the central node is the uppermost one, a middle level is the regional node, edge node geographically dispersed, to provide users with the nearest access to content services.

Here are some classified CDN node, is divided into two categories, POP backbone nodes and nodes, backbone nodes is divided into a central node and the regional nodes.

 

• Backbone nodes

  • Central node

  • Regional node

• POP node

  • Edge node

Logically speaking, the backbone node responsible for content distribution and be back to the source node does not hit the edge, POP node is responsible for providing access to the content of the nearest service users. But the pressure CDN network core equipment if a larger scale, directly back to the source edge node to the central node will result in the intermediate layer is too large, the introduction of regional nodes physically responsible for managing a geographic area, saving some hot data.

 

3. The live transmission network is different from the pain points of traditional CDN

 

With the advent of the era of Live, live and become a major battleground of the current CDN vendor, then the Live era CDN needs what kind of service support it?

• Streaming protocol support, including RTMP, HLS, HTTP-FLV and so on.

• Seconds on the first screen, click from the user to control playback within several seconds

• 1 to 3, the delay control, plug flow from end to end play, the delay control between 1 to 3 seconds

• 全球全网智能路由，可以利用整个 CDN 网络内的所有节点为某一单一用户服务，不受地域限制。随着全球一体化进程不断推进，跨区域、跨国家、跨洲的直播正变为常态，很可能主播在欧美，而用户在亚洲。

• 天级别的节点按需增加，中国公司出海已成大势，CDN 需要更多的海外节点，如今比拼的更多的是海外节点可以快速部署，从提出节点增加需求到节点入网提供服务，需要达到一天之内，对 CDN 运维和规划提出非常高的要求。原有的月级别规划和入网满足不了先进的要求。

 

4. 传统 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 压力过大都可以实时的反映到整理网络中，帮助用户实时推倒出最优链路。这时我们可以去掉前面的一些假设，通过机器而不是人类来时实时规划网络的链路路由，这种实时大规模的计算任务天生就不是人类的强项，我们应该交给更适合的物种。

 

5. CDN 的扩容

 

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

 

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

 

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

 

6. 回归本质：LiveNet

 

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

• 对 Cache 的要求没有以前那么高

• 对实时性的要求非常高

• 对节点运维的要求高，要更智能，尽量减少人工干预

• 对扩容这种运维事件响应度要求非常高

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

• 去中心化，网状拓扑

• 全球全网调度

• 节点无状态，节点对等

• 智能运维

 

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

 

1）去中心，网状拓扑

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

 

2）全球全网调度

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

 

3）节点无状态，节点对等

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

 

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

 

4）智能运维

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

 

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

• 监控节点健康状况，实时下线有问题的节点

• Failover 机制，保证服务一直可用

• 快速扩容

 

7.LiveNet VS P2P

 

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

 

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