这两周那是忙的天昏地暗。都是些琐碎的事情，两个项目的。理理代码，发发邮件，打打电话，改改 bug ，开开会，签签字，写写报告。周末也加了一天班，工作居然是安装一个论坛系统，外加修改 css ，以及修改模板，调整版面。没办法，时间紧，人手少。
btw, 在服务器上装 php 时，因为开始 ports 没有更新，出了好多问题。mysql 一开始忘记装 gbk 的支持，困扰我老半天。鄙视一下公司购买的某著名 php 写的论坛系统，居然默认不是用 utf-8 编码的。
闲话扯到这里，今天想谈一下上月底，四年逢一次的好日子里，我们公司憋了好久的《天下2》终于又一次体验测试的事情。
这篇 blog 的内容原本是去年 10 月写的，当时正在看《24小时反恐》，脑子里涌现出无数古怪的想法，觉得这个世界到处都是特工，什么通讯手段都不可靠。在我们还没有能力获得量子加密需要的硬件前，能有限依靠的恐怕只有数学能保证的加密技术。
当时那篇 blog 写了一大篇，自己都觉得太过于天马行空的乱扯，就没有公开。
不过今天开周会，我们又提到游戏 client 提交密码的安全性问题，指派了一个同事最近在这方面做些工作，这里也写点以前研究的东西，留点记录吧。
简单说，我们应该避免在一次登陆过程中从互联网连接中传递明文的用户名密码信息。这是一个起码的要求，但是我们以往的产品做的并不好。很多时候都是伪加密。就是 client 用个私有算法将密码信息编码后传送，再由 server 用相同的算法还原。
这个安全性极度依赖 client 的程序不被逆向工程。一旦有人完全逆向工程后，只需要他监听到通讯，就可以还原出用户的密码。
物理上防止通讯被监听的技术在可见的时间内几乎不可能被大众使用，我们现在即使能保证自己的 client 机器没有被人动过手脚，还是无法知道自己的通讯数据是否被监听。只能寄希望于数学的加密技术了。
SSL 就是干这个的，但是由于种种原因，暂时我们还不能在游戏 client/server 中推行使用。那么，现在是不是可以抽出一些东西来，自己先在程序中实现出来用着。其实，优先要做到的，无非是安全的让用户提交用户名密码而已。
我曾多次在 Blog 上讨论过增强游戏客户端的登陆安全问题。这个问题仅靠软件手段之所以难以从根本上解决，是因为现在国内的网络安全环境实在是太差，我们无法确保用户的机器上没有木马。
游戏客户端面临的问题更加严重。受经济利益趋势，几乎所有的热门游戏都有无数针对性木马泛滥。用户很难保证他每天运行的游戏客户端有没有被恶意程序修改过。（修改不仅包括直接对硬盘上的客户端程序做永久性修改，还包括使用内存黑客程序动态修改运行时代码）
我们几乎做不到让 client 程序自检，确保自己没被动过手脚。
周末又一次想到这个问题时，突然想到，其实最不容易被伪造的 client 软件其实就是最容易被动手脚的浏览器。虽然像 IE 这样存在很多安全问题的浏览器，会被无缘无故的插上诸多恶意插件。但不可否认，木马想骗过浏览器截取到其中的特定传输内容还是颇不容易的：大多数恶意插件都会很快被检查出来。毕竟这个是现在反木马病毒软件全力去做的事情。而且想伪造一个浏览器上的登陆过程比伪造一个游戏 Client 的登陆过程技术上要困难的多。
如果我们让游戏登陆时，启动浏览器，用 https 协议连接登陆服务器去通过身份认证。然后用服务器返回的 session key 来启动游戏 client 进入游戏。这个登陆过程可能更加安全。（由于 SSL 的技术保障，这个过程也可以防止 ARP 欺骗导致的密码把监听）
网易的所有产品都使用网易通行证系统做用户身份认证，包括游戏产品。
这是降低新产品用户门槛的好方法。几乎所有的网络服务提供商都弄了个自己的统一用户认证系统，网易通行证也是干的这挡子事，内部我们把这套系统简称为 URS。公司在 URS 系统上投入了很多人力和资源，但是其表现总是跟不上我们的需求。我个人从 03 年开始就不断的在提一些安全方面的改进建议。但是由于这些系统涉及面太广，想做出些实质性的改变举步维艰。
不断的写建议书，不断的参与北京 URS 部门的技术会议，让我充分理解了他们的困难，和其中许多非技术难点的难处。
但是，国内糟糕的网络安全环境，日益严重的游戏帐号失窃问题，让我不得不时常关注这方面的问题。最近，又想了个改进方案，希望可以有所改善安全问题。
网络游戏世界的构建有越来越大的趋势，游戏设计者希望更多的人可以发生互动。技术人员的工作就是满足这些越来越 BT 的需求。
我们目前这个项目由于是自己主导设计，而我本人又是技术方案的设计者。所以，技术解决不了的问题就不能乱发牢骚了。作为游戏设计者，我希望整个游戏世界的参于者可以在一个唯一的大世界中生存，他们永远有发生互动的可能。注意这里只是保留这种可能性，实际上，即使是现实社会，每个人的社交圈子都不大。即使是千军万马的战场上，无论是将军还是士兵，都不需要直接跟太多人互动。
我们的游戏的技术解决方案仍旧是将游戏大世界分成若干独立服务器组，人为的将人群切分成更小的独立单位。这里，技术上需要解决的是：服务器组间可以灵活的交换数据。
游戏服务器在设计时，会有许多组播的需求。比如一个 NPC 需要向周围的观察者播出它的状态信息。无出不在的各种聊天频道中需要向频道中的参于者广播聊天消息等。
通常，我们会为每个组播的请求维护一张列表，然后再把需要的信息包发送给指定列表上的多个连接。这个过程在很多地方都会遇到，一个设计的不太好的引擎，再这里有可能滋生诸多 bug 。尤其在多服务器的设计时尤其如此。
这两天，我试图寻找一种简洁统一的解决方案。
最近在考虑为一组游戏服务器配置多个连接入口。这个需求来至于我们的国情。作为大的游戏运营商，势必要考虑国内的网络状况——南北不通的现状。以往别的公司的代理游戏，由于不是自己开发，都选择了一个实际的方案：在北网通和南电信各放若干组服务器。北边来的在北边玩，南方住的安居在南方。
我们的游戏却不行，因为我需要一个完整的大世界，必须解决南北互通的问题。据我所知国内运营的游戏 EVE 是比较好解决了这个问题的。
我们自己的游戏大多也解决了，只是宣传上还是鼓励玩家登陆相应的服务器。我们的解决方案本质上很简单。建立有多个出口的机房，同时拥有电信和网通的线路。或是用自己的线路互联电信和网通的机器。这后者普通用户自己在家也可以做，只要你肯花钱，同时购买电信的 ADSL 于网通的宽带即可。目前许多城市两者都向大众提供服务。
当然，最终我们还是需要编写服务器的程序员做一些配合。
当游戏服务器群达到一定规模后，让用户只从一个入口连入会给这个入口带来很大的压力。这样，我们就需要让服务器群中的多台机器都允许用户直接连接。
当服务器开放给用户直接登陆后，必须面临的一个问题就是用户身份认证的问题。
大多数提供网络服务的公司都做了一套统一的用户认证系统，比如微软的 passport ，网易的通行证，等等。为了避免重复验证用户身份而给用户认证系统带来过大的负担，云风在这里给出一个参考解决方案。
今天研究 wow 时候发现，他 cache 了很多的信息。我们可以在 WDB 目录下找到这些 cache 文件。没有仔细去研究这些文件到底放了些什么，但是由此却想到一些东西。
我们在做 mmo 的服务器的时候，有些信息，数据量很大，却并非经常变动。比如物品的细节描述，工会/帮派信息，甚至还有好友列表等等。在 IM 软件中， cache 住朋友列表到本地硬盘是很常用的手法，不过我参与的几个 MMO 项目都没有这样做。
其实，这些不易变的信息，在 client 需要获取的时候，只需要在请求协议中加入一个自己 cache 的信息包的校验值过去就可以了。server 校对自己一方的校验值，当判断与 client 相同的时候，就不需要重发这些信息了。
很多信息都可以如法炮制，扩展开看，还可以是 npc 对话，任务描述等等。
这两天研究了一下 lzw 压缩算法，据说它专利已经过期了，那么应该可以随便用了吧。
这种基于字典的压缩算法，一个很大的优势就是，如果数据流中经常出现同一个词，那么会被极大的压缩掉。重复性的信息在网络游戏中经常碰到，不过是基于包和包之间的，而不是同一个包之内的。游戏又跟别的应用不太一样，我们往往希望更快的把数据交到对方，减少网络的延迟，所以大多数情况下，我们不会积攒很多数据一起发送。所以，不能简单的以每个数据包为单位调用压缩器。
最近有个小项目，很快的开始，似乎也能很快的完工。就一个不大不小的游戏，2d 的，图象引擎是成熟的，然后我就这这段日子对 lua 的热情，用 lua 把原来写的 C++ 图象引擎做了个封装。用起来感觉良好，UI 部分封装的也不错。游戏逻辑用 lua 驱动貌似很方便。一度幻想着哪天把它开源出去，没准可以成为 lua 开发 2d 游戏的准标准。想想可能性不大，纯当意淫了。
小项目比较能锻炼队伍，所以我做为基本封装就跟新同事上课了。看着别人做程序心里痒痒的，做不出来急急的。恨不得什么都自己代劳。
其中一个同事的工作安排是网络协议的封装，争取用 lua 封装的好用一些。
我最近在构思一个用 P2P 网络同步文件的计划。用于以后网络游戏的 client 同步更新。现有的 BT 之类的软件很成熟了，不过我考虑到网络游戏有其特殊性，说不定可以做的更好。
网络游戏可以说有一个天然的稳定的 p2p 网络的基础，好象我们的梦幻西游，最高已经超过八十万玩家同时在线了。而所有玩家所需求的是同一份 client。这跟 BT 网络上传输文件的需求和环境都不太相同。