RTMP
實時消息傳遞協議（RTMP）最初是由Macromedia開發的專有協議，用於通過因特網在Flash播放器和服務器之間傳輸音頻，視頻和數據。Macromedia現在歸Adobe所有，該公司已發佈該協議規範的不完整版本供公衆使用。
RTMP協議有多種變體：
“普通”協議，默認使用TCP端口號1935。
RTMPS，它是通過TLS / SSL連接的RTMP 。
RTMPE，使用Adobe自己的安全機制進行RTMP加密。雖然實現的細節是專有的，但該機制使用行業標準的加密原語。[1]
RTMPT，封裝在HTTP請求中以遍歷防火牆。經常發現RTMPT利用TCP 端口 80和443 上的明文請求繞過大多數企業流量過濾。封裝的會話可以攜帶普通的RTMP，RTMPS或RTMPE分組。
RTMFP，它是通過UDP而不是TCP的RTMP，取代了RTMP Chunk Stream。安全實時媒體流協議套件由Adobe Systems開發，使最終用戶能夠直接相互連接和通信（P2P）。
雖然RTMP的主要動機是作爲播放Flash視頻的協議，但它也用於其他一些應用程序，例如Adobe LiveCycle Data Services ES。
RTMP是一種基於TCP的協議，可以維護持久連接並允許低延遲通信。爲了順利地傳輸流並傳輸儘可能多的信息，它將流分成片段，並且它們的大小在客戶端和服務器之間動態協商。有時，它保持不變; 對於音頻數據，默認片段大小爲64字節，對於視頻數據和大多數其他數據類型，默認片段大小爲128字節。然後可以交織來自不同流的片段，並在單個連接上覆用。對於較長的數據塊，協議因此每個片段僅攜帶一個字節的頭部，因此產生的開銷非常小。然而，實際上，單個片段通常不是交錯的。相反，交織和多路複用在分組級別完成，跨越若干不同活動信道的RTMP分組以這樣的方式交織，以確保每個信道滿足其帶寬，等待時間和其他服務質量要求。以這種方式交織的分組被視爲不可分割的，並且不在分段級別上交織。
RTMP定義了幾個可以在其上發送和接收分組的虛擬信道，並且它們彼此獨立地操作。例如，存在用於處理RPC請求和響應的信道，用於視頻流數據的信道，用於音頻流數據的信道，用於帶外控制消息的信道（片段大小協商等）等等。 。在典型的RTMP會話期間，在任何給定時間可以同時激活多個通道。當編碼RTMP數據時，生成包頭。除其他事項外，包頭指定了發送它的信道的ID，生成它的時間戳（如果需要），以及包的有效載荷的大小。然後，此標頭後跟數據包的實際有效內容，在通過連接發送之前，根據當前商定的片段大小進行分段。數據包標頭本身從不分段，其大小不計入數據包第一個片段中的數據。換句話說，只有實際的數據包有效負載（媒體數據）會受到碎片的影響。
在更高級別，RTMP封裝MP3或AAC音頻和FLV1視頻多媒體流，並且可以使用動作消息格式進行遠程過程調用（RPC）。所需的任何RPC服務都是使用單個客戶端/服務器請求/響應模型異步進行的，因此不需要實時通信。
RTP
實時傳輸協議（RTP）是一種網絡協議，用於在傳送音頻和視頻IP網絡。RTP用於涉及流媒體的通信和娛樂系統，例如電話，包括WebRTC的視頻電話會議應用，電視服務和基於網絡的即按即說功能。
RTP通常在用戶數據報協議（UDP）上運行。RTP與RTP控制協議（RTCP）結合使用。當RTP承載媒體流（例如，音頻和視頻）時，RTCP用於監視傳輸統計和服務質量（QoS）並幫助多個流的同步。RTP是IP語音的技術基礎之一，並且在這種情況下通常與諸如會話發起協議（SIP）之類的信令協議結合使用，該協議建立跨網絡的連接。
RTP由互聯網工程任務組（IETF）的音頻 - 視頻傳輸工作組開發，並於1996年首次發佈爲RFC 1889，於2003年被RFC 3550取代。
RTP專爲端到端，實時，流媒體傳輸而設計。該協議提供抖動補償和丟包檢測以及無序傳送的功能，這些功能在IP網絡上的UDP傳輸過程中尤爲常見。RTP允許通過IP多播將數據傳輸到多個目的地。 RTP被視爲IP網絡中音頻/視頻傳輸的主要標準，並與相關的配置文件和有效載荷格式一起使用。 RTP的設計基於稱爲應用層框架的架構原理協議功能在應用程序中實現，而不是在操作系統的協議棧中實現。
實時多媒體流應用程序需要及時傳遞信息，並且通常可以容忍一些數據包丟失以實現此目標。例如，音頻應用中的分組丟失可能導致丟失一小部分音頻數據，這可以通過適當的錯誤隱藏算法而變得不明顯。[3]所述的傳輸控制協議（TCP），儘管標準化的RTP使用，[4]沒有被正常在RTP應用中使用，因爲TCP傾向於過度時效的可靠性。相反，大多數RTP實現都是基於用戶數據報協議（UDP）構建的。專門爲多媒體會話設計的其他傳輸協議是SCTP [5]和DCCP，但截至2012年，它們並未得到廣泛使用。
RTP由IETF標準組織的音頻/視頻傳輸工作組開發。RTP與其他協議（如H.323和RTSP）結合使用。[2] RTP規範描述了兩種協議：RTP和RTCP。RTP用於傳輸多媒體數據，RTCP用於週期性地發送控制信息和QoS參數。
數據傳輸協議RTP承載實時數據。該協議提供的信息包括時間戳（用於同步），序列號（用於分組丟失和重新排序檢測）和有效載荷格式，其指示數據的編碼格式。所述的控制協議，RTCP，用於媒體流之間的服務質量（QoS）的反饋和同步質量。與RTP相比，RTCP流量的帶寬很小，通常約爲5％。
RTP會話通常使用信令協議在通信對等體之間發起，例如H.323，會話發起協議（SIP），RTSP或Jingle（XMPP）。這些協議可以使用會話描述協議來指定會話的參數。
爲每個多媒體流建立RTP會話。音頻和視頻流可以使用單獨的RTP會話，使接收器能夠選擇性地接收特定流的組件。會話由目的地IP地址和一對RTP和RTCP端口組成。規範建議選擇RTP端口號爲偶數，並且每個關聯的RTCP端口是下一個更高的奇數。但是，在複用協議的應用程序中，爲RTP和RTCP選擇單個端口。 RTP和RTCP通常使用非特權UDP端口（1024到65535），但也可能使用其他傳輸協議，最值得注意的是，SCTP和DCCP，因爲協議設計是獨立於傳輸的。
RTSP
實時流協議（RTSP）是一種網絡控制協議，專爲娛樂和通信系統的使用，以控制流媒體 服務器。該協議用於建立和控制端點之間的媒體會話。媒體服務器的客戶端發出VHS風格的命令，例如播放，錄製和暫停，以便於實時控制從服務器到客戶端（視頻點播）或從客戶端到服務器的媒體流（錄音） 。
流數據本身的傳輸不是RTSP的任務。大多數RTSP服務器將實時傳輸協議（RTP）與實時控制協議（RTCP）結合使用以進行媒體流傳輸。但是，一些供應商實施專有傳輸協議。例如，RealNetworks的RTSP服務器軟件也使用了RealNetworks的專有實時數據傳輸（RDT）。
RTSP由RealNetworks，Netscape 和哥倫比亞大學開發，第一份草案於1996年提交給IETF。[2]它由互聯網工程任務組（IETF ）的多方多媒體會話控制工作組（MMUSIC WG）標準化。並於1998年作爲RFC 2326發佈。RTSP 2.0 於2016年作爲RFC 7826發佈，作爲RTSP 1.0的替代品。RTSP 2.0基於RTSP 1.0，但除了基本版本協商機制外，不向後兼容。
雖然在某些方面類似於HTTP，但RTSP定義了用於控制多媒體回放的控制序列。雖然HTTP是無狀態的，但RTSP具有狀態; 在需要跟蹤併發會話時使用標識符。與HTTP類似，RTSP使用TCP來維護端到端連接，並且雖然大多數RTSP控制消息由客戶端發送到服務器，但是一些命令在另一個方向上傳播（即從服務器到客戶端）。
SIP
會話發起協議（SIP）是一種信令協議用於發起，維持和終止實時會話包括語音，視頻和消息應用程序。[1] SIP用於信令和控制多媒體通信會話中的應用網絡電話的語音和視頻通話，在私有IP電話系統，在即時通訊上的互聯網協議（IP）網絡以及手機撥打了LTE（VoLTE的）。
該協議定義了交換的消息的特定格式以及參與者合作的通信順序。SIP是一種基於文本的協議，包含超文本傳輸協議（HTTP）和簡單郵件傳輸協議（SMTP）的許多元素。[2]使用SIP建立的呼叫可以由多個媒體流組成，但是在SIP消息中作爲有效載荷交換數據的應用（例如文本消息）不需要單獨的流。
SIP與指定和攜帶會話媒體的其他幾種協議一起工作。最常見的是，媒體類型和參數協商以及媒體設置使用會話描述協議（SDP）來執行，該協議作爲SIP消息中的有效載荷來承載。SIP被設計爲獨立於基礎的傳輸層的協議，並且可與使用用戶數據報協議（UDP），所述傳輸控制協議（TCP），和流控制傳輸協議（SCTP）。爲了在不安全的網絡鏈路上安全地傳輸SIP消息，可以使用傳輸層安全性來加密協議（TLS）。對於媒體流（語音，視頻）的傳輸，SIP消息中攜帶的SDP有效載荷通常採用實時傳輸協議（RTP）或安全實時傳輸協議（SRTP）。
