C++
也许你还不清楚
C++网络库领域的复杂局面。虽然libevent确实表现不错，但别忘了还有libev，那么asio是否能够支持QUIC？另外，HTTP和WebSocket的封装是否已经足够完善？从这些疑问中可以看出，需求本身是相当混乱的，而需要实现的协议种类也极为繁杂。此外，可能你尚未意识到，当前市面上有许多功能强大的网络库。例如
Meta（原
Facebook）推出的fb-Thrift、Apache Thrift、
百度的Brpc（作者为@戈君）、
腾讯的Tars，以及FunPlus/云上曲率开发的FPNN。网络上的两位知名技术博主——@陈硕 的muduo和@韦易笑 的kcp，同样在这一领域颇具影响力。当然，还有许多其他优秀的库。值得注意的是，像libevent和Thrift这样的库，并不属于同一个层次或类别。这里涉及到一些细节问题，比如网络库的分层结构：API集合 → IO库（IO封装） → 网络库 → 网络引擎 → 网络框架 → RPC框架 → 后端引擎 → 分布式系统框架等。如果按照这种层次逐步封装，最终的整体性能往往会因为过多的封装层次而显著下降。例如，在开发RPC框架时，与其使用封装了网络引擎的网络框架，不如直接调用最底层的API集合，甚至可以跳过IO封装库。一个典型的例子是
Java中的netty。即使不考虑netty在
C++中的底层实现，在
Java生态系统中，基于netty二次封装的高层库或框架，其性能通常无法与直接利用NIO精心设计的库或框架相媲美。同样的情况也适用于
C++环境。再以kcp为例，尽管大家普遍认为kcp主要用于UDP通信，但如果仔细阅读原作者的文档就会发现，其实TCP同样可以适用。kcp的设计并未严格绑定到特定的传输协议（如UDP或TCP）。因此，在实际应用中，我们应当更加灵活地看待这类工具。现在回到主题，首先需要明确两个关键问题：1. 如果将某个库加入标准库，应该选择哪个层次？是IO封装、网络引擎、RPC框架、后端引擎还是分布式服务框架？2. 以
Java为例，
SpringCloud是否可以被视为标准库的一部分？如果是的话，又该如何定位dubbo？假设我们决定将libevent纳入标准库，那asio怎么办？毕竟它们处于同一层次，且asio隶属于boost，后者本就是标准库的潜在候选者之一。如果目标是引入RPC框架，那么是选择fb-thrift、apache-Thrift、Brpc还是Tars？这显然会直接牵涉到各方的利益关系。假如标准库中包含HTTP支持，但缺乏TLS或OpenSSL集成，那么当需要实现HTTPS时，开发者是否仍需手动拼凑解决方案？这些问题进一步凸显了在
C++网络库领域制定统一标准的复杂性和挑战性。
