构建稳定高效的RTMP直播流服务器，实现流畅直播体验。 (rtmp直播流服务器)
构建稳定高效的RTMP直播流服务器，实现流畅直播体验
随着网络技术和手机普及率的不断提高，直播已成为一种非常流行的社交形态。一些个人主播、企业公众号、电视台等都开始了直播活动，这就要求我们能够构建一个稳定高效的RTMP直播流服务器，实现流畅直播体验。
1. RTMP协议简介
RTMP，是一种流媒体协议，用在 web 和 Flash 内，以实现音视频数据的传输。RTMP最初由 Adobe 公司推出，是一种实时性强、丢包率低、数据传输稳定的协议。RTMP通过UDP协议传输，并配合TCP进行控制，同时支持RTMPT和RTMPS加密传输协议。以RTMPT为例，其应用场景主要是HTTP协议过滤的部署环境下，通过HTTP Tunneling技术，将RTMP数据流打包进HTTP请求的数据区域中，用HTTP协议与服务器通信，再由服务器将数据流解封装送到客户端进行播放。
2. RTMP直播流服务器构建
为了实现稳定、高效的RTMP实时直播，通常需要一个完善的流媒体服务架构。具体步骤如下：
（1）选择合适的服务器：选择一台速度快、带宽宽裕的服务器，要求服务器的CPU、内存、磁盘容量、带宽等参数都能满足较高的性能要求。对于服务器系统方面推荐使用CentOS或Debian系统等。
（2）安装并配置Nginx：Nginx是一个高性能的HTTP和反向代理服务器，一般情况下需要编译安装Nginx来实现RTMP功能的支持，可以获得更快的速度和更高的扩展性。安装和配置Nginx后还需要修改配置文件：nginx.conf，以实现更好的RTMP模块支持。启动Nginx即可实现RTMP流服务器。
（3）安装并配置FFmpeg：FFmpeg是一套可以用来记录、转换音视频流的开源框架。在RTMP直播服务中，需要把摄像头的视频数据通过FFmpeg打包成RTMP数据推送到Nginx RTMP流服务器上。
3. 优化RTMP直播流服务器性能
为了实现稳定、高效的RTMP直播流服务器，以下几点需要特别注意：
（1）增加带宽资源：针对直播高峰期，增加带宽资源能够体现服务器的性能。
（2）优化推流参数：推流参数对直播流QoS有着重要的影响，合理地设置推流参数对实现直播的流畅性和良好的用户体验非常重要。
（3）增加服务器缓存：合理的缓存设置能够缓解服务器压力，提升直播流服务的稳定性。
4. 结论
构建稳定高效的RTMP直播流服务器，实现流畅直播体验需要在服务器选择、软件安装和配置、性能优化等多个方面做出调整。只有综合考虑各种因素，才能真正实现高性能的直播服务，让观众体验到快速、稳定、清晰的直播流服务。
相关问题拓展阅读：
视频直播App搭建的音视频采集和处理
一、直播的技术架汪山构：
直播视频采集SDK（PC/IOS/Anddroid）——直播CDN
（直播流分发加速）——直播视频播放器SDK（PC/IOS/Android）
二、音视频处理的一般流程：
数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示
1、数据采集：
摄像机及拾音器收集视频及音频数据，此时得到的为原始数据
涉及技术或协议：
摄像机：CCD、CMOS
拾音器：声电转换装置（咪头）、音频放大电路
2、数据编码：
使用相关硬件或软件对音视频原始数据进行编念燃码处理（数字化）及加工（如音视频困高中混合、打包封装等），得到可用的音视频数据
涉及技术或协议：
编码方式：CBR、VBR
编码格式
视频：H.265、H.264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等
音频：G.711μ、AAC、Opus等，封装有MP3、OGG、AAC等
3、数据传输：
将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类的线缆进行传输，IP网络发展后，使用IP网络优传输
涉及技术或协议：
传输协议：RTP与RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等
控制信令：SIP和SDP、SNMP等
4、解码数据：
使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图像/声音
涉及技术或协议：
一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等
5、播放显示：
在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声音
涉及技术或协议：
显示器、扬声器、3D眼镜等
三、常见的视频直播相关协议：
1、RTMP(Real Time Messaging Protocol，实时消息传送协议)
RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：
1）、工作在TCP之上的明文协议，使用端口1935；
2）、RTMPT封装在HTTP请求之中，可穿越防火墙；
3）、RTMPS类似RTMPT，但使用的是HTTPS连接；
RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。
2、RTSP(Real Time Streaming Protocol，实时流传输协议)
RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。
RTSP语法和运作跟HTTP/1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP，并且因为RTSP具有重新导向功能，可根据实际负载情况来切换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
3、RTP(Real-time Transport Protocol，实时传输协议)
RTP是针对多媒体数据流的一种传输层协议，详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H.323或SIP），使它成为IP产业的技术基础。
RTP是建立在UDP协议上的，常与RTCP一起使用，其本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。
RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性，只管发送，不管传输是否丢包，也不管接收方是否有收到包。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。
4、RTCP(Real-time Transport Control Protocol，实时传输控制协议）
RTCP是RTP的配套协议，为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送，定期在多媒体流会话参与者之间传输控制数据。
RTCP的主要功能是为RTP所提供的服务质量（QoS）提供反馈，收集相关媒体连接的统计信息，例如传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器。
开发直播网站，想在手机浏览器播放，用rtmp推流，但是手机浏览器无法接收rtmp，请问有什么好的方法吗
播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发趣拍直播SDK可以满足以下所有的功能和应用场景，帮助开发者解决各种直播难题采集手机直播SDK通过手机摄像头和麦克风直接采集视频数据和音频数据其中,视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式对于采集到的原始音视频的体积是非常大的，因此需要经过压缩技术来处理，降低视频的大小来提示传输效率在手机视频采集方面，iOS系统在硬件的兼容性方面做得比较好，系统本身提供了比较完整的视频采集的接口，使用起来也比较简单但是，Android系统就比较麻烦了，千奇百怪的机型都有，适配起来非常难我们在初期做了一项调研，发现Android的适配率还不到50%2.前处理在这个环节主要处理美颜、水印、模糊等效果特别是美颜功能几乎是直播的标配功能，没有美颜的直播主播们根本提不起兴趣我们见过太多case是因为没有美颜功能被抛弃使用的另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上所以，在选择直播SDK时，没有美颜和水印功能基本就可以选择放弃了美颜实际上是通过算法去识别图像中的皮肤部分，再对皮肤区域进行色值调整通常情况下人的肤色与周边环境色调存在较大差异，通过颜色对比，找到皮肤的基本轮廓，进一步进行肤色检查还可以确定人脸范围找到了皮肤的区域，可以进行色值调整、添加白层或调整透明度等来等来达到美白效果美颜除了美白效果还需要磨皮功能，磨皮实际上就是用模糊滤镜实现的滤镜有很多种，如高斯滤波，双边滤波，导向滤波，到底选择什么样的模糊滤镜各家也有自己的喜好在美颜处理方面，最著名的GPUImage提供了丰富的效果，同时可以支持IOS和Android，还支持自己写算法实现自己最理性的效果GPUImage本事内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了，比如大家可以试试使用GPUImageBilateralFiter的双边滤波滤镜来处理基本的磨皮效果，想要实现更理想的效果还是要通过自定义算法去实现的，各家也都有自己一套算法3、编码为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积现在比较常用的视频编码是H.264，但具有更高性能的H.265编码技术正在飞速发展，并可能很快成为主流；在音频方面，通比较常用的是用AAC编码格式进行压缩，其它如MP3、WMA也是可选方案视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码通俗点讲就是编码器将多张图像进行编码后产生一段段GOP（GroupofPictures），播放时解码器读取一段段GOP进行解码后读取图像并进行渲染显示在编码方面的核心是在分辨率、码率、帧率等参数中找到更佳平衡点，达到体积最小画面更优的效果，这些参数各家也都有自己的一套核心参数2023年8月，爱立信公司推出了首款H.265编解码器，六个月后，国际电联(ITU)就正式批准通过了HEVC/H.265标准，称之为高效视频编码(HighEfficiencyVideoCoding)，相较于之前的H.264标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于1.5Mbps的网络也能传输1080p的高清视频国内，如阿里云、金山云都在推自己的H.265编解码技术，随着直播的快速发展和对带宽的依赖，H.265编解码技术已有全面取代H.264的趋势当然，全面推开应用还需要些时间另外，硬件编码已经成为手轿则空机直播盯贺的首选方案，软编码处理在720p以上的视频颓势非常明显在IOS平台上硬件编码的兼容性比较好，可以直接采用，但在Android平台上，Android的MediaCodec编码器，针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的4、推流要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时闭瞎通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是更好的选择，可参考文章开头介绍的云视频服务商据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，性能还是非常有保障的通常，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅性和稳定性
RTMP协议抓包分析拉流过程
RTMP协议规定，播放一个流媒体有两个前提步骤：
之一步，建立一个网络连接（NetConnection）。
第二步，建立一个网络流（NetStream）。
网络连接代表服务器端应用程序和客户端之间基础的连通关系，网络流代表了发送多媒体数据的通道。服务器和客户端之间只能建立一个网络连接，但是基于该连接可以创建很多网络流。
播放一个RTMP协议的流媒体需要经过四个阶段：
下面是使用librtmp执行拉流过程的API调用流，如下：
RTMP定义了较为完善的协议标准，但是每种播放工具的实现略有差异，下面是我使用VLC播放器拉流时抓取的报文，使用wireshark分析过程整理为下面的图文。
先看一张总览图，图中显示的报文和时序包含了握手、建立连接、建立流和播放阶段，如下：
还有申明下，以下的流程是根据实际抓包情况分析出来的，由于不同的工具省略了一些不必要的步骤，故不代表标准结果，仅供参考。
由于讲解握手过程的文档资料比较多，我这里就不重复描述了，摘图如下：
个人认为这张图是更符合标准时序的，细节拿捏得非常讲究，虽然很多实现简化了流程。
包括以下报文和步骤：
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 0
CSID: 3
猛神 时间戳：0
BodySize: 201
枝坦亏 TypeID: 0x14
Stream ID: 0
负载格式：AMF0表示，connect 1 object1
object1属性列表：
信睁 “app”: “live”
“flashVer”: “LNX 9,0,124,2”
“tcUrl”: ” “
“fpad”: false
“capabilities”: 15,
“audioCodes”: 4071,
“videoCodes”: 252,
“videoFunction”: 1,
End Of Object Marker
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 2
时间戳：0
BodySize: 4
TypeID: 0x05
Stream ID: 0
负载格式：4字节整型表示，如
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 2
时间戳：0
BodySize: 5
TypeID: 0x06
Stream ID: 0
负载格式：5字节整型表示，前4字节为带宽，后1字节为标志，如, 2(动态调整)
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 2
时间戳：0
BodySize: 4
TypeID: 0x01
Stream ID: 0
负载格式：4字节整型表示，如4096
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 3
时间戳：0
BodySize: 190
TypeID: 0x14
Stream ID: 0
负载格式：AMF0表示，_result 1 object1 object2
object1属性列表：
“fmsVer”: “FMS/3,0,1,123”
“capabilities”: 31,
End Of Object Marker
object2属性列表：
“level”: “status”
“code”: “NetConnection.Connect.Success”,
“description”: “Connection succeeded.”,
“objectEncoding”: 0
End Of Object Marker
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 0
CSID: 2
时间戳：0
BodySize: 4
TypeID: 0x05
Stream ID: 0
负载格式：4字节整型表示，如
包括以下报文和步骤：
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 1
CSID: 3
时间戳：0
BodySize: 25
TypeID: 0x14
负载格式：AMF0表示，createStream 2 object(Null)
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 3
时间戳：0
BodySize: 29
TypeID: 0x14
Stream ID: 0
负载格式：AMF0表示，_result 2 object(Null) Number(1)
包括以下报文和步骤：
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 0
CSID: 8
时间戳：0
BodySize: 30
TypeID: 0x14
Stream ID: 1
负载格式：AMF0表示，play 4 Object(Null) String节目ID(“a”) Number开始时间(-2023)
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 1
CSID: 2
时间戳：1
BodySize: 10
TypeID: 0x04
负载格式：Event Type，2字节的类型(3) 4字节的流ID(1) 4字节的MS时间单位(3000)
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 2
时间戳：0
BodySize: 6
TypeID: 0x04
负载格式：Event Type，2字节的类型(0) 4字节的流ID(1)
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 5
时间戳：0
BodySize: 96
TypeID: 0x14
Stream ID: 1
负载格式：AMF0表示，onStatus 0 Object1(Null) object2
object2属性列表：
“level”: “status”
“code”: “NetStream.Play.Start”,
“description”: “Start live”,
End Of Object Marker
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 5
时间戳：0
BodySize: 387
TypeID: 0x12
Stream ID: 1
负载格式：AMF0表示，onMetaData object
object属性列表：
“Server”: “NGINX RTMP”
“width”: 480,
“height”: 270,
“displayWidth”: 480,
“displayHeight”: 270,
“duration”: 0,
“framerate”: 16,
“fps”: 16,
“videodatarate”: 193,
“videocodeid”: 7,
“audiodatarate”: 52,
“audiocodeid”: 10,
“profile”: “”,
“level”: “”,
End Of Object Marker
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 6
时间戳：0
BodySize: 209
TypeID: 0x08
Stream ID: 1
负载格式：格式头，媒体数据
结合以上分析，总结时序图如下：
另外，关于HeaderType和CSID的运用，先归纳使用情况：
0x14(connect) HeaderType: 0 CSID: 3
0x05(Ack Window Size) HeaderType: 0 CSID: 2
0x06(BrandWidth) HeaderType: 0 CSID: 2
0x01(ChunkSize) HeaderType: 0 CSID: 2
0x14(connect _result) HeaderType: 0 CSID: 3
0x14(createStream) HeaderType: 1 CSID: 3
0x14(createStream _result) HeaderType: 0 CSID: 3
0x14(play) HeaderType: 0 CSID: 8
0x04(SetBufferMS) HeaderType: 1 CSID: 2
0x04(Stream Begin) HeaderType: 0 CSID: 2
0x14(play onStatus) HeaderType: 0 CSID: 5
0x12(onMetaData) HeaderType: 0 CSID: 5
0x08(audioData) HeaderType: 0 CSID: 6
0x09(videoData) HeaderType: 0 CSID: 7
总结：
关于HeaderType的运用，有以下规则：
createStream使用1号HeaderType，借用3号CSID之前的StreamID。
SetBufferMS使用1号HeaderType。
audioData和videoData视情况使用0、1、2、3号HeaderType。
关于CSID的运用，有以下规则：
rtmp直播流服务器的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于rtmp直播流服务器,构建稳定高效的RTMP直播流服务器，实现流畅直播体验。,视频直播App搭建的音视频采集和处理,开发直播网站，想在手机浏览器播放，用rtmp推流，但是手机浏览器无法接收rtmp，请问有什么好的方法吗,RTMP协议抓包分析拉流过程的信息别忘了在本站进行查找喔。
