一个星期来，仔细分析了muduo的代码，还有学习IOCP的知识。我从未做过通信程序，有许多知识要准备。
我的项目需要给客户提供数据服务，如果用dot NET 或 Tomcat做http接口，我没有信心面对数百万的用户。
boost::asio的例程http server 2 (one io_service per cpu) 用webbench测试，接口性能达到 1.5万pages / 每秒。但boost::asio的cpu占用太高，是nginx的2倍，另外asio的线程池模型使性能下降很多。对boost::asio的代码进行优化后，收效甚微。我看见了boost::asio的瓶颈，但在boost::asio的框架内，我无法解开它的瓶颈。
要想得到理想的IO模型和线程池模型，我必须自己动手设计我的网络库。
从muduo学到了很多东西，特别感谢陈硕，让我这样的门外汉能迅速理解网络通信的要领。
一个星期的日思夜想，我慢慢理清了思路：
- 跨2个平台的网络库：Linux下用epoll，Windows下用IOCP。其它平台不考虑。
- 类似boost::asio，但只专注于TCP。（如果以后有时间，可考虑支持UDT）
- 线程安全，支持多核多线程
- 设计合理的生产者-消费者模型，尽可能减少缓冲区使用、多线程任务分配时的锁等待。
- 既要适合短连接，也要适合长连接。
主要的类：
- muyu::asio::io_service与boost::asio::io_service相同，包含一个reactor（epoll instance 或 完成端口），io_service设计2个线程：一个线程负责轮询和执行任务（或分配任务给线程池），一个线程负责端口操作（accept，add socket等）。
- muyu::asio::channel对用户不可见，负责完成通信任务。调用用户设置的回调函数。
- muyu::asio::socket提供通信接口。
- 连接对象是用户对象，muyu::asio不负责连接对象的管理，与boost::asio类似。让用户管理连接对象，更利于业务逻辑的设计。连接对象必须持有 muyu::asio::socket对象。
- muyu::asio::TcpServer不是必须的，用户只要有io_service、acceptor、socket也能完成通信程序设计，与boost::asio相似。TcpServer类用来封装线程池模型，让使用更简单。
- muyu::asio::socket，muyu::asio::channel，muyu::asio::io_service通过编译选项来选择不同的implement class对象，分别对应Linux和Windows，与boost::asio的做法一致.
明天开始写程序了，希望我的muyu::asio胜过boost::asio
我对缓冲区、任务队列、线程池已有构思，等完成代码测试后，我会拿出来分享。
完成了muyu::asio后，我将在此基础上设计muyu::ice，实现ICE的基本功能。