腾讯手游基础技术分享
张丹
• 浅谈手游的发展前景
• 手游网络环境
• 手游架构技术评估
• 手游SDK能力
• 手游运维能力
目录
国内移动游戏市场增长显著放缓，人口红利消耗殆尽
数据来源：App Annie、GPC、 IDC、CNG；腾讯内部整理
0
20
100
80
60
120
160
140
国内iOS平台移动游戏营收
（~，百万美元）
33%
37%
46%
52%
59%
61%
0%
10%
20%
40
40%
30%
50%
70%
60%
13Q1
13Q2
13Q3
13Q4
14Q1
14Q2
国内移动游戏用户渗透率（13Q1-14Q2）
移动互联网用户规模（亿人）
移动游戏用户渗透率
国内终端销量增长乏力，首次购机占比持续下降
数据来源：百度；腾讯内部整理
-10%
0%
-5%
5%
20%
15%
10%
0
40
20
60
120
100
80
12Q3
12Q4
13Q1
13Q2
13Q3
13Q4
14Q1
14Q2
国内智能机出货量及增长率（12Q3-14Q2）
出货量（百万台）
增长率
96%
94%
66%
55%
48%
43%
40%
0%
10%
30%
20%
40%
50%
100%
90%
80%
70%
60%
12Q3
12Q4
13Q1
13Q2
13Q3
13Q4
14Q1
国内Android手机首次购机比例下降
（12Q3-14Q1）
首次购买Android机
老Android用户换机
中国
日本
北美
韩国
Top 10 游戏占比
58%
50%
39%
49%
Top 25 游戏占比
79%
67%
53%
68%
Top 50 游戏占比
92%
78%
65%
80%
Top 100 游戏占比
97%
87%
77%
89%
2014H1
总体市场规模
（百万美元）
2,122
2,817
2,780
735
全球各主要地理区域移动游戏市场集中度（）
数据来源：App Annie、腾讯整理
国内移动游戏行业精品贡献主要收入份额，产品类型持续细分
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Apple store中国区营收TOP20移动游戏类型分布结构
(~)
卡牌
动作
战争策略
棋牌
经营
塔防
休闲益智
音乐
RPG
体育
单机类强联网
轻度中重度
社交化
国内游戏越来越往强联网，中重度，社交化，高品质方向发展
单机类：
休闲类：
卡牌类：
动作类：
高品质
• 浅谈手游的发展前景
• 手游网络环境
• 手游架构技术评估
• 手游SDK能力
• 手游运维能力
目录
移动网络RTT延时分布
单流最大带宽=TCP窗口/RTT（Round-Trip Time，往返延时）
最大带宽和RTT延时关系如下（WIN=64，MSS= Byte）：
注：电信3G带宽最小，但客户体验超越移动3G，关键是延时较小。
全国手游用户实际测试RTT延时结果：
空中网和核心网部分和运营商合作探讨实时游戏的QoS保证
在无线网络以及无线网关拥塞的情况下优先保证实时游戏的延时需求
其他需注意的问题：
跨网访问
全局调度
就近覆盖
动态路由
客户端
源点
传输节点
原始路径
优化路径
数据
客户端
源点
传输节点
原始路径
优化路径
数据
Internet网部分优化接入调度方式
分运营商接入
中国移动
AS9808
质量差
中国电信
163
AS4134
中国移动
中国联通
中国电信
其他中小
运营商
移动网关时序错乱
http协议被降级
域名被劫持或缓存
容灾调度
在终端配置server list，直接访问IP
国外用户接入点部署
双边TCP加速——应用局限
在TCP连接的两端部署硬件设备或安装软件，TCP
透明代理工作在TCP连接的两端，代理了两端的连
接，两个代理之间通常通过UDP或其它自定义协
议进行工作。
在实际使用中，TCP协议的两端与软件或硬件设备
在一个局域网内，两个透明代理设备之间是广域网
链路，通常具有一定的丢包、延迟，会造成TCP性
能下降，所以在这两个透明代理之间，通常将协议
转换为UDP协议或其它自定义协议，这些协议本
身可以完全按照自己的要求进行控制，达到提高
TCP性能的效果；同时，双边TCP加速还可以引入
压缩、缓存等技术进一步提高TCP性能。
双边TCP优化比较适用于TCP连接的两端比较容易
控制的场景，可以较容易的安装硬件设备或软件客
户端。
单边TCP加速——适用性广泛
单边TCP加速意味着可以只在TCP的一端部署软件或设
备，达到提升TCP性能的目标。
单边TCP加速的一个基本要求就是经过透明代理出去的
协议必须是TCP协议（包括5元组和TCP的各种状
态）。单边TCP加速的透明代理，在WAN一侧运行的
应该是一个与标准TCP兼容、同时性能提高的TCP。绝
大多数的单边TCP加速，都是在通过改进TCP的拥塞控
制算法来进行TCP加速，例如TCP Vegas, CUBIC,
FastTCP, Zeta-TCP等。
与双边TCP相比，单边TCP优化的适应性更广且更灵
活。例如只要在服务器端进行了TCP加速，所有访问此
服务器的客户端都会受益，并且不需要客户端安装任何
软件或部署硬件设备。这样，就更加适用于服务器的访
问对象不固定的情况，例如某个服务器是广大的互联网
用户来访问。但是，单边TCP加速无法直接实现压缩、
缓存等功能，如果要实现这些功能，同样也需要双边部
署。
Internet网部分优化TCP协议来加速
一、核心思想
TCP加速的核心思想就是采用透明代理的方式，将TCP一端的连接终结，然后重新发起一个连接到TCP
的另外一端。这样，两端的数据包都被缓存在两端的TCP加速器上，TCP加速器之间的数据发送由TCP
加速器进行控制。主流的TCP加速技术主要包括双边TCP优化和单边TCP优化两种。
TCP 加速技术的演进：三代技术
Loss-
based
Delay-
based
• 基于丢包的拥塞判断及处理– 以丢包来判断拥塞并调整传输速率
• 基于延迟的拥塞判断及处理– 以往返延迟（Round Trip Time, RTT）变化来判断拥塞并调整
传输速率
TCP 拥塞程度并相应调整传输速 大 度。这一机制更符合 (Congestion Window，CNWD) ，同时在通过丢包 的改进主要是通过增 初始 塞控 窗口 现代网络的 点，能够在发生拥 网络节点的队列开
的问题：
1 会产TCP 连接的路径上发生拥塞节点的队列很浅时，延迟并不提高，拥塞体现为阵发的丢包。 ．当 生非拥塞因素的丢包，特别是对无线网络，如信号被干扰等因素导致的丢包并不意味有拥塞发
但加重路径节点拥塞，而且需要花更长时间从大量丢包中恢复过来，经常会导致传输阻滞。
Loss-based 就 频繁；一些网络Linux 特别是安Cubic TCP 能 。
Loss-based 态 技 技 Delay-based的 的
Loss-based 加 加 Delay-based流 的 TCP 以 加 包 的 来 主 判 要 断 缺 拥 陷 塞 ， 并 在 调 原 整 理 传 上 输 率 延 的 迟 方 的 式 变 。 化 其 来判 传 断 统 速技术克服了 TCP 丢 不论是 的 TCP
始堆积时就及时下调传传统 TCP 免拥 恶 方 ， 恢复 CNWD 免 ， 丢 以 包 期减 发 少 生 拥 。 塞 同 对 时， 率 Delay-based 管这 因此，Loss-based 比输速度，避 塞 化 减少甚至避 的影响。尽
TCP ，并且随着传输的进行，网络路径特征因素发生的丢果也会起 加 伏 速 不 技 定 术 高 在 的 原 速 理 率 上具 因此 以下 设 两 计 个 优良 有效进在很多情况下确实能够提升速率，但 Loss-based 包TCP
1 此， ．将丢包作 塞发生 加 的 速 信 技 号 术 很 在使 易误 中 判 逐 ， 渐 导 暴 致 露 传 出 输 以下 率 主 下 要 降 缺 ， 陷 带 ： 宽 的动态算法，基于每一个TCP ，新一代 为拥 TCP
生。判断丢包 TCP 加速技术感应不到这种拥塞，会继续高速发送数据包，从而导致持续大量丢 时地
2 算，之后的丢包恢复期会很长，导致传输速率显著降低。同网络环境及频繁变化的网络延迟、丢包特 法无法适应网络路径特征变化的问题，保证了在各种不
Learnin • 基于学习的拥塞判断及处理– 通过对路径上传输历史的学习动态判断拥塞并调整传输速率
g-based
Learning-based TCP动加速 TCP 术 加速技术
Delay-based Loss-based 还是 速技术沿袭了主Loss-based速技术都采用静态算法：基于对互联网流量模型
的假设前提采用固定的拥塞判断及恢复机制。但网络的发展趋势是流量特征越来越复杂并难以预测。
判断出现拥塞后使用和 Delay-based 更激进的 TCP 式加速技术常常只在其前提假设成立的特定网络场景下
些改加速技术不将丢包当作拥塞，在非拥塞发生变化，效的时可以保持较，有时甚至出现反效果。 严
重 Delay-based TCP 加速技术比 Loss-based TCP 加速技术在传输速度上有了显著的提升。尽管如
so Delay-based Learning-based TCP容 加速技术采用网络路径特征自学习 得不到有效利用。现代很多网
连接实时观察、分析网络特征，根据学习到的网络特征随时调整算法来更准确的判断拥塞程度、更及
Delay-based，从而更恰当的进行拥塞处理并更快速的进行丢包恢复。这一设计从原理上克服了静态
包．现代网络设备通常队列比较深，当拥塞发生时队列变长，延迟显著提高，但丢包迟迟不会发生。
Loss-based 果 径本 TCP 的加速机制将继续高速传输直到队列完全 TCP 满，往往导致大量数据包丢失。这不
迟增加误判为拥塞并转入拥塞处理，从而导致没有必要的压低传输速率。包括移动互联网在内的无线
网络延迟变化 TCP 很 加速包括在最新 设备（系统中的全设备）也可 等 不定时地引入额外的数据包处理延
迟。
FastTCP 是一个典型的 Delay-based TCP 加速。
2 征 ． 下 当 加 网 速 络 效 路 的持 身 续有 延 效 迟 性 就 。 变化很大时，Delay-based 的 充 加速技术会将非拥塞因素导致的延
• 浅谈手游的发展前景
• 手游网络环境
• 手游架构技术评估
• 手游SDK能力
• 手游运维能力
目录
手游架构技术设计注意点
客户端
安全
服务端
运营
1.性能基线达标
2.架构设计合理
3.存储与容灾
4.弱网络处理
1.基础组件选型
2.高可用方案
3.弹性动态扩展
4.可运营规范
1.性能基线达标
2.流量、内存、CPU消耗
3.帧率基线达标
率控制
1.数据加密、协议保护
2.游戏逻辑安全
3.安全SDK接入
4.安全日志开发
服务端性能基线
• 事务成功率>%
• 事务响应时<1秒
• 稳定性运行10小时上，各事务成功率>%
容灾雪崩方案
• 限制频繁登录，防止出现雪崩
• 系统繁忙(过载)时的友好提示
• 单个系统过载导致所有玩家无法体验核心玩法
负载均衡与扩容
• GameSvr应该设计为无状态服务，支持动态扩容
• DB设计要支持分片和动态配置分布部署
• 支持TGW前端接入
弱网络处理
• 游戏中不能出现收支不等、客户端卡死/崩溃等异常情况
• 游戏核心功能不能有导致游戏无法正常进行的UI、交互问题
• 不能有损害玩家利益或可被玩家额外获利的问题
• 需要对延时的情况有相应的提示
安全反外挂
• 无法通过内存修改、变速、修改系统时间获益或降低游戏难度
• 安装包不存在可能泄密的明文信息或帮助分析作弊方法的信息
• 进行代码混淆，加壳保护或服务器对安装包进行签名校验
• 发布报在log文件或控制台log中无输出敏感信息
• 重发和修改协议不能获得额外收益或对游戏造成攻击和负面影响
• 核心游戏逻辑的用户行为与核心数据在服务器校验正确
• 有防止作弊的发现机制和处理机制
客户端性能基线
• 最低硬件配置要求
• Android平台：HTCG7（CPU：单核1GHZ，RAM：576M）
• iOS平台： iPhone4/iPod Touch5/iPad2
• CPU均值不大于80%
• 用户crash率必须低于6%，次数crash率必须低于5%
客户端内存消耗
• PSS—内存消耗指标
• Android平台内存1G以下机型：最高PSS<=96MB
• Android内存1G的机型：最高PSS<=150MB
• Android内存2G的机型：最高PSS<=200MB
• iOS平台在iPhone4S下运行，消耗内存（realmem）<=150MB
客户端流量消耗
• 对于分局的游戏场景，单局消耗流量不超过200KB
• 对于不分局游戏场景，10分钟消耗流量不超过500KB
客户端帧率基线
• 低配机型：游戏核心玩法中，最小FPS应不小于18帧/秒
• 中配机型：游戏核心玩法中，最小FPS应不小于25帧/秒
可运营规范
•程序必须实现动态重载相关的配置文件，而无需中断服务
• 游戏热点类(例如用户信息等)数据访问必须使用cache层
• 服务进程间具有自动重连机制
• 程序用到的系统参数不能hardcode到代码中
• 游戏架构必须具有良好的可扩展性，支持运营策略调整
• 浅谈手游的发展前景
• 手游网络环境
• 手游架构技术评估
• 手游SDK能力
• 手游运维能力
目录
典型手游架构
客
户
端
统一接口层
公共逻辑层
登录 分享 邀请 LBS 选区 更新 下载…
安全组件层
iOS
平台适配层
Android WP8 ……
服
务
器
游戏框架层
公共逻辑层
SNS LBS 支付 公告 PUSH 游客验证 …
数据存储层
游戏支撑
体系
经营分析
平台
安全防护
平台
游戏客户端逻辑
游戏引擎
游戏服务端逻辑
游戏开发
关注游戏
业务逻辑
提供框架
公共服务
SDK
SDK
SDK基础功能
帐号登录
支付
SDK社交功能
tail
Msg Body
消息分享
好友关系
附近的人
排行榜
SDK运营功能
游戏内公告
消息推送
营销活动
SDK功能地图
• 浅谈手游的发展前景
• 手游网络环境
• 手游架构技术评估
• 手游SDK能力
• 手游运维能力
目录
200
2009
2014
1、从2009年到2014年5年间，腾讯
游戏数量从30+款增加到200+款，数量
翻了7倍，其中手游占四分之一
180
30
端游
30
手游
手游增长迅猛，上线准备周期大大缩短
2、与游戏数量的增加相反，随着手游的
兴起，游戏运营准备周期大幅缩短，从端
游的6-12个月缩短到30天以内
3、传统端游和页游新进和挽留用户成本增加，加强精细化运营
新的行业形势带来的挑战
快
稳
省
适
自
资源供给快、系统对接快
服务搭建快
系统稳定、具备自恢复能力
减少资源闲置，降低人力投入
业务架构各异，如何适配
减少重复劳动，回归正常作息
外
内
对游戏云的要求
快
稳
IAAS
省
适
PAAS
自
配置系统
作业平台
数据平台
监控平台
腾讯游戏云架构
工具开发平台（蓝鲸）
ESB（接口总线及调度引擎）
虚拟化平台
游戏云存储
(GCS)
发布
APP
开区
APP
迁移
APP
故障
自愈
体验
优化
场景工具（APP）
PAAS
IAAS
稳
IAAS层关键能力体现
虚拟机快速供给、扩容
快
运行稳定、性能接近实体机
省
虚拟机快速回收、缩容
虚拟化平台
虚拟化平台介绍
稳
IAAS层关键能力体现
数据层快速变更
快
数据层高可用
省
数据层负载均衡
GCS
PAAS
场景工具（APP）
PAAS层构成
工具开发平台（蓝鲸）
工具开发平台
（蓝鲸）
场景工具（APP）
适
快
稳
自
适应不同架构的游戏
适配各个运营支撑子系统
全流程打通，一键完成
故障自愈，实时恢复
自助化，无人值守
ESB（芯雲调度引擎及接口总线）
iJobs作业平台
蓝鲸工作台
故
障
自
愈
容
量
调
度
游
戏
云
发
布
游
戏
云
开
区
游
戏
云
迁
移
枫叶数据实时
计算存储平台
体
验
关
怀
主机实时
管控管道
星河配置中心
TGW
uWork
Matrix
TNM2
GCS
NOC
…
…
agent
PAAS层架构
数据计算
海量计算
实时计算
总结：在云时代如何低成本的运维上百款架构各异的游戏？
IAAS平台
高可用
调度能力
PAAS平台
快速开发
基于场景
自动化、自助化
