rtmp rtsp 区别_Rtsp/Rtmp协议介绍及区别

RTSP是一种基于文本的协议，用CRLF(回车换行)作为每一行的结束符，其好处是，在使用过程中可以方便地增加自定义参数，也方便抓包分析。从消息传送方向上来分，RTSP的报文有两类：请求报文和响应报文。请求报文是指从客户端向服务器发送的请求(也有少量从服务器向客户端发送的请求)，响应报文是指从服务器到客户端的回应。

RTSP请求报文的常用方法与作用：

原文：https://blog.csdn.net/deliapu/article/details/79199023

RTMP spec下载：https://www.adobe.com/devnet/rtmp.html

RTMP操作流程(引用自：https://www.cnblogs.com/ostin/p/9900918.html)

播放一个RTMP协议的流媒体需要经过以下几个步骤：握手，建立连接，建立流，播放。

1. 握手

握手开始于客户端发送C0、C1块。服务器收到C0或C1后发送S0和S1。

当客户端收齐S0和S1后，开始发送C2。当服务器收齐C0和C1后，开始发送S2。

当客户端和服务器分别收到S2和C2后，握手完成。

2. 建立网络连接(NetConnection)

客户端发送命令消息中的“连接”(connect)到服务器，请求与一个服务应用实例建立连接。

服务器接收到连接命令消息后，发送确认窗口大小(Window Acknowledgement Size)协议消息到客户端，同时连接到连接命令中提到的应用程序。

服务器发送设置带宽协议消息到客户端。

客户端处理设置带宽协议消息后，发送确认窗口大小(Window Acknowledgement Size)协议消息到服务器端。

服务器发送用户控制消息中的“流开始”(Stream Begin)消息到客户端

服务器发送命令消息中的“结果”(_result)，通知客户端连接的状态。

3.建立网络流(NetStream)

客户端发送命令消息中的“创建流”(createStream)命令到服务器端。

服务器端接收到“创建流”命令后，发送命令消息中的“结果”(_result)，通知客户端流的状态。

4.播放(Play)

客户端发送命令消息中的“播放”(play)命令到服务器。

接收到播放命令后，服务器发送设置块大小(ChunkSize)协议消息。

服务器发送用户控制消息中的“streambegin”，告知客户端流ID。

播放命令成功的话，服务器发送命令消息中的“响应状态” NetStream.Play.Start & NetStream.Play.reset，告知客户端“播放”命令执行成功。

在此之后服务器发送客户端要播放的音频和视频数据。

RTMP的特点(引用自：https://www.cnblogs.com/gongyuhonglou/p/5605320.html)：

1) Adobe支持得很好：

RTMP实际上是现在编码器输出的工业标准协议，基本上所有的编码器(摄像头之类)都支持RTMP输出。

原因在于PC市场巨大，PC主要是Windows，Windows的浏览器基本上都支持flash，

Flash又支持RTMP支持得非常好。

2) 适合长时间播放：

因为RTMP支持的很完善，所以能做到flash播放RTMP流长时间不断流，

当时测试是100万秒，即10天多可以连续播放。

对于商用流媒体应用，客户端的稳定性当然也是必须的，否则最终用户看不了还怎么玩？

我就知道有个教育客户，最初使用播放器播放http流，需要播放不同的文件，结果就总出问题，

如果换成服务器端将不同的文件转换成RTMP流，客户端就可以一直播放；

该客户走RTMP方案后，经过CDN分发，没听说客户端出问题了。

3)延迟较低：

比起YY的那种UDP私有协议，RTMP算延迟大的(延迟在1-3秒)，

比起HTTP流的延时(一般在10秒以上)RTMP算低延时。

一般的直播应用，只要不是电话类对话的那种要求，RTMP延迟是可以接受的。

在一般的视频会议应用中，RTMP延时也能接受，原因是别人在说话的时候我们一般在听，

实际上1秒延时没有关系，我们也要思考(话说有些人的CPU处理速度还没有这么快)。

4) 有累积延迟：

技术一定要知道弱点，RTMP有个弱点就是累积误差，原因是RTMP基于TCP不会丢包。

所以当网络状态差时，服务器会将包缓存起来，导致累积的延迟；

待网络状况好了，就一起发给客户端。

这个的对策就是，当客户端的缓冲区很大，就断开重连。