轉載：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：Proactor
libevent ：Reactor
http://wanglimin2004.blog.163.com/blog/static/115488498201271611723476/
ZeroMQ：
普通socket是端到端，ZeroMQ卻可以N:M的關系
3種通訊模式：
請求回應模型，請求段發起請求，等待回應端回應請求。 請求端與回應端是1:N的，可以擴展成N:M的。
發布訂閱模型，發布端單向發送數據，不關心信息是否都發送給了訂閱端。訂閱端只負責接收，不反饋。若交互，需要額外的socket采用請求回應模型實現。
管道模型，管道是單向的，從PUSH端單向的向PULL端單向的推送數據流。