流式渲染技术,不同于传统意义上前端领域的服务端渲染(即 SSR),指的是云端性能强劲的机器进行画面渲染,将渲染完成的数据传送至客户端,客户端只负责播放及处理和上传用户输入信号至服务端的一种技术,谷歌的云游戏平台即是使用案例之一。在开源社区也有一些相关的方案,在拜读了 Parsec 公司的这篇博文——A Look at Game Streaming Tech in the Browser后,对整个技术体系中尤其是客户端(此处即浏览器)方面可能遇到的难点有了一个初步的认识,以下是一些相关的记录。
浏览器中的 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 客户端实现。
原文来自:https://fecoding.cn/2019/07/22/a-look-at-the-browser-based-client-streaming-tech/?utm_source=tuicool&utm_medium=referral
客户端检测方式:能力检测,怪癖检测,用户代理检测.最常用也是最为人们广泛接受的客户端检测形式是能力检测(又称特性检测)。能力检测的目标不是识别特定的浏览器
我们经常可以看到在浏览器打开客户端的场景:浏览器打开 QQ 聊天窗口,百度网盘打开网盘客户端下载等。我们如何使用浏览器网页链接打开本地 exe 客户端程序?
通过判断浏览器的userAgent,用正则来判断是否是ios和Android客户端;检查是否是移动端(Mobile)、ipad、iphone、微信、QQ等;判断iPhone|iPad|iPod|iOS|Android客户端
轻客户端是区块链生态系统中的关键要素。它们帮助用户以安全和去中心化的方式访问并与区块链交互,而无需同步整个区块链。在本文中,我将用简单的语言解释什么是轻客户端,什么不是,以及它从何而来。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!