开发一个完整的直播 app?看这里就够了(四)推流和传输

本贴最后更新于 2743 天前,其中的信息可能已经事过境迁

关于直播的技术文章不少,成体系的不多。我们将用七篇文章,更系统化地介绍当下大热的视频直播各环节的关键技术,帮助视频直播创业者们更全面、深入地了解视频直播技术,更好地技术选型。

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

本系列文章大纲如下:
(一)采集
(二)处理
(三)编码和封装
(四)推流和传输
(五)现代播放器原理
(六)延迟优化
(七)SDK 性能测试模型

##推送协议

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

  • RTMP

  • WebRTC

  • 基于 UDP 的私有协议

1. 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 已经不再更新

2. WebRTC

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

目前主要应用于视频会议和连麦中,协议分层如下:

优点
W3C 标准,主流浏览器支持程度高

Google 在背后支撑,并在各平台有参考实现

底层基于 SRTP 和 UDP,弱网情况优化空间大

可以实现点对点通信,通信双方延时低

缺点

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

3. 基于 UDP 的私有协议

有些直播应用会使用 UDP 做为底层协议开发自己的私有协议,因为 UDP 在弱网环境下的优势通过一些定制化的调优可以达到比较好的弱网优化效果,但同样因为是私有协议也势必有现实问题:

优点

更多空间进行定制化优化

缺点

开发成本高

CDN 不友好,需要自建 CDN 或者和 CDN 达成协议

独立作战,无法和社区一起演进

##传输网络

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

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

1. 为什么要有内容分发网络,内容分发网络的由来

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

2. 传统 CDN 的架构

上图是一个典型的 CDN 系统的三级部署示意图,节点是 CDN 系统中的最基本部署单元,分为三级部署,中心节点、区域节点和边缘节点,最上面一级是中心节点,中间一级是区域节点,边缘节点地理位置分散,为用户提供就近的内容访问服务。
下面介绍一下 CDN 节点的分类,主要分成两大类,骨干节点和 POP 节点,骨干节点又分为中心节点和区域节点。

  • 骨干节点

  • 中心节点

  • 区域节点

  • POP 节点

  • 边缘节点

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

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

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

流媒体协议的支持,包括 RTMP,HLS ,HTTP-FLV 等。

  • 首屏秒开,从用户点击到播放控制在秒级以内

  • 13 延迟控制,从推流端到播放端,延迟控制在 13 秒之间

全球全网智能路由,可以利用整个 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 厂商成本,利用共享经济提高资源利用率。

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

【没看过瘾?直接来上免费公开课】

为了让大家能够将技术理论快速应用到实践开发中,七牛云联合慕课网、StuQ 特别制作了一期课程,专门针对移动直播应用开发,供大家学习参考。

慕课网:
http://www.imooc.com/learn/707    
StuQ :
http://www.stuq.org/course/detail/1077

  • 程序员

    程序员是从事程序开发、程序维护的专业人员。

    529 引用 • 3527 回帖 • 2 关注
  • 节点
    7 引用 • 13 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 看上去好牛的样子。到最后发现是广告。。。

    1 回复
  • wulalala
    作者

    是七牛和慕课推出的免费课程,相信对直播技术感兴趣的童鞋肯定有帮助 ~

    1 回复
  • 这样呀。一下就担心是各种不好的小广告了。

推荐标签 标签

  • Swift

    Swift 是苹果于 2014 年 WWDC(苹果开发者大会)发布的开发语言,可与 Objective-C 共同运行于 Mac OS 和 iOS 平台,用于搭建基于苹果平台的应用程序。

    34 引用 • 37 回帖 • 495 关注
  • 服务器

    服务器,也称伺服器,是提供计算服务的设备。由于服务器需要响应服务请求,并进行处理,因此一般来说服务器应具备承担服务并且保障服务的能力。

    124 引用 • 580 回帖
  • Git

    Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    204 引用 • 357 回帖 • 1 关注
  • Sublime

    Sublime Text 是一款可以用来写代码、写文章的文本编辑器。支持代码高亮、自动完成,还支持通过插件进行扩展。

    10 引用 • 5 回帖 • 1 关注
  • Angular

    AngularAngularJS 的新版本。

    26 引用 • 66 回帖 • 498 关注
  • 自由行
  • 京东

    京东是中国最大的自营式电商企业,2015 年第一季度在中国自营式 B2C 电商市场的占有率为 56.3%。2014 年 5 月,京东在美国纳斯达克证券交易所正式挂牌上市(股票代码:JD),是中国第一个成功赴美上市的大型综合型电商平台,与腾讯、百度等中国互联网巨头共同跻身全球前十大互联网公司排行榜。

    14 引用 • 102 回帖 • 406 关注
  • Ruby

    Ruby 是一种开源的面向对象程序设计的服务器端脚本语言,在 20 世纪 90 年代中期由日本的松本行弘(まつもとゆきひろ/Yukihiro Matsumoto)设计并开发。在 Ruby 社区,松本也被称为马茨(Matz)。

    7 引用 • 31 回帖 • 166 关注
  • SMTP

    SMTP(Simple Mail Transfer Protocol)即简单邮件传输协议,它是一组用于由源地址到目的地址传送邮件的规则,由它来控制信件的中转方式。SMTP 协议属于 TCP/IP 协议簇,它帮助每台计算机在发送或中转信件时找到下一个目的地。

    4 引用 • 18 回帖 • 581 关注
  • flomo

    flomo 是新一代 「卡片笔记」 ,专注在碎片化时代,促进你的记录,帮你积累更多知识资产。

    3 引用 • 74 回帖 • 3 关注
  • 安装

    你若安好,便是晴天。

    128 引用 • 1183 回帖
  • 外包

    有空闲时间是接外包好呢还是学习好呢?

    26 引用 • 232 回帖 • 17 关注
  • Hprose

    Hprose 是一款先进的轻量级、跨语言、跨平台、无侵入式、高性能动态远程对象调用引擎库。它不仅简单易用,而且功能强大。你无需专门学习,只需看上几眼,就能用它轻松构建分布式应用系统。

    9 引用 • 17 回帖 • 591 关注
  • MongoDB

    MongoDB(来自于英文单词“Humongous”,中文含义为“庞大”)是一个基于分布式文件存储的数据库,由 C++ 语言编写。旨在为应用提供可扩展的高性能数据存储解决方案。MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。它支持的数据结构非常松散,是类似 JSON 的 BSON 格式,因此可以存储比较复杂的数据类型。

    90 引用 • 59 回帖 • 5 关注
  • Facebook

    Facebook 是一个联系朋友的社交工具。大家可以通过它和朋友、同事、同学以及周围的人保持互动交流,分享无限上传的图片,发布链接和视频,更可以增进对朋友的了解。

    4 引用 • 15 回帖 • 448 关注
  • webpack

    webpack 是一个用于前端开发的模块加载器和打包工具,它能把各种资源,例如 JS、CSS(less/sass)、图片等都作为模块来使用和处理。

    41 引用 • 130 回帖 • 294 关注
  • 小说

    小说是以刻画人物形象为中心,通过完整的故事情节和环境描写来反映社会生活的文学体裁。

    28 引用 • 108 回帖 • 3 关注
  • 周末

    星期六到星期天晚,实行五天工作制后,指每周的最后两天。再过几年可能就是三天了。

    14 引用 • 297 回帖
  • 链书

    链书(Chainbook)是 B3log 开源社区提供的区块链纸质书交易平台,通过 B3T 实现共享激励与价值链。可将你的闲置书籍上架到链书,我们共同构建这个全新的交易平台,让闲置书籍继续发挥它的价值。

    链书社

    链书目前已经下线,也许以后还有计划重制上线。

    14 引用 • 257 回帖 • 1 关注
  • Markdown

    Markdown 是一种轻量级标记语言,用户可使用纯文本编辑器来排版文档,最终通过 Markdown 引擎将文档转换为所需格式(比如 HTML、PDF 等)。

    163 引用 • 1446 回帖 • 1 关注
  • 面试

    面试造航母,上班拧螺丝。多面试,少加班。

    324 引用 • 1395 回帖
  • ZooKeeper

    ZooKeeper 是一个分布式的,开放源码的分布式应用程序协调服务,是 Google 的 Chubby 一个开源的实现,是 Hadoop 和 HBase 的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

    59 引用 • 29 回帖 • 18 关注
  • Postman

    Postman 是一款简单好用的 HTTP API 调试工具。

    4 引用 • 3 回帖
  • TGIF

    Thank God It's Friday! 感谢老天,总算到星期五啦!

    284 引用 • 4481 回帖 • 652 关注
  • 智能合约

    智能合约(Smart contract)是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易,这些交易可追踪且不可逆转。智能合约概念于 1994 年由 Nick Szabo 首次提出。

    1 引用 • 11 回帖 • 6 关注
  • jsDelivr

    jsDelivr 是一个开源的 CDN 服务,可为 npm 包、GitHub 仓库提供免费、快速并且可靠的全球 CDN 加速服务。

    5 引用 • 31 回帖 • 34 关注
  • OnlyOffice
    4 引用 • 19 关注