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”

總結

以上是生活随笔為你收集整理的ffmpeg抓取rtsp流并保存_详细解析RTSP框架和数据包分析(1)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。