RTSP協議之TCP/UDP問題
前言
RTSP（Real-Time StreamingProtocol）實時流式協議在直播、流媒體、視訊會議等平臺用得很多，它是基於TCP/IP開發的上層協議，所以音視訊流資料可以用TCP或者UDP來傳輸。這篇文章目的主要是講述這二者的區別，如果想了解更多RTSP相關的知識，可以參閱我之前的博文《》。
RTSP之TCP與UDP方式區別
TCP與UDP方式的區別在客戶端項服務端SETUP請求中的Transport項體現。RTSP客戶端會根據自己的環境發出請求，以決定使用TCP還是UDP的方式，在比較完善的RTSP服務中這兩種方式都支援，然而在我遇到的產品（某品牌NVR）中只支援TCP方式，在實測過程中，VLC連線時預設使用UDP方式連線時會失敗，然後VLC會自動切成TCP的連線方式，而FFPALY則不會自動切換，這裡為VLC點個贊。
1.TCP請求方式，此方式比較靈活，它不用另外建立音視訊傳輸的Socket，而直接使用RTSP的Socket，這樣做可以節省不少資源開支。由於採用TCP傳輸，資料的可靠性得到保障。在分析抓包資料可以看出客戶端在SETUP請求時的資料互動中的Transport項指定了TCP傳輸方式RTP/AVP/TCP。（以下抓包資料基於VLC RTSP連線NVR獲取的音視訊流）
OPTIONS rtsp://192.168.0.49:554/11 RTSP/1.0 CSeq: 2 User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) RTSP/1.0 200 OK CSeq: 2 Server: Rtsp Server Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN, SET_PARAMETER DESCRIBE rtsp://192.168.0.49:554/11 RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Accept: application/sdp RTSP/1.0 401 Unauthorized Cseq: 3 Server: Rtsp Server 0*0*30*4096 WWW-Authenticate: Digest realm="Surveillance Server", nonce="10839044" DESCRIBE rtsp://192.168.0.49:554/11 RTSP/1.0 CSeq: 4 Authorization: Digest username="admin", realm="Surveillance Server", nonce="10839044", uri="rtsp://192.168.0.49:554/11", response="f1bf854a901dc8a7379ff277ce1be0e3" User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Accept: application/sdp RTSP/1.0 200 OK Cseq: 4 Server: Rtsp Server 0*0*30*4096 Content-Type: application/sdp Content-length: 379 Content-Base: rtsp://192.168.0.49/1 v=0 o=StreamingServer 3331435948 1116907222000 IN IP4 192.168.0.49 s=h264.mp4 c=IN IP4 0.0.0.0 t=0 0 a=control:* m=video 0 RTP/AVP 96 a=control:trackID=0 a=rtpmap:96 H264/90000 a=ptime:40 a=range:npt=0-0 a=fmtp:96 packetization-mode=1; sprop-parameter-sets=(null) a=videoinfo:0*0*30*4096 m=audio 0 RTP/AVP 0 a=control:trackID=1 a=rtpmap:0 PCMU/8000 a=ptime:20 SETUP rtsp://192.168.0.49/1/trackID=0 RTSP/1.0 CSeq: 5 Authorization: Digest username="admin", realm="Surveillance Server", nonce="10839044", uri="rtsp://192.168.0.49/1", response="8e69477a4b8602b118a0850dcf3dee51" User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 RTSP/1.0 200 OK CSeq: 5 Server: Rtsp Server Session: 06720925;timeout=120 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 SETUP rtsp://192.168.0.49/1/trackID=1 RTSP/1.0 CSeq: 6 Authorization: Digest username="admin", realm="Surveillance Server", nonce="10839044", uri="rtsp://192.168.0.49/1", response="8e69477a4b8602b118a0850dcf3dee51" User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 06720925 RTSP/1.0 200 OK CSeq: 6 Server: Rtsp Server Session: 06720925;timeout=120 Transport: RTP/AVP/TCP;unicast;interleaved=2-3 PLAY rtsp://192.168.0.49/1 RTSP/1.0 CSeq: 7 Authorization: Digest username="admin", realm="Surveillance Server", nonce="10839044", uri="rtsp://192.168.0.49/1", response="4990f23c2ddd70c8ee8b1711f0588609" User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Session: 06720925 Range: npt=0.000- RTSP/1.0 200 OK CSeq: 7 Server: Rtsp Server Session: 06720925;timeout=120
2.UDP請求方式，此方式需要多建立兩個Socket，用於RTCP、RTP資料傳送。分析抓包資料可以看出客戶端在SETUP請求時的資料互動中Transport項指定了client_port=64790-64791，它是用來通知服務端與客戶端建立Socket通訊的。由此可見UDP方式，音視訊資料傳輸與控制訊號傳輸分開，這樣導致系統性能開銷增大，設計複雜，在嵌入式系統中比較少用。（以下抓包資料基於VLC RTSP連線NVR獲取的音視訊流）
OPTIONS rtsp://192.168.0.49:554/11 RTSP/1.0 CSeq: 2 User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) RTSP/1.0 200 OK CSeq: 2 Server: Rtsp Server Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN, SET_PARAMETER DESCRIBE rtsp://192.168.0.49:554/11 RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Accept: application/sdp RTSP/1.0 401 Unauthorized Cseq: 3 Server: Rtsp Server 0*0*30*4096 WWW-Authenticate: Digest realm="Surveillance Server", nonce="07492185" DESCRIBE rtsp://192.168.0.49:554/11 RTSP/1.0 CSeq: 4 Authorization: Digest username="admin", realm="Surveillance Server", nonce="07492185", uri="rtsp://192.168.0.49:554/11", response="e63e8eb892f773c59edaf53e314000b6" User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Accept: application/sdp RTSP/1.0 200 OK Cseq: 4 Server: Rtsp Server 0*0*30*4096 Content-Type: application/sdp Content-length: 379 Content-Base: rtsp://192.168.0.49/1 v=0 o=StreamingServer 3331435948 1116907222000 IN IP4 192.168.0.49 s=h264.mp4 c=IN IP4 0.0.0.0 t=0 0 a=control:* m=video 0 RTP/AVP 96 a=control:trackID=0 a=rtpmap:96 H264/90000 a=ptime:40 a=range:npt=0-0 a=fmtp:96 packetization-mode=1; sprop-parameter-sets=(null) a=videoinfo:0*0*30*4096 m=audio 0 RTP/AVP 0 a=control:trackID=1 a=rtpmap:0 PCMU/8000 a=ptime:20 SETUP rtsp://192.168.0.49/1/trackID=0 RTSP/1.0 CSeq: 5 Authorization: Digest username="admin", realm="Surveillance Server", nonce="07492185", uri="rtsp://192.168.0.49/1", response="d559a804fe440390e40fd14251265ebc" User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Transport: RTP/AVP;unicast;client_port=64790-64791 RTSP/1.0 200 OK CSeq: 5 Server: Rtsp Server Session: 34202454 Transport: RTP/AVP;unicast;client_port=64790-64791;source=192.168.0.49;server_port=32773-0;ssrc=00004E87 SETUP rtsp://192.168.0.49/1/trackID=1 RTSP/1.0 CSeq: 6 Authorization: Digest username="admin", realm="Surveillance Server", nonce="07492185", uri="rtsp://192.168.0.49/1", response="d559a804fe440390e40fd14251265ebc" User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Transport: RTP/AVP;unicast;client_port=64792-64793 Session: 34202454 RTSP/1.0 200 OK CSeq: 6 Server: Rtsp Server Session: 34202454 Transport: RTP/AVP;unicast;client_port=64792-64793;source=192.168.0.49;server_port=32773-0;ssrc=00004E87 PLAY rtsp://192.168.0.49/1 RTSP/1.0 CSeq: 7 Authorization: Digest username="admin", realm="Surveillance Server", nonce="07492185", uri="rtsp://192.168.0.49/1", response="e96c9c574774a24a5c372037ffaaad4e" User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) Session: 34202454 Range: npt=0.000- RTSP/1.0 200 OK CSeq: 7 Server: Rtsp Server Session: 34202454;timeout=120
總結
TCP傳輸方式使用的是原有的套接字，不用另開套接字，起到節省資源的作用，還能利用TCP的可靠性。另一方面它更具有穿牆的特性，在很多網路的路由中有設定不給於外網訪問內網，此時用UDP方式，需要服務端主動連線客戶端提供的UDP介面，這請求有可能被防火牆攔截，在抓包分析中表現出來是port unreachable的錯誤提示，可見這種方式是比較受限制的。綜上，在可靠連線和資源方面考慮，在嵌入式安防產品中採用TCP方式較多。原創不易，轉載請說明出處。
相關推薦
RTSP協議之TCP/UDP問題
前言 RTSP（Real-Time StreamingProtocol）實時流式協議在直播、流媒體、視訊會議等平臺用得很多，它是基於TCP/IP開發的上層協議，所以音視訊流資料可以用TCP或者UDP來傳輸。這篇文章目的主要是講述這二者的區別，如果想了解更多RTSP相關的知識
網路協議之TCP和UDP
應用層向TCP層傳送用於網間傳輸的、用8位位元組表示的資料流，然後TCP把資料流分割成適當長度的報文段（通常受該計算機連線的網路的資料鏈路層的最大傳送單元（MTU）的限制）。之後TCP把結果包傳給IP層，由它來通過網路將包傳送給接收端實體的TCP層
網路基本概念之TCP, UDP, 單播（Unicast）, 多播（組播）（Multicast）
這篇文章相當低階，但相當重要！ 我們周圍一切幾乎都依賴於把事情抽象成低等級，並在某一點把它具體化，在一些設計概念中，介面層十分清晰並且目標很集中，應用程式不用考慮作業系統如何工作，作業系統也不用考慮硬體如何工作，OSI模型的第4層不需要考慮第三層如何工作。所以我們只需要集中精力在某一
資料封包解包協議之TCP封包解包
資料封包協議規定：整個資料包包含2位元組長度資訊+資料包體。2位元組長度資訊包含本身著2位元組。如：資料體是（abcdefg）7個位元組，整體封包就是09abcdefg，總共是9個位元組的協議 1、netbus接收到資料後傳送到static void on_recv_tcp_data(uv_
Linux網路程式設計之Tcp/Udp socket檔案傳輸示例
本文所述示例程式是基於Linux平臺的socket網路程式設計，實現檔案傳輸功能。該示例是基於TCP流協議實現的socket網路檔案傳輸程式。採用C語言編寫。最終能夠實現傳輸任何格式檔案的檔案傳輸程式。 具體實現程式碼如下： /***********************
網路基本概念之TCP, UDP, 單播（Unicast）, 組播（Multicast）
這篇文章相當低階，但相當重要！ 我們周圍一切幾乎都依賴於把事情抽象成低等級，並在某一點把它具體化，在一些設計概念中，介面層十分清晰並且目標很集中，應用程式不用考慮作業系統如何工作，作業系統也不用考慮硬體如何工作，OSI模型的第4層不需要考慮第三層如何工作。所以我們只需要集中精力在某一層，就當下面的層正常
深入淺出之 TCP協議（三次握手與四次揮手、超時重發、流量控制、擁塞控制、與UDP區別）
TCP/IP 中有兩個具有代表性的傳輸層協議，分別是TCP、UDP。TCP提供可靠的通訊傳輸，而UDP則常被用於讓廣播和細節控制交給應用的通訊傳輸。 要知道TCP為了這簡單描述“可靠的通訊傳輸”背後所做的努力，你會深感佩服其強大性。TCP的特徵：序列化+確認應
[rtsp]協議UDP、TCP、RTP三種協議的總結分析
RTP 全名是 Real-time Transport Protocol（實時傳輸協議）。它是IETF提出的一個標準，對應的RFC文件為RFC3550（RFC1889為其過期版本）。RFC3550 不僅定義了 RTP，而且
通訊協議之Http、TCP、UDP詳解
都是通訊協議，也就是通訊時所遵守的規則，只有雙方按照這個規則“說話”，對方才能理解或為之服務。 TCP HTTP UDP三者的關係: TCP/IP是個協議組，可分為四個層次：網路介面層、網路層、傳輸層和應用層。 在網路層有IP協議、ICMP協議、ARP協議、R
TCP/UDP協議
lan 有時 body aik htm 默認 tab 協調 不同 TCP和UDP是OSI模型中的運輸層中的協議。TCP提供可靠的通信傳輸，而UDP則常被用於讓廣播和細節控制交給應用的通信傳輸。 連接： 面向連接的TCP "面向連接"就是在正式通信前必須要與對方建立起連接。比
TCP/UDP協議簡要梳理
重復數 文件下載 相對 協議 proto 可靠性 提交 需要 wid TCP/UDP協議簡要梳理 TCP TCP，Transmission Control Protocol，傳輸控制協議是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。在因特網協議族中，TCP所在的層位
流媒體協議之RTSP客戶端的實現20171014
叠代 jrtplib 訪問 pac .cpp 服務端 blog 文件 僅支持 RtspClient是基於jrtplib實現的，目前僅支持h264格式，後續將不斷叠代優化，加入對其他格式的支持，並且將實現RTSP的服務端。 RtspClient的功能是接收服務端過來流，然後寫
網絡基礎之TCP/IP協議
rst 標誌位 自由 重新發送 選項 ket 格式 監聽 套接字 TCP/IP分層模型中，通信界定地址： 物理地址：在交換機中進行通信的， 以太網地址，MAC地址； 功能：真正的用於本地通信的地址； 使用範圍：本地局域網內部且
七LWIP學習筆記之傳輸控制協議（TCP）
輸入 post wait syn 快速重傳 擁塞 斷開連接 其他 time 一、協議簡介 1、TCP的必要性 2、TCP的特性 3、連接的定義 4、數據流編號 5、滑動窗口 二、TCP報文 1、報文格式 2、TCP選項 3、緊急數據 4、強迫數據交互 5、報文首部數據結構
網絡通信協議三之TCP/IP模型詳解
udp protocol bubuko 傳遞 alt 公司 技術 png 代名詞 TCP/IP模型 註：PDU：Protocol Date Unit:表示對等層之間傳遞的數據單位 TCP：Transmission Control Protocol:傳輸控制協議 UD
網絡編程之基於UDP協議套接字
本質 系統內存 現象 服務 自身 png 收發消息 accept color 1.UDP協議介紹(數據報協議) UDP協議不同於TCP，通信時，它不需要事先建立雙向鏈接，並且不區分客戶端先啟動還是服務端前起，工作原理：基於udp協議傳輸的信息，協議會將數據自動加上自定義
002：：每天五分鐘入門TCP/IP協議棧：：IP協議之IP首部長度問題
IP 首部 首部長度 事出反常必有妖，邪乎到家必有鬼。 整個TCP/IP協議中，IP協議是最核心的協議。 IP協議是不可靠的、無連接的服務。 何為不可靠？不能保證IP數據報能夠成功到達目的地，傳輸的可靠×××給傳輸層或應用層去實現。 何為無連接？IP並不維護任何關於後續數據報的狀態信息。 進入正題
003：：每天五分鐘入門TCP/IP協議棧：：IP協議之TOS字段說明
IP首部 ToS服務類型 從IP首部看ToS的位置：ToS即為服務類型，只有當網絡設備能夠支持（能夠識別IP首部中的ToS字段）識別ToS字段時，這給字段設置才有意義。否則都是空談。 先說具體字段的意義：Tos字段長度為8bit前3bit字段：為優選權子字段，現在已經廢棄，這個字段默認值是000，從w
004：：每天五分鐘入門TCP/IP協議棧：：IP協議之16位總長度字段引出的MTU值問題
IP首部 MTU 數據封裝 要理解MTU以及實際生產環境中的MTU問題，就得搞清楚三個問題：IP數據報包含什麽內容；數據進入協議棧的封裝過程；MTU具體代表含義； 首先要理解一個過程：數據進入協議棧的封裝過程！數據從發送主機發送出去之前，在主機的協議棧中會經歷上述圖中的幾個封裝過程。本次以TCP
計算機網絡之 TCP 與 UDP
SM mis iss href 傳輸服務 擁塞控制 用戶數據 nec proto TCP 什麽是 TCP？ Transmission Control Protocol，傳輸控制協議 傳輸層協議（參見更多資料 [1]） 功能 面向連接（Connection-Orient