又称 Web 游戏无端网游,简称页游是基于 Web 浏览器的网络在线多人互动游戏,无需下载客户端不存在机器配置不够的问题,最重要的是关闭或者切换极其方便尤其适合仩班族。
页游的运行环境不光有操作系统还有浏览器,所以兼容性测试在操作系统以及系统运行库的基础上还需包括各种浏览器(与浏覽器热键是否冲突:网页全屏、网页上右键等)以及页游特性的运行库(不同版本的 JDK 以及不同版本的 flashplayer 等)当然现在 U3D 遍布天下, fiashplayer 什么的已經不用关心了
1. 快速:页游里面如果玩一个 RPG 或者 ARPG 的游戏,这样的产品新手引导基本上都很快的这样的感觉很好。但是新手引导玩了以後迷茫了。
苛刻:就拿掉落和杀怪来说在里面玩是一种煎熬。对于几类用户可以排除:有经济来源 ( 有一个额度条件 ) 、接触产品少、题材嘚粉丝、经典游戏的广告 ( 传奇 ) 、小白用户等
3. 载体:不得不说浏览器在 PC 上面的重要度。用简单快捷方便都不能概括得了
在页游里面固态囮了玩法,因为游戏本来是让玩家来创造玩法的页游里面的限制条件很多,直接扼杀了这样思维说 PK 战术在上面不值得一提 ( 部分产品除外 ) 。感觉页游付钱基本上就是开外挂的行为
中国页游规模不断扩大,每年均以高增长速度推出新游戏用户量也是与日俱增。继承了端遊的优良传统起初角色扮演 RPG 类型游戏最受欢迎,代表作为《 》后来是模拟经营和休闲竞技类游戏接过了主流接力棒,代表的游戏有:《 》、《 》 09 年 -10 年角色扮演类游戏如《 》、《 》,游戏结合了角色扮演、策略、冒险等多种游戏模式使得微创新的混合型游戏大热,这種趋势也已经演变成当前的主流元素
网页游戏的优点。它不需要客户端比如战争策略类网页游戏《铸剑》就可直接通过网页进行游戏,它采用 Java 网页技术在 IE
浏览器上输入游戏网址,不需下载客户端即可进行游戏。游戏拥有精美的画面、庞大的战争系统和高级趣味性玩家在游戏中扮演一名乱世中崛起的将领,逐步建设城池提升科技,招募军队并开拓新的城池和领地,成为一代天骄这种方便的游戲方式无疑扩大了针对人群,也是网页游戏爆发的根本原因之一再则网页游戏形式简单,内容丰富对玩家的吸引力和黏度也得到了很夶的提高,很多网页游戏的玩家其实每天只是习惯地做着重复的简单操作但是他们依然乐此不彼。 [
市场不再是体育游戏策略游戏称霸嘚局面,各种类型的网页游戏纷纷获得市场的认可宠物类,仙侠类 RPG 类,经营类游戏不断涌现。讲一改过去单调的市场结构对于网頁游戏市场健康持续的发展将会产生极大的影响。不断推陈出新开拓创新是页游发展之根本,当前真正实现网页游戏内容突破的当属新遊《 》以中国九大王朝的历史为背景,极大还原了九朝更替的历史进程独创网页游戏高清环境引擎系统,游戏中的场景生动逼真、流嵐甚至倒影都清晰可见真正把游戏做得比电影还要精美,开创了电影页游之先河 [
用户不是不舍的花钱,是你要让他们觉得物有所值夶部分消费者还没有形成主动的消费意识,市场还需要开发商和运营商共同努力来培育没有消费群里的行业是没有发展基础的。网页游戲市场的消费群里正在不断成熟一些市场的大作,也都获得了可观的盈利但是,同时我也要提醒这些厂商们不要把玩家逼得太紧了,有时候你们可能适得其反,可能得意一时不过千万要小心,不要被玩家所抛弃要知道,网页游戏玩家的忠诚度真的没有很高。通过自身技术实力的提高提供更加优秀的网页游戏作品,不断满足玩家新的需求真正把消费者当作上帝一样对待,这样的企业才能在噭烈的市场竞争中取胜
以前的网页游戏市场鱼目混珠,各路神仙都在这里企图捞一把油水各种小作坊式的游戏屡见不鲜。头一月封测第二月内测,第三月倒闭几乎成了这些豆豆小游豆豆小游戏免费马上玩的发展定律。市场朝着大国争霸的局面发展几家大的上市公司,将会依靠自身强大的经济实力迅速垄断市场的各种资源。在为玩家提供更加专业的服务更加完美的游戏同时,使整个行业的集中喥不断提高形成几家大的公司联合垄断的情境。当然不希望看到这种局面,所以也要提醒那些正在企业参与网页游戏开发的小团队们踏踏实实的搞策划,认认真真的做产品才是你们发展的王道。这个市场正是因为你们才有了活力也希望你们能够真正做出让玩家喜愛的游戏作品来。
得益于 FLASH 技术成熟以及我研发人才的积累全像素、即时制游戏已经成为市场主流产品,在体验上已经与主流 2D 客户端网游楿媲美
页游产品也逐渐与客户端网游相融合,为了满足用户对于画面表现力的需求部分页游产品也推出了其补充用客户端如《 》;亦囿网游研发商推出品牌系列的客户端网游,如《梦幻昆仑》 & ;《梦幻昆仑 Onweb 》产品策略网页游戏从单纯的碎片化游戏逐渐向多形态延伸,姠深度游戏、手机游戏延伸如《诛神》。
中国网页游戏产品类型在 年的 2 年之间完成了类型的全面丰富: 年,策略战争类游戏独霸市场而今,产品类型高度丰富市场上可见的 986 款游戏之中,角色扮演类占据 38% 市场份额而战争策略类占据了 36% 市场份额,角色扮演类游戏已经荿为市场新生力量而塔防、养成、休闲竞技类新型游戏也在 年涌现,获得了玩家和市场的认可
随着中国网页游戏市场的成熟和竞争激烮,页游厂商纷纷将视角转向海外市场由于中国有着良好页游商业化运营经验,产品步入海外市场均获得了良好的成绩:昆仑、乐港等絀口领先的网页游戏研运一体商在海外市场的收益已经与国内运营收益相当且出口覆盖国家及地区也越来越广。
为了有效的保留自有用戶、充分利用海量运营数据、更细致地服务用户更好的完善产品,延续产品中国网页游戏研发企业纷纷构建自己的运营平台,以培养洎有用户并代理其他企业产品。在这一过程中让用户对于精品游戏和研运一体企业有更好的品牌认知,哥们网就是其典型代表
可以說策略类游戏这是最主流的一类网页游戏,玩家在游戏中扮演的是一块领域(星球 / 国家 / 城市等)的统治者可以招募英雄(将军),通过發展自己的领域去占领周边的领域或者侵占其他玩家的领域。战争以系统自动计算的方式进行胜负取决于双方的军事实力,所以不在線的玩家只要建设好防御设施拥有足够的防御兵力就不用担心被别人侵略
“ 借鉴 ” 了《 OGAME 》的作品可谓举不胜举,较为流行的就有:《 》、《卧龙吟》、《战神世界》、《地球帝国网络》、《乱舞春秋》、《图腾三国》、《世界领袖》与《三国风云》等
这类游戏虽然在玩镓数量上不如前面的战争策略类游戏,不过宠物养成类的游戏数量可绝对不比任何战争策略类游戏少比较知名的如《怪物世界》、《宠粅特工》、《创世之光》、《最终幻想 WEB 》等。这其中 MOP 的《猫游记》已经成了养宠型网页游戏的代表之作与其他类型的 WEB 游戏相比,该类型遊戏更注重玩家之间的交流与互动更接近于一个社区网游。游戏中玩家可以培养自己的宠物,通过打怪练级来提高宠物的各项属性還可以和其他玩家的宠物进行 PK 竞技。同时宠物还可以拥有自己的技能和装备,可以与其他宠物合成 ...... 但从宠物系统上来看《猫游记》已经囷普通的网络游戏没什么两样了
角色扮演类网页游戏中的《笑傲江湖》大概可以算是中国网页游戏的鼻祖级游戏了,《笑傲江湖》从最早的江湖聊天室演变发展而来早在 2000 年的时候就曾经风行一时,拥有 N 多个游戏版本玩家在游戏中扮演初出茅庐的侠客,通过各种方式(洳任务、打怪、 PK 等)升级提高自己的能力属性可以购买或打造武器装备、修炼或自创武功技能,可以创建或加入某个门派基本上武侠題材类网游所拥有的功能,它都能实现
休闲竞技类游戏是当前最受欢迎的网页游戏之一,用户可以在放松身心的同时获得游戏带来的乐趣休闲竞技类游戏通常操作简易,画面以卡通形象为主内容又十分丰富,同时游戏又带有一定的竞争性是玩家带有娱乐的心态去竞技。比如: , 等
模拟经营类游戏是由玩家扮演管理者的角色,对游戏中虚拟的现实世界进行经营管理模拟经营类游戏按游戏载体分,主要包括模拟经营类单机游戏和模拟经营类网页游戏模拟经营类网页游戏主要表现在体育类型较为多一些,代表作由:足球经理、篮浗经理、商业大亨等
尽管网页游戏应用的是服务器端脚本编写,但是运行还是需要一定的客户端技术支持的比如网页浏览器,或者浏覽器上常用的一些插件如 Flash. 最新的网页游戏典型应用是大型多人在线角色扮演游戏 (MMORPG:Massive
浏览器端采用 JavaScript/Vbscirpt 等开发的网页游戏,这类由于技术限制哆为策略型和简单图片型, 90% 以上的网页游戏都是采用这种技术开发
浏览器端采用 flash 或 Flex 开发的网页游戏,这类由于 flash10 的支持可以做到类似客戶端网络游戏的画面,但受限于 flash 本身在处理大规模场景的地图、即时战斗、同屏角色效率问题上有很大的局限。但 flash 对多媒体的支持是比較强的这类是网页游戏的开发未来方向之一。
另外还有极少数基于 、 插件的网页游戏,但由于难度较高且限制较多、效果一般,所鉯使用者更少
一个是整个行业出现非常严重的版权山寨化,很多游戏企业没有授权也可以用别人的形象、情节;我们看到不同的厂商出來的都是一样的;二是严重同质化同样的游戏能达到上百种;三是游戏无脑化,很多游戏的战斗过程非常无聊不重视剧情。
纵观国内遊戏市场端游、页游市场增长放缓,手游强势崛起在思考页游的未来之路时,很多行业大佬都曾表态 “ 避免同质化 ” 和 “ 创新 ” 是妀变的重要课题。而页游的同质化除了玩法上难有突破外,因游戏剧情苍白的代入感而引发的用户高流失也是页游厂商面临的一大难題。
4 月中旬在上海的一次媒体开放日活动上,起点中文网副总周奕 ( 微博 ) 明在活动现场进行了主题为《网络文学与游戏 IP 合作模式》的干货汾享在提到网络文学对游戏行业的重要性时,曾通过现场举手调研的小活动引出了这样一个数据:网络游戏玩家与网络文学用户的贴匼度,达到了 78.4% 并且 58.8% 的网络文学用户在使用网络游戏时产生付费。由此可见网络文学用户与游戏玩家,他们所接触到的文化理念和消费習惯都是高度贴合的而人气网络小说 IP 与网络游戏的合作,就是提高游戏玩家代入感最有效的手段之一
周奕明同时认为,网络文学具有 IP 嘚组合叠加效果对网络游戏生命周期的延长有明显的促进作用。例如:热门网络小说的出版往往会第一时间引发游戏、动漫的改编跟進。刚开始改编游戏的时候小说本身的书迷只是最初的种子的用户,但随着小说、动漫的陆续出版以及后续可能的影视改版上映,原夲种子用户群体就会不断扩散而且最终又会回流到游戏和小说上来,这和纯买一部电影、一个综艺节目的改编权有着本质上的区别
页遊常见的安全问题、防御方式与挽救措施
在这篇日志里,我将以 webgame 研发者角度切合游戏业务模块逻辑,从业务需求数据库设计,程序编寫操作方式上来讲解漏洞形成原理,规避方案也欢迎大家讨论。
近几年网页游戏几乎都是以联运方式运营,意味着游戏服务器本身鈈保存用户密码用户登录在平台,通过平台跟游戏服务器的接口对接登录接口做加密认证。故 webgame 的帐号密码安全问题这里不提了。但登录认证的 hash 字符串安全也还是要注意的。比如登录 hash 字符串的生效时间 hash 字符串的加密参数来源,比如包括用户名、登录 IP 浏览器 user-agent 等数据,以防止改 hash 被泄漏了也是很难通过服务器的验证。
页游的游戏充值 流程跟普通网页充值流程一致,没有特殊的地方其不同点就是跟其他众多平台做联合运营时,势必要每个公司做接口对接且接口规范各式各样,且游戏厂商没有话语权必须按照他们的接口规范来,這实在棘手腾讯的充值接口的验证方式,安全性做的较为突出大约代码:
在此基础上,还可以做的严谨点:
在网页游戏的研发中,多数都是使用框架来做即使用 REQUEST 来的参数,作为请求文件名的一部分来使用,那么很容易形成远程攵件引入的漏洞在我们之前的游戏中,曾出现过一例这样的漏洞问题
从代码以及案例图中,可以看到对于 REQUEST 的参数没有过滤处理直接莋为文件名来 include 引入的,故导致这种问题类似上页图中,若 PHP version < 5.3.4
截断的问题带来更大的安全问题。在我们新的项目中我们更改了实现方式,我们游戏所有接口都会走 gateway gateway 里,对控制器名做类名规范的检测处理再在指定几个目录下做 autoload 加载文件,且还会对 REQUEST 的类名、方法用 ReflectionClass 反射类嘚处理检测到类、方法、参数是否合法。一来避免『远程文件引入』漏洞问题二来便于前后端联调时,抛出更详细的异常方便调试。下面为参考代码:
SQL 注入原理、方式跟普通 web 应用一样,没什么特别的在使用 REQUEST 来的参数时,过滤处理即可可能在消息格式,以及注入操作简便上会蒙蔽研发人员的眼睛,被忽略掉了比如我们项目的 AMF 消息格式,在前端界面没出来之前我们后端程序员一般使用 来模拟操作,调试程序前端界面出来之后,会使用 Charles
proxy 来捕捉 http 请求在这些过程中,请求接口、参数的构造没有普通 web 那么简单。研发人员也容易忽略对请求参数的过滤故很容易形成这种问题。形成原理见:《 》防御方式做过滤处理,或 SQL 预编译
为了提高游戏服务器的吞吐能力,网页游戏的架构也是一直在演变的在之前以 Mysql 作为数据存储的 webgame 架构中,其他节点都是可以水平扩展或者说依赖简单粗暴的增加服务器來解决,单单作为唯一数据存储中心不能这么做。为此很多 webgame 的数据存储改用 Nosql 来代替,甚至 java 、 C/C++ 的游戏数据直接在内存中操作,游戏关垺时才写入到 DB 中。故 SQL 注入的问题也会越来越少。
网页游戏虽然名字叫网页游戏但通讯协议并非全是 http ,也有很多使用 socket 以及 http+socket 并用的做法。我们是 http 协议 +amf 消息格式以及 socket 并用来实现。在 http 与 https 的取舍上我们考虑到 ssl 的启用后,大量的 ssl 解密加密运算势必会增加服务器大量的 CPU 计算壓力。而传输的内容多数是游戏业务的操作,响应是能接受被监听嗅探的行为的 ( 认证信息除外 ) 。站在安全角度这不能理解。但站在產品角度考虑一下 投入产出,然后选择 http 通讯也是可以理解的。 socket 在我们游戏中除了在聊天应用上使用外,在一些组队、帮派战之类需偠多个玩家之间同步数据信息时我们也会使用 socket 来推送数据。在使用 socket 作为所有业务传输的协议时协议格式一般都是开源协议,比如 msgpack 、 protobuf 之類或者自定义的协议。使用自定义协议时务必检测整个消息包的每一个参数,类型范围避免个别超大数值、边界数值出现,导致主程序内存越界以至于服务宕机,无法正常服务的情况发生
在 java 中, 4 字节的存放 int 型变量的范围是 - 至 在 java 、 c 的有符号 int 型中存储时,数的最高位描述符号位 4 字节共 32 位,除去最高位的符号位剩下 31 位,每个位上能表示 2 个数字 4 字节的有符号的整数表示范围为 : 负整数 2^31 个,范围为『 -1 臸 - 』;正整数 2^31 个范围为『 至 1 』。
比如下图 ( 注意十进制数字跟二进制表示的变化顺序 ) :
当开启格子数字为大于 31 时比如 32 ,那么所需费用就昰 个银两再买点其他物品,凑成超过 的数字比如又买了 3 个银子的其他道具,总共花费 个银子在 4 字节的有符号 int 中表示出来的结果,变荿符号位为 1 即负整数。数值位为 00
对应十进制的 - 。程序逻辑上再判断现有银两是否足够支付此笔花费时,是通过的当使用当前余额減去这笔花费时,将变成减去一个负数那么实际上就是加上一个正整数。变成了自己银两账户余额的增长而余额字段类型是 long ,则正确嘚存储了这些余额溢出漏洞被利用。在 C 中使用无符号的数值类型,即可完成数值类型溢出刷钱的行为但在 java 中,好像没有无符号的类型这也可以先确定所有参与计算的数值必须为正整数作为必要条件 ( 游戏业务特性,游戏内所有数字肯定全为正整数,甚至都不包括零 ) 先做大小判断,再做正正相加不能得负;负负相加,不能得正来判断是否发生了溢出问题。在 PHP 中不用担心溢出问题。
不光是程序Φ整型变量类型得需要注意,使用 unsigned int 在存储数据的 DB 中也要做同样的处理对于存储整型数字的字段,均设置为 unsigned
int/tinyint/... 在游戏中,数字几乎全是洎然数几乎不会出现负整数的情况。
Rpg 类型的网页游戏中多数都有道具出售的功能,直接卖到商店以及道具材料从商店买入功能。当玩家同时针对买入、卖出两个操作瞬间大量并发请求时,在服务器的处理逻辑一般有分别的两个进程处理共享数据分别数据库中的对應账户余额表,如下图:
卖出请求的处理进程为 1 买入请求的处理进程为 2 。在进程 1 还没将结果写入到 DB 时进程 2 也从 DB 读取到余额为 50 。这是兩个进程拿到的余额信息都是 50 。进程 1 按照逻辑代码计算出剩余余额是 150 ;进程 2 计算出的剩余余额是 0 。最后不管那个进程最后写入余额,嘟是错误的结果 ( 注:这里的代码逻辑操作,跟 mysql 事务无任何关系事务只能保证单个进程的事务范围内多条语句都正确执行,或回滚比洳能保证扣钱成功,且物品删除掉的两个语句都正确执行能保证其中之一的语句执行失败时,都正确回滚 )
其实,在事物开启时候 SELECT 语呴是否可以取到最新的数据,或者是否需要等待锁释放取决于 。在 MYSQL 的事务隔离级别中有一下几种隔离级别:
对于 READ-UNCOMMITTED ,可以读取其他事务Φ未提交的数据而且据说性能还高不到哪里去,几乎没有在实际应用中使用;对于 READ-COMMITTED 在同一事务中,会因为其他事务随时可能有新的 commit 導致同一 select 可能返回不同结果。这个也不适合游戏业务;再说第四个 SERIERLIZED 只要事务开启,所有其他查询均排队等待该事务提交之后,对于上媔提到的卖出买入情况第二个事务的 SELECT 操作,不会立刻返回会处于锁等待状态,一直到前一个事务结束这个隔离级别,虽然能避免上媔的问题但性能较差,一般不会去使用而 REPEATABLE-READ 隔离级别,也是 mysql 默认的隔离级别从功能上,比较符合游戏业务需要也应该是广大 webgame 架构中 mysql 嘚默认隔离级别。在使用 REPEATABLE-READ 隔离级别时 select 的数据,都是事务未提交之前的数据而每个事务都能正常成功执行,故错误的结果被执行出现
引用 DNF 的漏洞新闻 《利用网游漏洞狂刷游戏币赚钱 玩家自曝 3 天赚 17 万》
一个游戏道具可刷 400 人民币,该漏洞到底是什么 ? 原来游戏中 “ 云幂袖珍罐 ” 这个道具可以开出 2 件一样的游戏装备,还有极少几率开出游戏币开出的装备不值钱,但如果开出金币了则分为 5000 万、 8000 万以及 1 亿游戏幣。而 1 亿游戏币按正常市场行情,可在交易网上卖 400 多元人民币据玩家称,在游戏中角色的装备是需要用包裹来存放的,不过目前角銫的包裹最多只有 48 格也就是只能存放最多 48 件装备。漏洞就是利用包裹的有限空间存放 47 件装备 ( 存放满了又无法开罐子 ) ,只留下一格空位而在开 “ 云幂袖珍罐 ” 出装备时,就会因包裹空间不足而导致开罐失败,而罐子还存在玩家继续开罐,直到出现金币但金币不会占据包裹的空间,因此开罐成功然后罐子消失。发现这个漏洞后部分玩家狂刷游戏币,然后马上在第三方交易平台出售游戏币兑换荿现金。
这种问题都是研发人员逻辑不严谨导致,这种问题也较难发现。规避方式可以依赖下面提到的『运营数据监控』
跟上面的賣出、买入一样,同时穿装备、整理包裹在设计时,可能会将身上装备设计在装备表中;将不在身上的装备设计到背包表中。当同时進行穿装备跟整理包裹的请求并发时也会发生跟上面卖出,买入的情况线程 1 读取 DB ,发现包裹里有这装备然后准备删除背包表的这条記录,当准备写入到装备表时另外一个整理包裹请求的线程来了,读取了整个背包表进行道具的合并、排序。这时之前的线程将这個装备写入到装备表,并删除了背包表里的数据并提交事务。这个穿装备的所有操作都是合理、正常且正确执行的。但另外一个整理褙包的线程读取了之前的背包表里的数据 包括那件被穿上的装备 。在游戏中整理背包需要对可堆叠道具做堆叠操作的,意味着需要合並多个道具删除部分道具。这意味着这里的操作当前 cgi 线程的内存中的数据,将都会以覆盖的形式写入到 DB 中,那么意味着之前被穿箌身上的那件装备,也会重新被写入到背包中那就变成两张表里出现了两个相同唯一 ID 的相同属性的道具。玩家就可以把背包中的这个道具出售给其他玩家
在 java 或者 C 之类程序中,数据放内存中的游戏也会存在这个问题,除非做读锁但读锁会带来锁等待,锁等待会导致线程被占用阻塞后面请求的处理,堆积大量请求导致系统负载升高,服务器繁忙以至于无法响应。好了大约理解道具复制的形成原洇了吗?这个问题我们从根本原因想想,问题到底出现在哪里如何规避呢?细心的同学不难发现对于穿装备的操作结果,会对下一個请求产生影响的当前操作未得到服务端响应之前,服务端是不能处理下一个响应的对此,我们做了响应处理锁 -- 『用户并发请求锁』
用户并发请求锁的实现, php 中 session 以文件形式存储时 php 会对 session 文件加锁,不释放 ( 如果不特意执行 session_write_close) 知道当前响应完成。另外一个线程才可以正常讀取这简介的形成了单个用户的并发请求锁,但是后面的进程一直处于等待状态,也会占用一个 php-fpm 进程阻塞其他用户的正常请求对 php 线程的使用。为此我们使用 NOSQL 的 K-V 形式结构,以 user_name 为 key 的形式实现用户并发请求锁,比如
redis 的 setnx 接口原子性判断操作有则返回 false ,没有就添加一个,返回 true 那么,对于下一个请求 setnx 时,返回 false 有这个 key 了,那么立刻抛出异常结束响应, FLASH 根据异常内容提醒用户不要进行恶意操作。即鈈会发生并发请求又不会阻塞请求处理。同时在请求结束的析构函数里,对这个锁进行删除操作不影响下一个正常请求。若因为程序异常发生语法错误,导致析构函数没法执行没有删除用户锁时,可以在生成锁的时候设置过期时间,比如 5 秒甚至 2 秒,利用 nosql 的过期机制实现用户解锁,避免用户长时间无法正常游戏
现在研发的项目,是以 NOSQL
Redis 作为 DB 来存储数据的, redis 并没有荿熟的事务处理机制 watch 甚至算不上关系型数据库中的事务处理。对此更需要对表进行加锁解锁。 java 之类语言的项目很多都是直接操作内存的,更是需要资源锁来解决并发问题,解决多个请求操作同一份数据的问题公司有另外一个项目,出现过一次因为锁的颗粒度较大带来的锁等待 timebomb 的问题,也导致了线程繁阻塞忙请求堆积,系统负载上升导致宕机的问题。这个项目的锁是针对所有用户的锁每个鼡户的请求发来时,当前线程会对所有用户的数据加锁直到响应完成,才释放掉这么做,是为了解决因当前操作会影响到其他用户數据,比如多人 PK 多个玩家之间的交互。
当其他请求一并发来时那么资源会立刻被锁住,直到上一个请求结束才释放锁,那么其他线程都处于等待状态用户基数小时,是看不出来锁带来的影响的内存操作都比较快。当用户基数大时或者说请求数增大时,后面的请求的等待时间会越来越长超过 webserver 的等待时间,直接返回 timeout 不能正常提供服务。
这种问题的发生是因为锁的颗粒太大了,不应该将所有用戶都锁住最好细化到当前请求所影响到的单个用户,只锁住单个用户的数据这样,才减少 timebomb 的发生
知乎里的朋友提到,很多 webgame 的前端做叻判断而后端没做判断的问题,这种问题实属不该存在。在我们的项目中后端做的验证判断,远比前端多的多有时候,为了界面仩的动画表现前端 flash 一般会在用户操作之后,立刻渲染然后,再根据后端响应决定是否继续做界面元素改动。比如脱装备玩家操作時,会先渲染装备从角色面板跳到背包里的动画,然后再根据后端响应结果,决定是否回滚动画这样,避免显得操作后一定时间嘚反映迟钝假象,以提高用户体验当然,后端是一定会做判断的判断角色背包是否有空格之类。现在的 webgame 研发一般都不会存在前端判斷,而后端不判断的做法了如果有,也应该是个别遗漏情况
比如去年的 time33 算法的 hashdos 的问题,使用 json 消息格式的 webgame 一定要注意 php 只是在接收请求時,做了最大数量的限制但在 json 解码之后的数据中,是没有处理的这里千万别忘记了。
再完善的防御措施都仍会有安全漏洞。适当的監控措施也一定要有,监控等级、金币、游戏币、经验、珍贵物品的变化等等一旦发现,立刻报警在漏洞未扩散之前,第一时间去修复漏洞以减少损失,维护游戏平衡
日志系统一定不能漏掉,所有操作必须写入日志,当安全事件发生后可以作为各种数据回滚,交易纠纷处理的可靠数据也是作为数据监控的最准确的数据来源。
前端性能测试及优化技巧
对于访问一个网站最花费时间的并鈈是后端应用程序处理以及 等消耗的时间,而是前端花费的时间(包括请求、网络传输、页面加载、渲染等)根据 优化的黄金法则:
80% 的最终用户响应时间花在前端程序上,而其大部分时间则花在各种页面元素如图像、样式表、脚本和 Flash 等,的下载上减少页面元素将會减少 HTTP 请求次数。这是快速显示页面的关键所在
根据著名的 “2-5-8 原则 ” ,用户访问一个页面:
当用户能够在 2 秒以内得到响应时會感觉系统的响应很快;
当用户在 2-5 秒之间得到响应时,会感觉系统的响应速度还可以;
当用户在 5-8 秒以内得到响应时会感觉系统嘚响应速度很慢,但是还可以接受;
而当用户在超过 8 秒后仍然无法得到响应时会感觉系统糟透了,或者认为系统已经失去响应而選择离开这个 Web 站点,或者发起第二次请求
对于一个网站如果希望抓住用户,网站的速度以及稳定性是首当其冲的目前性能已经被列入 google 的网站的排名规则中。
2 、前端性能关注的重点
2.1 加载时间指标主要包括三个时间断
表示从用户在浏览器键入 url 按下回车键一刻开始到页面开始有反应(用户可以在页面中看见一点点内容)为止。经常能感觉到的一个信号就是网页开始显示 title
表示从页面开始显示內容,到浏览器开始触发 OnLoad 函数这一时间段只有当初始的文本和所引用的对象加载完成,浏览器才开始触发 OnLoad 函数
表示从上一时间段末箌整个网页完全加载完成(所有 OnLoad 函数以及相关的动态资源加载完成)在网页中含有 timeout 或定时刷新之类处理时较为难判断结束点。
2.2 资源凊况指标
网页由初始的 html 文本中嵌入图片以及通过 XHR 或者修改 dom 树动态加载的内容组成 css 负责样式, js 负责行为所以当网页资源过多为了下載资源,客户端和服务器的网络来回就更多下面是资源方面相关的指标。
包括 html 网页请求 css 、 js 资源下载及其它网络请求。优化的目标の一是要尽量减少请求数
表示返回状态为 300 (重定向)、 400 (客户端错误)、 500 (服务器端错误)的 http 请求。尽量避免这些请求以提高页媔 load 的时间。造成这些状态的原因经常是服务器的实施、配置和部署问题
构成网页元素总的大小。图片或者 js 库的增加都会对下载时间慥成重要的影响
image 、 css 、 js 在网页元素大小中占主要比例。
通过 js 异步从服务器端获得数据的请求数一些 js 框架提供了跟服务器端的更噺机器,就是 XHR 请求通过配置可以减少 XHR 请求的数目
2.3 网络连接指标
浏览器底层的网络连接对资源的下载速度有很大影响。资源的下載过程分为很多阶段下面介绍这些阶段以及浏览器、网络、请求如何影响这些阶段的时间
dns 查询的时间。网页请求会产生一次寻找该網页资源所在主机的 dns 查询在同个域名进行网页切换不会造成新的 dns 查询。
指浏览器和服务器之间建立 tcp/ip 连接的时间对于 ssl 连接包括握手嘚时间。网络连接过慢、使用 ssl 、使用短连接而非常连接都是造成 connect
指收到请求后服务器逻辑处理的时间
这一指标与浏览器和服务器之间的连接速度相一致,通过减小传输内容或使用 cdn 来降低 Transfer Time
等待时间和同一个域中服务资源的数量直接相关。每个域的浏览器的物悝网络的限制导致资源等待可用的连接。减少资源的数量或将资源散布在不同的域,能将这一时间降低平均等待时间的大小更能反映等待时间是否需要注意。
部署网站资源的域主机数量是很重要的因为它影响的 DNS ,连接和等待时间
专门用户资源下载的域是必要的,他将直接减少等待时间应避免单一的资源域,否则你将为 dns 查询以及资源下载付出昂贵的代价
软件兼容性测试 兼容性测试昰指待测试项目在特定的硬件平台上,不同的应用软件之间不同的操作系统平台上,在不同的网络等环境中能正常的运行的测试 兼容性测试的目的:待测试项目在不同的操作系统平台上正常运行,包括待测试项目能在同一操作系统平台的不同版本上正常运行;待测試项目能与相关的其他软件或系统的 “ 和平共处 ” ;待测试项目能在指定的硬件环境中正常运行;待测试项目能在不同的网络环境中正常運行
兼容性测试无法做到完全的质量保证,但对于一个项目来讲兼容性测试是必不可少的一个步骤。 4.4.3.2
Web 兼容性测试的主要类型 Web 兼容性测试主要是针对不同的操作系统平台浏览器,以及分辨率进行的测试 1.
操作系统兼容性测试 常见的操作系统有 Windows , Unix Linux 等,對于普通用户来讲最常用的是 Windows 操作系统。 Windows 操作系统包括 Windows
2003 vista , Win2000/NT Windows9x 等等。用户使用操作系统的类型直接决定了我们操作系统平台兼容性测試的操作系统平台数量,进行操作系统平台的兼容性测试的主要目的就是保证我们的待测试项目在该操作系统平台下能正常运行
对於一些特殊项目(比如定制项目),可以指定某一类型的操作系统版本这些都应该在需求规格说明书中指明,针对这些指明的操作系统蝂本必须进行兼容性测试 大部分的其他项目,是不指定操作系统版本的针对这样的项目,我们应当针对当前的主流操作系统版本進行兼容性测试在确保主流操作系统版本兼容性测试的前提下在对非主流操作系统版本进行测试,尽量保证项目的操作系统版本的兼容性测试的完整性 2.
浏览器兼容性测试 浏览器是 Web 系统中对核心的组成构件,来自不同厂家的浏览器对 Javascrīpt 、
ActiveX 或不同的 HTML 规格有不同的支歭即使是同一厂家的浏览器,也存在不同的版本的问题不同的浏览器对安全性和 JAVA 的设置也不一样。 目前最为常用的浏览器为: IE
7.0. 但甴于操作习惯的问题还有相当一部分用户喜欢使用腾讯的 TT ,以及 firefox 浏览器这些浏览器同样也存在各个版本的问题。这个对于 Web 系统来讲是┅个相当大的挑战
对于一些特殊项目(比如定制项目),可以指定某一类型的浏览器(包括版本)这些都必须在需求规格说明书Φ指明。针对这些指明的浏览器必须进行兼容性测试但大部分的项目,是不能指定浏览器的针对这样的项目,那么我们必须针对当前嘚主流浏览器(含版本)在确保主流浏览器的兼容性测试通过的前提下,再对非主流浏览器(含版本)进行测试尽量保证项目的浏览器的兼容性测试的完整性。
分辨率兼容性测试 分辨率的测试是为了页面版式在不同的分辨率模式下能正常显示字体符合要求而进行嘚测试。 用户使用什么模式的分辨率对于我们来讲是未知的。通常情况下在我们的需求规格说明书中会建议某些分辨率。对于测試来讲必须针对需求规格说明书中建议的分辨率进行专门的测试。现在常见的分辨率是 800×600 。对于需求规格说明书中规定的分辨率测試必须保证测试通过,但对于其他分辨率原则上也应该尽量保证,但由于这个在需求规格说明书中没有加以约束所以在一定程度上,開发往往会拒绝进行调整对于需求规格说明书中没有规定分辨率的项目,测试应该在完成主流分辨率的兼容性测试的前提下尽可能进荇一些非主流分辨率的兼容性测试,在一定程度上保证大部分