4． 完成端口的根基流程
5． 完成端口的使用详解
6． 实际应用中应该要注意的处所
一． 完成端口的长处
1. 我想只要是写过或者想要写C/S模式网络处事器真个伴侣，都应该或多或少的听过完成端口的台甫吧，完成端口会丰裕操作Windows内核来进行I/O的调理，是用于C/S通信模式中性能最好的网络通信模型，没有之一；甚至连和它性能接近的通信模型都没有。
2. 完成端口和其他网络通信方法最大的区别在哪里呢？
(1) 首先，如果使用“同步”的方法来通信的话，这里说的同步的方法就是说所有的操纵都在一个线程内挨次执行完成，这么做错误谬误是很明显的：因为同步的通信操纵会梗阻住来自同一个线程的任何其他操纵，只有这个操纵完成了之后，后续的操纵才可以完成；一个最明显的例子就是咱们在MFC的界面代码中，直接使用梗阻Socket挪用的代码，整个界面城市因此而梗阻住没有响应！所以我们不得不为每一个通信的Socket都要成立一个线程，多麻烦？这不坑爹呢么？所以要写高性能的处事器措施，要求通信必然要是异步的。
(2) 列位读者必定知道，可以使用使用“同步通信(梗阻通信)+多线程”的方法来改进(1)的情况，那么好，想一下，我们好不容易实现了让处事器端在每一个客户端连入之后，都要启动一个新的Thread和客户端进行通信，有几多个客户端，就需要启动几多个线程，对吧；但是由于这些线程都是处于运行状态，所以系统不得不在所有可运行的线程之间进行上下文的切换，我们本身是没啥觉得，但是CPU却痛苦不堪了，因为线程切换是相当浪费CPU时间的，如果客户真个连入线程过多，这就会弄得CPU都忙着去切换线程了，根柢没有几多时间去执行线程体了，所以效率长短常低下的，认可坑爹了不？
(3) 而微软提出完成端口模型的初衷，就是为了解决这种"one-thread-per-client"的错误谬误的，它丰裕操作内查东西的调理，只使用少量的几个线程来措置惩罚惩罚和客户真个所有通信，消除了无谓的线程上下文切换，最大限度的提高了网络通信的性能，这种神奇的效果具体是如何实现的请看下文。
3. 完成端口被广泛的应用于各个高性能处事器措施上，例如著名的Apache….如果你想要编写的处事器端需要同时措置惩罚惩罚的并发客户端连接数量有数百上千个的话，那不用纠结了，就是它了。
二． 完成端口措施的运行演示
首先，我们先来看一下完成端口在笔者的PC机上的运行表示，笔者的PC配置如下：
梗概就是i7 2600 + 16GB内存，我以这台PC作为处事器，简单的进行了如下的测试，通过Client生成3万个并发线程同时连接至Server，然后每个线程每隔3秒钟发送一次数据，一共发送3次，然后不雅察看处事器真个CPU和内存的占用情况。
如图2所示，是客户端3万个并发线程发送共发送9万条数据的log截图
图3是处事器端接收完毕3万个并发线程和每个线程的3份数据后的log截图
最关键是图4，图4是处事器端在接收到28000个并发线程的时候，CPU占用率的截图，使用的软件是台甫鼎鼎的Process Explorer，因为相对来讲这个比自带的任务打点器要准确和精确一些。
我们可以发明一个令人惊讶的功效，给与了完成端口的Server措施(蓝色横线所示)所占用的CPU才为 3.82%，整个运行过程中的峰值也没有赶过4%，是相当气定神闲的……哦，对了，这还是在Debug环境下运行的情况，如果给与Release方法执行，性能必定还会更高一些，除此以外，在UI上显示信息也很大成都上影响了性能。
相反给与了多个并发线程的Client措施(紫色横线所示)居然占用的CPU高达11.53%，甚至赶过了Server措施的数倍……
其实无论是哪种网络操模型，对付内存占用都是差不久不多的，真正的分歧就在于CPU的占用，其他的网络模型都需要更多的CPU动力来支撑同样的连接数据。
虽然这远远算不上处事器极限压力测试，但是从中也可以看出来完成端口的实力，而且这种方法比纯粹靠多线程的方法实现并发资源占用率要低得多。
三． 完成端口的相关观点
在开始编码之前，我们先来讨论一下和完成端口相关的一些观点，如果你没有耐心看完这段大段的文字的话，也可以跳过这一节直接去看下下一节的具体实现部分，但是这一节中涉及到的根基观点你还是有须要了解一下的，而且你也更能知道为什么有那么多的网络编程模式不用，非得要用这么又庞大又难以理解的完成端口呢？？也会坚定你继续学习下去的信心^_^
3.1 异步通信机制及其几种实现方法的对照
我们畴前面的文字中了解到，高性能处事器措施使用异步通信机制是必需的。
而对付异步的观点，为了便利后面文字的理解，这里还是再次简单的描述一下：