云游戏流媒体总体架构设计（云游戏流媒体技术前瞻，最近云游戏概念很火，加之对流媒体技术略有研究，简单写一些）

前言：

遥想当年阿法狗战败一众围棋国手，风气一转，彷佛全部人都懂AI。此次谷歌又放出了stadia，国内鹅厂再次跑步进场，贵州某xx云提早布局。

闲来无事，尝试体验了一下贵州某xx云的云游戏（不打广告），暂且不评论如何如何，恰好对流媒体技术略有研究，仅在这里简单聊一下这方面涉及的架构和技术。

架构设计：

整体架构自上而下大体分为四端：

一、云游戏主机端（云游戏运行端，或者叫云游戏画面渲染端，须要接收控制指令并录屏推流到流媒体服务）

主机端须要运行游戏并让经过录屏推流程序把渲染好的游戏画面（其实就是录屏）推流到流媒体服务进行实时视频分发。

有人会想这个云游戏主机端可能会很复杂，其实也还好，只是包含了录屏、推流、用户控制指令接收和一些其余诸如计费此类的相关功能。

二、流媒体服务（用于转发主机端推上来的游戏实时视频并分发出去，全部用户均可以观看这个视频）

这个不须要多讲了，只是用来转发游戏实时视频，并不涉及云游戏主机的控制权。

三、控制指令转发服务（用户须要获取控制指令服务的全部权才能控制云游戏主机）

这个是云游戏的控制核心，获取某台云游戏主机的用户就能够经过键盘或者鼠标进行云游戏的试玩（操做），理论上讲可以获取该控制权的不是只有一个用户，彻底能够支持多个用户同时控制一台云游戏主机。

四、客户端（浏览器，pc客户端，ios，安卓客户端等）

客户端须要从流媒体服务拉取实时游戏视频，用户须要先获取云游戏主机的控制权，才可以发送控制指令来试玩（操做）云游戏（鼠标，键盘，手柄等）

灵魂画师绘制结构图：

架构示意图-来自灵魂画师的倾情手绘

难点或者叫待解决的点：

一、流媒体协议的选择？高延迟才是最大杀手

从流媒体技术出身开始，实时视频延迟一直是个比较棘手的问题，好比rtmp/http-flv等基于tcp的协议自己优化到极点也要几百毫秒的延迟，hls这种超高延迟到几秒的不提也罢。就目前看只有sip、rtsp以及基于udp的一些协议可以知足这种超低延迟的需求，可是这种协议就很难在浏览器上就很难实现了，除了webrtc，而webrtc协议是谷歌力推的下一代流媒体协议，不排除此次是谷歌webrtc技术的奠定之做，拭目以待。

二、云游戏主机控制指令的全部权？依然是延迟

这个全部权其实不算是难点，只是用户获取某台云游戏主机的控制权而已。难点在于控制指令的延迟，没错，就是网络延迟。尤为是在拉取实时视频时，在视频已经占用大量带宽的状况下，在这种网络负载或者网络波动较大的状况下控制指令延迟或许值得重视。

跟不少朋友讨论过云游戏这个话题，不约而同第一个想到的都是网络延迟，固然这个延迟不只包含控制指令的延迟也指实时游戏视频的延迟。

 

后言（啰嗦几句）：

其实这块依然属于共享经济的后续，相似共享单车。

给你们举个栗子：我有一百台性能强劲的游戏主机，每台主机价值一万，当二手货卖掉可能还会亏点，好惋惜。那么我把他共享出来，假设如今有十万个用户想租我这一百台机器，而后每人只收10块钱月租，不考虑电费等其余成本，请问我何时能回本？

做者：eguid

说明：原CSDN相关博客文章已经所有转移到博客园