RTSP
TCP協議體系中的應用層協議
RTSP（Real Time Streaming Protocol），RFC2326，實時流傳輸協議，是TCP/IP協議體系中的一個應用層協議，由哥倫比亞大學、網景和RealNetworks公司提交的IETF RFC標準。該協議定義了一對多應用程序如何有效地通過IP網路傳送多媒體數據。HTTP請求由客戶機發出，伺服器作出響應；使用RTSP時，客戶機和伺服器都可以發出請求，即RTSP可以是雙向的。RTSP是用來控制聲音或影像的多媒體串流協議，並允許同時多個串流需求控制，傳輸時所用的網路通訊協定並不在其定義的範圍內，伺服器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但並不特彆強調時間同步，所以比較能容忍網路延遲。而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低伺服器端的網路用量，更進而支持多方視訊會議（Video Conference）。因為與HTTP1.1的運作方式相似，所以代理伺服器〈Proxy〉的快取功能〈Cache〉也同樣適用於RTSP，並因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。
其是 TCP/IP 協議體系中的一個應用層協議，該協議定義了一對多應用程序如何有效地通過 IP 網路傳送多媒體數據。RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或UDP完成數據傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTSP傳送的是多媒體數據。
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協議支持
（1）從媒體伺服器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用於連續媒體的組播地址和埠。如演示僅通過單播發送給用戶，用戶為了安全應提供目的地址。
（2）媒體伺服器邀請進入會議：媒體伺服器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分散式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。
（3）將媒體加到現成講座中：如伺服器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。
RTSP協議支持
RTSP協議具有如下特點：
可擴展性：新方法和參數很容易加入RTSP。
易解析：RTSP可由標準HTTP或MIME解析器解析。
安全：RTSP使用網頁安全機制。
多伺服器支持：每個流可放在不同伺服器上，用戶端自動與不同伺服器建立幾個併發控制連接，媒體同步在傳輸層執行。
記錄設備控制：協議可控制記錄和回放設備。
適合專業應用：通過SMPTE時標，RTSP支持幀級精度，允許遠程數字編輯。
演示描述中立：協議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包括一個RTSP URL。
代理與防火牆友好：協議可由應用和傳輸層防火牆處理。防火牆需要理解SETUP方法，為UDP媒體流打開一個“缺口”。
HTTP友好：此處，RTSP明智地採用HTTP觀念，使現在結構都可重用。結構包括Internet內容選擇平台（PICS）。由於在大多數情況下控制連續媒體需要伺服器狀態，RTSP不僅僅向HTFP添加方法。
適當的伺服器控制：如用戶啟動一個流，必須也可以停止一個流。
傳輸協調：實際處理連續媒體流前，用戶可協調傳輸方法。
性能協調：如基本特徵無效，必須有一些清理機制讓用戶決定哪種方法沒生效。這允許用戶提出適合的用戶界面。
RTSP是一種文本協議，採用UTF-8編碼中的ISO 10646字符集。一行可通過CRLF終止，但接收端需要做好解釋CR和LF作為一行終止符的準備。關於頭欄位概述如下：
Header Type Support Methods
Accept R opt. entity
Accept-Encoding R opt. entity
Accept-Language R opt. all
Allow R opt. all
Authorization R opt. all
Bandwidth R opt. all
Blocksize R opt. All but OPTIONS, TEARDOWN
Cache-Control G opt. SETUP
Conference R opt. SETUP
Connection G req. all
Content-Base E opt. entity
Content-Encoding E req. SET_PARAMETER
Content-Encoding E req. DESCRIBE, ANNOUNCE
Content-Language E req. DESCRIBE, ANNOUNCE
Content-Length E req. SET_PARAMETER, ANNOUNCE
Content-Length E req. entity
Content-Location E opt. entity
Content-Type E req. SET_PARAMETER, ANNOUNCE
Content-Type R req. entity
CSeq G req. all
Date G opt. all
Expires E opt. DESCRIBE, ANNOUNCE
From R opt. all
If-Modified-Since R opt. DESCRIBE, SETUP
Last-Modified E opt. entity
Proxy-authenticate
Proxy-Require R req. all
Public R opt. all
Range R opt. PLAY, PAUSE, RECORD
Range R opt. PLAY, PAUSE, RECORD
Referer R opt. all
Require R req. all
Retry-After R opt. all
RTP-Info R req. PLAY
Scale Rr opt. PLAY, RECORD
Session Rr req. All but SETUP, OPTIONS
Server R opt. all
Speed Rr opt. PLAY
Transport Rr req. SETUP
Unsupported R req. all
User-Agent R opt. all
Via G opt. all
WWW-Authenticate R opt. all
類型"g"表示請求和響應中的通用請求頭；類型“R”表示請求頭；類型“r”表示響應頭；類型"e"表示實體頭欄位。在“support”一欄中標有“req.”的欄位必須由接收者以特殊的方法實現；而“opt.”的欄位是可選的。注意，不是所有“req.”欄位在該類型的每個請求中都會被發送。“req.”只表示客戶機（支持響應頭）和伺服器（支持請求頭）必須執行該欄位。最後一欄列出了關於頭欄位產生作用的方法；其中“entity”針對於返回一個信息主體的所有方法。
RTSP並非只是微軟在用！
這是一個公開的規範，在這個規範上開發了很多的流伺服器。甚至Linux服務提供者和蘋果的程序員也使用RTSP協議以及Real Networks流媒體。似乎整個世界的網路流傳輸都用這個協議。然而，微軟並不只在rtsp上有所作為。
微軟和RTSP
在寫這個文檔的時候，微軟正處於從首選MMS協議轉換到首選採用RTSP協議的過程中。這個說明在Media Player 9.0版本和流媒體伺服器2003版本之後，我們會看到微軟將rtsp協議作為流媒體傳輸的主要協議。
隨著時間慢慢的流逝，我們會發現mms協議正逐步走出人們的視野。It is only assumed that this is so MS can say they are being open with their protocols (rtsp is an open standard) while at the same time disregarding the need to publicise their own MMS protocol once its gone from media player. 然而，mms還沒有真的死亡，至少在接下來的幾年中我們依然可以看到它在流媒體傳輸中的身影。
是否微軟的RTSP協議和標準的開放式RTSP不同？
是的。跟在RFC2326（1998年四月）中定義的原始RTSP協議相比，微軟的rtsp協議有一些輕微的改動。我們網站上有本文檔（還有後續版本）和一個簡單的研究，它們可以幫助你了解這些信息。
區別在哪兒？
微軟的rstp規範與標準rtsp協議相比最主要的改動是發送包payloads到客戶端的方式，另外還有一些請求命令有一些改動。傳輸單個媒體包的機制並沒有文檔（就我目前所知），這可能是微軟要保留的信息。
就像MMS和HTTP 1.0流協議使用一個媒體數據包頭一樣，RTSP也有。但是微軟的數據包頭格式沒有在任何的rtsp文檔中註明。在企圖連接微軟的rtsp伺服器時，這是主要的問題。
微軟RTSP協議的命令採用的語法和標準rtsp協議的命令語法一樣，只有一些小的修改和添加，可以通過閱讀網上的一些文檔，就可以知道怎麼去組成這些命令。微軟rtsp命令部分已經有文檔了。
對多個流的同時控制。對音頻/視頻來講，客戶端僅需發送一條播放或者暫停消息就可同時控制音頻流和視頻流。
作為請求或者回應的有效負荷傳輸的信息。由以實體標題域（entity-header field）形式存在的元信息和以實體主體（entity body）形式存在的內容組成。
如不受請求方法或響應狀態編碼限制，請求和響應信息可傳輸實體，實體則由實體頭文件和實體體組成，有些響應僅包括實體頭。在此，根據誰發送實體、誰接收實體，發送者和接收者可分別指用戶和伺服器。
實體頭定義實體體可選元信息，如沒有實體體，指請求標識的資源。擴展頭機制允許定義附加實體頭段，而不用改變協議，但這些段不能假定接收者能識別。不可識別頭段應被接收者忽略，而讓代理轉發。
可以容納多個媒體流的文件。RTSP伺服器可以為這些容器文件提供集合控制。
RTSP交互的全過程。對一個電影的觀看過程，會話（session）包括由客戶端建立媒體流傳輸機制（SETUP），使用播放（PLAY）或錄製（RECORD）開始傳送流，用停止（TEARDOWN）關閉流。
RTSP中所有的操作都是通過伺服器和客戶端的消息應答機制完成的，其中消息包括請求和應答兩種，RTSP是對稱的協議，客戶機和伺服器都可以發送和回應請求。RTSP是一個基於文本的協議，它使用UTF -8編碼（RFC2279）和ISO10646字元序列，採用RFC882定義的通用消息格式，每個語句行由CRLF結束。RTSP的消息包括請求和應答兩類。
請求消息由請求行、標題行中的各種標題域和主體實體組成。請求行和標題行由ASCⅡ字元組成。
請求消息的格式如右圖所示。
請求 消息格式
其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。URL是接接收方的地址，例如。RTSP版本一般都是。每行後面的CRLF表示回車換行，需要接收端有相應的解析，最後一個消息頭需要有兩個CRLF。消息體是可選的，有的請求消息並不帶消息體
RTSP應答消息的格式如右圖所示。
應答消息格式
其中RTSP版本一般都是。狀態碼是一個數值，用於表示請求消息的執行結果，比如200表示成功。短語是與狀態碼對應的文本解釋。
H.321採用，用RTSP代替HTTP。
“rksp"和“rtspu"方案用於指RTSP協議使用的網路資源，為RTSP URL定義方案特定的語法和語義。
會議標識對RTSP來說是模糊的，採用標準URI編碼方法編碼，可包含任何八位組數值。會議標識必須全局惟一。
連接標識是長度不確定的字元串，必須隨機選擇，至少要8個八位組長，使其很難被猜出。
SMPTE相關時標表示相對剪輯開始的時間，相關時標表示成SMPTE時間代碼，精確到幀級。時間代碼格式為小時：分鐘：秒：幀。預設smpte格式是"SMPTE 30"，幀速率為每秒29.97幀。其他SMPTE代碼可選擇使用smpte時間獲得支持（如"SMPIE 25"）。時間數值中幀段值可從0到29。每秒30與29.97幀的差別可將每分鐘的頭兩幀丟掉來實現。如幀值為零，就可刪除。
正常播放時間（NPT）表示相對演示開始的流絕對位置。時標由十進位分數組成。左邊部分用秒或小時、分鐘、秒表示；小數點右邊部分表示秒的部分。演示的開始對應0.0秒，負數沒有定義。特殊常數定義成現場事件的當前時刻，這也許只用於現場事件。直觀上，NPT是聯繫觀看者與程序的時鐘，通常以數字式顯示在VCR上。
可選標籤是用於指定RTSP新可選項的惟一標記。這些標記用在請求和代理-請求頭段。當登記新RTSP選項時，需提供下列信息：
（1）名稱和描述選項。名稱長度不限，但不應該多於20個字元。名稱不能包括空格、控制字元。
（3）深入描述的參考，如RFC、論文、專利、技術報告、文檔源碼和計算機手冊。
（4）對專用選項，附上聯繫方式。
RTSP是基於文本的協議，採用ISO 10646字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基於文本的協議使以自描述方式增加可選參數更容易。由於參數的數量和命令的頻率出現較低，處理效率沒引起注意。文本協議很容易以腳本語言（如：Tcl，Visual Basic與Perl）實現研究原型。
ISO 10646字符集避免敏感字符集切換，但對應用來說不可見。RTCP也採用這種編碼方案。帶有重要意義位的ISO 8859-1字元表示如。RTSP信息可通過任何低層傳輸協議攜帶。
請求包括方法、方法作用於其上的對象以及進一步描述方法的參數。方法也可設計為在伺服器端只需要少量或不需要狀態維護。當信息體包含在信息中，信息體長度由如下因素決定：
（1）不管實體頭段是否出現在信息中，不包括信息體的響應，信息總以頭段后第一個空行結束。
（2）如出現內容長度頭段，其值以位元組計，表示信息體長度。如未出現頭段，其值為零。
（3）伺服器關閉連接。
注意，RTSP目前並不支持HTTP 1.1“塊”傳輸編碼，需要有內容長度頭。假如返回適度演示描述長度，即使動態產生，使塊傳輸編碼沒有必要，伺服器也應該能決定其長度。如有實體，即使必須有內容長度，且長度沒顯式給出，規則可確保行為合理。
從用戶到伺服器端的請求信息在第一行內包括源採用的方法、源標識和所用協議版本。RTSP定義了附加狀態代碼，但沒有定義任何HTTP代碼。
RTSP請求可以幾種不同方式傳送：
· 持久傳輸連接，用於多個請求/響應傳輸；
· 每個請求/響應傳輸一個連接；
· 無連接模式。
傳輸連接類型由RTSP URL來定義。對“rtsp'’方案，需要持續連接；而"rtspu"方案，調用RTSP請求發送，而不用建立連接。
不像HTTP，RTSP允許媒體伺服器給媒體用戶發送請求。然而，這僅在持久連接時才支持，否則媒體伺服器沒有可靠途徑到達用戶，這也是請求通過防火牆從媒體伺服器傳到用戶的惟一途徑。
| 方法 | 方向 | 對象 | 要求 | 含義 |
| DESCRIBE | C->S | P，S | 推薦 | 檢查演示或媒體對象的描述，也允許使用接收頭指定用戶理解的描述格式。DESCRIBE的答覆-響應組成媒體RTSP初始階段 |
| ANNOUNCE | C->S S->C | P，S | 可選 | 當從用戶發往伺服器時，ANNOUNCE將請求URL識別的演示或媒體對象描述發送給伺服器；反之，ANNOUNCE實時更新連接描述。如新媒體流加入演示，整個演示描述再次發送，而不僅僅是附加組件，使組件能被刪除 |
| GET_PARAMETER | C->S S->C | P，S | 可選 | GET_PARAMETER請求檢查URL指定的演示與媒體的參數值。沒有實體體時，GET_PARAMETER也許能用來測試用戶與伺服器的連通情況 |
| OPTIONS | C->S S->C | P，S | 要求 | 可在任意時刻發出OPTIONS請求，如用戶打算嘗試非標準請求，並不影響伺服器狀態 |
| PAUSE | C->S | P，S | 推薦 | PAUSE請求引起流發送臨時中斷。如請求URL命名一個流，僅回放和記錄被停止；如請求URL命名一個演示或流組，演示或組中所有當前活動的流發送都停止。恢復回放或記錄后，必須維持同步。在SETUP消息中連接頭超時參數所指定時段期間被暫停后，儘管伺服器可能關閉連接並釋放資源，但伺服器資源會被預訂 |
| PLAY | C->S | P，S | 要求 | PLAY告訴伺服器以SETUP指定的機制開始發送數據；直到一些SETUP請求被成功響應，客戶端才可發布PLAY請求。PLAY請求將正常播放時間設置在所指定範圍的起始處，發送流數據直到範圍的結束處。PLAY請求可排成隊列，伺服器將PLAY請求排成隊列，順序執行 |
| RECORD | C->S | P，S | 可選 | 該方法根據演示描述初始化媒體數據記錄範圍，時標反映開始和結束時間；如沒有給出時間範圍，使用演示描述提供的開始和結束時間。如連接已經啟動，立即開始記錄，伺服器數據請求URL或其他URL決定是否存儲記錄的數據；如伺服器沒有使用URL請求，響應應為201（創建），並包含描述請求狀態和參考新資源的實體與位置頭。支持現場演示記錄的媒體伺服器必須支持時鐘範圍格式，smpte格式沒有意義 |
| REDIRECT | S->C | P，S | 可選 | 重定向請求通知客戶端連接到另一伺服器地址。它包含強制頭地址，指示客戶端發布URL請求；也可能包括參數範圍，以指明重定向何時生效。若客戶端要繼續發送或接收URL媒體，客戶端必須對當前連接發送TEARDOWN請求，而對指定主執新連接發送SETUP請求 |
| SETUP | C->S | S | 要求 | 對URL的SETUP請求指定用於流媒體的傳輸機制。客戶端對正播放的流發布一個SETUP請求，以改變伺服器允許的傳輸參數。如不允許這樣做，響應錯誤為"455 Method Not Valid In This State”。為了透過防火牆，客戶端必須指明傳輸參數，即使對這些參數沒有影響 |
| SET_PARAMETER | C->S S->C | P，S | 可選 | 這個方法請求設置演示或URL指定流的參數值。請求僅應包含單個參數，允許客戶端決定某個特殊請求為何失敗。如請求包含多個參數，所有參數可成功設置，伺服器必須只對該請求起作用。伺服器必須允許參數可重複設置成同一值，但不讓改變參數值。注意：媒體流傳輸參數必須用SETUP命令設置。將設置傳輸參數限制為SETUP有利於防火牆。將參數劃分成規則排列形式，結果有更多有意義的錯誤指示 |
| TEARDOWN | C->S | P，S | 要求 | TEARDOWN請求停止給定URL流發送，釋放相關資源。如URL是此演示URL，任何RTSP連接標識不再有效。除非全部傳輸參數是連接描述定義的，SETUP請求必須在連接可再次播放前發布 |
註：P----演示，S----流，C----用戶端，S----伺服器端
某些防火牆設計與其他環境可能要求伺服器插入RTSP方法和流數據。由於插入將使客戶端和伺服器操作複雜，並增加附加開銷，除非有必要，應避免這樣做。插入二進位數據僅在RTSP通過TCP傳輸時才可使用。流數據（如RTP包）用一個ASCII字元$封裝，後跟一個一位元組通道標識，其後是封裝二進位數據的長度，兩位元組整數。流數據緊跟其後，沒有CRLF，但包括高層協議頭。每個$塊包含一個高層協議數據單元。
當傳輸選擇為RTP，RTCP信息也被伺服器通過TCP連接插入。預設情況下，RTCP包在比RTP通道高的第一個可用通道上發送。客戶端可能在另一通道顯式請求RTCP包，這可通過指定傳輸頭插入參數中的兩個通道來做到。當兩個或更多流交叉時，為取得同步，需要RTCP。而且，這為當網路設置需要通過TCP控制連接透過RTP/RTCP提供了一條方便的途徑，可能時，在UDP上進行傳輸。
由於不是所有媒體伺服器有著相同的功能，媒體伺服器有必要支持不同請求集。RTSP可以如下三種方式擴展：
（1）以新參數擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。
（2）加入新方法。如信息接收者不理解請求，返回501錯誤代碼，發送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢伺服器支持的方法。伺服器使用公共響應頭列出支持的方法。
（3）定義新版本協議，允許改變所有部分（協議版本號位置除外）。
支持持久連接或無連接的客戶端可能給其請求排隊。伺服器必須以收到請求的同樣順序發出響應。如果請求不是發送給多播組，接收者就確認請求，如沒有確認信息，發送者可在超過一個來回時間（RTT）后重發同一信息。
在TCP中RTT估計的初始值為500ms。應用緩存最後所測量的RTT，作為將來連接的初始值。如使用一個可靠傳輸協議傳輸RTSP，請求不允許重發，RTSP應用反過來依賴低層傳輸提供可靠性。如兩個低層可靠傳輸（如TCP和RTSP）應用重發請求，有可能每個包損失導致兩次重傳。由於傳輸棧在第一次嘗試到達接收者前不會發送應用層重傳，接收者也不能充分利用應用層重傳。如包損失由阻塞引起，不同層的重發將使阻塞進一步惡化。時標頭用來避免重發模糊性問題，避免對圓錐演演算法的依賴。每個請求在CSeq頭中攜帶一個系列號，每發送一個不同請求，它就加一。如由於沒有確認而重發請求，請求必須攜帶初始系列號。
實現RTSP的系統必須支持通過TCP傳輸RTSP，並支持UDP。對UDP和TCP，RTSP伺服器的預設埠都是554。許多目的一致的RTSP包被打包成單個低層PDU或TCP流。RTSP數據可與RTP和RTCP包交叉。不像HTTP，RTSP信息必須包含一個內容長度頭，無論信息何時包含負載。否則，RTSP包以空行結束，後跟最後一個信息頭。
每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其他途徑用戶可獲得這個文件，它沒有必要保存在媒體伺服器上。為了說明這個問題，假設演示描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體參數外，網路目標地址和埠也需要決定。
下面區分幾種操作模式。
（1）單播：用戶選擇的埠號將媒體發送到RTSP請求源。
（2）伺服器選擇地址多播：媒體伺服器選擇多播地址和埠，這是現場直播或準點播常用的方式。
（3）用戶選擇地址多播：如伺服器加入正在進行的多播會議，多播地址、埠和密鑰由會議描述給出。
RTSP控制通過單獨協議發送的數據流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數據流通過UDP。因此，即使媒體伺服器沒有收到請求，數據也會繼續發送。在連接生命期，單個媒體流可通過不同TCP連接順序發出請求來控制。所以，伺服器需要維持能聯繫流與RTSP請求的連接狀態。RTSP中很多方法與狀態無關，但下列方法在定義伺服器流資源的分配與應用上起著重要的作用：
（1） SETUP：讓伺服器給流分配資源，啟動RTSP連接。
（2） PLAY與RECORD：啟動SETUP分配流的數據傳輸。
（3） PAUSE：臨時停止流，而不釋放伺服器資源。
（4） TEARDOWN：釋放流的資源，RTSP連接停止。
標識狀態的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，伺服器連接產生連接標識。
RTSP狀態機
實時流協議在語法和操作上與HTTP/1.1類似，因此HTTP的擴展機制大都可加入RTSP。然而，在很多重要方面RTSP仍不同於HTTP：
RTSP引入了大量新方法並具有一個不同的協議標識符；
在大多數情況下，RTSP伺服器需要保持預設狀態，與HTTP的無狀態相對；
RTSP中客戶端和伺服器都可以發出請求；
在多數情況下，數據由不同的協議傳輸；
RTSP使用ISO 10646（UTF-8）而並非ISO 8859-1，與當前的國際標準HTML相一致；
URI請求總是包含絕對URI。為了與過去的錯誤相互兼容，HTTP/1.1隻在請求過程中傳送絕對路徑並將主機名置於另外的頭欄位。
RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規範目的在於允許在網頁伺服器與實現RTSP媒體伺服器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP伺服器與用戶不全依靠HTTP。
但是，RTSP與HTTP的本質差別在於數據發送以不同協議進行。HTTP是不對稱協議，用戶發出請求，伺服器作出響應。RTSP中，媒體用戶和伺服器都可發出請求，且其請求都是無狀態的；在請求確認后很長時間內，仍可設置參數，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近時，在緩存、代理和授權上採用HTTP功能是有價值的。
當大多數實時媒體使用RTP作為傳輸協議時，RTSP沒有綁定到RTP。RTSP假設存在演示描述格式可表示包含幾個媒體流的演示的靜態與臨時屬性。
基本信息
- 中文名
- 實時流傳輸協議
- 外文名
- Real Time Streaming Protocol
- 簡稱
- RTSP
- 屬性
- 應用層協議