.引言

本篇文章是基于上篇文章去编写的，继续讲解协议转换的原理，可以看看前面的文章，能够更好理解本篇文章，参考列表如下。

聊聊视频会议系统中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”，欢迎关注