.引言

本篇文章是基于上篇文章去編寫的，繼續講解協議轉換的原理，可以看看前面的文章，能夠更好理解本篇文章，參考列表如下。

聊聊視頻會議系統中web端與客戶端通信的關鍵技術設計(1)

1.系統框架

本文主要講解視頻會議中協議轉換的設計，包括Web Socket-TCP 協議和 Web Socket-RTMP 協議的兩個雙向轉換，進而實現 PC Client、Flash Client 和 HTML5 Client 間視音頻實時通信的視頻會議應用。設計多種協議間轉換方案，就是為了既能夠通過PC Client參與視頻會議，也能夠通過Flash Client加入視頻會議，甚至能通過HTML5 Client接入視頻會議，三者之間相互通信。雖然市面上有這種解決方案，還是想通過一些實際的底層，去分析怎樣去解決這些問題，而不是拿來直接使用，而不知道底層發生了什么。

本文舉例的服務器系統包括了服務器(Web 服務器和流媒體服務器)、數據庫、多點控制單元 MCU、傳輸網絡、相關視音頻設備以及客戶端。整個軟硬件系統的框架如下圖所示:

可以看出該系統現有兩種客戶端：PC Client 和 Flash Client。有兩種流媒體服務器，包括私有流媒體服務器V5和Red5服務器。下面可以剖析下整個系統。

(1)PC Client 和 Flash Client 都是通過 XMPP 協議與 Web 服務器進行信令交互，如連接建立、建立流、身份驗證、信令正文以及連接斷開。

(2)PC Client 通過 HTTP 協議實現“發送用戶信息”、“傳輸用戶文本”以及“獲取用戶列表”等簡單功能。Flash Client 是一種 Web 客戶端，需要與 Web 服務器進行視頻會議應用程序交互，使用 HTTP 協議傳輸大量的數據，如地址、端口、會議房間等流媒體服務器信息。

(3)PC Client 底層也是通過 TCP 協議與 V5 服務器進行音視頻通信，其中 TCP 所承載視音頻數據是一種“借用”RTP/RTCP 協議頭部的自定義報文格式。Flash Client 將視頻和音頻分開處理：視頻通過 RTMP 協議與 Red5 服務器交互；音頻通過 TCP 協議與 V5 服務器交互，并且采用與 PC Client 相同的自定義報文格式。

Flash Client 將視頻和音頻分開處理！由于音頻數據相對較小，Flash Client 便采用基于 TCP 的自定義報文格式接發音頻數據，而沒有直接使用 RTMP 傳輸音頻數據。那么PC Client 與 Flash Client 間音頻交互和兩個 PC Client 間音頻交互相同。當初，Flash Client也打算基于 TCP 的自定義報文格式接發視頻數據，但是視頻流相對較大且壓縮成 H.264時十分消耗內存及 CPU，只好采用 RTMP 傳輸視頻數據。最終，系統采用 Red5服務器(也可以使用其它方案)作為 RTMP 中轉并添加協議轉換功能，實現 PC Client 與 Flash Client 視頻交互。

2.傳輸協議的關系

實際中還是推薦使用Nginx服務器做，基于第三方模塊 nginx-rtmp-module 的 Nginx 服務器可作為 RTMP 服務器，可以替換 Red5 服務器。但是該第三方模塊尚未提供一對多實時通信功能，無法滿足視頻會議多用戶應用需求。最近SRS服務器集成了webrtc，這個應該能夠滿足服務端的要求，我沒有測試過了，如果有人測試了，可以私信或者評論區回復。這里就使用第三方模塊進行擴展設計。

將 HTML5 Client 融入整個系統時候，我們必須實現 HTML5 Client 與現存的兩類客戶端間實時音視頻通信。下面從音頻和視頻兩個角度分析該系統傳輸協議間關系。

(1)音頻交互

鑒于 PC Client 和 Flash Client 使用相同的音頻處理方式，HTML5 Client 可采用基于Web Socket 協議傳輸音頻數據，并且音頻數據也采用自定義報文格式。那么各種客戶端之間音頻流上傳和接收流程圖，如下圖所示:

針對 HTML5 Client，主要分析如下：PC Client 或 Flash Client 的音頻上傳通過 TCP協議，HTML5 Client 通過 Web Socket 協議接收；HTML5 Client 通過 Web Socket 協議上傳音頻，PC Client 或 Flash Client 通過 TCP 協議接收音頻。那么音頻方面可得如下結論：當 HTML5 Client 融入視頻會議系統時，整個 系統需要實現 Web Socket-TCP 協議之間的轉換。

(2)視頻交互

前文可知，PC Client底層采用TCP 協議收發視頻數據；Flash Client 采用 RTMP 協議收發視頻數據。根據 HTML5 Client 處理音頻的方式，那么傳輸視頻數據時它仍可采用Web Socket 協議，并且視頻數據也采用自定義報文格式。因此，各客戶端之間視頻流上傳和接收流程圖，如下圖所示:

針對 HTML5 Client，那么視頻方面可得如下結論：當 HTML5 Client 與 Flash Client視頻通信時，系統需要實現 Web Socket-RTMP 協議間的轉換；當 HTML5 Client 與 PCClient 視頻通信時，需要實現 Web Socket-TCP 協議間的轉換。

通 過 實 現 Web Socket-TCP 協 議 和Web Socket-RTMP 協議的兩個轉換，將 HTML5 Client 融入系統。

3.可行方案分析

通過分析可行性方案，選取最優的方案。

(1)PC Client 視音頻數據和 Flash Client 音頻數據都是通過 TCP 協議上傳到服務器中私有流媒體服務器 V5，接著 V5 服務器的 TCP 模塊會進行分發處理。因而，HTML5 Client可使用Web Socket協議從V5服務器的TCP模塊獲得這些數據。這個過程需要TCP轉Web Socket 協議。反之，需要 Web Socket 轉 TCP 協議。可見，兩個轉換都位于 V5 服務器。V5 服務器添加 Web Socket協議處理也非常簡單。為了 系統的穩定性，可直接修改 V5 服務器的 TCP 模塊，實現 Web Socket-TCP 雙向轉換。Web Socket-TCP 轉換方案設計如下圖所示:

(2)Web Socket-RTMP 協議轉換

Flash Client 與 HTML5 Client 之間視頻交互，引起 Web Socket-RTMP 協議轉換。FlashClient 通過 RTMP 協議將視頻數據上傳到 Nginx 服務器，而 HTML5 Client 需要使用Web Socket 協議獲取這些視頻數據。 前面已經提到，Nginx 通過第三方 RTMP 模塊為 Flash Client 提供視頻服務。最初，打算使用 V5 服務器中轉視頻的方式：Nginx 的 RTMP模塊將 Flash Client 上傳的視頻轉發給 V5 服務器，然后 HTML5 Client 從 V5 服務器獲取視頻數據。但是測試發現，延遲至少 5s，不滿足視頻會議實時要求。隨著 Web Socket協議的廣泛應用，Nginx 論壇也出現了一些第三方模塊（HTTP 模塊）支持 Web Socket處理。因此，我選擇直接基于 Nginx服務器，先添加Web Socket處理（支持 HTML5 Client），然后添加 Web Socket-RTMP 協議轉換功能。在 Nginx 中，兩種協議的轉換既可以在 RTMP模塊中實現，也可以在 HTTP 模塊中實現。本文選擇“新增 HTTP 模塊”的方式來實現協議間相互轉換。

基于 RTMP 模塊，實現協議間相互轉換。基于第三方 RTMP 框架，在現有 live模塊或本文 RTMP 擴展模塊實現 Web Socket 處理。該方案，Nginx 不需要特殊對待 HTML5 Client（等同于 Flash Client）。但是，它存在一個非常大的難題：RTMP 協議是 Adobe 公司的私有協議，因而 RTMP 服務器不易進行其他協議的開發。研究后可知，該方案工作量巨大，可行性很低。如下圖所示:

基于 HTTP 第三方模塊，實現協議間相互轉換。RTMP 框架提供“ffmpeg 命令”支持流轉碼功能。本方案，首先利用 ffmpeg 命令的轉碼功能將 RTMP 流轉換為 HTTP流，然后使用支持 Web Socket 的 HTTP 第三方模塊 nchan 處理。這種方案，代碼工作量比較小，但是存在兩個缺點：一是只能從 RTMP 到 Web Socket 的單向轉換；二是整體可控性比較差。可控性差是因為 ffmpeg 命令無法根據實際網絡情況調整轉碼速率。該方案設計如下圖所示:

新增 HTTP 模塊，實現協議間相互轉換。新增 HTTP 模塊既充當 HTML5 Client的 Web Socket 服務器，同時又充當 RTMP 模塊的”Flash 客戶端”，主要采用 Upstream機制實現。通過 Upstream 機制，基于 Web Socket 協議的 HTML5 Client 便能與新增 HTTP模塊視頻交互以及新增 HTTP 模塊可與上游 RTMP 服務器（RTMP 模塊）交互視頻數據。該方案可充分利用 Nginx 并發特性。新增 HTTP 模塊的方案設計如下圖所示。本次就選取這種方案。

4.RTMP 擴展模塊設計

添加第三方RTMP 模塊的Nginx 服務器可以支持 Flash Client，實現一對一實時流和一對多點播通信但是該第三方模塊尚未提供一對多實時流通信功能，因而無法滿足視頻會議多用戶應用需求。大家可以去試一試srs流媒體服務器的webrtc。

每個模塊對于每個用戶會話存有一個獨立的上下文結構體（ctx，會話上下文）。會話上下文，一般在建立會話時建立并存于內存池中模塊指針數組。每個 RTMP 模塊自定義會話上下文的內容，這樣 RTMP 模塊就可以從會話上下文中獲取上下文信息，會話上下文在會話結束時自動銷毀。RTMP 會話上下文，一般都包括指向用戶會話的指針，進而通過上下文識別會話主體。為了滿足視頻會議中多 Flash Client 的應用需求，我們需要將各用戶會話上下文串起來。本文采用簡單且高效的單鏈表方式。視頻會議多用戶應用中，某個用戶發布且有多個用戶播放（類似于廣播）是最常見應用場景，因而會話上下文中需要添加標記位標識用戶類型。基于前面的分析，本文設計 RTMP 擴展模塊的會話上下文結構體，關鍵部分如下圖所示：

本文設計的 RTMP 擴展模塊位于 RTMP 框架第四層，包括發布、播放、啟動、暫停、流開始、流結束以及音頻|視頻流處理等功能。這些指令一般就對應RTMP第三層模塊的方法。擴展模塊設計如圖所示:

視頻會議多用戶應用的關鍵說明如下：

(1)當用戶需要發布視頻時，會將會話上下文 publishing 置為 1，并將媒體流發給Nginx 服務器。用戶都通過配置文件 nginx.conf 與擴展模塊會話連接時建立會話上下文。

(2)其他用戶作為接收者，會話上下文 publishing 取默認值 0，并等待接收媒體流。

(3)擴展模塊通過調用RTMP框架第三層方法收到的視頻流，并發送給會話上下文 publishing 為 0 的用戶，即接收用戶，這些用戶收到視頻流后便可播放視頻。

5.HTML5 Client設計

5.1 自定義報文設計

HTML5 Client 視音頻數據采用自定義報文（CELLPACKET）格式封裝，CELLPACKET 包括長度標識字段、RTP 頭部、RTPMM 頭部和視音頻數據流。CELLPACKET結構如下圖所示:

CELLPACKET 使用短整型變量 Length 標識該數據報的長度。之所以添加該字段，是因為視頻數據一般都比較大導致傳輸過程被分片，在接收端就需要按照該字段進行分片的整合。接著，CELLPACKE 直接包含 12bytes 的 RTP 頭部，為了滿足視頻會議的業務需求，CELLPACKE 頭部又增加了 20bytes 的 RTPMM 頭部。RTPMM 頭部是一種自定義的私有格式，如 MMID 表示媒體流 id、V/A Frame 標識視音頻數據幀類型等，RTPMM 頭部結構如下圖所示:

下面對 RTPMM頭部各字段屬性進行詳細解釋：

(1)V2RTP Version（8bits）：協議版本號，默認為 1。

(2)Flag（8bits）：RR Flag，標識該報文中是否有 RR（特殊報告）。

(3)Band Info（16bits）：帶寬信息，標識 Audio/Video 通道的帶寬值。服務器會根據該值，及時調整發送速率。

(4)Sub Number（8bits）：分片序號，若音視頻數據分片，使用該字段值標識該分片位于第幾個，默認為 0，即不分片。

(5)Total Num（8bits）：分片總數，常和分片序號（Sub Number）組合使用，進而完成數據包重組。若分片序號字段不為 0，Total Num 則表示該分片的總數。

(6)Seqence Number（16bits）：序列號，標識媒體報文，該值會隨著報文自動遞增。

(7)Timestamp（32bits）：時間戳，采用絕對時間，標識報文封裝的時間。

(8)MMID（32bits）：數據流 id，該值與音視頻流一一對應，最重要的標識字段。

(9)V/A Frame（8bits）：音頻、視頻的幀類型。如果數據包是 Video 數據，該字段值 0表示 I 幀，1 表示 P 幀；如果報文是 Aduio 數據，0 表示普通幀，1 表示重要幀。該字段默認為 0。

(10)Audio Burst（8bits）：突發 Audio 標記字段，默認為 0。當客戶端靜音抑制一段時間后，突然非抑制 Audio 幀，那么該字段會取 TRUE。

(11)Video Size（8bits）：標識視頻數據大小，默認為 0。

(12)Reserved（8bits）：保留位，供將來擴展使用。

5.2 HTML5 Client 相關設計

HTML5 Client 與流媒體服務器建立 Web Socket 連接，通過 Web Socket API 發送和接收 Web Socket 音視頻數據。本文對 HTML5 Client 音視頻處理設計，如下圖所示:

直接使用 HTML5 技術提供地 get User Media API 獲取本地視音頻。該 API訪問攝像頭和麥克風，啟動和獲取 Video 元素的視頻與音頻數據。Web 應用領域里，HTML5 已經可以通過 Java Script 腳本實現大量的音視頻編解碼器，其中比較流行的編解碼器包括：X264 視頻編解碼器、Open H264 視頻編解碼器以及 G.723 音頻編解碼器。如果你的video插件不支持視頻直播流顯示，可以采用固定周期地將視頻幀渲染到Canvas 的替代方法。目前一般集成了webrtc，使用起來更加方便。音視頻數據流向和結構如下圖所示:

本文的HTML5 Client 視音頻數據采用自定義報文格式，那么現有的 HTML5 客戶端是無法直接識別、解析和封裝。因此，本文對 HTML5 Client 新增這些功能，設計如上圖所示。關于 HTML5 Client 增加的功能，說明如下：

(1)將本地經編碼器處理過的視音頻數據流，先按照自定義報文格式封裝，接著將得到報文存入發送緩沖池，最后通過 Web Socket 發送出去。

(2)當 HTML5 客戶端接收視音頻數據流時，觸發 Web Socket 連接獲取數據并存入接收緩沖池，按照自定義報文格式拆包，最后將所得的視音頻流送入對應解碼器。

注意:采用Java Script 腳本來實現封裝和拆包功能。數據的傳送使用 Web Worker實現。

6.Web Socket轉TCP 方案設計

Web Socket-TCP 轉換可封裝于私有流媒體服務器 V5 的 TCP 模塊。本節詳細說明轉換方案的設計：對原 TCP 處理模塊增加 Web Socket 協議處理功能。該轉換先處理 Web Socket 協議握手過程，如解析握手請求與生成握手應答。握手成功后，該轉換再根據 Web Socket 數據幀對幀中有效負載解析或封裝。握手機制處理非常簡單，本節不描述。下面以 HTML5 Client 和 PC Client 間視音頻通信為例，說明 TCP 模塊新增處理 Web Socket 數據幀的設計思路，如下圖所示:

HTML5 Client1 發送音視頻數據流到 PC Client1，PC Client2 發送音視頻數據流到HTML5Client2。

(1)當私有流媒體服務器 V5 收到 TCP 數據流時，根據數據流所連接類型分類處理。當連接不是 Web Socket 連接時，則對應著 PC Client，數據流直接走原 TCP 接收處理過程；當連接是 Web Socket 連接，即對應著 HTML5 Client，服務器根據 Web Socket數據幀格式，先去掉 Web Socket 頭部，接著走原TCP 接收處理過程。

(2)當私有流媒體服務器 V5 發送 TCP 數據流時，也根據所連接類型分類處理。當連接不是 Web Socket 連接時，則對應著 PC Client，數據流直接走原 TCP 發送處理過程；當連接為 Web Socket 連接，即對應著 HTML5 Client，服務器根據 Web Socket 數據幀格式，先添加 Web Socket 頭部，接著走原TCP發送處理過程。

可見 Web Socket-TCP轉換功能，V5 服務器端僅僅需要改變原 TCP 模塊中接收TCP數據流和發送 TCP 數據流兩部分功能函數。

7.Web Socket轉RTMP 方案設計

本文選擇 Nginx 服務器“新增 HTTP 模塊”方案，而該方案需要具有兩大功能：Web Socket 處理，Web Socket-RTMP 轉換。前者通過借鑒 Nginx 現有的第三方模塊 nchan，很容易實現，這里不再敘述。后者是本文研究的核心，主要涉及 Upstream 機制和視頻數據報文轉換。下面描述新增 HTTP 模塊的相關設計。

Upstream 機制是 Nginx 提供一種全異步方式，能夠與第三方服務器交互，如建立TCP 連接、發送請求、接收響應以及關閉 TCP 連接。Upstream 機制十分高效，同時兼具簡單的特性：僅包括 8 個回調方法，用戶只需要根據自己的業務需求實現其中幾個回調方法即可。本文新增 HTTP 模塊需用到 Upstream 機制的 4 個回調方法：create_request、reinit_request、process_header 以及 finalize_request。

下面就舉例說明create_request 和 process_header 兩個關鍵回調方法：

(1)create_request 回調方法，Upstream 機制必須實現的方法。方案中該回調方法需將下游 TCP 連接讀寫事件置 empty_handler（不做任何事情，起阻塞作用）。該方法由 HTML5 Client 的第一個請求（Web Socket 握手請求）觸發，提取 Web Socket 握手信息供 process_header 回調方法處理進而建立 Web Socket 連接。

(2)process_header 回調方法，是最重要的 Upstream 回調方法，由上游服務器返回第一個響應觸發。process_header 方法，包括兩個主要任務：建立 HTML5 Client 與新增模塊間 Web Socket 連接，建立新增模塊與 RTMP 服務器間 RTMP連接。

通過Upstream的4個回調方法，新增HTTP模塊成為HTML5 Client 和 RTMP 服務器的橋梁。HTML5 Client 成功建立與新增 HTTP 的 Web Socket 連接，普通 Flash Client與 RTMP 服務器（Nginx 的 RTMP 模塊）相連接，通過新增 HTTP 模塊這個橋梁，兩類客戶端已經“連通”，如下圖所示:

描述 HTML5 Client 獲取 Flash Client 的視頻過程，即 RTMP 轉 Web Socket 過程，如下所示:

(1)基于前面所述 Upstream 機制，兩類客戶端已經連通。

(2)HTML5 Client 發送 PLAY 命令，該命令經新增 HTTP 模塊透傳給 RTMP 模塊。

(3)RTMP 模塊會將指定 Flash Client 上傳視頻流以 RTMP 數據包返回。

(4)新增 HTTP 模塊收到 RTMP 數據包，解析 RTMP 數據包中視頻數據，并將視頻數據重新封裝為自定義數據報文格式，然后發送給 HTML5 Client。RTMP 轉 Web Socket 過程如下圖所示:

上面第(4)步驟包括一個重要功能：HTML5 Client 視頻數據采用自定義報文，Flash Client視頻數據封裝于 RTMP 報文，因而我們必須在新增 HTTP 模塊添加視頻數據報文轉換功能。為了保障系統的穩定和轉換簡單化，HTML5 Client 采用與 Flash Client 相同的 H.264視頻數據格式。那么，視頻數據報文轉換可簡化為報文頭部轉換。兩類客戶端視頻報文轉換，如下圖所示:

8.總結

本文主要講解了HTML5 Client、RTMP 擴展模塊和多協議間轉換方案設計的原理。其中協議轉換設計包括了Web Socket到TCP相互轉換，Web Socket到RTMP相互轉換。針對上面的講的原理，如果目前有更好的商用穩定的框架，也歡迎大家能夠分享出來。后面再講講如何實現。歡迎關注，收藏，轉發，分享。

后期關于項目知識，也會更新在微信公眾號“記錄世界 from antonio”，歡迎關注