EPOLL是半成品，IOCP是成品，底层机制一样，协议栈的状态检查不需要用户去查询，由作业系统来通知。
其实这是任何守护性逻辑高性能的基础机制。
但是EPOLL只是告诉你现在可以读和写，即协议栈的读写缓冲被初始化或重设（对于写，上次数据已经提交并写缓冲重设为空，对于读，栈议栈读缓冲已经开始接受数据。）
但是写和读的过程还是由用户来控制，系统只是告诉你已经为你准备好了和网络驱动对接好的读写的通道。如果某个通道的读写很慢，我们其实自己可以控制，比如要读8K字节，但经过x秒只读到几个字节，这说明这个通道很差，我们可以将这个IO通道从EPOLL中分离出来把它投递到一个阻塞的socket中，而不影响整个EPOLL的性能。所以EPOLL虽然是半成品，但用户有更高的控制权。
而对于IOCP，从名称就可以知道，系统不仅控制IO通道的状态，而且把读写操作都做完了才通知用户。对于读，系统已经把数据读好放在buffer中，其实相当于是RBF，对于写，已经是写出了n长度的字节，所以即使某个IO通道上的传输很慢，你也无法控制，因为当你收到通知时，系统已经是读好数据或写出数据。所以IOCP在用户的控制上没有灵活的空间。
但是由系统来做毕竟比普通的二流以下的程序员自己来控制性能普遍来说要更好一些。
在高性能服务器的开发中，采用一个非阻塞的IO模型配两三个阻塞的socket混合处理，是最合理的，因为在大量连接中总会有一些客户端传输很慢，对于非常慢的连接，EPOLL，IOCP还不如阻塞模型处理性能更好，即时读写速度是一样的，但阻塞模型简单，上下文切换和内存分配的开销比较少。所以把一些很慢的连接重新投递到阻塞的socket上而让EPOLL能有更多的机会去处理传输非常快的连接才是非阻塞的优势。相比来说，IOCP就不能这样做。