、IOCP(Io Completion Port的缩写)
当使用并发模型的服务应用程序实现在Windows NT上时，Windows NT小组注意到这些应用程序的性能并没有预料的那么高。特别的，处理很多同时的客户请求意味着很多的线程并发地运行在系统中。因为所有这些线程都是可运行的（没有被挂起和等待发生什么事），Microsoft意识到Windows NT内核花费了太多的时间来转换运行线程的上下文，线程就没有得到很多CPU时间来做他们的工作。
要使Windows NT成为一个强大的服务器环境，Microsoft就需要解决这个问题。解决的方法是一个称为I/O完成端口的内核对象，它首次在Windows NT3.5中被引入。I/O完成端口的理论基础是并行运行的线程数目必须有一个上限，即有500个同时的客户请求，并不意味着有500个运行的线程。但并发运行的合适的线程是多少呢？读者只要思考一下，就会意识到如果一台机器有两个CPU，那么有多于两个的可运行线埕就没有意义了。一旦可运行的线埕数目超过CPU的数目，系统就不得不花费时间来进行线埕上下文的切换，这将会浪费宝贵的CPU周期。
并行模型的另一个低效之处是为每一个客户请求创建了一个新线埕。创建线埕比起创建进程来开销要小，但也远不是没有开销。如果当应用程序初始化时创建了一个线埕池，而这些线埕在应用程序执行期间是空闲的，应用程序的性能就能进一步提高。I/O完成端口就使用线埕池。 摘自《Window高级编程指南 第三版》I/O完成端口
2、问题
很显然，一个网络程序的性能和网卡的能力，网卡驱动的能力，系统的IO能力都有关系
实验机器大致配置如下：
A.intel 2.4(单核心) 512M内存 Via VT6105 网卡
B.intel 3.0(双核心) 1G内存 intel 100M网卡 (服务器)
C.amd 1800+ 512M内存 81xx网卡
客户端采用 堵塞IO
服务器用 IOCP
C作为客户端连接A, 建立230个连接, 服务器每秒总共收5500个包,发5500个包，网络占用55%
每个包大概1k,这个时候,
A机器的CPU 占用达 50%
而C的CPU占用<10%
而完成端口这个时候的表现非常奇怪，不是传说中的scalable
在200个连接也就是 3000-4000个包的时候，cpu <10%
后面处理的包增多的时候,cpu占用呈指数上升，很快到 100%
A一共是2,3个线程, C一共是231个线程
如果是这种情况，那连接 < 500的时候 还不如用堵塞模型？ nt系统，对thread的处理很好
如果一个iocp每秒只能收发5500个包，那么也太少了？
完成端口==高性能??
