Why Asio?

（点击 上方公众号 ，可快速关注）

Asio系列文章开写了，希望大家关注。

Asio库大概率会进入 C++23 标准库，是时候该学习一下了。

长久以来，C++最饱受诟病的一点就是缺少一些实用的库，比如，网络库、文件系统、日期库等。而网络库是我们平时最常用的库之一，现在的软件基本上都离不开它。所以有一套标准的网络库是多么的重要，开箱即用，不用在那么多的三方库中做选择，甚至也不用自己实现。

从目前进度来看， Asio 进入C++标准库只是时间问题，大概率会进入 C++23 。最新的提案是2018-10-08的n4771，包含的功能只是目前 Asio 库的子集，后续进入标准库时极有可能增加一些其他功能，比如，将 boost.beast 库加进去，使标准库支持 http/https/websocket 协议。所以，在后续选择网络库的时候应该提高 Asio 库的优先级，这样可以在后续平滑切换到标准库。

优点

与其说 Asio 的优点，不如说标准库的优点。凡是能入C++标准库的，都有以下几个优点：

• 跨平台

  网络库如果只针对某个平台，会极大限制软件向其他平台迁移。这种例子很多，如早期的服务软件使用了Windows下的软件API，后续想迁移到Linux平台，这个迁移成本是很大的，Api的替换只是工作的一部分，大部分的工作是兼容性、稳定性的测试。

  Windows下的socket api虽说和Linux下的socket api大同小异，但高性能的服务器编程用到的其他工具，如定时器、异步、同步等机制都是不同的，迁移成本也是很高的。

  所以，尽可能选择跨平台的网络库，为以后留下变化空间。

• 扩展性

  标准库被设计为其他上层工具的组件，必须要有足够的扩展性。

  横向地说，虽说Asio现在只支持tcp、udp等协议，但通过扩展也可以支持其他协议。

  纵向地说，Asio已经支持了常用地socket 选项，但保留了扩展的能力，后续可以支持更多的选项。

  相比而言，很多轮子的扩展性就一般了，尤其是很多公司内部造的轮子。

• 性能不错

  既然能进标准库，性能肯定不错，所以不要有疑问。而且，相信进入标准库后会有更大程度的优化。

• 无维护成本

  写一个网络库简单，但维护它就是另外一个话题了。很多个人或公司并没有足够的维护自己造的轮子，导致库停滞不前，成为废库，bug、安全漏洞没人修复。

这里并不是说Asio就是万能的，能进标准库，说明能解决绝大部分情况的问题，肯定有一些特殊的情况还是需要自己重新造轮子，这里只是希望能在造轮子之前先考虑以下Asio。

误解

实际上去年在技术选型阶段，我调研过 Asio 库，但看到网上很多评论对它的负面评价，所以并没有使用它。直到今年在进行了一番尝试之后才在正式项目中使用。

网上主要有几个观点：

• 不喜欢 Asio 风格，模板大量使用，代码不易阅读

  准确讲，这不是Asio的缺点，这是C++模板的问题，现在C++标准库的工具都有类似的问题。模板赐予C++更大的表现力，这是不争的事实，两者权衡取其轻，不能因为一些缺点就全盘否定模板。

  好的是，随着concept等工具进入C++，后续模板的一些问题会慢慢得到解决。

• Asio很慢

  这点一开始我还真信了，但通过自己的使用和一些专业的评测结果，实际上这一点子虚乌有的。如果性能真的差很多，只能说明自己的用法不对。抽象会伴随性能的些许降低，但正常情况下不会引起性能陡降。

• Asio依赖 boost

  Asio目前有三种载体，单独的Asio库，和boost捆绑在一起，提案的参考实现。可以看到，Asio是可以脱离boost的，你不必把整个boost引入。而且，以后进入标准库了，开箱即用，就更跟 boost 没关系了。

• 已经有 libevent 、 libev 、 libuv 了，不需要 Asio

  不可否认，它们三者都是优秀的网络库，但它们都是基于 C 语言的。 C++ 在抽象程度上是远远高于 C 的，这决定了同等能力的库，基于 C++ 的库使用更简单，更不易出错。