0.引言
为了更好理解本篇文章，可以先阅读前面几篇文章，文章列表如下:
详解RTP打包AAC实战分析(1)
详解RTP协议之H264封包和解包实战
详解RTP协议之H264封包细节(1)
详细解析RTSP框架和数据包分析(1)
手把手搭建RTSP流媒体服务器
RTP协议
HLS实战之Wireshark抓包分析
HTTP实战之Wireshark抓包分析
1.RTSP协议传输重要字段说明
(1)Accept:用于指定客户端可以接收的媒体描述信息类型。如下类型:
Accept: application/rtsl, application/sdp;level=2
(2)Bandwidth:描述客户端可⽤的带宽值。
(3)CSeq：指定了RTSP请求回应对的序列号，在每个请求或回应中都必须包括这个头字段。对每个包含⼀个给定序列号的请求消息，都会有⼀个相同序列号的回应消息。
(4)Rang：指定⼀个时间范围，可以使⽤SMPTE、NTP或clock时间单元。
(5)session:Session头字段标识了⼀个RTSP会话。Session ID是由服务器在SETUP的回应中选择的，客户端⼀当得到Session ID后，在以后的对Session的操作请求消息中都要包含Session ID。
(6)Transport:Transport头字段包含客户端可以接受的传输选项列表，包括传输协议，地址端⼝，TTL等。服务端也通过这个头字段返回实际选择的具体选项。如下所示:
Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
2.RSTP协议
2.1 RSTP协议简述
RTSP有一个session概念，是一个文本协议。rtsp传输音视频数据，一种是tcp，一种是Udp方式。本节课主要是讲解udp的方式。这里推荐一个RTSP很详细的文档，如下地址:
https://blog.csdn.net/u012519333/article/details/52746375
如下界面:
RTSP(Real-Time Stream Protocol )是⼀种基于⽂本的应⽤层协议，在语法及⼀些消息参数等⽅⾯，RTSP协议与HTTP协议类似。RTSP被⽤于建⽴的控制媒体流的传输，它为多媒体服务扮演“⽹络远程控制”的⻆⾊。尽管有时可以把RTSP控制信息和媒体数据流交织在⼀起传送，但⼀般情况RTSP本身并不⽤于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。
2.2 RTSP协议与HTTP协议区别
(1)RTSP引⼊了⼏种新的⽅法，⽐如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符。
(2)HTTP是⽆状态的协议，⽽RTSP会为每个会话保持状态session的概念。
(3)RTSP协议的客户端和服务器端都可以发送Request请求，⽽在HTTP协议中，只有客户端能发送Request请求。
(4)在RTSP协议中，负载数据⼀般是通过带外⽅式来传送的(除了交织的情况)，即通过RTP协议在不同的通道中来传送负载数据。⽽HTTP协议的载荷数据都是通过带内⽅式传送的，⽐如请求的⽹⻚数据是在回应。
(5)使⽤ISO 10646(UTF-8) ⽽不是ISO 8859-1，以配合当前HTML的国际化。
(6)RTSP使⽤URI请求时包含绝对URL。⽽由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放⼊单独的标题域中的消息体中携带的。
2.3 RTSP协议传输，拉流基本流程
拉流时，基本的RTSP传输的重要步骤，如下:
(1)客户端连接到服务端并发送⼀个RTSP描述命令（DESCRIBE）。
(2)服务端通过⼀个SDP描述来进⾏反馈，反馈信息包括流数量、媒体类型等信息。
(3)客户端再分析该SDP描述，并为会话中的每⼀个流发送⼀个RTSP建⽴命令(SETUP)，RTSP建⽴命令告诉服务器客户端⽤于接收媒体数据的端⼝。
(4)流媒体连接建⽴完成后，客户端发送⼀个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。
(5)在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送⼀个终⽌命令(TERADOWN)来结束流媒体会话。
接下来，就通过实战抓包的方式，详细分析拉流过程。
3.拉流详细过程
3.1 查询服务器端可⽤⽅法
(1)C->S，客户端发送给服务器，首先发送OPTION request请求，目的是查询服务器有哪些⽅法可以使用。如下图:
(2)S->C，服务端回应客户端，发送OPTION response，目的是回应信息的public头字段中包括提供的所有可⽤⽅法，如PLAY、PAUSE、ANNOUNCE、RECORD等。如下图:
3.2 DESCRIBE得到媒体描述信息
(3)C->S，客户端发送服务端DESCRIBE request，目的是要求得到服务端提供媒体描述信息。如下图：
(4)S->C，服务端回应客户端:DESCRIBE response，目的是服务端回应媒体描述信息，⼀般是sdp信息(包含了音视频的描述信息)。如下图：
3.3 SETUP建⽴RTSP会话
(5)C->S，客户端发送服务端SETUP request，目的是通过Transport头字段列出可接受的传输选项，请求服务端建⽴会话。如下图：
(6)S->C，服务端回应客户端SETUP response，目的是服务端建立会话，通过Transport头字段返回选择的具体转输选项。如下图：
(7)C->S，客户端发送服务端PLAY request，目的是客户端请求服务端开始发送数据。如下图：
(7)S->C，服务端回应客户端，PLAY response，目的是服务端回应请求信息，音视频流都会包含在里面。如下图：
注意：如果流已经播放了一段时间，那最终是通过npt=起始时间来去获取实时流。客户端请求服务器推流，可以设置范围。
3.4 RTP数据传输和播放
(8)S->C，服务端回应客户端，目的是服务端发送流媒体数据，通过RTP协议传送数据。video 这⾥的ssrc 就是来⾃setup返回来的SSRC。如下图：
audio 这⾥的ssrc 就是来⾃setup返回来的SSRC。如下图：
3.5 TEARDOWN关闭会话，退出
(9)C->S，TEARDOWN request，目的是客户端请求关闭会话。如下图：
(10)S->C，TEARDOWN response，目的是服务端回应请求。如下图：
4.总结
本文主要讲解了RTSP协议在拉流过程中的详细分析，通过WireShark抓包分析每一步，能够帮助你更好的理解整个协议。但是要值得提醒的是，上述的过程只是标准的、友好的rtsp流程，实际的需求中并不⼀定按此过程。希望能够帮助到大家。欢迎关注，收藏，转发，分享。
后期关于项目知识，也会更新在微信公众号“记录世界 from antonio”，欢迎关注
