干货分享 | 红点王宇航：以实时连接场景为目标的一些技术架构探索

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3268 天前的主题，其中的信息可能已经有所发展或是发生改变。

文 | 红点联合创始人王宇航
原文地址：http://t.cn/R4LVZ2B

我今天分享的主题，是以实时连接场景为目标的一些技术架构探索。主要是关于红点在产品研发过程中，我们的技术选择，架构变化，还有这个过程中，我们的一些考虑。

有很多科幻的作品，描述人类突破自然界对时间、空间的客观限制，去做一些事情。互联网在很多方面已经对我们的这种能力有了一个很强的补充，比如我们每个人都可以用微信，可以实时的与不同地域的人们对话。但是我们觉得这个能力还可以进一步提高，尤其在多人的场景。

我们希望在互联网上能够进一步提高信息的传输效率，进一步降低信息的传输延迟，去让一些线上的多人场景，有更好的体验。这是我们技术迭代的初衷，所以在后面的内容里大家可以看到，我们很多的技术选择跟这一点有很大关系。

红点的第一个版本

红点的第一个版本功能比较简单。我们当时要做一款手机端可以录音，网页端可以播放的直播产品。手机端只支持 iOS 就可以了，但是要能够全平台播放。对这个版本迭代的要求是能够快速上线，提供服务。

这个功能需求中，首要的问题是调研各个平台的 web 页面支持哪些音频直播格式。大家在图上可以看到调研结果，但是这个不是我们当时就使用的方案，这是我们花了一段时间通过线上实际运行的情况，总结的一个方案。

这里我们只列了两个格式， HLS ，这是苹果主力推广的手机网页直播格式 Http Live Streaming ，这个格式实际上是一个多媒体的播放列表，这个列表要求最少有三个文件，每个文件是一个独立的多媒体文件，通过在播放端循环更新文件列表，依次将最新的多媒体文件插入本地播放列表，顺序播放，来实现直播的效果，这个格式做直播的延迟在 8 秒以上会比较稳定，也就是每个文件的时长应该在 2 秒以上；另一个格式是 Http mp3 流，这个流是一个直播的流，不是我们平时经常见到的 mp3 点播的格式。

Pc 平台因为有 flash 对富媒体的支持，我们产品要求的多媒体形式都有成熟解决方案，比如基于 tcp 的 rtmp 协议，这是 adobe 公司推出的流媒体协议，等等。 iOS 平台上，苹果大力推广 HLS 作为他的标准格式，所以在 iOS 平台上也没有太多问题。

但是在安卓平台上情况并不理想。可能开发过需要运行在安卓平台上的 native 应用或者 H5 页面的朋友可能会了解，由于安卓厂商种类繁多，各自又存在脱离安卓标准修改 rom 的情况，安卓平台对多媒体的兼容性有很大问题。我们对 HLS 调研的情况最夸张的时候，复杂度是浏览器种类 设备种类 安卓系统版本 *安卓 Rom 种类。我们自己做的小样本调研结果是，大约一半的安卓浏览器，包括应用内的 webview ，无法正确播放 HLS 格式的直播。但是对于 Http mp3 流这种音频直播格式，效果就好很多，支持的比例在 90% 以上。

我们最初的全平台使用的是 HLS 方案，然后逐步过渡到， PC 网页和 iOS 使用 HLS 方案，安卓使用 http mp3 流的方案。

这是我们第一版产品的架构。客户端使用 tcp 协议上传 mp3 流，这里对照可选的还有 http 和 udp 两种，不过这两种的研发成本都较 tcp 高一些。我们这个版本的后台服务是一个单机的服务，支持接收 mp3 流的上传和 http mp3 流分发，同时能够本地落盘生成 HLS 切片和文件列表。 HLS 通过 nginx 反向代理，对外提供分发服务。

历史回听

接着我们对这个版本做了一次功能迭代，这次功能迭代我们主要增加了音频直播的历史回听。所以我们增加了新的后台服务，用于将直播结束后生成的历史多媒体文件上传到 UPYUN 上面。这个功能的主体部分我们是依靠 UPYUN 来完成的，这节省了我们大量的成本、时间和精力。大家都知道创业团队很多时候就是在跟时间和成本赛跑，所以能够直接使用成熟的第三方服务，是非常有帮助的。

多人语音

然后我们产品功能做了一次大的更新。我们需要实现多人语音功能，支持 iOS 和安卓两个平台的录音和播放。这里的多人语音是一个语音会议的能力，比如像 yy 语音， qtalk 这样的，能够多人实时会话的产品功能。

这个功能引入了这几个技术点，大家可以看到。首先是混音，混音就是将多路声音混为一路声音。这是我们播放能力带来的衍生需求。在 flash 里面，播放多路声音是没问题的，就是同时下载多路流，然后播放就行了，但是在手机 H5 页面里，没有这个能力。手机 H5 页面只允许同时播放一路声音，这就要求我们必须在后台实现多路转一路这个功能，然后才能支持手机 H5 的播放。

然后是音频格式。 Mp3 格式并不适用于低延迟场景， mp3 的编码延迟在 200ms 左右，这在音频编码中是特别高的。并且 mp3 这个格式本身是上下文相关的，也就是说一段声音的编解码依赖上一段或者下一段，这个特点也不适用于音频会议这种功能需求。所以我们需要选择一个新的音频格式。

下一个是网络协议，我第一版使用 tcp 的传输格式，但是基于 tcp 的协议有一个很严重的问题，就是无法改变拥塞控制策略。 Tcp 在遇到有丢包的情况时，会有非常严重的惩罚，影响传输效率，这也是语音通话不能容忍的，需要使用基于 udp 的协议来传输音频数据。

还有一个我没有列在上面的，是 AEC ，也就是回声消除。什么是回声消除呢，这个场景特别好理解。就是我们打电话的时候，如果我们打开免提，如果电话的回声消除做的不好，就会出现非常刺耳的尖叫声音，这个声音叫啸叫。这是由于设备本身的录音中包含了这个设备自己播放的声音，如果不能在录音中把自己播放的这部分去掉，就会出现循环，也就没法使用了。这个点我们在产品体验上规避了一下，我们要求安卓用户必须带耳机才可以使用多人语音功能， iOS 因为苹果提供系统支持，效果非常好，所以在 iOS 上没有这个问题。

音频格式

这两幅图是几种音频格式特性的对比，两幅图来自 opus 的官网，左图纵轴表示压缩的效果，横轴表示支持的采样率，右图的纵轴是编解码的延迟，编解码延迟是指输入一定时长的音频数据到输出压缩后对应的音频帧的时间间隔，横轴是码率。 Opus 压缩后的实际效果是否真的在数值上这么出色，我们没做详细的测评，但是我们对比了 ilbc 和 opus 对音乐压缩的效果， opus 在人声以外的场景仍然非常出色，并且编解码延迟也的确是如图中表示的这样，所以我们多人语音采用的音频格式是 opus 编码。

第一版多媒体接入节点设计

这里左图是多人语音上传分发功能的多媒体服务节点结构。每个节点由三个模块组成。 Room 模块实现房间对多媒体数据的广播；同时会将本地用户上传的数据转交给 Master 模块； Master 会将本地的上传数据同步给其他节点的 Slave 模块； Slave 模块是与 Master 配对的接收数据同步的模块。这个节点结构是同构的，每个节点的程序本身都一样，在部署的时候只有配置不同。

这要求整个服务内部节点之间必须是全连通的组织方式，每两个节点之间都需要有一个数据同步的链路。这种架构的好处是研发、运维成本很低，可以很容易的实现一定程度的可靠性和可用性。对于宕机节点，可以直接将这个点从服务列表中摘除，受影响的用户会自动由于本地网络失败，选择其他节点的服务。这个架构的问题在于，无法跨机房部署。由于是全连通的组织形式，如果跨机房，会导致机房间存在大量可能影响服务质量的数据链路，难以做网络优化。

这是多人语音功能的架构。其中 codec 服务是 ffmpeg 的网络封装，方便横向扩展。 Http mp3 流和 HLS 切片的输入是混音服务的输出。对 web 全平台通过 CDN 分发。

多媒体接入节点重构

这个版本上线以后，接着我们对多媒体服务节点做了一次重构。从全连通的组织形式改成树形组织形式。每个服务节点由两个模块组成， Room 模块实现对房间用户的广播， Client 模块是 Room 配对的客户端，用于实现节点间的数据节点。每个节点有一个唯一的 ID ，通过 ID 判断数据的同步是否会产生数据回路。当需要跨机房部署的时候，只需要多个机房能够共同通过同一个根节点进行数据同步即可完成整个功能。节点间我们增加 etcd 提供服务协调能力， etcd 是 golang 版本的类 zookeeper 服务。

视频

多人语音之后我们增加了视频功能。视频功能的要求也是一个会议的场景，需要延迟尽可能低。我们为协议增加了重传能力，前向纠错能力和选择重传算法。增加了私有协议转 RTMP 流的服务，和一套音视频同步的机制。转成 RTMP 标准输出以后，通过 CDN 支持 web 的播放。下面我们详细的看一下每一个技术点和架构选择。

H264 格式的视频有三种帧， I 帧 P 帧和 B 帧，其中 I 帧可以独立解码显示，但是 P 帧和 B 帧都直接或者间接依赖最近的 I 帧。所以如果 I 帧存在数据丢失，会造成大片持久的马赛克，这个在视频体验上是不能容忍的，所以重传在这里是必要的。 FEC ，也就是前向纠错，是对重传的一种补充，通过增加数据传输过程中的冗余比例，实现丢包恢复。

我们采用的是多项式方程的方案，这个方案可以自由调节冗余的比例和尺度。 Webrtc 中采用的冗余算法是异或的方案，异或的方案只能容忍一个数据包的丢失，无法处理连续丢失。选择重传算法要求数据重传要有时间限制和长度限制，这个算法本身是提高重传效率，提高网络利用率。

音视频同步这部分我们采用以音频为主时间线的方案。是因为人耳对声音更敏感，而对画面容忍度较高。

混流这部分我们实际采用的是客户端混流的方案。这里涉及到音视频复用，就是在服务器将音视频做好时间同步，再通过一个数据链路发送到客户端，或者在客户端做音视频复用，两个方案。由于服务器的复用处理会引入额外延迟，我们最终选择音频与视频，采用平行的系统提供上传与分发服务。这也带来了一个产品上额外的好处，就是当画面卡顿时，可以很容易的选择只播放声音，停止播放视频画面。

以上就是我们在迭代产品过程中的技术架构变迁。