基于浏览器客户端的流式渲染技术难点一览

本文首发于个人博客（点此查看），欢迎关注。

流式渲染技术，不一样于传统意义上前端领域的服务端渲染（即 SSR），指的是云端性能强劲的机器进行画面渲染，将渲染完成的数据传送至客户端，客户端只负责播放及处理和上传用户输入信号至服务端的一种技术，谷歌的云游戏平台便是使用案例之一。在开源社区也有一些相关的方案，在拜读了 Parsec 公司的这篇博文——A Look at Game Streaming Tech in the Browser后，对整个技术体系中尤为是客户端（此处即浏览器）方面可能遇到的难点有了一个初步的认识，如下是一些相关的记录。

整体流程

1. 经过 WebRTC 技术实现点对点（更常见的说法：P2P）链接；
2. 将客户端配置发送至服务端，初始化流；
3. 开始接收服务端发来的视频、音频及控制信息；
4. 使用 Opus 音频格式对音频进行解码并经过 Web Audio API 播放；
5. 使用 Media Source Extensions 将视频内容塞进 <video> 元素中;
6. 采集输入事件，将其打包为二进制形式并发送至服务端。

网络

浏览器中的 P2P 链接只能依赖 WebRTC 实现，WebSockets 不适合的缘由是其在 NAT 遍历及基于 TCP 的拥塞控制等多方面存在劣势。parsec 的 web 客户端使用 RTCDataChannels 与服务端通讯。RTCDataChannel 被 UDP 封装于 STCP 流中。出于安全考虑，STCP 流又被 DTLS 封装。

NAT 遍历和 P2P 的初次链接（后来发现其能够归结为 UDP 穿孔过程当中的一部分，就是一个简单的 STUN ping/pong）在技术实现上很复杂。初次握手须要预先交换安全凭证，这一操做经过 WebSocket 发送信号实现。

parsec 的原生客户端采用了本身基于 UDP 封装的 BUD 协议。出于开放心态，web 客户端使用了默认的 DTLS/SCTP。虽然能够保证理想情况下的使用，但其显然没有 BUD 协议来的鲁棒性好，因此后期可能会被 BUD 替换。

视频

在浏览器中（实际上只在 Chrome 中），咱们使用 Media Source Extensions 将视频帧装载进 HTML <video> 元素。Chrome 为 MSE 实现了『低延迟』模式，该模式使用视频流推送模型以支持任意低延迟视频流。

音频

音频以原始 Opus 编码格式传入，而后经过由 Web Assembly 编译而来的 Opus 库进行解码，最后由 Web Audio API 播放。Chrome 在 70 版本后会支持经过 MSE 处理 mp4/opus，采用这一方式将是更好的解决方案，实现上就相似视频推送，只不过是推送到了 <audio> 元素中。

输入/信号

输入事件（包括键盘、鼠标、游戏手柄）以及任意信息（光标、对话）都在各自信道处理。各类信息被打包为二进制格式发送至服务端。

我的总结

1. 网络

   网络是很是重要的一点，关系到是否可以保证整个应用正常使用。为了适应流式渲染技术对网络高吞吐、零缓冲的特色，可能须要对现有网络协议进行改造（主要针对 UDP）。此外，公网环境下须要面对的 NAT 遍历问题，若是前期只考虑局域网环境，该难点能够被绕过。

2. 视频

   基于 Chrome 的 MSE，视频在客户端的播放会相对较为容易。只须要熟悉 MSE API。

3. 音频

   一样能够基于 Chrome MSE 实现。

4. 输入/信号

   各自隔离处理便可，浏览器端对常见的输入信号几乎都有支持。

浏览器为 web 客户端的实现作了大量的工做，前期若是以快速落地为主要诉求，能够考虑基于浏览器的 web 客户端实现。