关于 C/C++ boost::asio 的一些须知

在 C/C++ 之中异步事件及网络库，建议直接统一采用 boost::asio、不要去自己手写 kqueue、epoll、iocp，这不会带来多大的性能提升。

国内很多所谓的大牛都在说 aiso 性能差，不要在意别人的看法，在绝大多数需要网络编程的场景里面 asio 的吞吐性能足够用。

如果大家真要追求所谓的单机网络吞吐性能（装13 geek），直接DPDK来处理是最快的，解决方案无外乎以下几种：

1、DPDK + VPP

2、DPDK + 多核LWIP

上述是假设处理TCP，UDP根本不需要带协议栈，DPDP+自己手写就行了，想要多少个核来彪性能就多少个核来彪，DPDK多队列模式就可以。

SOCKET用户层编程接口还要切入内核，哪有直接DPDK零拷贝来的快，不是要秀儿，追求网络吞吐效率嘛？

关于对 C/C++ asio 网络吞吐还有效能的童鞋，不要关心这个问题，在现代涉及到网络的绝大多数程序之中，瓶颈就不在 asio。

我不否认，aiso 在 Windows 上面效率会比较好，但 Linux 增加一层兼容包袱，跟你自己做没有区别，该有的CPU算力开销是不会少的。

asio 最大的问题是该框架库，一股STL标准库的尿性，晦涩难懂，大量的模板元编程，但库的使用者们几乎不会去关注它内部的实现，因为 asio 已经在无数个大型项目之中得到验证，稳定性绝对是有保障的，毕竟是 C/C++ 标准委员会的网络候选库。

asio 官方提供的默认示例代码是一个 io_context（io_service）被多个线程驱动，这个例子本身是没有问题的。

缺点只不过是每个 io_context 都有一个事件队列互斥体（CS临界区/同步锁），所以对于 asio 来说。

如果想要获得理论最大性能，每一个线程单独驱动一个 io_context 是比较合理的，但我本人在这里会一定层度，不认同这个观点。

每一个线程单独驱动一个 io_context 的确是可以解决线程锁导致的CPU上下文的问题，但也带来了一个全新的问题。

举个例子：

现在存在一个场景，网络IO负载很高，如果是多线程驱动一个 io_context，那么就可以获得多核并行吞吐效率，而每一个线程驱动一个 io_context，若某一个线程驱动的 io_context 同时需要处理得吞吐量CPU负载过高，那么必定导致该线程负载积压，迫使承载得TCP吞吐效能下降。

即对于CPU得利用率很难达到圆满，如果我们希望榨干所有的CPU机能，那么必定就会涉及到多线程交叉收发 socket 得情况（这里仅仅以 socket 网络IO为例）

首先我们要知道 iocp 是怎么被驱动得，（asio 是统一平台事件及网络库，统一为 iocp/proactor edsm 事件驱动状态机模型）

在 windows 平台上面，大家希望 iocp 获得最大网络吞吐效率，那么必定需要多个线程对同一个完成端口（主）调用

GetQueuedCompletionStatus 函数来获取队列的完成状态，那么对于完成端口锁得应用是在内核态完成得。

在 asio 之中单线程情况下，aiso 没有锁得开销，只有函数步入栈帧得开销，那么 Windows 平台上面，asio 得性能基本于裸写 iocp 队列得效率差不太多。

在 linux 下面，多线程也可以对于同个 epoll（主文件描述符句柄）进行 epoll_wait 等待，多线程之间得同步是在内核态完成，那么这部分开销是不算得。

同理在：

在 asio 之中单线程情况下，aiso 没有锁得开销，只有函数步入栈帧得开销，那么 linux 平台上面，asio 得性跟裸写 epoll 并且补齐 epoll 未完成得那部分得效率开销也不会差太多。

那么 asio 得问题在哪里是在多线程同时驱动一个 io_context 得情况下，但要取决于场景及情况，如果只是做单收测试，那直接用 epoll 更快，但是如果涉及到收发处理、转发处理，这未必，在多线程得情况下，无论用原生还是非原生，你都会涉及到锁得同步，效率一样会有影响。

访问公共资源锁开销都少不了，只是 aisio 相对多了一层 io_context 队列公共锁，如果你非要说这能影响多大得效率，这个我个人不敢苟同。

并且绝大多数网络编程之中，人们需要关注得更多是其核心域，而不是在网络底层上面各种折腾，因为即便是十几年前得CPU都可以轻松跑千兆，单核走 socket，TCP单核即便没有千兆，500兆都是随便有的。

找一个没多大问题得云服务器VPS，ASIO单核2Gbps、3Gbps 都是没多大问题得，所以，我一直不知道这些人所谓得纠结点在哪里，或许是单纯得找点纯在感，显示自己得优越性？

我还是那句话，不要在乎它们得看法，它们得看法并不重要，重要的是合不合适，技术没有好坏之分，存在即合理，如果是我，我是不愿意不会采用 libevent、libuv、或者用原生 kqueue、iocp、epoll 之类的来实现。

boost::asio 吞吐效率这块足够用、并且统一平台API兼容细节，这可以显著得减少成本，大家在这些没有必要浪费过多精力得上面折腾，这并没有太大实际意义。

补充：

一个好的建议是多线程同时驱动同一个 io_context，为每个线程单独分配一个 strand，而不是每个线程一个 io_context，这样才可以真正得把多线程吞吐效能利用起来，而不是某一个线程可能挤压过多的CPU负载。

这点无论是自己手写原生还是用什么 libuv、libevent 库做这块的正确做法，其它做法有一定道理，但并不一定多，具体场景需要具体分析，严格来说作为一个开发人员是需要动点脑子的。