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

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

流式渲染技术，不同于传统意义上前端领域的服务端渲染（即 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 客户端实现。