Ubuntu18.04安装RabbitMQ

1、安装erlang

由于rabbitMq需要erlang语言的支持,在安装rabbitMq之前需要安装erlang

sudo apt-get install erlang-nox

2、安装Rabbitmq

更新源
sudo apt-get update

安装

sudo apt-get install rabbitmq-server

启动、停止、重启、状态rabbitMq命令

  1. sudo rabbitmq-server start
  2. sudo rabbitmq-server stop
  3. sudo rabbitmq-server restart
  4. sudo rabbitmqctl status

三、添加admin,并赋予administrator权限

添加admin用户,密码设置为admin。

sudo rabbitmqctl add_user  admin  admin  

赋予权限

sudo rabbitmqctl set_user_tags 

34 | 如何使用Nginx搭建最简单的直播服务器?

在前面三篇文章中,我们介绍了传统直播系统架构、HLS 协议、RTMP 协议相关的知识,那今天我们就来具体实操一下,根据前面所学到的知识搭建出一套最简单的音视频直播系统。
今天我们要搭建的这套直播系统相较于《31 | 一对多直播系统 RTMP/HLS,你该选哪个?》一文中介绍的直播系统要简单得多。该系统不包括客户端、没有 CDN 分发,只包括最基本的推流、转发及拉流功能。虽然它简单了一点,但麻雀虽小五脏俱全,通过这样一个实战操作,我们就可以将前面讲解的理论与实际结合到一起了。
当然,作为一个直播系统来说,客户端是必不可少的。但由于时间和篇幅的原因,我们只能借助一些现成的或者开源的客户端对我们的直播系统进行测试了,所以客户端的界面可能会简陋一些。也正因为如此,我才没有将它们算作咱们这个直播实验平台之中。
实际上,我们完全可以以这个直播系统实验平台为原型,逐步地将一些功能添加进去,这样很快就可以构建出一套商业可用的传统直播系统了。

直播系统架构

在正式开始实战之前,我们先来简要介绍一下这个直播系统的架构,如下图所示:
最简单的直播系统
这个直播架构非常简单,由两部分组成,即媒体服务器客户端
媒体服务器有两个功能:
推流功能,可以让客户端通过 RTMP 协议将音视频流推送到媒体服务器上;
拉流功能,可以让客户端从媒体服务器上拉取 RTMP/HLS 流。
实际上,这个架构与我们前面介绍的传统直播架构相比是有变化的,减少了信令服务器,同时将 CDN 网络变成了一台流媒体服务器。但理解了整个直播架构的原理后,我们就可以快速地将这个简单的直播架构恢复成一个正式的、可商用的直播系统。
那对于我们这个简化的直播系统来说,如何实现架构中的媒体服务器呢?
这里我们使用了目前最流行的 Nginx 来实现它。之所以选用 Nginx 主要出于以下两方面的原因:
Nginx 的性能是很优越。在众多的
            

33 | FLV:适合录制的多媒体格式

虽然苹果拒绝使用 RTMP 协议并推出了自己的 HLS 技术,但大多数用户仍然还是使用 RTMP 协议作为传统直播系统的传输协议。在 Adobe 宣布不再对 RTMP 技术进行支持的情况下,仍然还有这么多用户在使用它,说明 RTMP 协议具有其他协议不可比拟的优势。
这里我们做个对比,你就知道 RTMP 协议的优势在哪里了。
首先,与 HLS 技术相比,RTMP 协议在传输时延上要比 HLS 小得多。主要原因在于 HLS 是基于切片(几秒钟视频的小文件)、然后缓存的技术,这种技术从原理上就比直接进行数据传输慢很多,事实也证明了这一点。
其次,相对于 RTP 协议,RTMP 底层是基于 TCP 协议的,所以它不用考虑数据丢包、乱序、网络抖动等问题,极大地减少了开发人员的工作量;而使用 RTP 协议,网络质量的保障都需要自己来完成。
最后,与现在越来越火的 WebRTC 技术相比,RTMP 也有它自己的优势。虽然在实时传输方面 WebRTC 甩 RTMP 技术几条街,但对于实时性要求并没有那么高的传统直播来说,RTMP
            

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 穿越的原理了。
如果从哲学的角度来讲,“世上的麻烦都是自己找的”,这句话还是蛮有道理的。