比 Protocol Buffers 快无限倍，开源十年后 Cap'n Proto 1.0 终发布

Cap"n Proto 是一种速度极快的数据交换格式和 capability-based RPC 系统，于 2013 年 4 月开源发布。时至今日，Cap"n Proto 1.0 终于发布，这是一个长期支持版本。

【资料图】

Cap"n Proto 项目作者是Kenton Varda —— Protocol Buffers version 2 的主要开发者。他表示，Cap"n Proto 是其多年来开发 Protobufs、听取用户反馈并汲取经验思考反思后的成果结晶。

目前他已离开谷歌，因此“Cap"n Proto 不隶属于谷歌，也从未隶属于谷歌”。基准测试结果表明，Cap"n Proto 比 Protocol Buffers 快无限倍。

自上一个版本 v0.10 以来，新版本的一些亮点内容包括：

针对 Cap"n Proto RPC 性能的一系列优化。其中包括减少 RPC 实现和 KJ I/O 框架的内存分配量，增加从 RPC 协议中省略某些信息以减少流量的功能，以及更好地缓冲一起发送和接收的小信息以减少系统调用。 Breaking change：在此之前，服务器可在调用完成后调用 context.allowCancellation()，选择允许取消 RPC。在 1.0 版中，选择取消 RPC 可通过模式注解（c++.capnp 中定义的 allowCancellation 注解）来实现；模式级注解可以一次对整个文件进行设置。此外，动态选择加入需要大量的簿记工作，在实际使用中会对性能产生明显影响；而改用注释则能提高性能。对于从未使用 context.allowCancellation() 的用户来说，升级到 1.0 版时无需做任何更改，默认情况下仍不允许取消。(如果受到影响，你将看到编译错误。如果没有编译错误，则无需担心）。 KJ 现在在有 kqueue() 的系统（MacOS 和 BSD 衍生版本）上使用它来处理异步 I/O。在 Linux 上，KJ 一直使用 epoll，但在其他类 Unix 平台上，KJ 一直使用较慢的 poll()-based 方法。 KJ 的 HTTP 客户端和服务器实现现在支持 CONNECT 方法。 引入了一个新类 capnp::RevocableServer，以帮助在生命周期不受包装器控制的对象周围导出 RPC 包装器。 以及一些更小的 bug 修复和改进。详情可参阅 PR 历史记录。

在 1.0 版本发布后，2.0 版本的工作也开始提上日程。根据规划，v2.0 旨在对 Cap"n Proto 的 C++ API 及其配套的 KJ C++ 工具包库做出一些改变；以及做一些全面的向后兼容改动以修复一些问题，并改善团队中开发人员的体验。目前的一些想法包括：

需要一个支持 C++20 甚至 C++23 的编译器。Cap"n Proto 1.0 仅需要 C++14。

需要一个支持 C++20 协程的编译器。

Cap"n Proto 的 RPC 应用程序接口、KJ 的 HTTP 应用程序接口和其他程序接口很可能会进行修改，使其更加的coroutine-friendly。

kj::Maybe 将变得更符合人体工学。它将不再重载 nullptr 来表示值的缺失，将引入 kj::none 来代替。KJ_IF_MAYBE 将不再生成指针，而是一个引用（这是利用 C++17 特性实现的一种技巧）。

将放弃对禁用异常情况下的编译的支持。

将放弃对no-RTTI 模式和其他会造成维护负担的特殊模式的支持。

可能会修改 KJ 的引用计数方法，因为目前的设计已被证明对许多用户来说并不直观。

将修复 kj::AsyncOutputStream 中一个长期存在的设计缺陷，目前 EOF 信号是通过销毁流来发出的。取而代之的是将添加一个返回 Promise 的显式 end() 方法。在不调用 end() 的情况下销毁数据流将发出错误的断开信号。(还想对 KJ 流 API 进行其他一些美观改进）。

重新设计几个核心 I/O API，以便更好地适应 Linux 新的 io_uring 事件通知范式。

RPC 实现可能会改为默认允许取消。

值得注意的是，目前还没有计划对序列化格式或 RPC 协议进行任何向后不兼容的更改。所讨论的更改仅影响 C++ API。用其他语言编写的应用程序完全不受这一切的影响。

正式的 2.0 版本短时间内不会推出发布，或许也要等上几年。

更多详情可查看官方公告。

关键词：