本文转自“雨夜随笔”公众号，欢迎关注



之前因为网络的发展，直播行业火热发展，特别是之前斗鱼，虎牙等的争斗，我们看到各种各样天价主播。可以说直播行业成为了一个新的风口。而2020年随着新冠病毒的影响，各种在线行业得以迅速发展，比如外卖，在线教育等。而直播更是涉足到了各种各样的行业，各类直播平台如雨后春笋一般冒了出来。而对于开发这一块，越来越多的人开始涉足直播技术。今天就让我们看一下直播技术的背后。



说到直播技术，那么就要涉及到视频和音频的实时传输。也就是一般所说的推流和拉流技术。像许多主播使用的OBS软件就是一个非常成熟的推流软件，可以将各种视频音频源推送到相应的直播平台。



OBS



而当其他用户进入到主播的直播间后，就相当于去服务器上拉取主播推送的视频音频源。这个就是所谓的拉流。所以整个直播平台的架构一般如下：



直播平台基本流程



那么推流工具是如何做到实时音视频传输的呢？这就要涉及到背后的RTMP协议了。

RTMP协议

RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写，是由Adobe公司创立的。目的就是为了解决多媒体数据的传输和分发问题。可以看出RTMP协议在一开始就是为了解决目前直播遇到的音视频传输的问题。



握手过程



RTMP是应用层协议，底层依靠的是TCP协议。因为多媒体传输是一个持续的过程，所以一般需要更为可靠的握手来保证连接的可靠性。RTMP协议在TCP三次握手的基础上，自己定义了六次握手，如下图：



RTMP握手过程



RTMP协议中规定了握手过程就是图上这样的：

1. 客户端发送版本号C0和生成的随机字符串C1

2. 服务端收到C0后，如果支持客户端的版本，则发送自己支持的版本号S0，否则不发送

3. 服务端收到C1后则发送自己生成的随机字符串S1

4. 客户端收到S1后，则发送S1的拷贝C2

5. 服务端收到C1后，则发送C1的拷贝S2

6. 客户端收到S2后，进行校验，通过后才发送控制信息和真实音视频等数据

7. 服务端收到C2后，进行校验，通过后才发送控制信息和真实音视频等数据



而我们经过分析发现，客户端发送C0和C1是相互独立的，所以可以一起发送。而服务端收到C1后，也可以将S0，S1，S2一起发送。这样就减少了传输过程，也不影响握手的效果。这个也就是实际RTMP的握手过程：

1. 客户端发送C0+C1

2. 服务端收到C1后发送S0+S1+S2

3. 客户端收到S1后发送C2



下面我们通过抓包来分别看一下上面的过程：



• RTMP协议建立前的TCP三次握手





• 客户端和服务端的握手，我们可以看到握手的过程和握手成功后接下来的数据传输





那么握手的具体内容是不是和我们上面说的一样呢，我们来看一下：



• C0, C1:版本号加随机字符串





• S0, S1, S2 : 服务端支持的版本号，随机字符串和C1的拷贝（我们可以看到和上面C1是一样的）





• C2： S1的拷贝（和上面S1一样）





传输

从上面的抓包我们可以看到握手成功后，就开始传输相关的控制指令和音视频数据，我们再来看一下断开RTMP连接发生了什么：





我们可以看到也是发送了相应的控制指令deleteStream()来删除流。RTMP协议的传输过程总体可以总结如下：



RTMP指令



通过这种方式，可以保证音视频传输的可靠性。这也是如今直播技术的主流方式之一。通过RTMP协议，可以让音视频传输的延迟达到很低，具体对比图我们看一下下图：





所以如果我们有对直播技术感兴趣或者需要实现直播平台的，可以去了解RTMP协议以及目前开源对这方面的努力。目前开源社区中也有很多成熟的直播技术，基本上都会支持RTMP协议。可以说不支持RTMP协议的直播平台是一个不完整的平台。很多热门的直播平台只要推流基本都支持RTMP协议。



欢迎关注