blog-website

前言

前段时间集成一些公司内组件的时候发现它依赖 nghttp2 。正好之前一直有给我的构建工具(cmake-toolset)里的构建 curl 的流程加 HTTP/2 和 HTTP/3 的计划。 所以这波一次性搞定了。

首先，curl 是支持多种第三方库作为 HTTP/2 和 HTTP/3（QUIC）算法库的。比如 nghttp3+ngtcp2，或者微软家 msquic，或者Google家 quiche。 其中HTTP/3只能选一个，互相是冲突的。而Google的quiche官方仅有对bazel构建系统的支持，而我的cmake-toolset是cmake生态的。 这里选用 nghttp3+ngtcp2 的组合，主要是为了和其他的模块共享依赖。

另外无论选哪一个HTTP/2 和 HTTP/3（QUIC）算法库，都需要SSL层支持quic算法。那目前官方版本的 openssl 是不支持的。我们可以选用 quictls版本的openssl 或者 boringssl。 其中 quictls版本的openssl 对一些非Google系的开源库支持性更好一些。在 cmake-toolset 中两种都支持，但是我们首选 quictls版本的openssl。

nghttp2,nghttp3和ngtcp2的依赖关系是 ngtcp2依赖nghttp3，nghttp2依赖ngtcp2。由于 cmake-toolset 中增加第三方库的流程已经比较成熟了，所以加这些组件的编译流程并不是什么难事。但是最后集成这个几个库组合起来的时候，还是碰到了一些问题。

nghttp2,nghttp3,ngtcp2构建流程的一些问题

nghttp2,nghttp3和ngtcp2的工程结构很相似，所以问题点也很相似。

首先是我们需要让他们使用我们自己的 openssl 库。它们的构建脚本都可以让我们自己指定 openssl 的位置。在使用 boringssl 的时候，因为使用了非标准的老式引入方式（非cmake CONFIG模式），我们指定 -DBORINGSSL_LIBRARIES=<libraries> 的时候包含多个库文件。 我们的构建系统辅助接口传入到 cmake 的 cmake_parse_arguments 接口的时候始终会被拆成多个参数。比如我们设置 -DBORINGSSL_LIBRARIES=a;b ，传入到 cmake_parse_arguments 接口的时候一定会被拆分成 -DBORINGSSL_LIBRARIES=a 和 b ，无论我用是否加转义。这里借鉴了官方 Moudle ExternalProject 的方式，加了一个类似 LIST_SEPARATOR 的选项，在接口里层做转换。

其次 nghttp2,nghttp3和ngtcp2 的构建流程中，都是通过一个宏来控制他们是否是输出的静态库（ NGHTTP2_STATICLIB ， NGHTTP3_STATICLIB和 NGTCP2_STATICLIB ）。 这些宏和符号导出标记和可见性相关，我们是需要编译时和链接时保持一致的，否则可能会链接的时候符号找不到。 如果按照cmake CONFIG的标准模式来，这些宏应该在install的时候导出到CONFIG文件里，这样下游模块链接的时候就能自动加上这个宏。 但是这几个库的cmake构建脚本都没有根据当前构建的库的类型来处理宏的导出，所以这里我们也需要适配处理一下。而且这里要注意既要在编译时按需加上这些宏，也需要Patch install后的imported target来设置PUBLIC definition 。

另外 nghttp2的构建碰到了一个兼容性问题，它在输出的头文件里直接使用了 ssize_t 这个类型，但是有些平台中，这个类型是不存在的，所以也需要处理适配添加一下。

最后的构建脚本如下:

• https://github.com/atframework/cmake-toolset/blob/main/ports/nghttp2/nghttp2.cmake
• https://github.com/atframework/cmake-toolset/blob/main/ports/ngtcp2/nghttp3.cmake
• https://github.com/atframework/cmake-toolset/blob/main/ports/ngtcp2/ngtcp2.cmake

curl 的Future检测问题

最后在接入到 curl 的时候也碰到了几个问题，基本上都是导致 curl 检测 nghttp2,nghttp3和ngtcp2 失败而最终导致没开开启 HTTP/2 和 HTTP/3（QUIC） 。

一方面针对于上面提到的 nghttp2,nghttp3,ngtcp2 的静态库宏问题和 ssize_t 类型的问题，我也推了个PR到 curl （ https://github.com/curl/curl/pull/10364 ）去适配，还需要等维护者进一步Review之后可能才会合入。目前我在 cmake-toolset 里写了 Patch 文件（ https://github.com/atframework/cmake-toolset/blob/main/ports/libcurl/libcurl-7.87.patch ）来适配。

另外还碰到在Windows平台上，curl 缺失链接了几个 openssl 依赖的系统库，导致检测依赖库的时候链接失败而检测失败，这些库也是补上就好了。整体来说 curl 的整个工程质量还是很高的。

最后

至此，整个适配接入就完成了，可能哪天有空了也我可以试着接入一下 msquic ，这样可选项就更多了。

也欢迎有兴趣的小伙伴互相交流研究。