转载：https://www.cnblogs.com/leijiangtao/p/5197566.html
https://blog.csdn.net/cnsword/article/details/7161856
一、区别和总结
aio是linux2.6以后内核实现的异步IO，或者说他才是真正意义上的异步IO。
epoll作为select的linux的替代品，解决了selectfd_set的限制。性能优于select。而在mac os x平台上替代方案是kqueue。
libevent是一个跨平台异步解决方案，他根据不同的平台提供了不同的异步方案，采用Reactor模型实现。
Boost::asio是一个跨平台的网络及底层IO的C++编程库，实现了对TCP、UDP、ICMP、串口的支持。对于读写方式，ASIO支持同步和异步两种方式。采用了epoll来实现，插入了大量的信号处理。Asio库不需要单独便于，但是测试过程中对boost::system的依赖可能会需要编译部分boost中的库。
muduo采用Reactor模型实现的网络库，只支持Linux 2.6.x下的并发非阻塞TCP网络编程，不跨平台，不支持udp和ipv6。吞吐量方面muduo比libevent2快18%，在事件处理效率方面，muduo与libevent2总体比较接近，muduo吞吐量比boost.asio高15%以上。性能方面作为解决大数据吞吐量很有优势，但是对平台和网络协议支持方面是一个问题。
ACE也是很经典的网络库，出自《C++网络编程》作者之手，设计精妙程度堪称一流，支持协议范围也很广，但是使用复杂度和学习复杂度较高，一直有“学我者生，用我者死”的评价。
需要注意的是他们的定位不同，aio和epoll主要是对异步提供解决方案不是网络库不提供网络支持，而libevent也是主要解决IO的问题只提供简单的http支持，asio和muduo还有ACE一样是高性能网络库。
二、对比分析
开源C/C++网络库：ACE C++语言 跨平台Boost的ASIO C++语言 跨平台libevent C语言 主要支持linux，新版增加了对windows的IOCP的支持libev C语言 只支持linux，只封装了EPOLL模型层次架构：ACE：底层是OS适配层，上一层C++的wrap类，再上一层框架(Accpetor,Connector,Reactor，Proactor等)，再上一层框架上的服务。Boost的ASIO：底层是OS适配层，上一层一些模板类，再上一层模板类的参数化(TCP/UDP)，再上一层是服务，它只有一种框架io_service。libevent ：libevent在不同OS下，做了多路复用模型的抽象，可以选择不同的模型，通过事件函数提供服务。涉及范围：ACE：ACE包含了日志，IPC，线程池，共享内存，配置服务，递归锁，定时器等。Boost的ASIO：ASIO只涉及到Socket，提供简单的线程操作。libevent ：libevent只提供了简单的网络API的封装， 线程池， 内存池， 递归锁等均需要自己实现。开发难度：ACE：ACE难度较大，必须了解其框架Boost的ASIO：难度适中要求熟悉boost库中的boost::bind，内存管理等libevent ：相对容易发布方式：ACE：ACE不依赖第3方库，以DLL方式提供Boost的ASIO：依赖Boost，使用时只要include头文件，不需要动态库libevent ：一遍编译为静态库使用线程调用：ACE：ACE Reactor是单线程调度，Proactor支持多线程调度。Boost的ASIO：支持单线程和多线程调度。libevent ：线程调度需要自己来注册不同的时间句柄。事件分派处理：ACE：ACE注册handler类，事件分派时，调用其handler的虚挂钩函数，实现ACE_Handler/ACE_Svc_Handler/ACE_Event_handler等类的虚函数。Boost的ASIO：基于函数对象的hanlder事件分派。任何函数都有可能成为hanlder，少了一堆虚表的维护，调度优于ACE。libevent ：基于注册的事件回调函数来实现事件分发设计模式：ACE：ACE 主要应用了Reactor("信号驱动IO")，Proactor(异步IO)Boost的ASIO：Proactorlibevent ：Reactorhttp://wanglimin2004.blog.163.com/blog/static/115488498201271611723476/ZeroMQ：普通socket是端到端，ZeroMQ却可以N:M的关系3种通讯模式： 请求回应模型，请求段发起请求，等待回应端回应请求。 请求端与回应端是1:N的，可以扩展成N:M的。 发布订阅模型，发布端单向发送数据，不关心信息是否都发送给了订阅端。订阅端只负责接收，不反馈。若交互，需要额外的socket采用请求回应模型实现。 管道模型，管道是单向的，从PUSH端单向的向PULL端单向的推送数据流。