直播

32 | HLS:实现一对多直播系统的必备协议

上一篇文章中 ,我们对 RTMP 协议和 HLS 协议的优势与劣势进行了比较。从比较的结果我们可以看出,RTMP 作为传统的直播传输技术在实时性方面要比 HLS 好很多,所以它还是有一定优势的。
不过,随着 Chrome 浏览器宣布不再对 Flash 插件提供支持、Adobe 公司停止对 RTMP 协议更新以及苹果公司声称 iOS 上不允许使用 RTMP 协议等一系列事件的发生,我们可以断定 RTMP 协议已失去了未来。
而 HLS 协议则恰恰相反,它在未来会有更广阔的应用前景。我们可以通过以下几点来得到这个结论:
HLS 是苹果开发的协议,苹果产品原生支持此协议;
HLS 是基于 HTTP 的,可以不受防火墙限制,所以它的连通性会更好;
HLS 还能根据客户的网络带宽情况进行自适应码率的调整,这对于很多用户来说是非常有吸引力的。
基于以上原因,我们有必要从 HLS 直播架构、FFmpeg
                

31 | 一对多直播系统RTMP/HLS,你该选哪个?

近年来,随着智能手机的普及以及移动互联网的飞速发展,音视频技术在各个行业得到了广泛的应用。尤其是娱乐直播在前几年着实火了一把,像映客、斗鱼这类以展示才艺为主的直播产品非常受大家的欢迎。
从技术角度来讲,映客、斗鱼这类娱乐直播与在线教育、音视频会议直播有着非常大的区别。在线教育、音视频会议这类直播属于实时互动直播,主要考虑传输的实时性,因此一般使用 UDP 作为底层传输协议;而娱乐直播对实时性要求不高,更多关注的是画面的质量、音视频是否卡顿等问题,所以一般采用 TCP 作为传输协议。我们称前者为实时互动直播,后者为传统直播。
本专栏的前两个模块都是介绍实时互动直播的,而从今天开始我们会讲解传统直播技术。
传统直播技术使用的传输协议是 RTMP 和 HLS。其中,RTMP 是由 Adobe 公司开发的,虽然不是国际标准,但也算是工业标准,在 PC 占有很大的市场;而 HLS 是由苹果公司开发的,主要用在它的 iOS 平台,不过 Android 3 以后的平台也是默认支持 HLS 协议的。
接下来,我们先看一下传统音视频直播系统的基本架构,让你对传统直播架构的“内幕”有一个初步的了解。

传统直播基本架构

商业级直播系统的规模、结构是非常复杂的,除了最核心的音视频直播外,还包括用户管理、认证系统、直播间管理、打赏、红包、私信等很多功能,不过这些更多的是一些业务逻辑,在本文中我们不会对它们进行讲解,而是聚焦在最核心的音视频直播技术上。
我们先来看一下传统直播的基本架构图,如下图所示:
传统直播基本架构图
从图中可以看出,传统直播架构由直播客户端、信令服务器和 CDN
                

24 | 多人音视频实时通讯是怎样的架构?

在前面的章节里,我们通过大量的篇幅介绍了 WebRTC 在浏览器上对实时通信的各种支持。WebRTC 本身提供的是 1 对 1 的通信模型,在 STUN/TURN 的辅助下,如果能实现 NAT 穿越,那么两个浏览器是可以直接进行媒体数据交换的;如果不能实现 NAT 穿越,那么只能通过 TURN 服务器进行数据转发的方式实现通信。目前来看,Google 开源的用于学习和研究的项目基本都是基于 STUN/TURN 的 1 对 1 通信。
如果你想要通过 WebRTC 实现多对多通信,该如何做呢?其实,基于 WebRTC 的多对多实时通信的开源项目也有很多,综合来看,多方通信架构无外乎以下三种方案。
Mesh 方案,即多个终端之间两两进行连接,形成一个网状结构。比如 A、B、C 三个终端进行多对多通信,当 A 想要共享媒体(比如音频、视频)时,它需要分别向 B 和 C 发送数据。同样的道理,B 想要共享媒体,就需要分别向
            

21 | 如何保证数据传输的安全(上)?

数据安全越来越受到人们的重视,尤其是一些敏感数据,如重要的视频、音频等。在实现音视频通信的过程中,如果在网络上传输的音视频数据是未加密的,那么黑客就可以利用 Wireshark 等工具将它们录制下来,并很容易地将它们播放出来并泄漏出去。
如果这些音视频的内容涉及到股票交易或者其他一些更敏感的内容的话,很可能会造成不可挽回的损失。
对于浏览器更是如此,在全球至少有几亿用户在使用浏览器,这么大的用户量,如果通过浏览器进行音视频传输时,没有对音视频数据进行安全保护的话,那将会产生灾难性的后果。
既然数据安全这么重要,那接下来我将带你了解一下数据安全方面的相关概念。只有将这些基本概念搞清楚了,你才知道 WebRTC 是如何对数据进行防护的。

非对称加密

目前对于数据的安全保护多采用非对称加密,这一方法在我们的日常生活中被广泛应用。那什么是非对称加密呢?下面我就向你简要介绍一下。
在非对称加密中有两个特别重要的概念,即公钥私钥。它们起到什么作用呢?这里我们可以结合一个具体的例子来了解一下它们的用处。
有一个人叫小 K,他有一把特制的锁,以及两把特制的钥匙——公钥和私钥。这把锁有个非常有意思的特点,那就是:用公钥上了锁,只能用私钥打开;而用私钥上的锁,则只能公钥打开
这下好了,小 K 正好交了几个异性笔友,他们在书信往来的时候,难免有一些“小秘密”不想让别人知道。因此,小 K 多造了几把公钥,给每个笔友一把,当笔友给他写好的书信用公钥上了锁之后,就只能由小 K 打开,因为只有小 K 有私钥(公钥上的锁只有私钥可以打开),这样就保证了书信内容的安全。
从这个例子中,你可以看到小 K 的笔友使用公钥对内容进行了加密,只有小 K 可以用自己手中的私钥进行解密,这种对同一把锁使用不同钥匙进行加密 / 解密的方式称为非对称加密,而对称加密
            

13 | 在WebRTC中如何控制传输速率呢?

在上一篇《12 | RTCPeerConnection:音视频实时通讯的核心》一文中,我向你介绍了 RTCPeerConnection 对象是如何在端与端之间建立连接的,以及音视频数据又是如何通过它进行传输的。而本文则更进一步,向你介绍如何使用 RTCPeerConnection 来控制音视频数据的传输速率。
通过 RTCPeerConnection 进行传输速率的控制实际上还是蛮简单的一件事儿,但在学习相关知识的时候,你不仅要能知其然,还要知其所以然。对于本文来讲,就是你不但要学习如何控制传输速率,同时还应该清楚为什么要对传输速率进行控制。
其实,之所以要进行传输速率的控制,是因为它会对音视频服务质量产生比较大的影响,对于音视频服务质量这部分知识,接下来我就与你一起做详细探讨。

在 WebRTC 处理过程中的位置

在此之前,我们依旧先来看看本文的内容在整个 WebRTC 处理过程中的位置。
WebRTC 处理过程图
通过上图你可以知道,本文所讲的内容仍然属于传输的范畴。

音视频服务质量

像上面所说的,虽然通过 RTCPeerConnection 在端与端之间建立连接后,音视频数据可以互通了,但你还应对传输速率有所控制。之所以要对传输速率进行控制,主要是为了提高音视频服务质量。
举个简单的例子,假设你的带宽是 1Mbps,你想与你的朋友进行音视频通话,使用的视频分辨率为 720P,帧率是 15 帧 / 秒,你觉得你们通话时的音视频质量会好吗?
咱们来简单计算一下,根据经验值,帧率为 15 帧

10 | WebRTC NAT穿越原理

WebRTC 中, NAT 穿越是非常重要的一部分内容,也是比较有深度、比较难以理解的一部分知识。当然,等你学完本文,并完全理解了这部分知识后,你也会特别有成就感!
在我们真实的网络环境中,NAT 随处可见,而它的出现主要是出于两个目的。第一个是解决 IPv4 地址不够用的问题。在 IPv6 短期内无法替换 IPv4 的情况下,如何能解决 IP 地址不够的问题呢?人们想到的办法是,让多台主机共用一个公网 IP 地址,然后在内部使用内网 IP 进行通信,这种方式大大减缓了 IPv4 地址不够用的问题。第二个是解决安全问题,也就是主机隐藏在内网,外面有 NAT 挡着,这样的话黑客就很难获取到该主机在公网的 IP 地址和端口,从而达到防护的作用。
不过凡事有利也有弊,NAT 的引入确实带来了好处,但同时也带来了坏处。如果没有 NAT,那么每台主机都可以有一个自己的公网 IP 地址,这样每台主机之间都可以相互连接。可以想象一下,如果是那种情况的话,互联网是不是会更加繁荣?因为有了公网 IP 地址后,大大降低了端与端之间网络连接的复杂度,我们也不用再费这么大力气在这里讲 NAT 穿越的原理了。
如果从哲学的角度来讲,“世上的麻烦都是自己找的”,这句话还是蛮有道理的。

09 | 让我们揭开WebRTC建立连接的神秘面纱

在上一篇《08 | 有话好商量,论媒体协商》文章中,我向你介绍了 WebRTC 进行通信时,是如何进行媒体协商的,以及媒体协商的目的是什么。
在媒体协商过程中,如果双方能达成一致,也就是商量好了使用什么编解码器,确认了使用什么传输协议,那么接下来,WebRTC 就要建立连接,开始传输音视频数据了。
WebRTC 之间建立连接的过程是非常复杂的。之所以复杂,主要的原因在于它既要考虑传输的高效性,又要保证端与端之间的连通率
换句话说,当同时存在多个有效连接时,它首先选择传输质量最好的线路,如能用内网连通就不用公网。另外,如果尝试了很多线路都连通不了,那么它还会使用服务端中继的方式让双方连通,总之,是“想尽办法,用尽手段”让双方连通。
对于传输的效率与连通率这一点,既是 WebRTC 的目标,也是 WebRTC 建立连接的基本策略。下面我们就来具体看一下 WebRTC 是如何达到这个目标的吧!

在 WebRTC 处理过程中的位置

下面这张图清晰地表达了本文所讲的内容在整个 WebRTC 处理过程中的位置。
WebRTC 处理过程图
图中的红色部分——连接的创建、STUN/TURN 以及 NAT 穿越,就是我们本文要讲的主要内容。

连接建立的基本原则

接下来,我将通过两个具体的场景,向你介绍一下 WebRTC

从 0 打造音视频直播系统:06 | WebRTC中的RTP及RTCP详解

可以毫不夸张地说,WebRTC 是一个 “宝库”,它里面有各种各样的 “好东西”。无论你从事什么行业,几乎都可以从它里边吸取能量。
在学习 WebRTC 时,你不光要学习如何使用它,还应该多去看它底层的代码,多去了解它都能做些什么,争取对它的原理和使用都了然于心。如此一来,当遇到某个恰当的时机,你就可以从 WebRTC 库中抽取一点“精髓”放到你自己的项目中,让你的项目大放异彩。
比如,你是搞音频的,你就可以从 WebRTC 中提取 3A(AEC、AGC、ANC)的算法用到自己的项目中,这些算法可是目前世界上最顶级处理音频的算法;如果你是搞网络的,网络带宽的评估、平滑处理、各种网络协议的实现在 WebRTC 中真是应有尽有,你完全可以从中抽取你想用的。
鉴于 WebRTC 的强大“光环”,所以本文我将向你讲解学习 WebRTC 时你不得不知道的几个与网络相关的基本知识,让你在前期就能夯实基础。

UDP 还是 TCP?

如果抛开 WebRTC,让你自己实现一套实时互动直播系统,在选择网络传输协议时,你会选择使用 UDP 协议还是 TCP 协议呢?
这个问题在 2011 年至 2012

史上最全的WebRTC服务器技术选型分析

在上一篇文章里我们介绍了我们介绍了MCU和SFU的优缺点,webRTC通信方案SFU和MCU的区别?

下面就来探讨下常见的SFU开源解决方案,当然,你也可以自己实现 SFU 流媒体服务器,但自已实现流媒体服务器困难还是蛮多的,它里面至少要涉及到 DTLS 协议、ICE 协议、SRTP/SRTCP 协议等,光理解这些协议就要花不少的时间,更何况要实现它了。…

        

多人实时互动之各WebRTC流媒体服务器比较

前言

随着网络基础设施的提高,音视频实时通信越来越成为人们日常生活和工作中必不可少的需求。2011年 WebRTC的出现,则更加速了这种需求变为现实的可能性。

熟悉 WebRTC 的同学应该都知道,WebRTC规范只定义了实时通信中客户端的行为,而没有规范服务端(包括哪些信令、数据如何流转)的行为。所以,你可以使用WebRTC库方便的实现 1:1 实时通信,但对于多人实时互动,光依靠 WebRTC库显然就无法完成要求了。…