以下叙述仅限于网络通信。
所谓完成端口，就是一个队列。
这个队列里面以句柄（网络通信里为socket）为元素，在有消息到达后，通知工作线程（如果队列里的元素有投递请求）进行消息处理。这个流程与select模型相反，select模型是主动查询去获取消息，而iocp则是由windows内核通知工作线程有消息来了你可以进行处理了。
同时，iocp有一个消息队列，其中的每一个消息只会发送给一个工作线程。
具体流程（UDP为例）：
1.创建完成端口；
2.启动工作线程；
3.创建socket并与本地端口绑定；
4.将socket句柄关联到完成端口；
5.投递请求；
6.关闭socket句柄；
7.关闭完成端口；
在上述流程中，对于每个socket句柄，3、4、5、6是必须的。而在每个socket的流程中，5步骤必须重复，因为只有先投递请求才能收到响应。
关于完成端口收到消息后的数据处理。
1.创建IO类，该IO类中有存储数据的链表、消息处理回调函数的地址等信息。在该IO类的启动函数（自定义函数）中，创建存储空间并启动消息处理线程，在该线程中调用回调函数处理存储空间中的数据。
2.每个socket句柄关联一个IO类对象，并把该socket的处理收到的消息的函数的地址传给IO类对象。
3.把在工作线程中收到的消息直接存储到IO类对象中，保证工作线程不会阻塞或者耗费很长时间去处理一个消息。
4.该IO类必须能够自动扩展。比如原来的存储空间为1M，现在已经写满了，却都没有处理，然而消息还在源源不断的到来，此时必须扩展存储空间以容纳更多的消息，当然，如何扩展及扩展多少则根据需求决定。
5.该IO类最好能够自动缩减存储空间，在消息比较少的时候释放部分存储空间。
经测试，在每s一万条消息的情况下，iocp服务工作正常。在每s有8-10万条消息的情况下也能保证每条消息都收到，对比select模型简直堪称完美！
由于是用手机，代码就不提供了。
总结：iocp只是MS提供的一个处理模型，至于具体的消息接收、数据处理等则需要自行实现，对于高并发服务器简直是利器。