gRPC 构建时如何启用 SSL 汇编优化以避免加密流处理性能损失？
【免费下载链接】grpcC++ based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc
如果你从源码编译 gRPC C++，构建过程中 SSL 库有时会以OPENSSL_NO_ASM选项编译，即禁用汇编代码。根据 doc/ssl-performance.md 的说明，这样做在处理加密流时会让性能损失达一个数量级（"by an order of magnitude"）。这篇文章面向从源码构建 gRPC C++ 的读者，目标是选对构建系统和构建组合，让最终使用的 SSL 库带上汇编优化，避免这种性能损失。以下所有结论均来自仓库内的 doc/ssl-performance.md 与 BUILDING.md。
先对照官方矩阵：你的构建组合是否启用了汇编优化
doc/ssl-performance.md 给出了 gRPC C++ 各构建系统对汇编优化的支持情况：
| 构建系统 | 条件 | 平台 | 使用汇编优化 |
|---|---|---|---|
| Makefile | 使用 OpenSSL 1.0.2 开发文件 | all | 是 |
| Makefile | 其他所有情况 | all | 否 |
| Bazel | Linux | 是 | |
| Bazel | MacOS | 是 | |
| Bazel | Windows | 否 | |
| CMake | boringssl from submodule（默认） | Linux 或 MacOS | 是 |
| CMake | boringssl from submodule（默认），generator=Ninja | Windows | 是 |
| CMake | boringssl from submodule（默认），generator=Visual Studio | Windows | 否 |
| CMake | 预装 OpenSSL 1.0.2+（gRPC_SSL_PROVIDER=package） | all | 是 |
对照这张表可以得出两条选择原则：
- Linux / MacOS 上，CMake（默认走 boringssl submodule）和 Bazel 默认就带汇编优化，无需额外配置；
- Windows 是唯一需要主动选择的平台：Bazel 不带汇编优化，CMake 则取决于生成器——Visual Studio 生成器不带，Ninja 生成器才带。
准备条件
按 BUILDING.md 的要求：
- 克隆仓库时包含子模块（CMake 构建需要从子模块编译 boringssl；Bazel 使用不同的依赖模型，不需要手动下载子模块）：
$ git clone -b RELEASE_TAG_HERE <你的 grpc 仓库地址> $ cd grpc $ git submodule update --init其中RELEASE_TAG_HERE替换为你要构建的发布标签，<你的 grpc 仓库地址>替换为你实际使用的 grpc 仓库地址。
- 平台依赖（以下命令会安装系统包，需要相应权限）：
- Linux：
[sudo] apt-get install build-essential autoconf libtool pkg-config，使用 CMake 时另需[sudo] apt-get install cmake - Windows：Visual Studio 2022 或更高版本（提供 Visual C++ 编译器）、Git、CMake，以及 BUILDING.md 明确标注"required by boringssl"的 NASM（加入
PATH）；Ninja 为可选项
- Linux：
CMake 主路径：Linux / MacOS（默认即启用汇编优化）
在 grpc 仓库根目录（已初始化子模块）下执行 BUILDING.md 给出的命令：
$ mkdir -p cmake/build $ cd cmake/build $ cmake -DCMAKE_CXX_STANDARD=17 ../.. $ make这里../..指向仓库根目录的 CMakeLists.txt。CMake 构建中 SSL 依赖由gRPC_SSL_PROVIDER控制，其默认值就是module（见 CMakeLists.txt 第 75 行），即从third_party/boringssl-with-bazel子模块构建 BoringSSL——这正是官方矩阵中标记为"使用汇编优化"的组合，因此 Linux / MacOS 上不需要任何额外开关。
如果希望改用系统预装的 OpenSSL，官方矩阵中标记为可用汇编优化的条件是"预装 OpenSSL 1.0.2+"，对应 CMake 变量为gRPC_SSL_PROVIDER=package（可参考 BUILDING.md 中-DgRPC_SSL_PROVIDER=package的用法示例）。
Windows CMake：用 Ninja 生成器才能获得汇编优化
这是本主题下最需要主动操作的一条路径。doc/ssl-performance.md 的矩阵明确区分了两种 Windows 生成器：
- Visual Studio 生成器：不使用汇编优化；
- Ninja 生成器：使用汇编优化。
而 cmake/ssl.cmake 揭示了 Ninja / Visual Studio 生成器下汇编优化实际生效的两个前提，CMake 版本不低于 3.13，并且能在PATH中找到 NASM。缺任意一项时，CMake 会发出警告并回退为禁用汇编（即设置OPENSSL_NO_ASM）：
- CMake 低于 3.13 时：
WARNING "Disabling SSL assembly support because CMake version ${CMAKE_VERSION} is too old (less than 3.13)" - 找不到 NASM 时：
WARNING "Disabling SSL assembly support because NASM could not be found"
所以配置方法是：先确认 NASM 已安装并在PATH中（BUILDING.md 给出的安装方式是choco install nasm），CMake 版本不低于 3.13，然后按 BUILDING.md 的 Ninja 流程构建：
@rem Run from grpc directory after cloning the repo with --recursive or updating submodules. cd cmake md build cd build call "%VS170COMNTOOLS%..\..\VC\Auxiliary\Build\vcvarsall.bat" x64 cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 ..\.. cmake --build .其中%VS170COMNTOOLS%是 Visual Studio 2022 安装后提供的环境变量，命令原样来自 BUILDING.md；使用 Ninja 仍需已安装 Visual C++ 编译器。
验证方式：configure 阶段的输出就是判据——出现上述两条警告中的任何一条，说明该次构建的 SSL 汇编优化已被禁用（分别对应 CMake 过旧、NASM 缺失，按前提条件修复后重新 configure）；两条警告均未出现，则按官方矩阵该组合使用汇编优化。
如果当前只能使用 Visual Studio 生成器（命令见 BUILDING.md：cmake -G "Visual Studio 17 2022" -DCMAKE_CXX_STANDARD=17 ..后cmake --build . --config Release），按矩阵该路径不使用汇编优化，文档未提供在该生成器下开启汇编的选项。
Bazel 路径：Linux / MacOS 默认启用，Windows 不启用
doc/ssl-performance.md 的矩阵中，Bazel 在 Linux 与 MacOS 上标记为使用汇编优化，在 Windows 上不启用。BUILDING.md 将 Bazel 列为首选构建系统，在仓库根目录执行：
# Build gRPC C++ $ bazel build :all注意事项（均来自 BUILDING.md）：
- 需要 Bazel 1.0.0 或更高版本；
- 如果使用 Bazel 7 或更高版本，需要给 Bazel 命令加上
--enable_bzlmod=false，因为 gRPC 尚未完全兼容 bzlmod。
也就是说，如果你的构建必须跑在 Windows 上且目标是带汇编优化的 SSL，Bazel 不是可行组合，应回到 CMake + Ninja 路径。
Makefile 路径与预构建包的边界
- Makefile：只有"使用 OpenSSL 1.0.2 开发文件"这一条件才启用汇编优化，其他情况均不启用。同时 BUILDING.md 已声明
make不再是推荐构建系统，仅作内部用途，因此不建议为此专门走 Makefile 路径。 - 其他语言的包（C#、Node.JS、Electron、ObjC、PHP、Python、Ruby）：doc/ssl-performance.md 单独列了矩阵。其中 C#、Node.JS、Python、Electron 的多数 64 位 Linux / MacOS 组合带汇编优化，而 C# Linux 32 位、Node.JS Windows、Python Linux 32 位 / MacOS 32 位 / Windows、Ruby、PHP 非源码包、ObjC 源码包（iOS）均标记为不启用；PHP 从源码构建则等同于上面的 Makefile 情况。如果你消费的是这些语言的分发包而非自己编译 gRPC C++，选型时应以这张表为准。
小结
- Linux / MacOS：CMake 默认（
gRPC_SSL_PROVIDER=module，boringssl 子模块）或 Bazel 构建即可得到带汇编优化的 SSL，无需额外配置； - Windows：必须用 CMake + Ninja 生成器，且满足 CMake ≥ 3.13、NASM 在
PATH中两个条件，configure 输出中若出现 "Disabling SSL assembly support" 警告即表示回退到OPENSSL_NO_ASM； - 构建矩阵之外的语言分发包，按 doc/ssl-performance.md 的语言/平台表核对，不要假定所有分发物都带汇编优化。
需要深入了解构建细节可继续查阅 BUILDING.md 的完整构建说明，以及 cmake/ssl.cmake 中 SSL provider 的处理逻辑。
【免费下载链接】grpcC++ based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
