本文首发于“雨夜随笔”公众号，欢迎关注。

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

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

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

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

RTMP协议

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

握手过程

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

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

相关学习资料推荐，点击下方链接免费报名，先码住不迷路~】

音视频免费学习地址：
https://xxetb.xet.tech/s/2cGd0

【免费分享】音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击788280672加群免费领取~

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

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

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

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

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

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

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

传输

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

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

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

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

作者：soolaugust
原文链接：
https://juejin.cn/post/6847902219338153997