流式渲染技术,不同于传统意义上前端领域的服务端渲染(即 SSR),指的是云端性能强劲的机器进行画面渲染,将渲染完成的数据传送至客户端,客户端只负责播放及处理和上传用户输入信号至服务端的一种技术,谷歌的云游戏平台即是使用案例之一。在开源社区也有一些相关的方案,在拜读了 Parsec 公司的这篇博文——A Look at Game Streaming Tech in the Browser后,对整个技术体系中尤其是客户端(此处即浏览器)方面可能遇到的难点有了一个初步的认识,以下是一些相关的记录。
<video>
元素中;浏览器中的 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>
元素中。
输入事件(包括键盘、鼠标、游戏手柄)以及任意信息(光标、对话)都在各自信道处理。各种信息被打包为二进制格式发送至服务端。
浏览器为 web 客户端的实现做了大量的工作,前期如果以快速落地为主要诉求,可以考虑基于浏览器的 web 客户端实现。