整體而言，RTSP 通常工作于可靠的傳輸協(xié)議 TCP 之上，就像 HTTP 那樣，用于發(fā)起/結(jié)束流媒體傳輸，交換流媒體元信息。RTP 通常工作于 UDP
之上，用于傳輸實(shí)際的流媒體數(shù)據(jù)，其中的載荷格式因具體流媒體類型的不同而不同，通常有專門的 RFC 規(guī)范對(duì)其進(jìn)行定義，如 H.264 編碼格式視頻數(shù)據(jù)的載荷格式在 RFC 6184, RTP Payload Format for H.264 Video 中定義，其它流媒體數(shù)據(jù)類型有其它的規(guī)范進(jìn)行定義。RTCP 同樣通常工作于 UDP 之上，用于對(duì) RTP 進(jìn)行控制，流媒體數(shù)據(jù)的收發(fā)端在傳輸過程中相互發(fā)送 RTCP 數(shù)據(jù)包，將自己這一端檢測(cè)到的 QoS 等信息傳遞給對(duì)方，使用 RTP/RTCP 協(xié)議的應(yīng)用程序，利用這些信息對(duì)收發(fā)過程進(jìn)行控制。RTP 和 RTCP 在傳輸過程中，工作于不同的端口上。

我們通過 Wireshark 抓包來看一下 RTSP/RTP/RTCP 的基本工作過程。我們啟動(dòng) live555MediaServer，其工作目錄下存有一些流媒體文件，其中包括 H.264 原始碼流格式的文件 raw_h264_stream.264。啟動(dòng) Wireshark 抓包。然后通過 ffplay 請(qǐng)求 live555MediaServer 并播放 raw_h264_stream.264：

$ ffplay rtsp://10.240.248.20:8554/raw_h264_stream.264

其中 URI 中的 IP 地址為 live555MediaServer 運(yùn)行的主機(jī)的 IP 地址，端口號(hào)為其采用的端口號(hào)。在 Wireshark 中，通過 Display Filter 過濾僅顯示 RTSP/RTP/RTCP 包，將看到類似下面這樣的包序列：

可以看到，首先是 RTSP 數(shù)據(jù)的交互，建立媒體傳輸會(huì)話，隨后開始通過 RTP/RTCP 傳輸數(shù)據(jù)。RTSP 協(xié)議在制定時(shí)較多地參考了 HTTP/1.1 協(xié)議，甚至許多內(nèi)容與 HTTP/1.1 完全相同。與 HTTP/1.1 類似，RTSP 客戶端首先向服務(wù)器發(fā)送請(qǐng)求，隨后服務(wù)器發(fā)回響應(yīng)，以此實(shí)現(xiàn)數(shù)據(jù)的交互。RTSP 同樣定義了一系列方法，表示對(duì) URI 標(biāo)識(shí)的資源所執(zhí)行的操作。RTSP 具體定義的方法有如下這些：

method direction object requirementDESCRIBE C->S P,S recommendedANNOUNCE C->S, S->C P,S optionalGET_PARAMETER C->S, S->C P,S optionalOPTIONS C->S, S->C P,S required(S->C: optional)PAUSE C->S P,S recommendedPLAY C->S P,S requiredRECORD C->S P,S optionalREDIRECT S->C P,S optionalSETUP C->S S requiredSET_PARAMETER C->S, S->C P,S optionalTEARDOWN C->S P,S required

回到 Wireshark 抓的包來看 RTSP/RTP/RTCP 的基本工作過程。

客戶端首先向服務(wù)器發(fā)送了一個(gè)方法為 OPTIONS 的請(qǐng)求，如第 112 號(hào)包，該請(qǐng)求內(nèi)容如上圖所示，攜帶有 URL，RTSP 版本號(hào)，User-Agent 等信息。RTSP 的 OPTIONS 與 HTTP/1.1 的對(duì)應(yīng)方法具有相同的語(yǔ)義，具體在 HTTP/1.1 規(guī)范 RFC 2616 的 9.2 節(jié) 中定義?？蛻舳送ㄟ^這個(gè)方法了解服務(wù)器為 URL 提供了哪些方法的支持。

第 112 號(hào)包是 RTSP 服務(wù)器對(duì)客戶端的 OPTIONS 請(qǐng)求的響應(yīng)，其具體內(nèi)容如下：

服務(wù)器將該 URL 支持的方法的列表返回給客戶端。對(duì)于這里的情況，也就是 OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER。

然后客戶端向服務(wù)器發(fā)送了一個(gè) DESCRIBE 請(qǐng)求，即第 116 號(hào)包，該請(qǐng)求內(nèi)容如下：

DESCRIBE 方法用于客戶端提取由所請(qǐng)求的 URL 標(biāo)識(shí)的表示或媒體對(duì)象的描述信息。它可以使用 Accept 頭部指定客戶端理解的描述格式。服務(wù)器則用所請(qǐng)求的資源的描述作為響應(yīng)。DESCRIBE 應(yīng)答響應(yīng)對(duì)構(gòu)成RTSP的媒體初始化階段。

對(duì)于這里的情況，DESCRIBE 請(qǐng)求的 Accept 頭部值為 application/sdp，表示客戶端希望收到 SDP 格式的媒體表示。

服務(wù)器以一個(gè) RTSP/SDP 包作為響應(yīng)，如圖中的第 118 號(hào)包：

這個(gè) SDP 包實(shí)際內(nèi)容的文本格式如下：

v=0 o=- 1504179985128927 1 IN IP4 10.240.248.20 s=H.264 Video, streamed by the LIVE555 Media Server i=raw_h264_stream.264 t=0 0 a=tool:LIVE555 Streaming Media v2017.07.18 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server a=x-qt-text-inf:raw_h264_stream.264 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=42802A;sprop-parameter-sets=Z0KAKtoBEA8eXlIKDAoNoUJq,aM4G4g== a=control:track1

服務(wù)器通過 SDP 包，告知流媒體數(shù)據(jù)傳輸所用的協(xié)議，以及流媒體本身的一些信息，這里所用的協(xié)議為 RTP/RTCP。通常的 SDP 文件中，“Media Description” 選項(xiàng)，即以 “m” 開頭的那一行中會(huì)指定，會(huì)指定客戶端接收 RTP 包所需要監(jiān)聽的端口，但在這里這個(gè)端口為 0。傳輸中客戶端和服務(wù)器所選擇的用于 RTP/RTCP 包收發(fā)的端口將在后面的 RTSP 請(qǐng)求中交換。

客戶端在收到服務(wù)器發(fā)來的 SDP 包之后，會(huì)選擇兩個(gè)端口，分別用于 RTP 和 RTCP 包的收發(fā)，并發(fā)送了一個(gè) SETUP 請(qǐng)求用于建立媒體會(huì)話，如第 119 號(hào)包：

客戶通過 SETUP 請(qǐng)求的 Transport 頭部，將為 RTP 和 RTCP 選擇的端口、協(xié)議及通信方式（UDP 單播還是多播）發(fā)送給客戶端。這里可以看到，客戶端選擇了 19008 和 19009 兩個(gè)端口來進(jìn)行 RTP 和 RTCP 包的收發(fā)。

隨后服務(wù)器對(duì) SETUP 請(qǐng)求做出了響應(yīng)，如第121 號(hào)包：

服務(wù)器通過這個(gè)響應(yīng)，把它為媒體會(huì)話開啟的用于收發(fā) RTP、RTCP 包的端口，會(huì)話的標(biāo)識(shí)符，超時(shí)時(shí)間等信息通知給客戶端。隨后，客戶端分別在 RTP 和 RTCP 的端口上，向服務(wù)器的 RTP 和 RTCP 端口上發(fā)送了兩個(gè)包，如第 122 號(hào)包和第 123 號(hào)包：

這兩個(gè)包中攜帶的都是無意義的數(shù)據(jù)。發(fā)送它們的目的，大概主要是為了 NAT 穿墻。

隨后客戶端向服務(wù)器發(fā)送了一個(gè) PLAY 請(qǐng)求，來啟動(dòng)播放，如第 124 號(hào)包：

PLAY 請(qǐng)求中會(huì)攜帶從前面的 SETUP 請(qǐng)求的響應(yīng)獲得的會(huì)話標(biāo)識(shí)符。

隨后服務(wù)器向客戶端發(fā)送了一個(gè) RTCP 包，如第 125 號(hào)包：

在這個(gè)包中，服務(wù)器把 RTP 時(shí)間戳，服務(wù)器的 SSRC，服務(wù)器的 CNAME 等信息發(fā)送給客戶端。之后，服務(wù)器發(fā)送了 PLAY 請(qǐng)求的響應(yīng)：

在這個(gè)包中，發(fā)送的 RTP 包的初始序列號(hào)，RTP 時(shí)間等重要信息被發(fā)送給客戶端。

至此媒體會(huì)話最終建立完成，后面就可以開始通過 RTP 傳輸視頻數(shù)據(jù)了。請(qǐng)求的 H.264 視頻文件的前兩個(gè) NALU，即 SPS 和 PPS 如下所示：

00000000 00 00 00 01 67 42 80 2A DA 01 10 0F 1E 5E 52 0A ....gB.*.....^R. 00000010 0C 0A 0D A1 42 6A 00 00 00 01 68 CE 06 E2

開始的兩個(gè) RTP 包，即第 127 號(hào)包和第 128 號(hào)包內(nèi)容如下：

它們的內(nèi)容與 H.264 視頻文件的前兩個(gè) NALU 的內(nèi)容完全吻合，即 live555 通過兩個(gè) RTP 包發(fā)送了前兩個(gè) NALU SPS 和 PPS。

從 RTSP 的 OPTIONS 請(qǐng)求開始，到首個(gè)視頻數(shù)據(jù) NALU 開始發(fā)送，經(jīng)過了總共大概 102 ms 的時(shí)間，媒體會(huì)話完全建立完成。

視頻數(shù)據(jù)經(jīng)過一端時(shí)間的穩(wěn)定傳輸，最終以服務(wù)器向客戶端發(fā)送的一個(gè) RTCP BYE 包而結(jié)束，如第 6451 號(hào)包：

總結(jié)一下這個(gè)過程：
1. 客戶端首先向服務(wù)器發(fā)送一個(gè)方法為 OPTIONS 的請(qǐng)求，了解服務(wù)器為 URL 提供了哪些方法的支持。
2. 服務(wù)器將該 URL 支持的方法的列表返回給客戶端。
3. 客戶端向服務(wù)器發(fā)送了一個(gè) DESCRIBE 請(qǐng)求，提取由所請(qǐng)求的 URL 標(biāo)識(shí)的表示或媒體對(duì)象的描述信息。
4. 服務(wù)器通過 SDP 包，告知流媒體數(shù)據(jù)傳輸所用的協(xié)議，以及流媒體本身的一些信息。
5. 客戶端在收到服務(wù)器發(fā)來的 SDP 包之后，會(huì)選擇兩個(gè)端口，分別用于 RTP 和 RTCP 包的收發(fā)，并發(fā)送了一個(gè) SETUP 請(qǐng)求用于建立媒體會(huì)話。
6. 服務(wù)器發(fā)回 SETUP 響應(yīng)，把它為媒體會(huì)話開啟的用于收發(fā) RTP、RTCP 包的端口，會(huì)話的標(biāo)識(shí)符，超時(shí)時(shí)間等信息通知給客戶端。
7. 客戶端分別在 RTP 和 RTCP 的端口上，向服務(wù)器的 RTP 和 RTCP 端口上發(fā)送了兩個(gè)包。
8. 客戶端向服務(wù)器發(fā)送一個(gè) PLAY 請(qǐng)求，來啟動(dòng)播放。
9. 服務(wù)器向客戶端發(fā)送一個(gè) RTCP 包，把 RTP 時(shí)間戳，服務(wù)器的 SSRC，服務(wù)器的 CNAME 等信息發(fā)送給客戶端。
10. 服務(wù)器發(fā)送 PLAY 請(qǐng)求的響應(yīng)，其中包含 RTP 包的初始序列號(hào)，RTP 時(shí)間等重要信息。至此媒體會(huì)話最終建立完成。
11. 通過 RTP/RTCP 發(fā)送流媒體數(shù)據(jù)。
12. 服務(wù)器向客戶端發(fā)送一個(gè) RTCP BYE 包結(jié)束會(huì)話。

live555 源碼分析系列文章

live555 源碼分析：簡(jiǎn)介
live555 源碼分析：基礎(chǔ)設(shè)施
live555 源碼分析：MediaSever
Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作過程
live555 源碼分析：與客戶端的交互

超強(qiáng)干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作过程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。