現在視頻直播流用到的協議主要有3個。
RTMP
RTP/RTCP
HLS
rtp協議詳解/rtcp協議詳解
1、簡介
目前，在IP網絡中實現實時語音、視頻通信和應用已經成爲網絡應用的一個主流技術和發展方向，本文詳細介紹IP協議族中用於實時語音、視頻數據傳輸的標準協議RTP（ Real-time Transport Protocol）和RTCP（RTP Control Ptotocol）的主要功能。
2、RTP/RTCP協議簡介
RTP 由 IETF（http://www.ietf.org/）定義在 RFC 3550和3551中。
RTP被定義爲傳輸音頻、視頻、模擬數據等實時數據的傳輸協議，與傳統的注重的高可靠的數據傳輸的運輸層協議相比，它更加側重的數據傳輸的實時性，此協議提供的服務包括數據順序號、時間標記、傳輸控制等。
RTP通常與輔助控制協議RTCP一起工作，RTP只負責實時數據的傳輸，RTCP負責對RTP的通信和會話進行帶外管理（如流量控制、擁塞控制、會話源管理等）。
3、RTP/RTCP協議層次和封裝
RTP位於傳輸層（通常是UDP）之上，應用程序之下，實時語音、視頻數據經過模數轉換和壓縮編碼處理後，先送給RTP封裝成爲RTP數據單元，RTP數據單元被封裝爲UDP數據報，然後再向下遞交給IP封裝爲IP數據包。
RTP分組只包含RTP數據，而控制是由另一個配套協議RTCP提供。RTP在端口號1025到65535之間選擇一個未使用的偶數UDP端口號，而在同一次會話中的RTCP則使用下一個奇數UDP端口號。
RTP通常和RTCP一起工作，在RTP會話期間，各參與者週期的發送RTCP消息。RTCP消息含有已發送數據的丟包統計和網絡擁塞等信息，服務器可以利用這些信息動態的改變傳輸速率，甚至改變淨荷的類型。RTCP消息也被封裝爲UDP數據報進行傳輸。
4、RTP/RTCP協議頭信息
version (V): 2 bits
標明RTP版本號。協議初始版本爲0，RFC3550中規定的版本號爲2。
padding (P): 1 bit
如果該位被設置，則在該packet末尾包含了額外的附加信息，附加信息的最後一個字節表示額外附加信息的長度（包含該字節本身）。該字段之所以存在是因爲一些加密機制需要固定長度的數據塊，或者爲了在一個底層協議數據單元中傳輸多個RTP packets。
extension (X): 1 bit
如果該位被設置，則在固定的頭部後存在一個擴展頭部，格式定義在RFC3550 5.3.1節。
CSRC count (CC): 4 bits
在固定頭部後存在多少個CSRC標記。
marker (M): 1 bit
該位的功能依賴於profile的定義。profile可以改變該位的長度，但是要保持marker和payload type總長度不變（一共是8 bit）。
payload type (PT): 7 bits
標記着RTP packet所攜帶信息的類型，標準類型列出在RFC3551中。如果接收方不能識別該類型，必須忽略該packet。
sequence number: 16 bits
序列號，每個RTP packet發送後該序列號加1，接收方可以根據該序列號重新排列數據包順序。
timestamp: 32 bits
時間戳。反映RTP packet所攜帶信息包中第一個字節的採樣時間。
SSRC: 32 bits
數據源標識。在一個RTP Session其間每個數據流都應該有一個不同的SSRC。
CSRC list: 0 to 15 items, 每個源標識32 bits
貢獻數據源標識。只有存在Mixer的時候纔有效。如一個將多聲道的語音流合併成一個單聲道的語音流，在這裏就列出原來每個聲道的SSRC。
5、RTCP協議
RTCP協議處理機根據定義了五種類型的報文：
RR: receiver report
SR: sender report
SDES: source description items.
BYE: indicates end of participation.
APP: application specific functions
它們完成接收、分析、產生和發送控制報文的功能。
RTCP可以說是控制交通的協議，它提供了：
1）SR發送者報告分組：用來使發送端週期的向所有接收端用多播方式進行報告。內容包括：
該RTP流的SSRC；該RTP流中最新產生的RTP分組的時間戳和絕對時鐘時間（或稱牆上時間：wall clock time);該RTP流包含的分組數；該RTP流包含的字節數。
絕對時鐘時間是必要的。因爲RTP要求每一種媒體使用一個流。有了絕對時鐘時間就可以進行圖形和聲音的同步。
2）RR接收者報告分組：用來使接收端週期性的向所有的點用多播方式進行報告。內容包括
所接收到的RTP流的SSRC；該RTP流的分組丟失率；在該RTP流中的最後一個RTP分組的序號；分組到達時間間隔的抖動等。
發送RR分組有兩個目的。第一，可以使所有的接收端和發送端了解當前網絡的狀態。
第二，可以使所有發送RTCP分組的站點自適應的調整自己發送RTCP分組的速率，RTCP分組的通信量不超過網絡中的數據分組的通信量的5%，而接收端分組報告分組的通信量又應小於所有RTCP分組的通信量的75%。
3）SDES源描述分組：給出會話中參加者的描述，包括參加者的規範名（CNAME）
4）BYE分組：關閉一個數據流。
5）APP分組：應用程序能夠定義新的分組類型。
6、實時流協議RTSP協議
1） RTSP協議
RTSP（Real Time Streaming Protocol）協議定義瞭如何有效地通過IP網絡傳送多媒體數據，是一種客戶端到服務器端的多媒體描述協議，詳見RFC2326。
RTSP是一個非常類似於HTTP的應用層協議。每個發佈和媒體文件也被定義爲RTSP UPL。而媒體文件的發佈信息被書寫進一個被稱爲媒體發佈文件裏，這個文件在後面會說明。在這個文件說明的包括編碼器，語言，RTSP ULS，地址，端口號以幾其它參數。這個發佈文件可以在客戶端通過EMAIL形式或者HTTP形式獲得。
2） RTSP協議的特點：
RTSP是應用層協議,與RTP、RSVP一起設計來完全流式服務。
RTSP有很大的靈活性，可被用在多種操作系統上,它允許客戶端和不同廠商的服務平臺交互。
RTSP在體系結構上位於RTP和RTCP之上，它使用RTP完成數據傳輸。它將流式媒體數據可控制的通過網絡傳輸到客戶端。
RTSP可以保持用戶計算機與傳輸流業務服務器之間的固定連接，用於觀看者與單播（Unicast）服務器通信並且還允許雙向通信，觀看者可以同流媒體服務器通信.
提供類似“VCR”形式的例如暫停、快進、倒轉、跳轉等操作。操作的資源對象可以是直播流也可以是存儲片段。
RTSP是設還提供了選擇傳輸通道，如使用UDP還是多點UDP或是TCP。
7、資源預留協議RSVP
1） RSVP協議：
RSVP (Resorce reSerVation Protocol) 資源預留協議並不是一個路由協議，而是一種IP網絡中的信令協議，它與路由協議相結合來實現對網絡傳輸服務質量（QoS）的控制。RSVP是爲支持因特網綜合業務而提出的。這是解決IP通信中QoS（服務質量）問題的一種技術，用來保證點端到端的傳輸帶寬。
2） RSVP協議是如何工作：
RSVP使用控制數據報，這些數據報在向特定地址傳輸時包括了需要由路由器檢查（有些時候需要更新）的信息,如果路由器需要決定是不是要檢查數據報的內容的時候對上層數據內容進行語法分析。這種分析的代價可不小。現在的情況是，網絡終端利用它向網絡申請資源，在這種表明“申請” 的信號中，包含着如下的信息：業務的種類？ 使用者類型？ 什麼時間？ 需要多大帶寬？ 其他參考信息？ 網絡在接收到上類信息後，會根據實際情況爲此次連接分配一個優先代碼，用戶利用優先代碼進行信息傳遞時，網絡不需重新對業務進行分析與判別，從另外一個角度來說，利用RSVP 能從一定程度上減少網絡對信息處理的時延，提高網絡節點的工作效率，改善信息傳輸的服務質量（QoS）。實時應用用RSVP是爲了在傳輸路徑中保持必要的資源以保證請求能確保到達。
RSVP是IP路由器爲提供更好的服務質量向前邁進的具有深刻意義的一步。傳統上IP路由器只負責分組轉發，通過路由協議知道鄰近路由器的地址。而RSVP則類似於電路交換系統的信令協議一樣，爲一個數據流通知其所經過的每個節點（IP路由器），與端點協商爲此數據流提供質量保證。
8、結束語
在前面我們討論了一些與實時數據傳輸相關的四個協議：
1）RTP是實時數據傳輸協議。它提供時間標誌，序列號以及其它能夠保證在實時數據傳輸時處理時間的方法；它是依靠RVSP保證服務質量標準的。
2）RTCP是RTP的控制部分,是用來保證服務質量和成員管理的。
3）RTSP是開始和指引流媒體數據從流媒體服務器。它又可叫做"網上錄像機控制協議".它是提供遠程的控制，具體的數據傳輸是交給RTP的。
4）RSVP是Internet上的資源預訂協議，使用RSVP預留一部分網絡資源（即帶寬），能在一定程度上爲流媒體的傳輸提供QoS。就像TCP的重發和滑動窗口等都是