0.引言
本文主要讲解RTSP框架和抓取RTSP数据包，进行详细分析。可以阅读以下几篇文章，能够帮助你更详细理解。
手把手搭建RTSP流媒体服务器
HLS实战之Wireshark抓包分析
HTTP实战之Wireshark抓包分析
1.RTSP协议简述
RTSP：Real Time Streaming Protocol是⼀种实时⽹络流传输协议，旨在发送低延迟流。该协议由RealNetworks，Netscape和哥伦⽐亚⼤学的专家在1996年开发。它定义了应如何打包流中的数据以进⾏传输。
其实 TCP/IP 协议体系中的一个应用层协议，该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTSP传送的是多媒体数据。
RTSP是基于文本的协议，采用ISO10646字符集，使用UTF-8编码方案。行以CRLF中断，包括消息类型、消息头、消息体和消息长。但接收者本身可将CR和LF解释成行终止符。基于文本的协议使其以自描述方式增加可选参数更容易，接口中采用SDP作为描述语言。
RTSP是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
RTSP建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。
RTSP协议具有如下特点：
可扩展性：新方法和参数很容易加入RTSP。
易解析：RTSP可由标准HTTP或MIME解析器解析。
安全：RTSP使用网页安全机制。
独立于传输：RTSP可使用不可靠数据报协议(EDP)、可靠数据报协议(RDP)；如要实现应用级可靠，可使用可靠流协议。
多服务器支持：每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行。
记录设备控制：协议可控制记录和回放设备。
流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建惟一会议标识号。特殊情况下，可用SIP或H.323来邀请服务器入会。
适合专业应用：通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。
演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个RTSP URL。
代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
HTTP友好：此处，RTSP明智地采用HTTP观念，使现在结构都可重用。结构包括Internet内容选择平台(PICS)。由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTFP添加方法。
适当的服务器控制：如用户启动一个流，必须也可以停止一个流。
传输协调：实际处理连续媒体流前，用户可协调传输方法。
性能协调：如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效。这允许用户提出适合的用户界面。
关于更详细的描述，可以参考如下链接:
https://baike.baidu.com/item/RTSP/1276768?fromtitle=RTSP%E5%8D%8F%E8%AE%AE&fromid=3361755&fr=aladdin
个人觉得RTSP协议相比RTMP协议，更加的复杂。
RTSP协议家族由RTSP部分，RTP部分，RTCP部分，SDP部分组成。RTSP(应用层)也是一个控制命令协议，能够播放、暂停、停止码流。音视频数据不走RTSP协议。RTP是负责音视频的数据发送，RTP(传输层)即可以基于TCP(可能会有点延时，丢包会重传)，也可以基于UDP(实时性更好，丢包不会重传)。RTCP(应用层)是对RTP进行控制同步机制。SDP(应用层)是描述多媒体会话，如包含音视频的编解码信息，源地址信息，时间信息等。RTSP整个协议系统如下图:
注意:这里的RTP实际也是应用层，只是在该协议系统中的位置是传输层。只是所处的位置不一样。
2.RTSP家族协议框架
音视频数据是通过RTP协议传输数据，控制部分主要是由RTCP和RTSP协议部分，其中RTCP与RTP是有一定关系，控制部分的RTSP是基于TCP协议，RTCP与RTP既可以走TCP传输，也可以走UDP传输。也就是RTSP协议系统涉及多组传输通道，这与RTMP协议的出入还是很大，RTSP会更加复杂。
注意:SDP是封装在控制部分的RTSP去传输，并不是单独的。并且RTSP部分和SDP部分，只能基于TCP去传输，切记！
3.推流端使用TCP方式，Wireshark抓取RTSP协议数据包
关于RTSP流媒体服务器环境搭建，可以参考上面一篇文章。手把手搭建RTSP流媒体服务器
通过Wireshark抓包，获取数据和控制协议部分。
(1)首先运行ZLMediakit流媒体服务器
(2)然后开启rtsp推流，拉流。
(3)推流命令，先选择TCP的方式传输。
ffmpeg -re -i source.200kbps.768x320.flv -vcodec h264 -acodec aac -f rtsp -rtsp_transport tcp rtsp://172.16.204.139/live/test
(4)运行Wireshark
注意:网卡一定要选择对，我这里选择如下网卡。
(5)设置过滤器，在窗口输入命令:
rtsp or rtp or rtcp
如下界面:
(6)通过wireshark抓包工具，可以更清楚的看看这个协议的组成。如下界面；
注意:下面看到的OPTIONS、Reply、ANNOUNCE都是信令，
(7)第一个包是通过RTSP协议，客户端发给服务端，数据如下:
(8)第二个包是通过RTSP协议，服务端发给客户端，数据如下:
(9)第三个包是通过RTSP和SDP协议，客户端发给服务端，数据如下:
通过抓包数据可以看到，这里SDP协议专用于传输文本。
注意:这里的RTSP和SDP都是用的统一端口号，默认是554。
(10)第四个包是通过RTSP协议，服务端发给客户端，数据如下:
(11)第五个包是通过RTSP协议，客户端发给服务端，数据如下:
(12)第六个包是通过RTSP协议，服务端发给客户端，数据如下:
(13)第七个包是通过RTSP协议，客户端发给服务端，数据如下:
(14)第八个包是通过RTSP协议，服务端发给客户端，数据如下:
(15)第九个包是通过RTSP协议，客户端发给服务端，数据如下:
(16)第十个包是通过RTSP协议，服务端发给客户端，数据如下:
(17)第十一个包是通过RTCP协议，客户端发给服务端，数据如下:
注意:RTCP协议也是通过端口号554发送。
(18)从第十二个包开始，后面就是一直通过RTP协议发送音视频数据，中间会有RTCP协议从客户端到服务端去发送“Sender Report”。如下界面:
通过查看数据含义可以看出，这里的"96"表示H264，如下:
通过查看数据含义可以看出，这里的"97"表示AAC，如下:
注意:RTP协议发送真正的音视频数据默认也是通过端口号554发送。
(19)当客户端终止推流时，也会向服务器上发送，终止命令"TEARDOWN"。如下界面:
4.推流端使用udp方式，Wireshark抓取RTSP协议数据包
ffmpeg -re -i source.200kbps.768x320.flv -vcodec h264 -acodec aac -f rtsp -rtsp_transport udp rtsp://172.16.204.139/live/test
注意:下面看到的OPTIONS、Reply、ANNOUNCE、SETUP、RECORD都是信令。
(1)第一个包是通过RTSP协议，客户端发给服务端，数据如下:
这里的RTSP端口号(RTSP协议部分始终是基于tcp)，还是使用的554。
(2)第二个包是通过RTSP协议，服务端发给客户端，数据如下:
(3)第三个包是通过RTSP/SDP协议，客户端发给服务端，数据如下:
这里的RTSP/SDP协议还是使用的同一端口号554。
发送SDP信息(音视频文本描述信息)很重要，推流客户端会把码流相关的信息告诉服务端，比如这里的SPS信息，这个是很重要的，这样服务端就可以很清楚知道客户端码流的基本信息。如下界面:
(4)第四个包是通过RTSP协议，服务端发给客户端，数据如下:
(5)第五个包是通过RTSP/SDP协议，客户端发给服务端，数据如下:
(6)第六个包是通过RTSP协议，服务端发给客户端，数据如下:
这里服务器回复客户端，设置了视频传输的专用端口号。
(7)第七个包是通过RTSP协议，客户端发给服务端，数据如下:
(8)第八个包是通过RTSP协议，服务端发给客户端，数据如下:
这里服务器回复客户端，设置了音频传输的专用端口号。
(9)第九个包是通过RTSP协议，客户端发给服务端，数据如下:
(10)第十个包是通过RTSP协议，服务端发给客户端，数据如下:
从数据来看，回复的是一些流地址信息。
(11)第十一个包是通过RTSP协议，客户端发给服务端，数据如下:
(12)从第十一个包以后，就会发送音频和视频数据了，推流端设置的UDP方式，就会影响这里的RTP和RTCP的方式，即通过UDP传输。
(13)这时候可以看到RTCP使用的就是UDP协议传输，端口号使用的是40451。
(14)这时候可以看到RTCP使用的就是UDP协议传输，视频传输端口号使用的是40450。
(15)这时候可以看到RTCP使用的就是UDP协议传输，音频传输端口号使用的是55034。
(16)这时候可以看到RTCP使用的就是UDP协议传输，在音视频中间传输的还有使用RTCP协议，这里使用的端口号为55035。
(17)客户端首先发送“SETUP”给服务端，服务端回应“Reply”给客户端，并指定了端口号40450，专用于视频传输。
(18)客户端紧接着又发送“SETUP”给服务端，服务端回应“Reply”给客户端，并指定了端口号55034，专用于音频传输。
综上所述，在基于udp协议传输的时候，RTP和RTCP通道端口号都是独立。而且RTP对于audio、video也是独立，RTCP对于audio、video也是独立。同时也可以得出，设置的推流基于UDP协议，仅仅是针对RTP和RTCP，不针对RTSP部分，因为RTSP部分依然还是TCP。这是一定要记住的。
使用udp会使用很多端口号，这是与基于TCP协议很大的不同地方。
5.总结
本文重点讲解了RTSP家族协议的组成和框架，并通过抓包更详细的分析了每个协议的数据，能够让大家更清楚的认识RTSP家族协议每个部分的功能。通过设置TCP和UDP两种不同的推流方式，抓取数据包，能够理解推流客户端与服务端之间的数据关系。希望能够帮助到大家。欢迎关注，转发，点赞，收藏，分享，评论区讨论。
后期关于项目的知识，会在微信公众号上更新，如果想要学习项目，可以关注微信公众号“记录世界 from antonio”
0.引言
本文主要讲解RTSP框架和抓取RTSP数据包，进行详细分析。可以阅读以下几篇文章，能够帮助你更详细理解。
手把手搭建RTSP流媒体服务器
HLS实战之Wireshark抓包分析
HTTP实战之Wireshark抓包分析
1.RTSP协议简述
RTSP：Real Time Streaming Protocol是⼀种实时⽹络流传输协议，旨在发送低延迟流。该协议由RealNetworks，Netscape和哥伦⽐亚⼤学的专家在1996年开发。它定义了应如何打包流中的数据以进⾏传输。
其实 TCP/IP 协议体系中的一个应用层协议，该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTSP传送的是多媒体数据。
RTSP是基于文本的协议，采用ISO10646字符集，使用UTF-8编码方案。行以CRLF中断，包括消息类型、消息头、消息体和消息长。但接收者本身可将CR和LF解释成行终止符。基于文本的协议使其以自描述方式增加可选参数更容易，接口中采用SDP作为描述语言。
RTSP是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
RTSP建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。
RTSP协议具有如下特点：
可扩展性：新方法和参数很容易加入RTSP。
易解析：RTSP可由标准HTTP或MIME解析器解析。
安全：RTSP使用网页安全机制。
独立于传输：RTSP可使用不可靠数据报协议(EDP)、可靠数据报协议(RDP)；如要实现应用级可靠，可使用可靠流协议。
多服务器支持：每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行。
记录设备控制：协议可控制记录和回放设备。
流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建惟一会议标识号。特殊情况下，可用SIP或H.323来邀请服务器入会。
适合专业应用：通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。
演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个RTSP URL。
代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
HTTP友好：此处，RTSP明智地采用HTTP观念，使现在结构都可重用。结构包括Internet内容选择平台(PICS)。由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTFP添加方法。
适当的服务器控制：如用户启动一个流，必须也可以停止一个流。
传输协调：实际处理连续媒体流前，用户可协调传输方法。
性能协调：如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效。这允许用户提出适合的用户界面。
关于更详细的描述，可以参考如下链接:
https://baike.baidu.com/item/RTSP/1276768?fromtitle=RTSP%E5%8D%8F%E8%AE%AE&fromid=3361755&fr=aladdin
个人觉得RTSP协议相比RTMP协议，更加的复杂。
RTSP协议家族由RTSP部分，RTP部分，RTCP部分，SDP部分组成。RTSP(应用层)也是一个控制命令协议，能够播放、暂停、停止码流。音视频数据不走RTSP协议。RTP是负责音视频的数据发送，RTP(传输层)即可以基于TCP(可能会有点延时，丢包会重传)，也可以基于UDP(实时性更好，丢包不会重传)。RTCP(应用层)是对RTP进行控制同步机制。SDP(应用层)是描述多媒体会话，如包含音视频的编解码信息，源地址信息，时间信息等。RTSP整个协议系统如下图:
注意:这里的RTP实际也是应用层，只是在该协议系统中的位置是传输层。只是所处的位置不一样。
2.RTSP家族协议框架
音视频数据是通过RTP协议传输数据，控制部分主要是由RTCP和RTSP协议部分，其中RTCP与RTP是有一定关系，控制部分的RTSP是基于TCP协议，RTCP与RTP既可以走TCP传输，也可以走UDP传输。也就是RTSP协议系统涉及多组传输通道，这与RTMP协议的出入还是很大，RTSP会更加复杂。
注意:SDP是封装在控制部分的RTSP去传输，并不是单独的。并且RTSP部分和SDP部分，只能基于TCP去传输，切记！
3.推流端使用TCP方式，Wireshark抓取RTSP协议数据包
关于RTSP流媒体服务器环境搭建，可以参考上面一篇文章。手把手搭建RTSP流媒体服务器
通过Wireshark抓包，获取数据和控制协议部分。
(1)首先运行ZLMediakit流媒体服务器
(2)然后开启rtsp推流，拉流。
(3)推流命令，先选择TCP的方式传输。
ffmpeg -re -i source.200kbps.768x320.flv -vcodec h264 -acodec aac -f rtsp -rtsp_transport tcp rtsp://172.16.204.139/live/test
(4)运行Wireshark
注意:网卡一定要选择对，我这里选择如下网卡。
(5)设置过滤器，在窗口输入命令:
rtsp or rtp or rtcp
如下界面:
(6)通过wireshark抓包工具，可以更清楚的看看这个协议的组成。如下界面；
注意:下面看到的OPTIONS、Reply、ANNOUNCE都是信令，
(7)第一个包是通过RTSP协议，客户端发给服务端，数据如下:
(8)第二个包是通过RTSP协议，服务端发给客户端，数据如下:
(9)第三个包是通过RTSP和SDP协议，客户端发给服务端，数据如下:
通过抓包数据可以看到，这里SDP协议专用于传输文本。
注意:这里的RTSP和SDP都是用的统一端口号，默认是554。
(10)第四个包是通过RTSP协议，服务端发给客户端，数据如下:
(11)第五个包是通过RTSP协议，客户端发给服务端，数据如下:
(12)第六个包是通过RTSP协议，服务端发给客户端，数据如下:
(13)第七个包是通过RTSP协议，客户端发给服务端，数据如下:
(14)第八个包是通过RTSP协议，服务端发给客户端，数据如下:
(15)第九个包是通过RTSP协议，客户端发给服务端，数据如下:
(16)第十个包是通过RTSP协议，服务端发给客户端，数据如下:
(17)第十一个包是通过RTCP协议，客户端发给服务端，数据如下:
注意:RTCP协议也是通过端口号554发送。
(18)从第十二个包开始，后面就是一直通过RTP协议发送音视频数据，中间会有RTCP协议从客户端到服务端去发送“Sender Report”。如下界面:
通过查看数据含义可以看出，这里的"96"表示H264，如下:
通过查看数据含义可以看出，这里的"97"表示AAC，如下:
注意:RTP协议发送真正的音视频数据默认也是通过端口号554发送。
(19)当客户端终止推流时，也会向服务器上发送，终止命令"TEARDOWN"。如下界面:
4.推流端使用udp方式，Wireshark抓取RTSP协议数据包
ffmpeg -re -i source.200kbps.768x320.flv -vcodec h264 -acodec aac -f rtsp -rtsp_transport udp rtsp://172.16.204.139/live/test
注意:下面看到的OPTIONS、Reply、ANNOUNCE、SETUP、RECORD都是信令。
(1)第一个包是通过RTSP协议，客户端发给服务端，数据如下:
这里的RTSP端口号(RTSP协议部分始终是基于tcp)，还是使用的554。
(2)第二个包是通过RTSP协议，服务端发给客户端，数据如下:
(3)第三个包是通过RTSP/SDP协议，客户端发给服务端，数据如下:
这里的RTSP/SDP协议还是使用的同一端口号554。
发送SDP信息(音视频文本描述信息)很重要，推流客户端会把码流相关的信息告诉服务端，比如这里的SPS信息，这个是很重要的，这样服务端就可以很清楚知道客户端码流的基本信息。如下界面:
(4)第四个包是通过RTSP协议，服务端发给客户端，数据如下:
(5)第五个包是通过RTSP/SDP协议，客户端发给服务端，数据如下:
(6)第六个包是通过RTSP协议，服务端发给客户端，数据如下:
这里服务器回复客户端，设置了视频传输的专用端口号。
(7)第七个包是通过RTSP协议，客户端发给服务端，数据如下:
(8)第八个包是通过RTSP协议，服务端发给客户端，数据如下:
这里服务器回复客户端，设置了音频传输的专用端口号。
(9)第九个包是通过RTSP协议，客户端发给服务端，数据如下:
(10)第十个包是通过RTSP协议，服务端发给客户端，数据如下:
从数据来看，回复的是一些流地址信息。
(11)第十一个包是通过RTSP协议，客户端发给服务端，数据如下:
(12)从第十一个包以后，就会发送音频和视频数据了，推流端设置的UDP方式，就会影响这里的RTP和RTCP的方式，即通过UDP传输。
(13)这时候可以看到RTCP使用的就是UDP协议传输，端口号使用的是40451。
(14)这时候可以看到RTCP使用的就是UDP协议传输，视频传输端口号使用的是40450。
(15)这时候可以看到RTCP使用的就是UDP协议传输，音频传输端口号使用的是55034。
(16)这时候可以看到RTCP使用的就是UDP协议传输，在音视频中间传输的还有使用RTCP协议，这里使用的端口号为55035。
(17)客户端首先发送“SETUP”给服务端，服务端回应“Reply”给客户端，并指定了端口号40450，专用于视频传输。
(18)客户端紧接着又发送“SETUP”给服务端，服务端回应“Reply”给客户端，并指定了端口号55034，专用于音频传输。
综上所述，在基于udp协议传输的时候，RTP和RTCP通道端口号都是独立。而且RTP对于audio、video也是独立，RTCP对于audio、video也是独立。同时也可以得出，设置的推流基于UDP协议，仅仅是针对RTP和RTCP，不针对RTSP部分，因为RTSP部分依然还是TCP。这是一定要记住的。
使用udp会使用很多端口号，这是与基于TCP协议很大的不同地方。
5.总结
本文重点讲解了RTSP家族协议的组成和框架，并通过抓包更详细的分析了每个协议的数据，能够让大家更清楚的认识RTSP家族协议每个部分的功能。通过设置TCP和UDP两种不同的推流方式，抓取数据包，能够理解推流客户端与服务端之间的数据关系。希望能够帮助到大家。欢迎关注，转发，点赞，收藏，分享，评论区讨论。
后期关于项目的知识，会在微信公众号上更新，如果想要学习项目，可以关注微信公众号“记录世界 from antonio”