2. 程式人生 > >rtsp詳解二之wireshark抓包分析

rtsp詳解二之wireshark抓包分析

阿新 • • 發佈：2019-01-09

一、概述

    RTSP(Real-Time Stream Protocol )是一種基於文字的應用層協議，在語法及一些訊息引數等方面，RTSP協議與HTTP協議類似。

    RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網路遠端控制”的角色。RTSP本身並不用於傳送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協議來完成。

  基本的RTSP操作過程

首先，客戶端連線到流伺服器併發送一個OPTIONS命令查詢伺服器提供的方法收到伺服器的迴應後，傳送DESCRIBE命令查詢某個媒體檔案的SDP資訊。流伺服器通過一個SDP描述來進行迴應，迴應資訊包括流數量、媒體型別等資訊。客戶端分析該SDP

描述，併為會話中的每一個流傳送一個SETUP命令，SETUP命令告訴伺服器客戶端用於接收媒體資料的埠。流媒體連線建立完成後，客戶端傳送一個PLAY命令，伺服器就開始傳送媒體流資料。在播放過程中客戶端還可以向伺服器傳送PAUSE等其他命令控制流的播放。通訊完畢，客戶端可傳送TERADOWN命令來結束流媒體會話。

   是通過wireshark抓包獲得的完整客戶端與伺服器進行的RTSP互動。黑色字體表示客戶端請求，紅色字體表示伺服器迴應。

  1. OPTIONS rtsp://10.34.3.80/D:/a.264 RTSP/1.0
  2. CSeq: 2  
  3. User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
  4. <span style="color:#ff0000;">RTSP/1.0 200 OK  
  5. CSeq: 2  
  6. Date: Tue, Jul 22 2014 02:41:21 GMT  
  7. Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER  
  8. </span>DESCRIBE rtsp://10.34.3.80/D:/a.264 RTSP/1.0
  9. CSeq: 3  
  10. User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
  11. Accept: application/sdp  
  12. <span style="color:#ff0000;">RTSP/1.0 200 OK  
  13. CSeq: 3  
  14. Date: Tue, Jul 22 2014 02:41:21 GMT  
  15. Content-Base: rtsp://10.34.3.80/D:/a.264/
  16. Content-Type: application/sdp  
  17. Content-Length: 494  
  18. v=0  
  19. o=- 1405995833260880 1 IN IP4 10.34.3.80  
  20. s=H.264 Video, streamed by the LIVE555 Media Server  
  21. i=D:/a.264  
  22. t=0 0  
  23. a=tool:LIVE555 Streaming Media v2014.07.04  
  24. a=type:broadcast  
  25. a=control:*  
  26. a=range:npt=0-  
  27. a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server  
  28. a=x-qt-text-inf:D:/a.264  
  29. m=video 0 RTP/AVP 96  
  30. c=IN IP4 0.0.0.0  
  31. b=AS:500  
  32. a=rtpmap:96 H264/90000  
  33. a=fmtp:96 packetization-mode=1;profile-level-id=42001E;sprop-parameter-sets=Z0IAHpWoLQSZ,aM48gA==  
  34. a=control:track1  
  35. </span>SETUP rtsp://10.34.3.80/D:/a.264/track1 RTSP/1.0
  36. CSeq: 4  
  37. User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
  38. Transport: RTP/AVP;unicast;client_port=60094-60095  
  39. <span style="color:#ff0000;">RTSP/1.0 200 OK  
  40. CSeq: 4  
  41. Date: Tue, Jul 22 2014 02:41:25 GMT  
  42. Transport: RTP/AVP;unicast;destination=10.34.3.80;source=10.34.3.80;client_port=60094-60095;server_port=6970-6971  
  43. Session: 54DAFD56;timeout=65  
  44. </span>PLAY rtsp://10.34.3.80/D:/a.264/ RTSP/1.0
  45. CSeq: 5  
  46. User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
  47. Session: 54DAFD56  
  48. Range: npt=0.000-  
  49. <span style="color:#ff0000;">RTSP/1.0 200 OK  
  50. CSeq: 5  
  51. Date: Tue, Jul 22 2014 02:41:25 GMT  
  52. Range: npt=0.000-  
  53. Session: 54DAFD56  
  54. RTP-Info: url=rtsp://10.34.3.80/D:/a.264/track1;seq=10244;rtptime=2423329550
  55. </span>GET_PARAMETER rtsp://10.34.3.80/D:/a.264/ RTSP/1.0
  56. CSeq: 6  
  57. User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
  58. Session: 54DAFD56  
  59. <span style="color:#ff0000;">RTSP/1.0 200 OK  
  60. CSeq: 6  
  61. Date: Tue, Jul 22 2014 02:41:25 GMT  
  62. Session: 54DAFD56  
  63. Content-Length: 10  
  64. </span>   
  65. //終止
  66. TEARDOWN rtsp://10.34.3.80/D:/a.264/ RTSP/1.0
  67. CSeq: 7  
  68. User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
  69. Session: 54DAFD56  
  70. <span style="color:#ff0000;">RTSP/1.0 200 OK  
  71. CSeq: 7  
  72. Date: Wed, Jul 30 2014 07:13:35 GMT  
  73. </span>  

     可以發現RTSP協議的格式與http協議很類似，都是基於文字的協議，語法也基本相同。但是它們並不相同，有以下主要差別：

        首先，方法名稱不同。RTSP新增了DESCRIBE、SETUP、PLAY等方法。

       其次，HTTP協議是無狀態的協議，方法之間的傳送並無明顯的次序關係。而RTSP是有狀態的協議，各方法存在次序關係。

在者，HTTP協議可以以內帶載荷資料的方式傳送資料，如網頁資料。而RTSP僅僅提供流播放的控制，並不傳送流媒體資料。流媒體資料可以通過RTP/RTCP的方式傳送。

二、RTSP訊息

    1. RTSP請求訊息格式

     方法名稱 URL RTSP版本回車換行

     訊息頭回車換行回車換行

     訊息體回車換行

    方法名稱包括OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。

    URL是接受方的地址，如:rtsp://192.168.0.1/video1.3gp。

    RTSP版本一般是RTSP/1.0

    訊息的每一行都會以回車換行結尾，為了便於定位識別，訊息頭的最後一行有兩個回車換行。

    訊息體有時是可選的。

2. 迴應訊息格式

    RTSP版本狀態碼對應文字解釋回車換行

    訊息頭回車換行回車換行

    訊息體回車換行

    RTSP版本一般為RTSP/1.0。

    狀態碼錶示對應訊息的執行結果。

    部分狀態碼與文字解釋對應列表如下：

   狀態碼文字解釋含義

  “200”         OK                              執行成功

  “400”         Bad Request                 錯誤請求

  “404”        Not Found                  未找到

  “500”        Internal Server Error   伺服器內部錯誤

3. 各方法詳細介紹

(1)OPTIONS

     客戶端使用OPTION來查詢伺服器提供的方法。伺服器會在public欄位給出自己提供方法集合。從上面的抓包中可以看到此伺服器提供了OPTIONS、DESCRIBE、 SETUP、TEARDOWN、 PLAY,、PAUSE,、GET_PARAMETER、SET_PARAMETER等方法。

    OPTIONS方法並不是必須的。客戶端可以繞過OPTIONS，直接向伺服器傳送其他訊息。

CSeq欄位表示請求的序號。客戶端的每一個請求都會被賦值一個序號。每個請求訊息也會對應一個同樣序號的迴應訊息。

     OPTIONS訊息可以在任何時間傳送。有的客戶端會定時向伺服器傳送OPTION訊息。而伺服器也可以通過是否定時收到OPTIONS訊息來判斷客戶端是否線上。但並不是所有客戶端和伺服器都這樣做。

     User Agent

     該域用於使用者標識.不同公司或是不同的客戶端。不同客戶端發出的訊息中的這個域的內容都不大相同。有時會指明客戶端的版本號、型號等等。

     下面的對話中該欄位指明採用VLC作為客戶端，並給出版本號和使用LIVE555庫的版本。

  1. OPTIONS rtsp://10.34.3.80/D:/a.264 RTSP/1.0
  2. CSeq: 2                                                                                              //請求序號
  3. User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
  4. <span style="color:#ff0000;">RTSP/1.0 200 OK  
  5. CSeq: 2                                                                                              //回覆序號
  6. Date: Tue, Jul 22 2014 02:41:21 GMT  
  7. Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER  
  8. </span>  

(2)DESCRIBE

    DESCRIBE訊息是由客戶端傳送到伺服器端，用於客戶端得到請求連結中指定的媒體檔案的相關描述，一般是SDP資訊。SDP（Session Description Protocol）包含了會話的描述、媒體編碼型別、媒體的位元速率等資訊。對於流媒體服務而言，以下幾個域是在SDP中一定要包含的。

“a=control:”

“a=range:”

“a=rtpmap:”

“a=fmtp:”

     當一個錄影中即包含音訊又包含視訊時，會有多個上述結構。每個媒體描述以m開始。下面綠色和黃色背景的字型分別表示對視訊和音訊媒體的描述。請求中的Accept欄位用於指定客戶端可以接受的媒體描述資訊型別，此處為SDP資訊。

  1. DESCRIBE rtsp://10.34.3.80/D:/a.264 RTSP/1.0
  2. CSeq: 3  
  3. User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
  4. Accept: application/sdp                                //請求獲得SDP資訊
  5. <span style="color:#ff0000;">RTSP/1.0 200 OK  
  6. CSeq: 3  
  7. Date: Tue, Jul 22 2014 02:41:21 GMT  
  8. Content-Base: rtsp://10.34.3.80/D:/a.264/                   //指明對某媒體的描述資訊
  9. Content-Type: application/sdp                                   //請求型別
  10. Content-Length: 494                                                //SDP長度
  11. v=0                                            //Version SDP協議的版本
  12. o=- 1405995833260880 1 IN IP4 10.34.3.80            //Origion  會話的發起者資訊
  13. s=H.264 Video, streamed by the LIVE555 Media Server  //會話名稱
  14. i=D:/a.264                                                              //會話的描述資訊
  15. t=0 0                                                                      //會話的開始和結束時間
  16. a=tool:LIVE555 Streaming Media v2014.07.04          //Attribute
  17. a=type:broadcast  
  18. a=control:*                                                             //控制資訊
  19. a=range:npt=0-  
  20. a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server  
  21. a=x-qt-text-inf:D:/a.264  
  22. m=video 0 RTP/AVP 96            //傳送方所支援的媒體型別（視訊）等資訊
  23. c=IN IP4 0.0.0.0               //會話連線資訊，支出真正的媒體流使用的IP地址。
  24. b=AS:500                                

相關推薦

rtsp詳解二之wireshark抓包分析

一、概述     RTSP(Real-Time Stream Protocol )是一種基於文字的應用層協議，在語法及一些訊息引數等方面，RTSP協議與HTTP協議類似。     RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網路遠端控制”的角

計算機網路實驗（二）之Wireshark抓包分析獲取URL列表（去重、排序、統計）

實驗要求 本試驗要求基於第一次實驗中訪問某官網主頁時所抓取到的資料包，用Python 3語言、Jupyter Notebook和Pyshark編寫程式碼進行協議分析所需的開發環境，編寫程式碼，以輸出的方式列出首頁以及其所包含的所有資源（至少包含如下型別

DHCP完整過程詳解及Wireshark抓包分析

DHCP，Dynamic Host Configuration Protocol，動態主機配置協議，簡單來說就是主機獲取IP地址的過程，屬於應用層協議。 DHCP採用UDP的68（客戶端）和67（伺服器）埠進行通訊。 【過程】 DHCP過程主要為DHCP Discover-->DHCP Offer--&

銳捷CCNA系列(二) Wireshark抓包分析Ping過程

銳捷 CCNA 銳捷實戰 銳捷CCNA 數通 實訓目的 初步了解Wireshark的使用。 能分析Ping過程。 實訓背景 PING(Packet Internet Groper， 因特網包探索器)，用於測試網絡是否連通的程序，在Windows、Linux、Unix下都是標配程序，Pi

死磕Netty原始碼之記憶體分配詳解(二)PoolArena記憶體分配結構分析

前言 在應用層通過設定PooledByteBufAllocator來執行ByteBuf的分配，但是最終的記憶體分配工作被委託給PoolArena。由於Netty通常用於高併發系統所以各個執行緒進行記憶體分配時競爭不可避免，這可能會極大的影響記憶體分配的效率，為

Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作過程

整體而言，RTSP 通常工作於可靠的傳輸協議 TCP 之上，就像 HTTP 那樣，用於發起/結束流媒體傳輸，交換流媒體元資訊。RTP 通常工作於 UDP 之上，用於傳輸實際的流媒體資料，其中的載荷格式因具體流媒體型別的不同而不同，通常有專門的 RFC 規範對其進行定義，如 H

wireshark抓包分析之ftp協議的分析

今天剛剛申請了一個虛擬主機，上傳資料成為問題，Google一下，呵呵噠，看到了flashfxp這個軟體，這個叫什麼鬼東西，原諒小客的英語爛到了極點，下載安裝後，最近正好對協議分析很是感興趣呀，於是，就有了今天這篇處女座的文章，呵呵，個人總是愛說些廢話，好吧，如果你也這麼覺得

AndroidManifest.xml 詳解 (二) 之 ——譯自《Beginning Android Games》 .

    To reference resources, we use the preceding notation. The @ specifies that we want to reference a resource defined elsewhere. The following string ide

Android中Intent詳解(二)之使用Intent廣播事件及Broadcast Receiver簡介

通過第一篇的講解，我們已經看到了如何使用Intent來啟動新的應用程式元件，但是實際上他們也可以使用sendBroadcast方法來在元件間匿名的廣播訊息。 作為一個系統級別的訊息傳遞機制，Intent可以在程序之間傳送結構化的訊息。因此，通過實現Broadcast Rec

從wireshark抓包分析rtmp協議，並提取出H264視頻流

tmp mage idt 進制 tro shark src 技術 wid 利用wireshark抓取rtmp流數據, 分析到rtmp流後，寫入過濾條件，如 tcp.stream eq 6導出tcp流保存16進制的數據為純文本格式一定要選擇 Hex轉儲，然後點擊 “Sava

FTP協議的粗淺學習--利用wireshark抓包分析相關tcp連接

sha ftp命令 動向 c中 細胞 nsf ref 後退 圖片 一、為什麽寫這個 昨天遇到個ftp相關的問題，關於ftp匿名訪問的。花費了大量的腦細胞後，終於搞定了服務端的配置，現在客戶端可以像下圖一樣，直接在瀏覽器輸入url，即可直接訪問。 期間不會彈出輸入用戶名密

聊聊tcpdump與Wireshark抓包分析

1 起因# 前段時間，一直在調線上的一個問題：線上應用接受POST請求，請求body中的引數獲取不全，存在丟失的狀況。這個問題是偶發性的，大概發生的機率為5%-10%左右，這個概率已經相當高了。在排查問題的過程中使用到了tcpdump和Wireshark進行抓包分析。感覺這兩個工具搭配起來

用wireshark抓包分析TCP三次握手、四次揮手以及TCP實現可靠傳輸的機制（轉）

關於TCP三次握手和四次揮手大家都在《計算機網路》課程裡學過，還記得當時高超老師耐心地講解。大學裡我遇到的最好的老師大概就是這位了，雖然他只給我講過《java程式設計》和《計算機網路》，但每次課幾乎都動手敲程式碼或者當場做實驗。好了不扯了，下面進入正題。      關

實現Telnet遠端登入，利用Wireshark抓包分析

一、實驗環境 伺服器：windows server 2008 客戶機：windows 2007 網絡卡連線：NAT（Vmnet 8） 實現客戶機遠端登入伺服器 二、實驗步驟 1、設定IP地址 伺服器：windows server 2008 IP 地 址：192.168.10.1 子

使用tcpdump+wireshark抓包分析網路資料包

最近和學弟在除錯一個GPRS通訊模組,需求是通過GPRS模組通過http協議傳送資料到伺服器,但是http協議一直失敗,伺服器返回400,通過查詢http狀態碼得知,http400錯誤是請求無效,因為GPRS模組沒有實現http協議的封裝,需要在TCP協議的基礎上,手動拼裝http格式的報文.所以初步猜測是h

FTP協議的粗淺學習--利用wireshark抓包分析相關tcp連線

一、為什麼寫這個 昨天遇到個ftp相關的問題，關於ftp匿名訪問的。花費了大量的腦細胞後，終於搞定了服務端的配置，現在客戶端可以像下圖一樣，直接在瀏覽器輸入url，即可直接訪問。 期間不會彈出輸入使用者名稱密碼來登入的視窗。 今天我主要是有點好奇，在此過程中，究竟是否是用匿名賬戶“anonymo

Wireshark抓包分析TCP.IP.UDP.ICMP報文格式

TCP 報文格式分析： TCP 報文段的報頭有 10 個必需的欄位和 1 個可選欄位。報頭至少為 20 位元組。 1）源埠（16位）：標識傳送報文的計算機埠或程序。一個 TCP 報文段必須包括源埠號，使目的主機知道應該向何處傳送確認報文。 2）目的埠（16位）：標識接收報文的目的主機的埠或程序。   由

基於wireshark抓包分析TCP的三次握手

img src 建立 tab 安全 連接狀態 協議 處理 基於 在TCP/IP協議通訊過程中，采用三次握手建立連接，從而保證連接的安全可靠。 通常三次握手步驟如下： 1. 第1次握手：建立連接時，客戶端發送 SYN 包到服務器端，攜帶一個序列碼給服務器端用於確認，並進入

TCP協議基礎知識及wireshark抓包分析實戰

TCP相關知識 應swoole長連線開發調研相關TCP知識並記錄。 資料封包流程 如圖，如果我需要傳送一條資料給使用者，實際的大小肯定是大於你傳送的大小，在各個資料層都進行了資料的封包，以便你的資料能完整的發給你想要的使用者。 乙太網的資料包的負載是1500位元組，IP包頭需要20個位元組，TCP

WireShark抓包分析

簡述：本文介紹了抓包資料含義，有TCP報文、Http報文、DNS報文。如有錯誤，歡迎指正。 1、TCP報文 TCP：（TCP是面向連線的通訊協議，通過三次握手建立連線，通訊完成時要拆除連線，由