企业官网建设流程全解析

mbed TLS 2.4.2 构建与配置全指南：特性裁剪、多构建系统与 Monkey HTTP 服务集成

【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit

导读

本文以 fluent-bit 仓库内嵌的 mbed TLS 2.4.2 构建说明 为骨架，系统讲解这一轻量级 TLS/SSL 库在 Linux/BSD/Windows 等平台上的配置、编译与测试方法：包括通过config.h进行功能裁剪、四种构建系统（yotta / Make / CMake / Visual Studio）的使用细节、多构建模式（Release、Debug、ASan、MemSan 等）的选择，以及预置裁剪配置的两种套用方式。读完本文，你将能够独立完成 mbed TLS 的定制编译，并理解它在当前仓库中作为 Monkey HTTP 服务器 TLS 后端（MK_TLS_BACKEND=mbedtls）的集成原理。

一、mbed TLS 是什么，它在这份仓库中扮演什么角色

mbed TLS（ARM mbed TLS）是一个面向嵌入式与资源受限环境的轻量级 TLS/SSL 库，同时提供加密、X.509 证书解析与 TLS 协议实现。它的目标场景决定了它的两大设计取向：

• 可裁剪：所有功能通过 include/mbedtls/config.h 中的宏开关控制，按需启用模块以缩小体积；
• 可移植：仅依赖标准 C 与少量平台抽象，便于移植到不同 OS、架构与编译环境。

在本仓库中，该库位于lib/monkey/deps/mbedtls-2.4.2/，是 Monkey HTTP 服务器 的第三方依赖之一。Monkey 的顶层 CMakeLists.txt 通过MK_MBEDTLS_SHARED（是否使用 mbedtls 共享库）和MK_TLS_BACKEND（TLS 后端：auto/openssl/mbedtls）两个选项接入该库。也就是说，构建 Fluent Bit 时选择 Monkey 的 TLS 后端为mbedtls，即可用这份内嵌源码为 HTTP 服务提供 HTTPS 能力，无需依赖系统 OpenSSL。

从仓库实际快照看，此处保留了configs/、include/、library/三个核心目录（顶层文件列表），对应 README 中“配置、头文件、库源码”三大部分；而programs/（示例程序）、tests/（测试套件）与scripts/（辅助脚本）属于上游完整发行版的组成部分，未随本仓库快照打包，下文涉及时会特别注明。

二、Configuration：一切裁剪从 config.h 开始

mbed TLS 在绝大多数系统上可以直接编译（“build out of the box”）。需要平台定制时，核心入口是带完整注释的配置文件 include/mbedtls/config.h，它同时也是功能开关的选择器：

• 每个MBEDTLS_XXX_C宏对应一个实现模块（如MBEDTLS_AES_C启用 AES、MBEDTLS_SSL_TLS_C启用 TLS 协议栈）；
• 每个MBEDTLS_XXX_ENABLED宏对应一种协议/算法特性（如MBEDTLS_KEY_EXCHANGE_RSA_ENABLED、MBEDTLS_SSL_PROTO_TLS1_2）；
• 关闭不用的模块可以显著减少二进制体积与内存占用，这正是嵌入式裁剪的核心手段。

修改该文件有两种方式：

1. 手工编辑：直接增删#define/#undef；
2. 脚本化修改：使用上游发行版提供的 Perl 脚本scripts/config.pl（--help查看用法），可编程地查询、启用或禁用配置项。

编译器的选择与参数则通过常规环境变量传入，例如CC指定编译器、CFLAGS追加编译选项（在 Make 与 CMake 构建系统下均生效）。README 给出的换编译器示例为：

CC=gcc CFLAGS='-fstack-protector-strong -Wa,--noexecstack' cmake .

其中-fstack-protector-strong开启栈保护，-Wa,--noexecstack标记堆栈不可执行，是面向安全加固场景的典型组合。

需要注意：本仓库的 mbedtls 快照未包含scripts/目录，因此scripts/config.pl仅存在于上游完整发行版中；若要在当前仓库内做配置裁剪，请直接手工编辑 include/mbedtls/config.h。

三、编译：四种构建系统与三大库的依赖关系

mbed TLS 2.4.2 官方维护四种构建系统：

CMake 与 Make 是开发主力，功能始终完整、最新；另外两者不一定自动同步所有新特性。

三大库与链接顺序（Make 与 CMake 均产出以下三个库）：

• libmbedcrypto：底层加密算法库（AES、RSA、ECC、哈希、随机数等）；
• libmbedx509：X.509 证书解析与验证库，依赖libmbedcrypto；
• libmbedtls：TLS/SSL 协议栈，依赖libmbedx509与libmbedcrypto。

依赖链为libmbedtls → libmbedx509 → libmbedcrypto，因此：

• GNU 链接器要求库标志按序书写：-lmbedtls -lmbedx509 -lmbedcrypto；
• 使用dlopen()动态加载共享库时，必须先加载libmbedcrypto，再加载libmbedx509，最后才能加载libmbedtls。

这一结构在仓库的 library/CMakeLists.txt 中有直接印证：它分别构建mbedcrypto、mbedx509、mbedtls三个 target，并声明mbedtls链接libs与mbedx509，最后通过add_custom_target(lib DEPENDS mbedcrypto mbedx509 mbedtls)汇总为统一的lib目标。

3.1 Yotta 构建（mbed OS 场景）

yotta 是 mbed 团队开发的包管理器兼构建系统，也是 mbed OS 16.03 的默认构建方式。安装 yotta 后：

# 从 yotta registry 下载并构建最新 mbedtls yotta install mbedtls yotta build

若已从源码（例如克隆仓库或下载独立发行包）获得一份 mbed TLS，则需要先生成 yotta 模块：

# 在 mbed TLS 项目根目录执行 yotta/create-module.sh # 生成的模块位于 yotta/module 目录 cd yotta/module yotta build

构建前通常还要设置 yotta target（除非已全局设置）。yotta 版默认提供最小化配置文件，且可能根据目标平台在示例与测试中启用 mbed OS 特性。

3.2 Make 构建

mbed TLS 刻意只使用“最小化”的 Make 语法，因为大量 Make 特性在不同实现或平台上并不通用——这意味着在个别平台上，Makefile 可能需要手工微调或设置 export 语句才能正常工作。基本流程：

# 编译 make # 编译并运行测试（测试需要 Perl） make check # 无 Perl 环境时跳过测试构建 make no_test # 仍可运行小规模自检程序（programs/test/selftest）

面向 Windows 平台的两个关键变量：

• WINDOWS_BUILD=1：目标是 Windows，但构建环境是类 Unix（如交叉编译、MSYS shell）时使用；
• WINDOWS=1：构建环境本身就是 Windows shell（如使用 mingw32-make）时使用，此时部分 target 不可用。

其他常用变量：

• SHARED：在静态库之外额外构建共享库；
• DEBUG：进行调试构建；
• CFLAGS/LDFLAGS：可在环境或命令行覆盖，覆盖时-I等关键参数仍会被保留；
• WARNING_CFLAGS：可单独覆盖告警选项。

遇到平台问题时可检查library/、programs/、tests/下的 Makefile，按平台增删选项。

3.3 CMake 构建

CMake 是当前仓库实际使用的构建方式（Monkey 与 Fluent Bit 均以 CMake 驱动）。基本流程：

cmake . make

运行测试：

make test

关键 CMake 选项

关闭测试套件后，若仍保留示例程序，可以用programs/test/selftest运行小规模自检。

安全护栏：CMake 构建在发现配置了MBEDTLS_TEST_NULL_ENTROPY（测试用“空熵源”，完全不适合生产）时会输出醒目警告，并默认以FATAL_ERROR终止构建；只有显式传入-DUNSAFE_BUILD=ON才允许继续。这组逻辑完整地写在 mbedtls-2.4.2/CMakeLists.txt，从中可以读出项目对“配置即安全边界”的坚持。

构建模式（Build Modes），多数适用于 gcc 与 clang，部分为编译器特有：

切换模式示例（Debug）：

cmake -D CMAKE_BUILD_TYPE=Debug .

列出全部可用的 CMake 选项：

cmake -LH

更换编译器/选项需清缓存：CMake 运行过一次后，若想更换编译器或编译选项，必须先清除 CMake 缓存再重新配置：

find . -iname '*cmake*' -not -name CMakeLists.txt -exec rm -rf {} + CC=gcc CFLAGS='-fstack-protector-strong -Wa,--noexecstack' cmake .

（该命令中rm -rf仅清理构建缓存目录，不涉及源码。）

3.4 Microsoft Visual Studio 构建

工程文件面向 Visual Studio 2010 生成：

• 解决方案文件mbedTLS.sln包含构建库与所有程序所需的全部基础工程；
• tests/下的测试文件因需要 Perl 环境，默认不生成、不编译；
• 但programs/test/下的selftest程序仍然可用。

四、示例程序与测试体系

4.1 示例程序（programs/）

上游发行版的programs/目录针对不同特性与使用场景提供了大量示例程序，绝大多数只聚焦单一特性或单一用法，适合作为“拷贝式”学习素材。README 特别提醒：复制其中代码时要注意这一点（组合场景需自行整合）。如前所述，本仓库的 mbedtls 快照未包含programs/目录。

4.2 测试套件（tests/）

mbed TLS 在tests/中内置了庞大的测试套件，其生成机制很特别：

• 测试文件（如test_suite_mpi.c）由两类源文件生成：
  • function 文件（如suites/test_suite_mpi.function）：存放测试函数；
  • data 文件（如suites/test_suite_mpi.data）：存放测试用例，即传给测试函数的参数列表；
• 初始生成需要 Perl，因此 README 才反复强调“测试依赖 Perl”。

在具备 Unix shell 与 OpenSSL（可选 GnuTLS）的机器上，还提供额外测试脚本：

五、configs/：面向特定场景的预置裁剪配置

configs/目录提供若干“非标准”配置，各自聚焦特定使用场景，目标是在满足该场景需求的前提下把资源占用压到最低，可直接作为自定义配置的起点。目录说明见 configs/README.txt。

这些文件是默认config.h的完整替代品。使用方式有两种：

方式一：直接替换默认配置文件

将选中的配置复制/替换为 include/mbedtls/config.h。替换后若编译报错，可能需要在配置文件中调整#include "mbedtls/check_config.h"所在行。

方式二：通过MBEDTLS_CONFIG_FILE宏指定配置文件（推荐，可把自定义配置放在树外）

# Make 方式 CFLAGS="-I$PWD/configs -DMBEDTLS_CONFIG_FILE='<foo.h>'" make

# CMake 方式（先清缓存） find . -iname '*cmake*' -not -name CMakeLists.txt -exec rm -rf {} + CFLAGS="-I$PWD/configs -DMBEDTLS_CONFIG_FILE='<foo.h>'" cmake . make

方式二同样适用于把自定义配置文件放在 mbed TLS 源码树之外的情况——只需让-I指向配置文件所在目录。

本仓库快照中保留了五个示例配置（完整列表见 configs/），它们展示了“按场景最小化”的思路：

• config-mini-tls1_1.h：仅实现 TLS 1.1（RFC 4346）必需密码套件MBEDTLS_TLS_RSA_WITH_3DES_EDE_CBC_SHA的最小配置。从 源码 可以看到它只启用了MBEDTLS_AES_C、MBEDTLS_DES_C、MBEDTLS_RSA_C、MBEDTLS_SHA1_C、MBEDTLS_SSL_PROTO_TLS1_1等少量模块；
• config-ccm-psk-tls1_2.h：面向 PSK（预共享密钥）+ CCM 模式 + TLS 1.2 的组合，配置 中通过MBEDTLS_KEY_EXCHANGE_PSK_ENABLED、MBEDTLS_AES_C、MBEDTLS_CCM_C、MBEDTLS_SSL_PROTO_TLS1_2构建一个紧凑的 PSK 方案，并把MBEDTLS_PSK_MAX_LEN限制为 16 字节（128 位密钥通常够用）；
• config-picocoin.h、config-suite-b.h（Suite B 密码套件）、config-thread.h（多线程场景）则分别对应比特币轻客户端类应用、政府级算法组合、线程安全等不同目标。

这些文件的结构完全一致：先是“系统支持”（如MBEDTLS_HAVE_ASM、MBEDTLS_HAVE_TIME），再是“特性开关”（如MBEDTLS_CIPHER_MODE_CBC、MBEDTLS_KEY_EXCHANGE_XXX_ENABLED），最后是“模块清单”（MBEDTLS_XXX_C）——照此组织方式即可编写自己的精简配置。

六、移植 mbed TLS

mbed TLS 可以移植到众多架构、操作系统与平台。移植前值得先厘清两个问题：目标环境的外部依赖有哪些、配置如何适配新平台。对嵌入式移植而言，重点是MBEDTLS_HAVE_XXX系列宏（是否具备时间、汇编、特定系统调用等能力）与平台相关的熵源实现。在库源码中，与平台打交道的关键文件位于 library/（如entropy_poll.c、net_sockets.c），而对外依赖的声明集中在 include/mbedtls/config.h 中。

七、从构建指南到仓库集成：Monkey 的 TLS 后端选择

回到当前仓库的实际用途：这份 mbed TLS 快照是被 Monkey HTTP 服务器 以“依赖（deps）”形式引入的。Monkey 的 CMakeLists.txt 中与 mbed TLS 直接相关的构建入口为：

option(MK_MBEDTLS_SHARED "Use mbedtls shared lib" No) set(MK_TLS_BACKEND "auto" CACHE STRING "TLS backend: auto, openssl, or mbedtls") set_property(CACHE MK_TLS_BACKEND PROPERTY STRINGS auto openssl mbedtls)

也就是说，构建 Fluent Bit（其内嵌 Monkey 提供 HTTP/TLS 能力）时，可以通过-DMK_TLS_BACKEND=mbedtls强制使用本仓库内置的 mbed TLS，而不是依赖系统 OpenSSL；MK_MBEDTLS_SHARED则决定链接静态还是共享版本。这与 README 中“Make/CMake 会产出 libmbedcrypto / libmbedx509 / libmbedtls 三个库”的说明相互印证——集成方只需按 library/CMakeLists.txt 生成的目标进行链接即可。

因此，在深入 Fluent Bit / Monkey 的 HTTPS 配置之前，先按本文方法完成 mbed TLS 的特性裁剪与编译，是理解其 TLS 栈行为的第一步。

八、小结与上手建议

mbed TLS 2.4.2 的构建哲学可以概括为三条：

1. 配置先行：一切能力由 config.h 的宏决定，裁剪越精准，体积与内存收益越大；
2. 构建系统自治：CMake/Make 是官方主推且始终完整的两条路径，yotta 面向 mbed OS，VS 工程面向 Windows 传统开发者；
3. 测试闭环：function + data 文件生成测试套件的机制，配合ssl-opt.sh、compat.sh等互操作测试，保证了裁剪配置下的正确性。

实际操作建议：

• 在具备 Perl 的机器上用make check/make test跑一遍完整测试，验证环境；
• 需要精简体积时，从 configs/ 挑选最接近的场景配置，用MBEDTLS_CONFIG_FILE方式接入（无需改动默认头文件）；
• 在 Fluent Bit / Monkey 体系中，通过-DMK_TLS_BACKEND=mbedtls选择内置 TLS 后端，即可复用本仓库这一份源码，无需系统级安装依赖。

【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit