在游戏服务器开发中, 网络通信是很关键的, 而在网络通信中,数据的同步是关键, 在我的上一篇博客(
http://www.cppblog.com/zhengxf/archive/2010/07/08/119737.html)中谈的了数据如何同步的问题, 其中提到了两点 1.数据发送给谁. 2.网络延迟的话,如何同步.
上次主要谈了网络延迟时的同步问题,今天我们主要谈论数据发送给谁的问题, 要谈论这个问题,我们就不的不谈论: 地图, NPC, 玩家他们三个之间的关系.
其实地图是个静态的数据集合, 其中主要包含了地形信息和物品信息,这里的物品指的是静态的,所以它是不需要进行同步的,也就是每个玩家在同一个地图上看到信息是一样的,所以这些信息有客户端的场景管理器管理. 不进行网络通信.
NPC: NPC主要分两种 一种是静态的NPC,如玩家获取任务的NPC, 另外玩家升级打的怪, 也是NPC. 静态的NPC有属性和功能,但不需要同步, 动态的NPC(如怪)需要进行网络同步,这里我们就有一个问题, 动态的NPC要将它的信息发送给谁呢?任何一个涉及到网络通信的NPC和玩家都有一个共同的性质就是它有可见范围,假如说一个玩家在十米范围内可见,那么他就回将信息发送给距离十米以内的玩家和NPC, 这里有含有两个问题: 一: 十米以外的NPC怎么办, 二:怎么获取十米以内的发送用户。有两种解决办法:一是在场景中搜索找到要发送的用户信息,告诉服务器让服务器来发,二是发送自己的信息到服务器,服务器搜索NPC列表,和玩家列表,来发送,我觉的后着更合理。
玩家: 玩家的同步主要是玩家和玩家的同步, 如玩家每前进一步, 就向服务器发一条消息. 服务器在玩家列表中查找到范围之内的其他玩家信息,并发送消息,这里有一个问题,是玩家要不要将消息发送给NPC?因为这种NPC也可以理解为机器人,它可以感知到敌人就在附近, 本身就在服务上, 所以不用发送消息, 但是NPC在感受到玩家的时候要向它(NPC) 可见范围内的玩家发送消息.
接下来还有一个问题,是发送什么样的消息的问题,因为针对NPC,和玩家,并不是所有的消息都发,而是有选择向的发,这个问题我们下次讨论。
__stdcall和__cdecl两者的区别;
#define CALLBACK __stdcall
#define WINAPI __stdcall
#define WINAPIV __cdecl
#define APIENTRY WINAPI
#define APIPRIVATE __stdcall
#define PASCAL __stdcall
#define cdecl _cdecl
#ifndef CDECL
#define CDECL _cdecl
#endif
几乎我们写的每一个WINDOWS API函数都是__stdcall类型的,首先,需要了解两者之间的区别: WINDOWS的函数调用时需要用到栈(STACK,一种先入后出的存储结构)。当函数调用完成后,栈需要清除,这里就是问题的关键,如何清除??如果我们的函数使用了_cdecl,那么栈的清除工作是由调用者,用COM的术语来讲就是客户来完成的。这样带来了一个棘手的问题,不同的编译器产生栈的方式不尽相同,那么调用者能否正常的完成清除工作呢?答案是不能。如果使用__stdcall,上面的问题就解决了,函数自己解决清除工作。所以,在跨(开发)平台的调用中,我们都使用__stdcall(虽然有时是以 WINAPI的样子出现)。那么为什么还需要_cdecl呢?当我们遇到这样的函数如fprintf()它的参数是可变的,不定长的,被调用者事先无法知道参数的长度,事后的清除工作也无法正常的进行,因此,这种情况我们只能使用_cdecl。到这里我们有一个结论,如果你的程序中没有涉及可变参数,最好使用__stdcall关键字。
2.
__cdecl,__stdcall是声明的函数调用协议.主要是传参和弹栈方面的不同.一般c++用的是__cdecl,windows里大都用的是__stdcall(API)
__cdecl 是C/C++和MFC程序默认使用的调用约定,也可以在函数声明时加上__cdecl关键字来手工指定。采用__cdecl约定时,函数参数按照从右到左的顺序入栈,并且由调用函数者把参数弹出栈以清理堆栈。因此,实现可变参数的函数只能使用该调用约定。由于每一个使用__cdecl约定的函数都要包含清理堆栈的代码,所以产生的可执行文件大小会比较大。__cdecl可以写成_cdecl。
__stdcall调用约定用于调用Win32 API函数。采用__stdcall约定时,函数参数按照从右到左的顺序入栈,被调用的函数在返回前清理传送参数的栈,函数参数个数固定。由于函数体本身知道传进来的参数个数,因此被调用的函数可以在返回前用一条ret n指令直接清理传递参数的堆栈。__stdcall可以写成_stdcall。
__fastcall 约定用于对性能要求非常高的场合。__fastcall约定将函数的从左边开始的两个大小不大于4个字节(DWORD)的参数分别放在ECX和EDX寄存器,其余的参数仍旧自右向左压栈传送,被调用的函数在返回前清理传送参数的堆栈。__fastcall可以写成_fastcall
3.
__stdcall:
_stdcall 调用约定相当于16位动态库中经常使用的PASCAL调用约定。
在32位的VC++5.0中PASCAL调用约定不再被支持(实际上它已被定义为 __stdcall。除了__pascal外,__fortran和__syscall也不被支持),取而代之的是__stdcall调用约定。两者实质上是一致的,即函数的参数自右向左通过栈传递,被调用的函数在返回前清理传送参数的内存栈,但不同的是函数名的修饰部分(关于函数名的修饰部分在后面将详细说明)。
_stdcall是Pascal程序的缺省调用方式,通常用于Win32 Api中,函数采用从右到左的压栈方式,自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀,在函数名后加上"@"和参数的字节数。
_cdecl:
_cdecl c调用约定, 按从右至左的顺序压参数入栈,由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的(正因为如此,实现可变参数的函数只能使用该调用约定)。另外,在函数名修饰约定方面也有所不同。
_cdecl是C和C++程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码,所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。
__fastcall:
__fastcall调用约定是"人"如其名,它的主要特点就是快,因为它是通过寄存器来传送参数的(实际上,它用ECX和EDX传送前两个双字(DWORD)或更小的参数,剩下的参数仍旧自右向左压栈传送,被调用的函数在返回前清理传送参数的内存栈),在函数名修饰约定方面,它和前两者均不同。
_fastcall方式的函数采用寄存器传递参数,VC将函数编译后会在函数名前面加上"@"前缀,在函数名后加上"@"和参数的字节数。
thiscall:
thiscall仅仅应用于"C++"成员函数。this指针存放于CX寄存器,参数从右到左压。thiscall不是关键词,因此不能被程序员指定。
naked call:
采用1-4的调用约定时,如果必要的话,进入函数时编译器会产生代码来保存ESI,EDI,EBX,EBP寄存器,退出函数时则产生代码恢复这些寄存器的内容。
naked call不产生这样的代码。naked call不是类型修饰符,故必须和_declspec共同使用。
另附:
关键字 __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前,也可以在编译环境的Setting...\C/C++ \Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时,直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、 /Gd和/Gr。缺省状态为/Gd,即__cdecl。
要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定,至于函数名修饰约定,可以通过其它方法模仿。还有一个值得一提的是WINAPI宏,Windows.h支持该宏,它可以将出函数翻译成适当的调用约定,在WIN32中,它被定义为__stdcall。使用WINAPI宏可以创建自己的APIs。
名字修饰约定
1、修饰名(Decoration name)
“C” 或者“C++”函数在内部(编译和链接)通过修饰名识别。修饰名是编译器在编译函数定义或者原型时生成的字符串。有些情况下使用函数的修饰名是必要的,如在模块定义文件里头指定输出“C++”重载函数、构造函数、析构函数,又如在汇编代码里调用“C””或“C++”函数等。
修饰名由函数名、类名、调用约定、返回类型、参数等共同决定。
2、名字修饰约定随调用约定和编译种类(C或C++)的不同而变化。函数名修饰约定随编译种类和调用约定的不同而不同,下面分别说明。
a、C编译时函数名修饰约定规则:
__cdecl调用约定仅在输出函数名前加上一个下划线前缀,格式为_functionname。
__fastcall调用约定在输出函数名前加上一个“@”符号,后面也是一个“@”符号和其参数的字节数,格式为@functionname@number。
它们均不改变输出函数名中的字符大小写,这和PASCAL调用约定不同,PASCAL约定输出的函数名无任何修饰且全部大写。
b、C++编译时函数名修饰约定规则:
__stdcall调用约定:
1、以“?”标识函数名的开始,后跟函数名;
2、函数名后面以
“@@YG”标识参数表的开始,后跟参数表;
3、参数表以代号表示:
X--void ,
D--char,
E--unsigned char,
F--short,
H--int,
I--unsigned int,
J--long,
K--unsigned long,
M--float,
N--double,
_N--bool,
....
PA--表示指针,后面的代号表明指针类型,如果相同类型的指针连续出现,以“0”代替,一个“0”代表一次重复;
4、参数表的第一项为该函数的返回值类型,其后依次为参数的数据类型,指针标识在其所指数据类型前;
5、参数表后以
“@Z”标识整个名字的结束,如果该函数无参数,则以“Z”标识结束。
__cdecl调用约定:
规则同上面的_stdcall调用约定,只是参数表的开始标识由上面的
“@@YG”变为
“@@YA”。
__fastcall调用约定:
规则同上面的_stdcall调用约定,只是参数表的开始标识由上面的
“@@YG”变为
“@@YI”。
VC++对函数的省缺声明是“__cedcl“,将只能被C/C++调用.
CB在输出函数声明时使用4种修饰符号
//__cdecl
cb的默认值,它会在输出函数名前加_,并保留此函数名不变,参数按照从右到左的顺序依次传递给栈,也可以写成_cdecl和cdecl形式。
//__fastcall
她修饰的函数的参数将尽肯呢感地使用寄存器来处理,其函数名前加@,参数按照从左到右的顺序压栈;
//__pascal
它说明的函数名使用Pascal格式的命名约定。这时函数名全部大写。参数按照从左到右的顺序压栈;
//__stdcall
使用标准约定的函数名。函数名不会改变。使用__stdcall修饰时。参数按照由右到左的顺序压栈,也可以是_stdcall;
VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用.
注意:
1、_beginthread需要__cdecl的线程函数地址,_beginthreadex和CreateThread需要__stdcall的线程函数地址。
2、一般WIN32的函数都是__stdcall。而且在Windef.h中有如下的定义:
#define CALLBACK __stdcall
#define WINAPI __stdcall
3、extern "C" _declspec(dllexport) int __cdecl Add(int a, int b);
typedef int (__cdecl*FunPointer)(int a, int b);
修饰符的书写顺序如上。
4、extern "C"的作用:如果Add(int a, int b)是在c语言编译器编译,而在c++文件使用,则需要在c++文件中声明:extern "C" Add(int a, int b),因为c编译器和c++编译器对函数名的解释不一样(c++编译器解释函数名的时候要考虑函数参数,这样是了方便函数重载,而在c语言中不存在函数重载的问题),使用extern "C",实质就是告诉c++编译器,该函数是c库里面的函数。如果不使用extern "C"则会出现链接错误。
一般象如下使用:
#ifdef _cplusplus
#define EXTERN_C extern "C"
#else
#define EXTERN_C extern
#endif
#ifdef _cplusplus
extern "C"{
#endif
EXTERN_C int func(int a, int b);
#ifdef _cplusplus
}
#endif
5、MFC提供了一些宏,可以使用AFX_EXT_CLASS来代替__declspec(DLLexport),并修饰类名,从而导出类,AFX_API_EXPORT来修饰函数,AFX_DATA_EXPORT来修饰变量
AFX_CLASS_IMPORT:__declspec(DLLexport)
AFX_API_IMPORT:__declspec(DLLexport)
AFX_DATA_IMPORT:__declspec(DLLexport)
AFX_CLASS_EXPORT:__declspec(DLLexport)
AFX_API_EXPORT:__declspec(DLLexport)
AFX_DATA_EXPORT:__declspec(DLLexport)
AFX_EXT_CLASS:#ifdef _AFXEXT
AFX_CLASS_EXPORT
#else
AFX_CLASS_IMPORT
6、DLLMain负责初始化(Initialization)和结束 (Termination)工作,每当一个新的进程或者该进程的新的线程访问DLL时,或者访问DLL的每一个进程或者线程不再使用DLL或者结束时,都会调用DLLMain。但是,使用TerminateProcess或TerminateThread结束进程或者线程,不会调用DLLMain。
7、一个DLL在内存中只有一个实例
DLL程序和调用其输出函数的程序的关系:
1)、DLL与进程、线程之间的关系
DLL模块被映射到调用它的进程的虚拟地址空间。
DLL使用的内存从调用进程的虚拟地址空间分配,只能被该进程的线程所访问。
DLL的句柄可以被调用进程使用;调用进程的句柄可以被DLL使用。
DLLDLL可以有自己的数据段,但没有自己的堆栈,使用调用进程的栈,与调用它的应用程序相同的堆栈模式。
2)、关于共享数据段
DLL定义的全局变量可以被调用进程访问;DLL可以访问调用进程的全局数据。使用同一 DLL的每一个进程都有自己的DLL全局变量实例。如果多个线程并发访问同一变量,则需要使用同步机制;对一个DLL的变量,如果希望每个使用DLL的线程都有自己的值,则应该使用线程局部存储(TLS,Thread Local Strorage)。
于网络所带来的诸多不安全因素使得网络使用者不得不采取相应的网络安全对策。为了堵塞安全漏洞和提供安全的通信服务,必须运用一定的技术来对网络进行安全建设,这已为广大网络开发商和网络用户所共识。
现今主要的网络安全技术有以下几种:
一、加密路由器(Encrypting Router)技术
加密路由器把通过路由器的内容进行加密和压缩,然后让它们通过不安全的网络进行传输,并在目的端进行解压和解密。
二、安全内核(Secured Kernel)技术
人们开始在操作系统的层次上考虑安全性,尝试把系统内核中可能引起安全性问题的部分从内核中剔除出去,从而使系统更安全。如S olaris操作系统把静态的口令放在一个隐含文件中, 使系统的安全性增强。
三、网络地址转换器(Network Address Translater)
网络地址转换器也称为地址共享器(Address Sharer)或地址映射器,初衷是为了解决IP 地址不足,现多用于网络安全。内部主机向外部主机连接时,使用同一个IP地址;相反地,外部主机要向内部主机连接时,必须通过网关映射到内部主机上。它使外部网络看不到内部网络, 从而隐藏内部网络,达到保密作用。
数据加密(Data Encryption)技术
所谓加密(Encryption)是指将一个信息(或称明文--plaintext) 经过加密钥匙(Encrypt ionkey)及加密函数转换,变成无意义的密文( ciphertext),而接收方则将此密文经过解密函数、解密钥匙(Decryti on key)还原成明文。加密技术是网络安全技术的基石。
数据加密技术要求只有在指定的用户或网络下,才能解除密码而获得原来的数据,这就需要给数据发送方和接受方以一些特殊的信息用于加解密,这就是所谓的密钥。其密钥的值是从大量的随机数中选取的。按加密算法分为专用密钥和公开密钥两种。
专用密钥,又称为对称密钥或单密钥,加密时使用同一个密钥,即同一个算法。如DES和MIT的Kerberos算法。单密钥是最简单方式,通信双方必须交换彼此密钥,当需给对方发信息时,用自己的加密密钥进行加密,而在接收方收到数据后,用对方所给的密钥进行解密。这种方式在与多方通信时因为需要保存很多密钥而变得很复杂,而且密钥本身的安全就是一个问题。
DES是一种数据分组的加密算法,它将数据分成长度为6 4位的数据块,其中8位用作奇偶校验,剩余的56位作为密码的长度。第一步将原文进行置换,得到6 4位的杂乱无章的数据组;第二步将其分成均等两段 ;第三步用加密函数进行变换,并在给定的密钥参数条件下,进行多次迭代而得到加密密文。
公开密钥,又称非对称密钥,加密时使用不同的密钥,即不同的算法,有一把公用的加密密钥,有多把解密密钥,如RSA算法。
在计算机网络中,加密可分为"通信加密"(即传输过程中的数据加密)和"文件加密"(即存储数据加密)。通信加密又有节点加密、链路加密和端--端加密3种。
①节点加密,从时间坐标来讲,它在信息被传入实际通信连接点 (Physical communication link)之前进行;从OSI 7层参考模型的坐标 (逻辑空间)来讲,它在第一层、第二层之间进行; 从实施对象来讲,是对相邻两节点之间传输的数据进行加密,不过它仅对报文加密,而不对报头加密,以便于传输路由的选择。
②链路加密(Link Encryption),它在数据链路层进行,是对相邻节点之间的链路上所传输的数据进行加密,不仅对数据加密还对报头加密。
③端--端加密(End-to-End Encryption),它在第六层或第七层进行 ,是为用户之间传送数据而提供的连续的保护。在始发节点上实施加密,在中介节点以密文形式传输,最后到达目的节点时才进行解密,这对防止拷贝网络软件和软件泄漏也很有效。
在OSI参考模型中,除会话层不能实施加密外,其他各层都可以实施一定的加密措施。但通常是在最高层上加密,即应用层上的每个应用都被密码编码进行修改,因此能对每个应用起到保密的作用,从而保护在应用层上的投资。假如在下面某一层上实施加密,如TCP层上,就只能对这层起到保护作用。
值得注意的是,能否切实有效地发挥加密机制的作用,关键的问题在于密钥的管理,包括密钥的生存、分发、安装、保管、使用以及作废全过程。
(1)数字签名
公开密钥的加密机制虽提供了良好的保密性,但难以鉴别发送者, 即任何得到公开密钥的人都可以生成和发送报文。数字签名机制提供了一种鉴别方法,以解决伪造、抵赖、冒充和篡改等问题。
数字签名一般采用不对称加密技术(如RSA),通过对整个明文进行某种变换,得到一个值,作为核实签名。接收者使用发送者的公开密钥对签名进行解密运算,如其结果为明文,则签名有效,证明对方的身份是真实的。当然,签名也可以采用多种方式,例如,将签名附在明文之后。数字签名普遍用于银行、电子贸易等。
数字签名不同于手写签字:数字签名随文本的变化而变化,手写签字反映某个人个性特征, 是不变的;数字签名与文本信息是不可分割的,而手写签字是附加在文本之后的,与文本信息是分离的。
(2)Kerberos系统
Kerberos系统是美国麻省理工学院为Athena工程而设计的,为分布式计算环境提供一种对用户双方进行验证的认证方法。
它的安全机制在于首先对发出请求的用户进行身份验证,确认其是否是合法的用户;如是合法的用户,再审核该用户是否有权对他所请求的服务或主机进行访问。从加密算法上来讲,其验证是建立在对称加密的基础上的。
Kerberos系统在分布式计算环境中得到了广泛的应用(如在Notes 中),这是因为它具有如下的特点:
①安全性高,Kerberos系统对用户的口令进行加密后作为用户的私钥,从而避免了用户的口令在网络上显示传输,使得窃听者难以在网络上取得相应的口令信息;
②透明性高,用户在使用过程中,仅在登录时要求输入口令,与平常的操作完全一样,Ker beros的存在对于合法用户来说是透明的;
③可扩展性好,Kerberos为每一个服务提供认证,确保应用的安全。
Kerberos系统和看电影的过程有些相似,不同的是只有事先在Ker beros系统中登录的客户才可以申请服务,并且Kerberos要求申请到入场券的客户就是到TGS(入场券分配服务器)去要求得到最终服务的客户。
Kerberos的认证协议过程如图二所示。
Kerberos有其优点,同时也有其缺点,主要如下:
①、Kerberos服务器与用户共享的秘密是用户的口令字,服务器在回应时不验证用户的真实性,假设只有合法用户拥有口令字。如攻击者记录申请回答报文,就易形成代码本攻击。
②、Kerberos服务器与用户共享的秘密是用户的口令字,服务器在回应时不验证用户的真实性,假设只有合法用户拥有口令字。如攻击者记录申请回答报文,就易形成代码本攻击。
③、AS和TGS是集中式管理,容易形成瓶颈,系统的性能和安全也严重依赖于AS和TGS的性能和安全。在AS和TGS前应该有访问控制,以增强AS和TGS的安全。
④、随用户数增加,密钥管理较复杂。Kerberos拥有每个用户的口令字的散列值,AS与TGS 负责户间通信密钥的分配。当N个用户想同时通信时,仍需要N*(N-1)/2个密钥
( 3 )、PGP算法
PGP(Pretty Good Privacy)是作者hil Zimmermann提出的方案, 从80年代中期开始编写的。公开密钥和分组密钥在同一个系统中,公开密钥采用RSA加密算法,实施对密钥的管理;分组密钥采用了IDEA算法,实施对信息的加密。
PGP应用程序的第一个特点是它的速度快,效率高;另一个显著特点就是它的可移植性出色,它可以在多种操作平台上运行。PGP主要具有加密文件、发送和接收加密的E-mail、数字签名等。
(4)、PEM算法
保密增强邮件(Private Enhanced Mail,PEM),是美国RSA实验室基于RSA和DES算法而开发的产品,其目的是为了增强个人的隐私功能, 目前在Internet网上得到了广泛的应用,专为E-mail用户提供如下两类安全服务:
对所有报文都提供诸如:验证、完整性、防抵 赖等安全服务功能; 提供可选的安全服务功能,如保密性等。
PEM对报文的处理经过如下过程:
第一步,作规范化处理:为了使PEM与MTA(报文传输代理)兼容,按S MTP协议对报文进行规范化处理;
第二步,MIC(Message Integrity Code)计算;
第三步,把处理过的报文转化为适于SMTP系统传输的格式。
身份验证技术
身份识别(Identification)是指定用户向系统出示自己的身份证明过程。身份认证(Authertication)是系统查核用户的身份证明的过程。人们常把这两项工作统称为身份验证(或身份鉴别),是判明和确认通信双方真实身份的两个重要环节。
Web网上采用的安全技术
在Web网上实现网络安全一般有SHTTP/HTTP和SSL两种方式。
(一)、SHTTP/HTTP
SHTTP/HTTP可以采用多种方式对信息进行封装。封装的内容包括加密、签名和基于MAC 的认证。并且一个消息可以被反复封装加密。此外,SHTTP还定义了包头信息来进行密钥传输、认证传输和相似的管理功能。SHTTP可以支持多种加密协议,还为程序员提供了灵活的编程环境。
SHTTP并不依赖于特定的密钥证明系统,它目前支持RSA、带内和带外以及Kerberos密钥交换。
(二)、SSL(安全套层) 安全套接层是一种利用公开密钥技术的工业标准。SSL广泛应用于Intranet和Internet 网,其产品包括由Netscape、Microsoft、IBM 、Open Market等公司提供的支持SSL的客户机和服务器,以及诸如Apa che-SSL等产品。
SSL提供三种基本的安全服务,它们都使用公开密钥技术。
①信息私密,通过使用公开密钥和对称密钥技术以达到信息私密。SSL客户机和SSL服务器之间的所有业务使用在SSL握手过程中建立的密钥和算法进行加密。这样就防止了某些用户通过使用IP packet sniffer工具非法窃听。尽管packet sniffer仍能捕捉到通信的内容, 但却无法破译。 ②信息完整性,确保SSL业务全部达到目的。如果Internet成为可行的电子商业平台,应确保服务器和客户机之间的信息内容免受破坏。SSL利用机密共享和hash函数组提供信息完整性服务。③相互认证,是客户机和服务器相互识别的过程。它们的识别号用公开密钥编码,并在SSL握手时交换各自的识别号。为了验证证明持有者是其合法用户(而不是冒名用户),SSL要求证明持有者在握手时对交换数据进行数字式标识。证明持有者对包括证明的所有信息数据进行标识以说明自己是证明的合法拥有者。这样就防止了其他用户冒名使用证明。证明本身并不提供认证,只有证明和密钥一起才起作用。 ④SSL的安全性服务对终端用户来讲做到尽可能透明。一般情况下,用户只需单击桌面上的一个按钮或联接就可以与SSL的主机相连。与标准的HTTP连接申请不同,一台支持SSL的典型网络主机接受SSL连接的默认端口是443而不是80。
当客户机连接该端口时,首先初始化握手协议,以建立一个SSL对话时段。握手结束后,将对通信加密,并检查信息完整性,直到这个对话时段结束为止。每个SSL对话时段只发生一次握手。相比之下,HTTP 的每一次连接都要执行一次握手,导致通信效率降低。一次SSL握手将发生以下事件:
1.客户机和服务器交换X.509证明以便双方相互确认。这个过程中可以交换全部的证明链,也可以选择只交换一些底层的证明。证明的验证包括:检验有效日期和验证证明的签名权限。
2.客户机随机地产生一组密钥,它们用于信息加密和MAC计算。这些密钥要先通过服务器的公开密钥加密再送往服务器。总共有四个密钥分别用于服务器到客户机以及客户机到服务器的通信。
3.信息加密算法(用于加密)和hash函数(用于确保信息完整性)是综合在一起使用的。Netscape的SSL实现方案是:客户机提供自己支持的所有算法清单,服务器选择它认为最有效的密码。服务器管理者可以使用或禁止某些特定的密码。
代理服务
在 Internet 中广泛采用代理服务工作方式, 如域名系统(DNS), 同时也有许多人把代理服务看成是一种安全性能。
从技术上来讲代理服务(Proxy Service)是一种网关功能,但它的逻辑位置是在OSI 7层协议的应用层之上。
代理(Proxy)使用一个客户程序,与特定的中间结点链接,然后中间结点与期望的服务器进行实际链接。与应用网关型防火墙所不同的是,使用这类防火墙时外部网络与内部网络之间不存在直接连接,因此 ,即使防火墙产生了问题,外部网络也无法与被保护的网络连接。
防火墙技术
(1)防火墙的概念
在计算机领域,把一种能使一个网络及其资源不受网络"墙"外"火灾"影响的设备称为"防火墙"。用更专业一点的话来讲,防火墙(FireW all)就是一个或一组网络设备(计算机系统或路由器等),用来在两个或多个网络间加强访问控制,其目的是保护一个网络不受来自另一个网络的攻击。可以这样理解,相当于在网络周围挖了一条护城河,在唯一的桥上设立了安全哨所,进出的行人都要接受安全检查。
防火墙的组成可以这样表示:防火墙=过滤器+安全策略(+网关)。
(2)防火墙的实现方式
①在边界路由器上实现;
②在一台双端口主机(dual-homed host)上实现;
③在公共子网(该子网的作用相当于一台双端口主机)上实现,在此子网上可建立含有停火区结构的防火墙。
(3)防火墙的网络结构
网络的拓扑结构和防火墙的合理配置与防火墙系统的性能密切相关,防火墙一般采用如下几种结构。
①最简单的防火墙结构
这种网络结构能够达到使受保护的网络只能看到"桥头堡主机"( 进出通信必经之主机), 同时,桥头堡主机不转发任何TCP/IP通信包, 网络中的所有服务都必须有桥头堡主机的相应代理服务程序来支持。但它把整个网络的安全性能全部托付于其中的单个安全单元,而单个网络安全单元又是攻击者首选的攻击对象,防火墙一旦破坏,桥头堡主机就变成了一台没有寻径功能的路由器,系统的安全性不可靠。
②单网端防火墙结构
其中屏蔽路由器的作用在于保护堡垒主机(应用网关或代理服务) 的安全而建立起一道屏障。在这种结构中可将堡垒主机看作是信息服务器,它是内部网络对外发布信息的数据中心,但这种网络拓扑结构仍把网络的安全性大部分托付给屏蔽路由器。系统的安全性仍不十分可靠。
③增强型单网段防火墙的结构
为增强网段防火墙安全性,在内部网与子网之间增设一台屏蔽路由器,这样整个子网与内外部网络的联系就各受控于一个工作在网络级的路由器,内部网络与外部网络仍不能直接联系,只能通过相应的路由器与堡垒主机通信。
④含"停火区"的防火墙结构
针对某些安全性特殊需要, 可建立如下的防火墙网络结构。 网络的整个安全特性分担到多个安全单元, 在外停火区的子网上可联接公共信息服务器,作为内外网络进行信息交换的场所。
网络反病毒技术
由于在网络环境下,计算机病毒具有不可估量的威胁性和破坏力, 因此计算机病毒的防范也是网络安全性建设中重要的一环。网络反病毒技术也得到了相应的发展。
网络反病毒技术包括预防病毒、检测病毒和消毒等3种技术。(1) 预防病毒技术,它通过自身常驻系统内存,优先获得系统的控制权,监视和判断系统中是否有病毒存在,进而阻止计算机病毒进入计算机系统和对系统进行破坏。这类技术是:加密可执行程序、引导区保护、系统监控与读写控制(如防病毒卡)等。(2)检测病毒技术,它是通过对计算机病毒的特征来进行判断的技术,如自身校验、关键字、文件长度的变化等。(3)消毒技术,它通过对计算机病毒的分析,开发出具有删除病毒程序并恢复原文件的软件。
网络反病毒技术的实施对象包括文件型病毒、引导型病毒和网络病毒。
网络反病毒技术的具体实现方法包括对网络服务器中的文件进行频繁地扫描和监测;在工作站上采用防病毒芯片和对网络目录及文件设置访问权限等。
随着网上应用不断发展,网络技术不断应用,网络不安全因素将会不断产生,但互为依存的,网络安全技术也会迅速的发展,新的安全技术将会层出不穷,最终Internet网上的安全问题将不会阻挡我们前进的步伐
同步在网络游戏中是非常重要的,它保证了每个玩家在屏幕上看到的东西大体是一样的。其实呢,解决同步问题的最简单的方法就是把每个玩家的动作都向其他玩家广播一遍,这里其实就存在两个问题:1,向哪些玩家广播,广播哪些消息。2,如果网络延迟怎么办。事实上呢,第一个问题是个非常简单的问题,不过之所以我提出这个问题来,是提醒大家在设计自己的消息结构的时候,需要把这个因素考虑进去。而对于第二个问题,则是一个挺麻烦的问题,大家可以来看这么个例子:
比如有一个玩家A向服务器发了条指令,说我现在在P1点,要去P2点。指令发出的时间是T0,服务器收到指令的时间是T1,然后向周围的玩家广播这条消息,消息的内容是“玩家A从P1到P2”有一个在A附近的玩家B,收到服务器的这则广播的消息的时间是T2,然后开始在客户端上画图,A从P1到P2点。这个时候就存在一个不同步的问题,玩家A和玩家B的屏幕上显示的画面相差了T2-T1的时间。这个时候怎么办呢?
有个解决方案,我给它取名叫 预测拉扯,虽然有些怪异了点,不过基本上大家也能从字面上来理解它的意思。要解决这个问题,首先要定义一个值叫:预测误差。然后需要在服务器端每个玩家连接的类里面加一项属性,叫TimeModified,然后在玩家登陆的时候,对客户端的时间和服务器的时间进行比较,得出来的差值保存在TimeModified里面。还是上面的那个例子,服务器广播消息的时候,就根据要广播对象的TimeModified,计算出一个客户端的CurrentTime,然后在消息头里面包含这个CurrentTime,然后再进行广播。并且同时在玩家A的客户端本地建立一个队列,保存该条消息,只到获得服务器验证就从未被验证的消息队列里面将该消息删除,如果验证失败,则会被拉扯回P1点。然后当玩家B收到了服务器发过来的消息“玩家A从P1到P2”这个时候就检查消息里面服务器发出的时间和本地时间做比较,如果大于定义的预测误差,就算出在T2这个时间,玩家A的屏幕上走到的地点P3,然后把玩家B屏幕上的玩家A直接拉扯到P3,再继续走下去,这样就能保证同步。更进一步,为了保证客户端运行起来更加smooth,我并不推荐直接把玩家拉扯过去,而是算出P3偏后的一点P4,然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S,然后让玩家A用速度S快速移动到P4,这样的处理方法是比较合理的,这种解决方案的原形在国际上被称为(Full plesiochronous),当然,该原形被我篡改了很多来适应网络游戏的同步,所以而变成所谓的:预测拉扯。
另外一个解决方案,我给它取名叫 验证同步,听名字也知道,大体的意思就是每条指令在经过服务器验证通过了以后再执行动作。具体的思路如下:首先也需要在每个玩家连接类型里面定义一个TimeModified,然后在客户端响应玩家鼠标行走的同时,客户端并不会先行走动,而是发一条走路的指令给服务器,然后等待服务器的验证。服务器接受到这条消息以后,进行逻辑层的验证,然后计算出需要广播的范围,包括玩家A在内,根据各个客户端不同的TimeModified生成不同的消息头,开始广播,这个时候这个玩家的走路信息就是完全同步的了。这个方法的优点是能保证各个客户端之间绝对的同步,缺点是当网络延迟比较大的时候,玩家的客户端的行为会变得比较不流畅,给玩家带来很不爽的感觉。该种解决方案的原形在国际上被称为(Hierarchical master-slave synchronization),80年代以后被广泛应用于网络的各个领域。
最后一种解决方案是一种理想化的解决方案,在国际上被称为Mutual synchronization,是一种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案,并不是说我们已经完全的实现了这种方案,而只是在网络游戏领域的某些方面应用到这种方案的某些思想。我对该种方案取名为:半服务器同步。大体的设计思路如下:
首先客户端需要在登陆世界的时候建立很多张广播列表,这些列表在客户端后台和服务器要进行不及时同步,之所以要建立多张列表,是因为要广播的类型是不止一种的,比如说有local message,有remote message,还有global message 等等,这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时,还需要获得每个列表中广播对象的TimeModified,并且要维护一张完整的用户状态列表在后台,也是不及时的和服务器进行同步,根据本地的用户状态表,可以做到一部分决策由客户端自己来决定,当客户端发送这部分决策的时候,则直接将最终决策发送到各个广播列表里面的客户端,并对其时间进行校对,保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。那么再采用预测拉扯中提到过的计算提前量,提高速度行走过去的方法,将会使同步变得非常的smooth。该方案的优点是不通过服务器,客户端自己之间进行同步,大大的降低了由于网络延迟而带来的误差,并且由于大部分决策都可以由客户端来做,也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权都放在客户端本地,所以给外挂提供了很大的可乘之机。
综合以上三种关于网络同步派系的优缺点,综合出一套关于网络游戏传输同步的较完整的解决方案,我称它为综合同步法(colligate synchronization)。大体设计思路如下:
首先将服务器需要同步的所有消息从划分一个优先等级,然后按照3/4的比例划分出重要消息和非重要消息,对于非重要消息,把决策权放在客户端,在客户端逻辑上建立相关的决策机构和各种消息缓存区,以及相关的消息缓存区管理机构.
对于非重要消息,客户端的大体处理流程,其中有一个客户端被动行为值得大家注意,其中包括对服务器发过来的某些验证代码做返回,来确保消息缓存中的消息和服务器端是一致的,从而有效的防止外挂来篡改本地消息缓存。其中的消息来源是包括本地的客户端响应玩家的消息以及远程服务器传递过来的消息。
对于重要消息,比如说战斗或者是某些牵扯到玩家一些比较敏感数据的操作,则采用另外一套方案,该方案首先需要在服务器和客户端之间建立一套Ping System,然后服务器保存和用户的及时的ping值,当ping比较小的时候,响应玩家消息的同时先不进行动作,而是先把该消息反馈给服务器,并且阻塞,服务器收到该消息,进行逻辑验证之后向所有该详细广播的有效对象进行广播(包括消息发起者),然后客户端收到该消息的验证,才开始执行动作。而当ping比较大的时候,客户端响应玩家消息的同时立刻进行动作,并且同时把该消息反馈给服务器,值得注意的是这个时候还需要在本地建立一个无验证消息的队列,把该消息入队,执行动作的同时等待服务器的验证,还需要保存当前状态。服务器收到客户端的请求后,进行逻辑验证,并把消息反馈到各个客户端,带上各个客户端校对过的本地时间。如果验证通过不过,则通知消息发起者,该消息验证失败,然后客户端自动把已经在进行中的动作取消,恢复原来状态。如果验证通过,则广播到的各个客户端根据从服务器获得校对时间进行对其进行拉扯,保证在该行为完成之前完成同步。
至此,一个比较成熟的网络游戏的同步机制已经初步建立起来了,接下来的逻辑代码就根据各自不同的游戏风格以及侧重点来写了。
同步是网络游戏最重要的问题,如何同步也牵扯到各个方面的问题,比如说游戏的规模,游戏的类型以及各种各样的方面,对于规模比较大的游戏,在同步方面可以下很多的工夫,把消息分得十分的细腻,对于不同的消息采用不同的同步机制,而对于规模比较小的游戏,则可以采用大体上一样的同步机制,究竟怎么样同步,没有个定式,是需要根据自己的不同情况来做出不同的同步决策的
网游同步算法之导航推测(Dead Reckoning)算法:
在了解该算法前,我们先来谈谈该算法的一些背景资料。大家都知道,在网络传输的时候,延迟现象是很普遍的,而在基于Server/Client结构下的网络游戏的同步也就成了很头疼的问题,在保证客户端响应用户本地指令流畅的情况下,没法有效的保证的同步的及时性。同样,在军方也有类似的事情发生,即使是同一LAN里面的机器,也会因为传输的延迟,导致一些运算的失误,介于此,美国国防部投入了大量的资金用于研究一种比较的好的方案来解决分布式系统中的延迟问题,特别是一个叫分布式模拟运动(Distributed Interactive Simulation)的系统,这套系统呢,其中就提出了一套号称是Latency Hiding & Bandwidth Reduction的方案,命名为Dead Reckoning。呵呵,来头很大吧,恩,那么我们下面就来看看这套系统的一些观点,以及我们如何把它运用到我们的网络游戏的同步中。
本文使用的表示方法和VC6的Memory视图一致,即:左上表示低位。
提示2:下文提到的“类大小”严格上来说是该类经过实例化的对象的大小。当然了,光研究长度的话,两者差别不大,因为:CClassA objA,sizeof(CClassA)和sizeof(objA)得到的结果都是一样的。
一、真空类
class CNull
{
};
长度:1
内存结构:
??
评注:长度其实为0,这个字节作为内容没有意义,可能每次都不一样。
二、空类
class CNull2
{
public:
CNull2(){printf("Construct\n");}
~CNull2(){printf("Desctruct\n");}
void Foo(){printf("Foo\n");}
};
长度:1
内存结构:
??
评注:同真空类差不多,内部的成员函数并不会影响类大小。
三、简单类
class COneMember
{
public:
COneMember(int iValue = 0){m_iOne = iValue;};
private:
int m_iOne;
};
长度:4
内存结构:
00 00 00 00 //m_iOne
评注:成员数据才影响类大小。
四、简单继承
class CTwoMember:public COneMember
{
private:
int m_iTwo;
};
长度:8
内存结构:
00 00 00 00 //m_iOne
CC CC CC CC //m_iTwo
评注:子类成员接在父类成员之后。
五、再继承
class CThreemember:public CTwoMember
{
public:
CThreemember(int iValue=10) {m_iThree = iValue;};
private:
int m_iThree;
};
长度:12
内存结构:
00 00 00 00 //m_iOne
CC CC CC CC //m_iTwo
0A 00 00 00 //m_iThree
评注:孙类成员接在子类之后,再再继承就依此类推了。
六、多重继承
class ClassA
{
public:
ClassA(int iValue=1){m_iA = iValue;};
private:
int m_iA;
};
class ClassB
{
public:
ClassB(int iValue=2){m_iB = iValue;};
private:
int m_iB;
};
class ClassC
{
public:
ClassC(int iValue=3){m_iC = iValue;};
private:
int m_iC;
};
class CComplex :public ClassA, public ClassB, public ClassC
{
public:
CComplex(int iValue=4){m_iComplex = iValue;};
private:
int m_iComplex;
};
长度:16
内存结构:
01 00 00 00 //A
02 00 00 00 //B
03 00 00 00 //C
04 00 00 00 //Complex
评注:也是父类成员先出现在前边,我想这都足够好理解。
七、复杂一些的继承
不写代码了,怕读者看了眼花,改画图。
![](http://hiphotos.baidu.com/hailoong/pic/item/665a4b51762123be8d5430b6.jpg)
长度:32
内存结构:
01 00 00 00 //A
02 00 00 00 //B
03 00 00 00 //C
04 00 00 00 //Complex
00 00 00 00 //OneMember
CC CC CC CC //TwoMember
0A 00 00 00 //ThreeMember
05 00 00 00 //VeryComplex
评注:还是把自己的成员放在最后。
只要没涉及到“虚”(Virtual),我想没什么难点,不巧的是“虚”正是我们要研究的内容。
八、趁热打铁,看“虚继承”
class CTwoMember:virtual public COneMember
{
private:
int m_iTwo;
};
长度:12
内存结构:
E8 2F 42 00 //指针,指向一个关于偏移量的数组,且称之虚基类偏移量表指针
CC CC CC CC // m_iTwo
00 00 00 00 // m_iOne(虚基类数据成员)
评注:virtual让长度增加了4,其实是多了一个指针,关于这个指针,确实有些复杂,别的文章有具体分析,这里就不岔开具体讲了,可认为它指向一个关于虚基类偏移量的数组,偏移量是关于虚基类数据成员的偏移量。
九、“闭合”虚继承,看看效果
![](http://hiphotos.baidu.com/hailoong/pic/item/6bbfde29a60a77cf98250ab6.jpg)
长度:24
内存结构:
14 30 42 00 //ClassB的虚基类偏移量表指针
02 00 00 00 //m_iB
C4 2F 42 00 //ClassC的虚基类偏移量表指针
03 00 00 00 //m_iC
04 00 00 00 //m_iComplex
01 00 00 00 //m_iA
评注:和预料中的一样,虚基类的成员m_iA只出现了一次,而且是在最后边。当然了,更复杂的情况要比这个难分析得多,但虚继承不是我们研究的重点,我们只需要知道:虚继承利用一个“虚基类偏移量表指针”来使得虚基类即使被重复继承也只会出现一次。
十、看一下关于static成员
class CStaticNull
{
public:
CStaticNull(){printf("Construct\n");}
~CStaticNull(){printf("Desctruct\n");}
static void Foo(){printf("Foo\n");}
static int m_iValue;
};
长度:1
内存结构:(同CNull2)
评注:可见static成员不会占用类的大小,static成员的存在区域为静态区,可认为它们是“全局”的,只是不提供全局的访问而已,这跟C的static其实没什么区别。
十一、带一个虚函数的空类
class CVirtualNull
{
public:
CVirtualNull(){printf("Construct\n");}
~CVirtualNull(){printf("Desctruct\n");}
virtual void Foo(){printf("Foo\n");}
};
长度:4
内存结构:
00 31 42 00 //指向虚函数表的指针(虚函数表后面简称“虚表”)
00423100:(虚表)
41 10 40 00 //指向虚函数Foo的指针
00401041:
E9 78 02 00 00 E9 C3 03 … //函数Foo的内容(看不懂)
评注:带虚函数的类长度就增加了4,这个4其实就是个指针,指向虚函数表的指针,上面这个例子中虚表只有一个函数指针,值就是“0x00401041”,指向的这个地址就是函数的入口了。
十二、继承带虚函数的类
class CVirtualDerived : public CVirtualNull
{
public:
CVirtualDerived(){m_iVD=0xFF;};
~CVirtualDerived(){};
private:
int m_iVD;
};
长度:8
内存结构:
3C 50 42 00 //虚表指针
FF 00 00 00 //m_iVD
0042503C:(虚表)
23 10 40 00 //指向虚函数Foo的指针,如果这时候创建一个CVirtualNull对象,会发现它的虚表的内容跟这个一样
评注:由于父类带了虚函数,子类就算没有显式声明虚函数,虚表还是存在的,虚表存放的位置跟父类不同,但内容是同的,也就是对父类虚表的复制。
十三、子类有新的虚函数
class CVirtualDerived: public CVirtualNull
{
public:
CVirtualDerived(){m_iVD=0xFF;};
~CVirtualDerived(){};
virtual void Foo2(){printf("Foo2\n");};
private:
int m_iVD;
};
长度:8
内存结构:
24 61 42 00 //虚表指针
FF 00 00 00 //m_iVD
00426124:(虚表)
23 10 40 00
50 10 40 00
评注:虚表还是只有一张,不会因为增加了新的虚函数而多出另一张来,新的虚函数的指针将添加在复制了的虚表的后面。
十四、当纯虚函数(pure function)出现时
class CPureVirtual
{
virtual void Foo() = 0;
};
class CDerivePV : public CPureVirtual
{
void Foo(){printf("vd: Foo\n");};
};
长度:4(CPureVirtual),4(CDerivePV)
内存结构:
CPureVirtual:
(不可实例化)
CDerivePV:
28 50 42 00 //虚表指针
00425028:(虚表)
5A 10 40 00 //指向Foo的函数指针
评注:带纯虚函数的类不可实例化,因此列不出其“内存结构”,由其派生类实现纯虚函数。我们可以看到CDerivePV虽然没有virtual声明,但由于其父类带virtual,所以还是继承了虚表,如果CDerivePV有子类,还是这个道理。
十五、虚函数类的多重继承
前面提到:(子类的虚表)不会因为增加了新的虚函数而多出另一张来,但如果有多重继承的话情况就不是这样了。下例中你将看到两张虚表。
![](http://hiphotos.baidu.com/hailoong/pic/item/c7c0d0a8cf201a80ca130cb6.jpg)
大小:24
内存结构
F8 50 42 00 //虚表指针
01 00 00 00 //m_iA
02 00 00 00 //m_iB
E8 50 42 00 //虚表指针
03 00 00 00 //m_iC
04 00 00 00 //m_iComplex
004250F8:(虚表)
5A 10 40 00 //FooA
55 10 40 00 //FooB
64 10 40 00 //FooComplex
004250E8:(虚表)
5F 10 40 00 //FooC
评注:子类的虚函数接在第一个基类的虚函数表的后面,所以B接在A后面,Complex接在B后面。基类依次出现,子类成员接在最后面,所以m_iComplex位于最后面。