上一篇主要谈了一些基本理念，本篇将谈谈我个人总结的一些IOCP编程技巧。

网络游戏前端服务器的需求和设计

　　首先介绍一下这个服务器的技术背景。在分布式网络游戏服务器中，前端连接服务器是一种很常见的设计。他的职责主要有：

　　1. 为客户端和后端的游戏逻辑服务器提供一个软件路由 —— 客户端一旦和前端服务器建立TCP连接以后就可以通过这个连接和后端的游戏服务器进行通讯，而不再需要和后端的服务器再建立新的连接。

　　2. 承担来自客户端的IO压力 —— 一组典型的网络游戏服务器需要服务少则几千多则上万（休闲游戏则可以多达几十万）的游戏客户端，这个IO处理的负载相当可观，由一组前端服务器承载这个IO负担可以有效的减轻后端服务器的IO负担，并且让后端服务器也只需要关心游戏逻辑的实现，有效的实现IO和业务逻辑的解耦。

　　架构如图：

　　对于网络游戏来说，客户端与服务器之间需要进行频繁的通讯，但是每个数据包的尺寸基本都很小，典型的大小为几个字节到几十个字节不等，同时用户上行的数据量要比下行数据量小的多。不同的游戏类型对延迟的要求不太一样，FPS类的游戏希望延迟要小于50ms，MMO类型的100～400ms，一些休闲类的棋牌游戏1000ms左右的延迟也是可以接受的。因此，网络游戏的通讯是以优化延迟的同时又必须兼顾小包的合并以防止网络拥塞，哪个因素为主则需要根据具体的游戏类型来决定。

　　技术背景就介绍这些，后面介绍的IOCP连接服务器就是以这些需求为设计目标的。

对IOCP服务器框架的考察

　　在动手实现这个连接服务器之前，我首先考察了一些现有的开源IOCP服务器框架库，老牌的如ACE，整个库太多庞大臃肿，代码也显老态，无好感。boost.asio据说是个不错的网络框架也支持IOCP，我编译运行了一下他的例子，然后尝试着阅读了一下asio的代码，感觉非常恐怖，完全弄不清楚内部是怎么实现的，于是放弃。asio秉承了boost一贯的变态作风，将C++的语言技巧凌驾于设计和代码可读性之上，这是我非常反对的。其他一些不入流的IOCP框架也看了一些，真是写的五花八门什么样的实现都有，总体感觉下来IOCP确实不太容易把握和抽象，所以才导致五花八门的实现。最后，还是决定自己重新造轮子。

服务框架的抽象

　　任何的服务器框架从本质上说都是封装一个事件（Event）消息循环。而应用层只要向框架注册事件处理函数，响应事件并进行处理就可以了。一般的同步IO处理框架是先收到IO事件然后再进行IO操作，这类的事件处理框架我们称之为Reactor。而IOCP的特殊之处在于用户是先发起IO操作，然后接收IO完成的事件，次序和Reactor是相反的，这类的事件处理框架我们称之为Proactor。从词根Re和Pro上，我们也可以容易的理解这两者的差别。除了网络IO事件之外，服务器应该还可以响应Timer事件及用户自定义事件。框架做的事情就是把这些事件统统放到一个消息队列里，然后从队列中取出事件，调用相应的事件处理函数，如此循环往复。

　　IOCP为我们提供了一个系统级的消息队列（称之为完成队列），事件循环就是围绕着这个完成队列展开的。在发起IO操作后系统会进行异步处理（如果能立刻处理的话也会直接处理掉），当操作完成后自动向这个队列投递一条消息，不管是直接处理还是异步处理，最后总会投递完成消息。

　　顺便提一下：这里存在一个性能优化的机会：当IO操作能够立刻完成的话，如果让系统不要再投递完成消息，那么就可以减少一次系统调用（这至少可以节省几个微秒的开销），做法是调用SetFileCompletionNotificationModes(handle, FILE_SKIP_COMPLETION_PORT_ON_SUCCESS)，具体的可以查阅MSDN。

　　对于用户自定义事件可以使用Post来投递。对于Timer事件，我的做法则是实现一个TimerHeap的数据结构，然后在消息循环中定期检查这个TimerHeap，对超时的Timer事件进行调度。

　　IOCP完成队列返回的消息是一个OVERLAPPED结构体和一个ULONG_PTR complete_key。complete_key是在用户将Socket handle关联到IOCP的时候绑定的，其实用性不是很大，而OVERLAPPED结构体则是在用户发起IO操作的时候设置的，并且OVERLAPPED结构可以由用户通过继承的方式来扩展，因此如何用好OVERLAPPED结构在螺丝壳里做道场，就成了封装好IOCP的关键。

　　这里，我使用了一个C++模板技巧来扩展OVERLAPPED结构，先看代码：

struct IOCPHandler
{
    virtual void Complete(ULONG_PTR key, DWORD size) = 0;
    virtual void OnError(ULONG_PTR key, DWORD error){}
    virtual void Destroy() = 0;
};

struct Overlapped : public OVERLAPPED
{
    IOCPHandler* handler;
};

template<class T>
struct OverlappedWrapper : T
{
    Overlapped overlap;

    OverlappedWrapper(){
        ZeroMemory(&overlap, sizeof(overlap));
        overlap.handler = this;
    }

    operator OVERLAPPED*(){return &overlap;}
};

　　IOCPHandler是用户对象的接口，用户扩展这个接口来实现IO完成事件的处理。然后通过一个OverlappedWrapper<T>的模板类将用户对象和OVERLAPPED结构封装成一个对象，T类型就是用户扩展的对象，由于用户对象位于OVERLAPPED结构体的前面，因此我们会将OVERLAPPED的指针传递给IO操作的API，同时我们在OVERLAPPED结构的后面还放置了一个用户对象的指针，当GetQueuedCompletionStatus接收到OVERLAPPED结构体指针后，我们通过这个指针就可以找到用户对象的位置了，然后调用虚函数Complete或者OnError就可以了。

　　图解一下对象结构：

 

在事件循环里的处理方法 ：

DWORD size;
ULONG_PTR key;
Overlapped* overlap;
BOOL ret = ::GetQueuedCompletionStatus(_iocp, &size, &key, (LPOVERLAPPED*)&overlap, dt);
if(ret){
    if(overlap == 0){
        OnExit();
        break;
    }
    overlap->handler->Complete(key, size);
    overlap->handler->Destroy();
}
else {
    DWORD err = GetLastError();
    if(err == WAIT_TIMEOUT)
        UpdateTimer();
    else if(overlap) {
        overlap->handler->OnError(key, err);
        overlap->handler->Destroy();
    }
}

 　　在这里利用我们利用了C++的多态来扩展OVERLAPPED结构，在框架层完全不用关心接收到的是什么IO事件，只需要应用层自己关心就够了，同时也避免了使用丑陋的难于扩展的switch..case结构。

　　对于异步操作来说，最让人痛苦的事情就是需要把原本顺序逻辑的代码强行拆分成多块来回调，这使得代码中原本蕴含的顺序逻辑被打散，并且在各个代码块里的上下文变量无法共享，必须另外生成一个对象放置这些上下文变量，而这又引发一个对象生存期管理的问题，对于没有GC的C++来说尤其痛苦。解决异步逻辑的痛苦之道目前有两种方案：一种是用coroutine（协作式线程）将异步逻辑变成同步逻辑，在Windows上可以使用Fiber来实现coroutine；另一种方案是使用闭包，闭包原本是函数式语言的特性，在C++里并没有，不过幸运的是我们可以通过一个稍微麻烦一点的方法来模拟闭包行为。coroutine在解决异步逻辑方面是最拿手的，特别是一个函数里需要依次进行多个异步操作的时候尤其强大（在这种情况下闭包也相形见拙），但是另一方面coroutine的实现比较复杂，线程的手工调度常常把人绕晕，对于IOCP这种异步操作比较有限的场景有点杀鸡用牛刀的感觉。因此最后我还是决定使用C++来模拟闭包行为。

　　这里演示一个典型的异步IO用法，看代码： 

一个异步发送的例子：

 　　这个例子中，我们在函数内部定义了一个SendHandler对象，模拟出了一个闭包的行为，我们可以把需要用到的上下文变量放置在SendHandler内，当下次回调的时候就可以访问到这些变量了。本例中，我们在SendHandler里记了一个cookie，其作用是当异步操作返回时，可能这个Client对象已经被回收了，这个时候如果再调用EndSend必然会导致错误的结果，因此我们通过cookie来判断这个Client对象是否是那个异步操作发起时的Client对象。

　　使用闭包虽然没有coroutine那样漂亮的顺序逻辑结构，但是也足够方便你把各个异步回调代码串起来，同时在闭包内共享需要用到的上下文变量。另外，最新版的C++标准对闭包有了原生的支持，实现起来会更方便一些，如果你的编译器足够新的话可以尝试使用新的C++特性。

IO工作线程 单线程vs多线程

　　在绝大多数讲解IOCP的文章中都会建议使用多个工作线程来处理IO事件，并且把工作线程数设置为CPU核心数的2倍。根据我的印象，这种说法的出处来自于微软早期的官方文档。不过，在我看来这完全是一种误导。IOCP的设计初衷就是用尽可能少的线程来处理IO事件，因此使用单线程处理本身是没有问题的，这可以使实现简化很多。反之，用多线程来处理的话，必须处处小心线程安全的问题，同时也会涉及到加锁的问题，而不恰当的加锁反而会使性能急剧下降，甚至不如单线程程序。有些同学可能会认为使用多线程可以发挥多核CPU的优势，但是目前CPU的速度足够用来处理IO事件，一般现代CPU的单个核心要处理一块千兆网卡的IO事件是绰绰有余的，最多的可以同时处理2块网卡的IO事件，瓶颈往往在网卡上。如果是想通过多块网卡提升IO吞吐量的话，我的建议是使用多进程来横向扩展，多进程不但可以在单台物理服务器上进行扩展，并且还可以扩展到多台物理服务器上，其伸缩性要比多线程更强。

　　 当时微软提出的这个建议我想主要是考虑到在IO线程中除了IO处理之外还有业务逻辑需要处理，使用多线程可以解决业务逻辑阻塞的问题。但是将业务逻辑放在IO线程里处理本身不是一种好的设计模式，这没有很好的做到IO和业务解耦，同时也限制了服务器的伸缩性。良好的设计应该将IO和业务解耦，使用多进程或者多线程将业务逻辑放在另外的进程或者线程里进行处理，而IO线程只需要负责最简单的IO处理，并将收到的消息转发到业务逻辑的进程或者线程里处理就可以了。我的前端连接服务器也是遵循了这种设计方法。

关闭发送缓冲区实现自己的nagle算法

　　IOCP最大的优势就是他的灵活性，关闭socket上的发送缓冲区就是一例。很多人认为关闭发送缓冲的价值是可以减少一次内存拷贝的开销，在我看来这只是捡了一粒芝麻而已。主流的千兆网卡其最大数据吞吐量不过区区120MB/s，而内存数据拷贝的吞吐量是10GB/s以上，多一次120MB/s数据拷贝，仅消耗1%的内存带宽，意义非常有限。

　　在普通的Socket编程中，我们只有打开nagle算法或者不打开的选择，策略的选择和参数的微调是没有办法做到的。而当我们关闭发送缓冲之后，每次Send操作一定会等到数据发送到对方的协议栈里并且收到ACK确认才会返回完成消息，这就给了我们一个实现自定义的nagle算法的机会。对于网络游戏这种需要频繁发送小数据包，打开nagle算法可以有效的合并发送小数据包以降低网络IO负担，但另一方面也加大了延迟，对游戏性造成不利影响。有了关闭发送缓冲的特性之后，我们就可以自行决定nagle算法的实现细节，在上一个send操作没有结束之前，我们可以决定是立刻发送新的数据（以降低延迟），还是累积数据等待上一个send结束或者超时后再发送。更复杂一点的策略是可以让服务器容忍多个未结束的send操作，当超出一个阈值后再累积数据，使得在IO吞吐量和延迟上达到一个合理的平衡。

发送缓冲的分配策略

　　前面提到了关闭socket的发送缓冲，那么就涉及到我们自己如何来分配发送缓冲的问题。

　　一种策略是给每个Socket分配一个固定大小的环形缓冲区。这会存在一个问题：当缓冲区内累积的未发送数据加上新发送的数据大小超出了缓冲区的大小，这个时候就会碰上麻烦，要么阻塞以等待前面的数据发送完毕（但是IO线程不可以阻塞），要么干脆直接把Socket关闭，一个妥协的办法是尽可能把发送缓冲区设置的大一些，但这又会白白浪费很多内存。

　　另一种策略是让所有的客户端socket共享一个非常大的环形缓冲区，假设我们保留一个1G的内存区域给这个环形缓冲区，每次需要向客户端发送数据时就从这个环形缓冲区分配内存，当缓冲区分配到底了再绕到开头重新分配。由于这个缓冲区非常大，1G的内存对千兆网卡来说至少需要花费10s才能发送完，并且在实际应用中这个时间会远超10s。因此当新的数据从头开始分配的时候，老的数据早已经发送掉了，不用担心将老的数据覆盖，即使碰到网络阻塞，一个数据包超过10s还未发送掉的话，我们也可以通过超时判断主动关闭这个socket。

socket池和对象池的分配策略

　　允许socket重用是IOCP另一个优势，我们可以在server启动时，根据我们对最大服务人数的预计，将所有的socket资源都分配好。一般来说每个socket必需对应一个client对象，用来记录一些客户端的信息，这个对象池也可以和socket绑定并预先分配好。在服务运行前将所有的大块对象的内存资源都预先分配好，用一个FreeList来做对象池的分配，在客户端下线之后再将资源回收到池中。这样就可以避免在服务运行过程中动态的分配大的对象，而一些需要临时分配的小对象（例如OVERLAPPED结构），我们可以使用诸如tcmalloc之类的通用内存分配器来做，tcmalloc内部使用小对象池算法，其分配性能和稳定性非常好，并且他的接口是非侵入式的，我们仍然可以在代码里保留malloc/free及new/delete。很多服务在长期运行之后出现运行效率降低，内存占用过大等问题，都跟频繁的分配和释放内存导致出现大量的内存碎片有关。所以做好服务器的内存分配管理是至关重要的一环。

待续....

下一篇将通过几个压力测试和profiling的例子，来分析服务器的性能和瓶颈所在，请大家关注。