网络游戏中的网络编程--性能

谈谈网络游戏中的“网络”编程

???? 近段时间总是有不少人问我关于完成端口模型的一些资料，很多时候其实我很郁闷，为什么大家会选择使用完成端口呢？或者说很多时候他们竟为了使用完成端口， 而使用WINDOWS作为网络游戏服务器平台，还一开口罗列出一堆使用WINDOWS平台的网络游戏案例。有些兄弟跟我一直争论“Windows? 2003?Server很猛的，效率很高的”，这句话的正确性暂且不讨论，先说Windows?2003?Server多少钱一张授权？降低成本不就等于 多赚钱嘛。放着免费且高效的Linux不用，篇篇要花钱买贵的？而且性能还低得一塌糊涂？

不要着急，放心，我说的是对的，下面来看看IBM的一些研究者对Linux和Windows下编程的性能比较。

首先来看看线程创建的速度比较：

????当然，也许你会说，现在都用线程池了，都是在开始的时候创建好线程，然后运行的时候直接拿来用就好了，恩，那么再来看看SOCKET的速度。

????不用脸红脖子粗，这个只是简单的测试，不过有小道消息说Windows在对于本地127.0.0.1地址传输的时候，速度会提高很多，那么到底是不是呢？我们来看看下面这张测试结果：

???? 其中带叉叉的线就是在针对127.0.0.1这个地址的情况下的传输速度，看得出来，那个小道消息确实是真的，Windows2000在对于本机地址传输 的时候确实要快很多。那么Windows和Linux相比，还有什么缺点呢？Windows在线程方面还有个特点，叫Thread?Creation? Decay，什么意思呢？就是指随着运行时间的越来越长，刚刚启动的时候创建线程的速度和启动了一段时间之后，线程的创建速度会不一样，这也就是为什么一 台Linux服务器可以几年都不重启，而Windows操作系统则不行。我这里并不是否认Windows，我在这里只是想说，Windows系统由于它所 提供的Built-in?GUI，导致内核在处理各个系统调用的时候，或多或少会有些损耗。

????好像有点跑题了，这些和网络都没什么 关系，那么我们回过头来看网络编程，首先我们来讨论一下网络的根本，根本是什么？是IO。接收一些数据，发送一些数据，在C/S模式下，又根据接收发送行 为的不同，而分成了服务器和客户端两种程序模型。那么究竟该如何处理这些IO呢？我们来看看目前几种常见的方法：

Blocking?Read-Write

????关于这个最常见的模型就是：

while?(size?=?read(fd,?buf,?max_size,?0)?)
ProcessMessage(buf,?size);

????用这种模型几乎无法处理面对多个用户连接的情况，因为在这种情况下，read的操作是阻塞的，会一直等到有消息到达才会返回。于是大家为了让这种模型适用于多个用户连接，就想了一个办法，那么就是：

Multi?Threading?Blocking?IO

????就是为每个用户连接，开启一个线程来跑上面的那个循环。但是，随着用户人数的增加，线程数量越来越多，虽然大部分时间都消耗在阻塞上，但是操作系统却为此付出了相当大的用户级线程间切换的代价。


IOCP?(I/O?Completion?Port)

???? 这就是很多人都津津乐道的完成端口，的确，在Windows平台下，它是最完美的关于IO的解决方案，不仅效率高，而且占用资源也相对较少，对于在 Windows平台下编写网络相关的操作，用它肯定是没错了。其原理就类似车站的售票窗口一样，有固定，有限的几个窗口来处理所有的请求。

Asynchronous?IO

????那么什么又是AIO呢？这是一个和以上三者不同的一个概念，或者说只是一种定义，不像上 面，都是特定的看得到的结构模型。而这里所谓的AIO的定义是为了使在更大限度上对操作系统IO带宽的利用，从而产生的一种高效率的IO处理结构。这只是 一个定义，而事实上对AIO的实现是多种多样的。一般来讲，真正的AIO，也就是按照AIO的思想来实现的，我们叫真AIO，比如Windows下的 WSAASync系列的API，和Linux下POSIX?AIO系列的API，其原理是在执行IO的时候立刻返回，然后让操作系统在处理完IO以后呼叫 其回调函数。所以，对于用其他方法，达到AIO目的的方法，我们叫假AIO，因为假AIO从AIO的定义出发，到达的效果基本和真AIO一样，典型的方法 就是select/poll/epoll配合非阻塞IO读写的来实现的假AIO。事实上呢，关于AIO的争论很多，Linux的内核对AIO的支持的实现 方法也几乎在每个版本都有改动。有一些对AIO的PATCH甚至几乎和完成端口是一样的模型，但是仍然被称为是AIO。

????好，谈到这里，希望大家对目前一些主流的IO处理方式有所了解了，那么我们再来看看如何根据不同的需求来选择不同的IO处理方案。

???? 首先考虑到的显然是效率问题，就像刚刚在介绍IOCP时中说的一样，IOCP毫无疑问是任何情况下Windows来解决IO问题的最佳方案，那么 Linux下呢？对于Linux下IO操作的选择应该有些取舍，其关键在于对select/poll/epoll配合非阻塞IO模拟的假AIO和 POSIX系列的真AIO?API之间的取舍。

????在Linux?2.5版本之前，POSIX?AIO几乎没什么特有的优势，因此几 乎所有的基于Linux的网络应用都使用的select/poll/epoll配合非阻塞模拟来实现高效的IO处理方案，但是在Linux?2.5的内核 中，对AIO的支持改进非常大，从而导致使用POSIX?AIO的可能。但是缺点也是显而易见的，由于在内核中对AIO的支持是由和操作系统相关十分紧密 一系列操作系统级的系统调用组成的。导致兼容性上会出现一定的问题，所以，这里的建议是，如果不太理解POSIX?AIO的，最好别贸然选择使用 POSIX?AIO，而是老老实实的用select/poll/epoll配合非阻塞的IO处理方法吧，尽管两者之间的性能差别在目前来说还不算很大，但 是我想随着不断更新的Linux内核，POSIX?AIO会变得越来越好。