快訊!我的新書登上天瓏網路書店11月份暢銷榜第一名啦!看過的都說讚!歡迎大家前往訂購!
>>>> AI 職場超神助手:ChatGPT 與生成式 AI 一鍵搞定工作難題 <<<<

串流的網路概念

FFmpeg介紹

FFmpeg 是一個應用程式工具,它的主要功能包括讀取、解碼、編碼、轉碼、重新封裝、串流等各種視頻和音頻格式。這種應用程式大多數情況下被認為是在應用層(Application Layer)

然而,如果從數據表示、編碼和轉換的角度來看,你也可以說 FFmpeg 做的工作涉及到表示層(Presentation Layer)的部分功能。例如,它會解碼影片檔案(從一種表現形式轉換為另一種),並將其轉換為對應的像素和音頻資料。

若是使用ffmpeg讀取HTTP-FLV的串流,HTTP-FLV 協議主要是在應用層工作,而接收端的應用程序(例如媒體播放器)則在應用層和表示層之間工作,負責解封裝和解碼接收到的數據

HTTP 和 WebSocket 協議

HTTP 協議的握手過程通常包括客戶端發送一個請求到伺服器,然後伺服器回應這個請求。這種請求/回應模式構成了 HTTP 的基本交互模式。

而 WebSocket 協議的握手過程稍微有些不同。WebSocket 的握手過程基於 HTTP,一開始由客戶端發送一個 HTTP 升級請求到伺服器。如果伺服器接受這個升級請求,它會回應一個升級的回應,此時連接就會從 HTTP 轉變為 WebSocket。然後這個 WebSocket 連接就可以用來做全雙工的通訊,直到一方選擇關閉連接為止。

這些握手過程都是在應用層進行的,並且直接涉及到最終的應用程序(例如網頁瀏覽器或者 Web 伺服器)的行為。

WebRTC(Web Real-Time Communications)的網路概念

WebRTC(Web Real-Time Communications)是一種用於網頁瀏覽器的 P2P(Peer-to-Peer,即點對點)通訊技術。它可以讓網頁瀏覽器直接與另一個網頁瀏覽器進行實時的音視頻通訊,不需要中間的伺服器轉發。

WebRTC 在 OSI 模型中的定位並不容易確定,因為它實際上涉及到了多個 OSI 層次。例如,WebRTC 使用了 RTP(Real-time Transport Protocol,實時傳輸協議)來傳輸音視頻數據,RTP 通常被認為是在傳輸層(第四層)。同時,WebRTC 還需要用到 STUN/TURN/ICE 這些協議來進行 NAT 穿透和對等節點的發現,這些協議也工作在傳輸層。而且,WebRTC 最終的實際應用(例如在網頁瀏覽器中進行音視頻通話)則是在應用層(第七層)

所以,我們不能簡單地說 WebRTC 屬於 OSI 模型的某一個層次。相反,我們可以說 WebRTC 是一種跨層次的技術,它涉及到了 OSI 模型中的多個層次。這也再次顯示了 OSI 模型在實際應用中的限制,並非所有的網路技術都能夠簡單地映射到 OSI 的七個層次中。

WebRTC 是一個開放標準,允許通過網頁進行實時通信(RTC)。它使用一系列的協議和技術來實現這一點。下面是一些關鍵部分:

  1. RTP(實時傳輸協議):用於媒體數據(例如音頻和視頻)的傳輸,通常基於UDP。
  2. STUN/TURN/ICE:這些協議和技術用於 NAT 穿透和對等節點發現。STUN 和 TURN 伺服器協助 WebRTC 節點找到彼此並建立直接連接。TURN 伺服器可以在需要時中轉數據,可能使用 TCP 或 UDP。
  3. 信令:WebRTC 本身不規定信令協議。信令用於在通信的兩個端點之間交換元信息,例如呼叫設置、能力協商等。這可以通過各種方式實現,例如使用 WebSocket、HTTP 或其他協議,通常基於 TCP。

所以,WebRTC 使用了多個協議,其中一些是基於 UDP 的(如 RTP 和某些 TURN 場景),而其他一些可能是基於 TCP 的(如信令或當 TURN 使用 TCP 時)。

上圖展示了整個WebRTC所運用的協定架構,左邊(TCP)為Signal應用,右邊(UDP)為串流應用, 協定堆的搭配使用,補足彼此的不足,而本章主要專注在串流應用(右邊)上的協定上,為WebRTC提供了哪些功能。

SRT(Secure Reliable Transport)協定

SRT(Secure Reliable Transport)是一種基於UDP的開源傳輸協定,由Haivision公司發起並由SRT聯盟持續開發。它的主要目的是優化在公共網路(如互聯網)上進行高品質視訊串流的性能。

SRT旨在解決在廣播等高品質視訊串流場景下,對於低延遲、丟包率低的傳輸要求。它在UDP之上實現了數據包重傳機制,並且加入了AES加密,以確保傳輸的安全性。此外,SRT還提供了一個預測網路傳輸性能的機制(稱為「SRT預測模型」),該模型可動態調整傳輸參數,以優化傳輸性能並減少延遲。

因此,SRT協定將UDP的低延遲特性與TCP的可靠傳輸特性相結合,旨在在公共網路上提供一種安全、可靠、低延遲的視訊傳輸解決方案。這使得它在如廣播、遠程生產和OTT串流等領域中得到了廣泛應用。

SRT 加入了一些特性來強化它的穩定性和效能,這使得它能夠對傳輸過程進行更細膩的控制,同時也提供了比 TCP 更低的延遲。

這些特性包括:

  1. 數據包重傳:如果檢測到數據包丟失,SRT 會嘗試重新傳輸這些丟失的數據包,這樣就可以保證數據的完整性。
  2. 端到端的安全性:SRT 支持數據加密,確保數據在傳輸過程中的安全性。
  3. 低延遲:相比 TCP,UDP 的傳輸延遲更低,這使得 SRT 更適合實時或近實時的視訊串流

SRT通常不直接在網頁上播放的原因也是因為他是使用UDP的傳輸協定:

  1. 協議支援:瀏覽器通常支援的協議,如HTTP和WebSocket,是基於TCP的。這些協議被廣泛用於Web應用程序中,因為它們提供了可靠的連接和內建的流控制。由於SRT是基於UDP的,它不是瀏覽器原生支援的協議之一。
  2. UDP的限制:UDP不保證資料包的到達順序或可靠性。SRT在此基礎上增加了一些特性來改善這些問題,但這並不意味著它可以直接在所有客戶端上使用。瀏覽器可能因安全和可靠性的考量而限制或不支援UDP流量。
  3. 轉碼和轉封裝:為了在網頁上播放SRT流,可能需要額外的伺服器組件來轉碼或轉封裝流為瀏覽器支援的格式,例如HLS或MPEG-DASH。這可能增加了複雜性和延遲。
  4. 安全性考量:網頁的安全模型可能限制了直接使用UDP的能力。WebRTC是一個允許網頁使用UDP的技術,但即使如此,它也需要符合特定的安全和隱私要求。

17年資歷女工程師,專精於動畫、影像辨識以及即時串流程式開發。經常組織活動,邀請優秀的女性分享她們的技術專長,並在眾多場合分享自己的技術知識,也活躍於非營利組織,辦理活動來支持特殊兒及其家庭。期待用技術改變世界。

如果你認同我或想支持我的努力,歡迎請我喝一杯咖啡!讓我更有動力分享知識!