0.引言
本文主要講解RTSP框架和抓取RTSP數據包，進行詳細分析?？梢蚤喿x以下幾篇文章，能夠幫助你更詳細理解。
1.RTSP協(xié)議簡述
RTSP：Real Time Streaming Protocol是?種實時?絡流傳輸協(xié)議，旨在發(fā)送低延遲流。該協(xié)議由RealNetworks，Netscape和哥倫?亞?學的專家在1996年開發(fā)。它定義了應如何打包流中的數據以進?傳輸。
其實 TCP/IP 協(xié)議體系中的一個應用層協(xié)議，該協(xié)議定義了一對多應用程序如何有效地通過 IP 網絡傳送多媒體數據。RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或UDP完成數據傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTSP傳送的是多媒體數據。
RTSP是基于文本的協(xié)議，采用ISO10646字符集，使用UTF-8編碼方案。行以CRLF中斷，包括消息類型、消息頭、消息體和消息長。但接收者本身可將CR和LF解釋成行終止符?；谖谋镜膮f(xié)議使其以自描述方式增加可選參數更容易，接口中采用SDP作為描述語言。
RTSP是應用級協(xié)議，控制實時數據的發(fā)送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協(xié)議目的在于控制多個數據發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發(fā)送機制提供方法。
RTSP建立并控制一個或幾個時間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交換是可能的，通常它本身并不發(fā)送連續(xù)流。換言之，RTSP充當多媒體服務器的網絡遠程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關閉多個對服務器的可傳輸連接以發(fā)出RTSP請求。此外，可使用無連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機制。
RTSP協(xié)議具有如下特點：
可擴展性：新方法和參數很容易加入RTSP。
易解析：RTSP可由標準HTTP或MIME解析器解析。
安全：RTSP使用網頁安全機制。
獨立于傳輸：RTSP可使用不可靠數據報協(xié)議（EDP）、可靠數據報協(xié)議（RDP）；如要實現應用級可靠，可使用可靠流協(xié)議。
多服務器支持：每個流可放在不同服務器上，用戶端自動與不同服務器建立幾個并發(fā)控制連接，媒體同步在傳輸層執(zhí)行。
記錄設備控制：協(xié)議可控制記錄和回放設備。
流控與會議開始分離：僅要求會議初始化協(xié)議提供，或可用來創(chuàng)建惟一會議標識號。特殊情況下，可用SIP或H.323來邀請服務器入會。
適合專業(yè)應用：通過SMPTE時標，RTSP支持幀級精度，允許遠程數字編輯。
演示描述中立：協(xié)議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包括一個RTSP URL。
代理與防火墻友好：協(xié)議可由應用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個“缺口”。
HTTP友好：此處，RTSP明智地采用HTTP觀念，使現在結構都可重用。結構包括Internet內容選擇平臺（PICS）。由于在大多數情況下控制連續(xù)媒體需要服務器狀態(tài)，RTSP不僅僅向HTFP添加方法。
適當的服務器控制：如用戶啟動一個流，必須也可以停止一個流。
傳輸協(xié)調：實際處理連續(xù)媒體流前，用戶可協(xié)調傳輸方法。
性能協(xié)調：如基本特征無效，必須有一些清理機制讓用戶決定哪種方法沒生效。這允許用戶提出適合的用戶界面。
關于更詳細的描述，可以參考如下鏈接:
https://baike.baidu.com/item/RTSP/1276768?fromtitle=RTSP%E5%8D%8F%E8%AE%AE&fromid=3361755&fr=aladdin
個人覺得RTSP協(xié)議相比RTMP協(xié)議，更加的復雜。
RTSP協(xié)議家族由RTSP部分，RTP部分，RTCP部分，SDP部分組成。RTSP(應用層)也是一個控制命令協(xié)議，能夠播放、暫停、停止碼流。音視頻數據不走RTSP協(xié)議。RTP是負責音視頻的數據發(fā)送，RTP(傳輸層)即可以基于TCP(可能會有點延時，丟包會重傳)，也可以基于UDP(實時性更好，丟包不會重傳)。RTCP(應用層)是對RTP進行控制同步機制。SDP(應用層)是描述多媒體會話，如包含音視頻的編解碼信息，源地址信息，時間信息等。RTSP整個協(xié)議系統(tǒng)如下圖:
注意:這里的RTP實際也是應用層，只是在該協(xié)議系統(tǒng)中的位置是傳輸層。只是所處的位置不一樣。
2.RTSP家族協(xié)議框架
音視頻數據是通過RTP協(xié)議傳輸數據，控制部分主要是由RTCP和RTSP協(xié)議部分，其中RTCP與RTP是有一定關系，控制部分的RTSP是基于TCP協(xié)議，RTCP與RTP既可以走TCP傳輸，也可以走UDP傳輸。也就是RTSP協(xié)議系統(tǒng)涉及多組傳輸通道，這與RTMP協(xié)議的出入還是很大，RTSP會更加復雜。
注意:SDP是封裝在控制部分的RTSP去傳輸，并不是單獨的。并且RTSP部分和SDP部分，只能基于TCP去傳輸，切記！
3.推流端使用TCP方式，Wireshark抓取RTSP協(xié)議數據包
關于RTSP流媒體服務器環(huán)境搭建，可以參考上面一篇文章。手把手搭建RTSP流媒體服務器
通過Wireshark抓包，獲取數據和控制協(xié)議部分。
(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抓包工具，可以更清楚的看看這個協(xié)議的組成。如下界面；
注意:下面看到的OPTIONS、Reply、ANNOUNCE都是信令，
(7)第一個包是通過RTSP協(xié)議，客戶端發(fā)給服務端，數據如下:
(8)第二個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
(9)第三個包是通過RTSP和SDP協(xié)議，客戶端發(fā)給服務端，數據如下:
通過抓包數據可以看到，這里SDP協(xié)議專用于傳輸文本。
注意:這里的RTSP和SDP都是用的統(tǒng)一端口號，默認是554。
(10)第四個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
(11)第五個包是通過RTSP協(xié)議，客戶端發(fā)給服務端，數據如下:
(12)第六個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
(13)第七個包是通過RTSP協(xié)議，客戶端發(fā)給服務端，數據如下:
(14)第八個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
(15)第九個包是通過RTSP協(xié)議，客戶端發(fā)給服務端，數據如下:
(16)第十個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
(17)第十一個包是通過RTCP協(xié)議，客戶端發(fā)給服務端，數據如下:
注意:RTCP協(xié)議也是通過端口號554發(fā)送。
(18)從第十二個包開始，后面就是一直通過RTP協(xié)議發(fā)送音視頻數據，中間會有RTCP協(xié)議從客戶端到服務端去發(fā)送“Sender Report”。如下界面:
通過查看數據含義可以看出，這里的'96'表示H264，如下:
通過查看數據含義可以看出，這里的'97'表示AAC，如下:
注意:RTP協(xié)議發(fā)送真正的音視頻數據默認也是通過端口號554發(fā)送。
(19)當客戶端終止推流時，也會向服務器上發(fā)送，終止命令'TEARDOWN'。如下界面:
4.推流端使用udp方式，Wireshark抓取RTSP協(xié)議數據包
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協(xié)議，客戶端發(fā)給服務端，數據如下:
這里的RTSP端口號(RTSP協(xié)議部分始終是基于tcp)，還是使用的554。
(2)第二個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
(3)第三個包是通過RTSP/SDP協(xié)議，客戶端發(fā)給服務端，數據如下:
這里的RTSP/SDP協(xié)議還是使用的同一端口號554。
發(fā)送SDP信息(音視頻文本描述信息)很重要，推流客戶端會把碼流相關的信息告訴服務端，比如這里的SPS信息，這個是很重要的，這樣服務端就可以很清楚知道客戶端碼流的基本信息。如下界面:
(4)第四個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
(5)第五個包是通過RTSP/SDP協(xié)議，客戶端發(fā)給服務端，數據如下:
(6)第六個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
這里服務器回復客戶端，設置了視頻傳輸的專用端口號。
(7)第七個包是通過RTSP協(xié)議，客戶端發(fā)給服務端，數據如下:
(8)第八個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
這里服務器回復客戶端，設置了音頻傳輸的專用端口號。
(9)第九個包是通過RTSP協(xié)議，客戶端發(fā)給服務端，數據如下:
(10)第十個包是通過RTSP協(xié)議，服務端發(fā)給客戶端，數據如下:
從數據來看，回復的是一些流地址信息。
(11)第十一個包是通過RTSP協(xié)議，客戶端發(fā)給服務端，數據如下:
(12)從第十一個包以后，就會發(fā)送音頻和視頻數據了，推流端設置的UDP方式，就會影響這里的RTP和RTCP的方式，即通過UDP傳輸。
(13)這時候可以看到RTCP使用的就是UDP協(xié)議傳輸，端口號使用的是40451。
(14)這時候可以看到RTCP使用的就是UDP協(xié)議傳輸，視頻傳輸端口號使用的是40450。
(15)這時候可以看到RTCP使用的就是UDP協(xié)議傳輸，音頻傳輸端口號使用的是55034。
(16)這時候可以看到RTCP使用的就是UDP協(xié)議傳輸，在音視頻中間傳輸的還有使用RTCP協(xié)議，這里使用的端口號為55035。
(17)客戶端首先發(fā)送“SETUP”給服務端，服務端回應“Reply”給客戶端，并指定了端口號40450，專用于視頻傳輸。
(18)客戶端緊接著又發(fā)送“SETUP”給服務端，服務端回應“Reply”給客戶端，并指定了端口號55034，專用于音頻傳輸。
綜上所述，在基于udp協(xié)議傳輸的時候，RTP和RTCP通道端口號都是獨立。而且RTP對于audio、video也是獨立，RTCP對于audio、video也是獨立。同時也可以得出，設置的推流基于UDP協(xié)議，僅僅是針對RTP和RTCP，不針對RTSP部分，因為RTSP部分依然還是TCP。這是一定要記住的。
使用udp會使用很多端口號，這是與基于TCP協(xié)議很大的不同地方。
5.總結
聯系客服
