OceanBase ussl-hook 源码级解析基于 LD_PRELOAD 的 socket 认证与 SSL 传输 Hook 库【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbaseussl-hook 是 OceanBase 仓库deps/ussl-hook目录下的一个独立 C 组件它以动态库形式提供通过 Hook 进程内的listen/accept/connect/read/write等 libc socket 函数在业务代码完全无感知的前提下为任意 TCP 应用注入连接认证 SSL 加密传输能力。本文以 deps/ussl-hook/README.md 为骨架结合其源码实现与 oblib 中的真实集成点讲解它的两种接入方式、ussl-cfg配置目录、自定义 socket 选项协议、双端协商状态机、SSL/国密支持以及它在 OceanBase 网络框架中的落地方式读完即可在自有服务上复现并理解整套认证链路。ussl-hook 是什么根据 deps/ussl-hook/README.md 的定位ussl-hook 的目的是提供一个动态库通过动态库 hook socket listen/accept/connect/read/write 函数实现基本的认证。它的核心思想是不改业务代码应用仍然调用标准的 socket 编程接口ussl-hook 在背后拦截这些调用透明插入认证层连接建立时客户端与服务端在正式业务数据之前先交换一段协商报文约定本次连接采用哪种认证/加密方式可选 SSL 传输协商结果可以是不加密USSL_AUTH_NONE、仅用 SSL 完成握手认证后回落到明文 IOUSSL_AUTH_SSL_HANDSHAKE或全程 SSL 加密 IOUSSL_AUTH_SSL_IO。README 同时预告了config目录即ussl-cfg承载明文 key 认证的配置并预留了一个空的design doc小节下文将基于当前仓库源码把设计细节补全。快速上手两种使用方式方式一LD_PRELOAD 动态库注入README 给出的最简用法是编译出ussl-hook.so用LD_PRELOAD注入到任意程序进程make ussl-hook.so # 终端 1以服务端身份监听 LD_PRELOADussl-hook.so nc -l 8042 # 终端 2以客户端身份连接 LD_PRELOADussl-hook.so nc 127.0.0.1 8042nc -l 8042本身就是一个标准的 socket 服务端nc 127.0.0.1 8042是标准的 socket 客户端。由于 ussl-hook.so 抢先接管了 libc 的 socket 符号两端会在业务数据之前自动完成一次认证协商。为了让.so中的符号确实能覆盖 libc 的同名函数ussl-hook.h 提供了OVERRIDE_SYSCALL编译开关开启后把ussl_setsockopt/ussl_listen/ussl_connect/ussl_accept/ussl_accept4/ussl_epoll_ctl/ussl_write/ussl_read/ussl_close分别重命名为对应的系统调用名setsockopt/listen/connect/...从而在符号表中直接覆盖 libc 版本。这是 LD_PRELOAD 场景下的标准做法。方式二编译期集成到 CMake 工程如果不想走动态库注入可以把ussl-hook.c直接加进自己的 CMakeLists.txt 一起编译并显式调用ussl_*接口此时不定义OVERRIDE_SYSCALL符号保持ussl_前缀#include ussl-hook.h ... ussl_setsockopt(fd, SOL_OB_SOCKET, SO_OB_SET_CLIENT_GID, gid, sizeof(gid)); ussl_connect(fd, addr, addr_len);README 提示参考test/ussl-test.c作为最小示例该文件未收录在当前仓库快照中可直接参考 ussl-hook.c 与 ussl-hook.h 的公开 API 编写。这种方式的典型落地就是 OceanBase 自身deps/oblib/src/rpc/obrpc/ob_listener.cpp在文件末尾直接#include ussl-hook.c将整套实现编入 observerdeps/oblib/src/rpc/obrpc/ob_net_client.cpp 则#include ussl-hook.h使用其 API。配置目录 ussl-cfg 与明文 key 认证README 说明配置目录名为ussl-cfg文件列表如下$ ls ussl-cfg/ authorized enabled key三个文件的语义README 原文key 文件保存的是本端自己的一个随机字符串。key 文件有效时client 会发送认证包authorized 文件保存的是本端认可的 key 列表。当enabled1时server 端会校验收到的 key 是否在 authorized 列表里enabled开关文件控制 server 是否启用 key 校验。也就是说集群内每个节点维护自己的随机key身份凭证同时把信任的节点 key 写入authorized列表客户端发起连接时携带自己的 key服务端在enabled1时校验该 key 是否在授权列表内从而把未授权的节点拒之门外。在头文件 ussl-hook.h 中SOL_OB_CTX层专门预留了两个与此对应的 setsockopt 选项SO_OB_CTX_SET_PLAIN_KEY_DIR设置明文 key 目录与SO_OB_CTX_SET_PLAIN_AUTH_LIST_DIR设置明文授权列表目录可以推断它们就是运行时把ussl-cfg/key与ussl-cfg/authorized的目录路径注入到 hook 层的入口。从源码结构看明文 key 认证的协商形态与下方介绍的 SSL 协商共用同一套协商报文 状态机框架只是认证载荷从证书换成了随机 keyhandle-event.c 中定义的USSL_SCRAMBLE_LEN 16、USSL_MAX_KEY_LEN 16常量即为该场景预留。核心机制一libc 函数解析与 Hook 入口dlsym(RTLD_NEXT) 解析原始函数被 Hook 之后ussl-hook 内部必须还能调用真正的 libc 函数否则会陷入无限递归。ussl-deps.c 通过构造函数constructor(101)优先级 101最先执行用dlsym(RTLD_NEXT, listen)等方式一次性解析出全部原始函数指针保存为libc_listen、libc_connect、libc_accept、libc_accept4、libc_epoll_ctl、libc_read、libc_write、libc_writev、libc_close、libc_setsockopt等全局变量声明见 ussl-deps.h。此后所有ussl_*包装函数只调用这些libc_*指针形成业务代码 → ussl_* → libc_*的干净调用链。构造函数初始化除了 libc 函数指针解析还有两个构造函数负责初始化 hook 层自己的状态ussl-hook.c的init_global_array()constructor(102)ussl-hook.c把USSL_MAX_FD_NUM1024×1024大小的三张全局表初始化global_gid_arr每 fd 对应的 GID默认UINT64_MAX表示未设置、global_client_ctx_id_arr每 fd 的客户端 SSL 上下文 ID、global_send_negotiation_arr每 fd 是否需要发送协商报文ssl_config.c的setup()constructor(103)ssl_config.c初始化 SSL 上下文数组gs_ssl_ctx_array[SSL_CTX_ID_MAX][2]、fd→SSL 映射gs_fd_ssl_array及读写锁。三个构造函数按 101 → 102 → 103 的优先级顺序执行保证原始函数指针 → fd 状态表 → SSL 状态依次就绪。被 Hook 的 API 全景ussl-hook.h 暴露的完整接口为ussl_stop()、ussl_wait()、ussl_setsockopt、ussl_listen、ussl_connect、ussl_accept、ussl_accept4、ussl_epoll_ctl、ussl_read、ussl_write、ussl_writev、ussl_close。各函数的职责要点函数职责ussl_setsockopt拦截自定义的SOL_OB_SOCKET/SOL_OB_CTX选项其余选项透传给libc_setsockoptussl_listen把监听 fd 注册进后台事件循环由后台线程负责 acceptussl_connect先走libc_connect附带自连接检测设置了 GID 的连接返回EINPROGRESS转入异步协商ussl_accept/ussl_accept4从后台线程的 pipe 中读取已协商完成的 fdpipe 场景否则透传libc_accept4ussl_epoll_ctl对设置了 GID 的 fd 且EPOLL_CTL_ADD时把 fd 交给后台协商线程接管其余透传ussl_read/ussl_write/ussl_writev根据 fd 是否处于 SSL 状态分流到SSL_read/SSL_write或 libc 原生读写ussl_close清理 RPC 连接类型标记、禁用 fd 上的 SSL 对象再调用libc_close核心机制二自定义 socket 选项协议ussl-hook 没有引入新 API 函数来传参而是复用了setsockopt的调用形式但使用两个自定义 levelussl-hook.h 定义SOL_OB_SOCKET -1面向单个 fd 的选项与SOL_OB_CTX -2面向全局上下文的选项。SOL_OB_SOCKET 层按 fd 维度enum SocketLevelOptname { SO_OB_SET_CLIENT_GID 1, // 客户端连接归属的组 GID SO_OB_SET_SERVER_GID 2, // 服务端监听 GID SO_OB_SET_CLIENT_SSL_CTX_ID 3, // 客户端使用的 SSL 上下文 ID SO_OB_SET_SERVER_SSL_CTX_ID 4, // 服务端使用的 SSL 上下文 ID SO_OB_SET_SEND_NEGOTIATION_FLAG 5 // 是否发送协商报文 };实现位于 ussl-hook.c 的 ussl_setsockopt客户端 GID 与 SSL 上下文 ID 会按 fd 写入global_gid_arr/global_client_ctx_id_arr服务端 SSL 上下文 ID 写入线程局部变量ussl_server_ctx_id。ussl_setsockopt还有两个隐含动作懒启动后台线程通过ATOMIC_BCAS(is_ussl_bg_thread_started, 0, 1)保证第一个调用者负责拉起协商后台线程ussl_init_bg_thread参数校验fd 必须落在[0, USSL_MAX_FD_NUM)ctx_id 不能为负非法输入返回EINVAL并记录日志。SOL_OB_CTX 层全局维度enum CtxLevelOptName { SO_OB_CTX_SERVER_AUTH_METHODS 1, // 服务端支持的认证方法位掩码 SO_OB_CTX_CLIENT_AUTH_METHODS, // 客户端支持的认证方法位掩码 SO_OB_CTX_SET_PLAIN_KEY_DIR, // 明文 key 目录对应 ussl-cfg/key SO_OB_CTX_SET_PLAIN_AUTH_LIST_DIR, // 明文授权列表目录对应 ussl-cfg/authorized SO_OB_CTX_SET_SSL_KEY_DIR, // SSL key 目录 SO_OB_CTX_SET_SSL_CONFIG, // SSL 证书配置ssl_config_item_t };认证方法位掩码来自 UsslAuthMethodsenum UsslAuthMethods { USSL_AUTH_NONE 1, // 不加密仅协商 USSL_AUTH_SSL_HANDSHAKE 2, // 仅用 SSL 握手完成身份认证业务数据仍走明文 USSL_AUTH_SSL_IO 4 // 认证 业务数据全程走 SSL 加密 };两端默认值在 auth-methods.c 中定义客户端默认USSL_AUTH_NONE服务端默认三种全部支持NONE | SSL_HANDSHAKE | SSL_IO。设置时会先经过ussl_check_methods校验ussl-hook.c只允许 1/2/4 的组合位。set_server_auth_methods直接写全局变量set_client_auth_methods使用原子 store读取端协商线程则用原子 load保证跨线程可见性。核心机制三后台事件循环与协商状态机后台线程与事件循环ussl_setsockopt首次被调用时启动后台线程ussl_loop线程名由ob_set_thread_name(ussl_loop)指定见 ussl-loop.c。初始化流程ussl_init_bg_threadussl-loop.c创建一对非阻塞、O_CLOEXEC的 pipeclient_comm_pipe并尝试通过F_SETPIPE_SZ把管道容量扩到 128KB初始化事件循环uloop_t内部持有ussl_eloop_t ep自研 epoll 封装、IPv4/IPv6 两个监听 fd 集合、pipe fd 与超时双向链表通过ob_pthread_create拉起bg_thread_func。客户端 fd 的移交是关键设计业务线程调用ussl_epoll_ctl(epfd, EPOLL_CTL_ADD, fd, ...)且该 fd 设置了 GID 时ussl_epoll_ctl 不会真正注册到业务 epoll而是调用ussl_loop_add_clientfd把client_fd_info_t含 GID、SSL ctx_id、协商标志、auth_methods、原 epfd、原 event 等写入client_comm_pipeussl-loop.c。后台线程从管道读出后接管该 fd完成协商/SSL 握手再把 fd 挂回业务原来的 epoll。这就是业务代码感知不到认证过程的关键协商期间 fd 暂时从业务 epoll 摘除由 ussl 后台线程独占处理。服务端 fd 的回传同理后台线程 accept 到新连接并完成协商后把 fd 写入另一对管道业务线程的ussl_accept/ussl_accept4检测到传入的 fd 是 FIFOussl_is_pipeussl-hook.c时直接从管道读出协商好的 fdussl-hook.c。客户端协商流程客户端 fd 的状态机定义在 handle-event.cenum ClientNegoStage { SEND_FIRST_NEGO_MESSAGE 1, // 已发送首个协商报文 DOING_SSL_HANSHAKE 2, // 正在进行 SSL 握手 };流程handle_client_writable_eventhandle_client_readable_eventhandle-event.c连接可写后先getsockopt(SO_ERROR)确认连接成功把事件从EPOLLOUT改为EPOLLIN根据客户端 auth_methods 决定是否发送协商报文USSL_AUTH_NONE时仅当显式设置了send_negotiation标志才发送SSL 模式则始终发送发送negotiation_message_ttype client_gid然后等待对端读到对端报文后若 type 为 SSL 模式调用fd_enable_ssl_for_client创建 SSL 对象并开始SSL_do_handshakeEAGAIN时进入DOING_SSL_HANSHAKE阶段等待下次可读事件继续握手握手成功ssl_do_handshake返回 0即把 fd 归还业务 epoll客户端侧认证完成。客户端对本机回环地址127.0.0.1有特殊处理发送协商报文后直接归还 fd不进入超时等待handle-event.c避免本地调试链路被认证流程卡住。服务端协商流程服务端状态机handle-event.cenum ServerNegoStage { SERVER_ACCEPT_CONNECTION 1, // 刚 accept等待首个报文 SERVER_ACK_NEGO_AND_AUTH 2, // 已确认协商准备认证 SERVER_ACK_NEGO_AND_SSL 3, // 已确认协商准备 SSL 握手 };服务端首包处理acceptfd_handle_first_readable_eventhandle-event.c是整套认证的核心判断逻辑recv(MSG_PEEK)偷看首包校验NEGOTIATION_MAGIC若首包不是协商报文老客户端/第三方工具按以下优先级决定是否放行服务端启用了USSL_AUTH_NONE源地址是本机回环地址是 net keepalive 协商报文is_net_keepalive_connection见下文放行通道开启了 RPC 认证 bypassussl_get_auth_bypass_flag()则所有连接放行否则仅当原始包解码出的 pcode 属于 TableAPI 范围时放行ob_judge_is_tableapi_pcode_from_raw_packet放行时设置OB_CONNECTION_AUTH_BYPASS_TYPE连接标记并归还 fd不放行则直接关闭连接若首包是协商报文解析negotiation_message_t.type——USSL_AUTH_NONE服务端支持该模式则归还 fd否则在 bypass 开启时标记放行其余拒绝USSL_AUTH_SSL_IO/USSL_AUTH_SSL_HANDSHAKE校验服务端支持列表与ssl_config_ctx_id是否已配置然后fd_enable_ssl_for_server创建服务端 SSL 对象、回发协商 ACK进入SERVER_ACK_NEGO_AND_SSL阶段acceptfd_handle_ssl_eventhandle-event.c持续驱动SSL_do_handshake完成后归还 fd 并打印客户端 GID。超时与异常处理为防止恶意或故障连接长期占住后台线程协商设置了 3 秒超时TIMEOUT_THRESHOLD_SEC 3ussl-loop.c。check_and_handle_timeout_eventussl-loop.c遍历超时链表客户端连接超时则shutdown(SHUT_WR)并从 epoll 摘除、归还业务 epoll 由业务侧自行关闭服务端连接超时则直接关闭 fd。超时节点挂在timeout_link上通过 ussl-deps.h 实现的双向链表与ussl_structof容器反推宏统一管理。此外客户端侧ussl_connectussl-hook.c还内置了自连接检测connect成功后通过getsockname对比本地地址与目标地址若相同进程连到了自己则返回EIO并告警若该 fd 设置了 GID则无论 connect 结果如何都返回EINPROGRESS让业务按异步连接处理由后台线程完成后续协商。三类特殊放行通道从 handle-event.c 与 oblib 配套代码可以还原出服务端在无协商报文场景下的三种例外通道本机回环is_local_ip_address匹配127.0.0.1本地运维/调试连接直接放行net keepaliveis_net_keepalive_connection实现于 ob_net_keepalive.cpp识别 OceanBase 内部心跳协商报文NET_KEEPALIVE_MAGIC保证集群心跳链路不受认证影响TableAPI / bypassob_judge_is_tableapi_pcode_from_raw_packetob_rpc_authentication_utility.cpp从原始 RPC 包中解码 pcode判断是否为 TableAPI 请求ob_is_bypass_pcode同文件 L27-L38进一步覆盖 libobcdc、standby 集群等特殊 pcode。开启认证 bypass 后这些连接被标记为OB_CONNECTION_AUTH_BYPASS_TYPE后续ussl_check_pcode_mismatch_connection会校验 bypass 连接上的实际 pcode 是否越权。协商消息协议协商报文格式定义在 message.h 与 message.c#define NEGOTIATION_MAGIC 0xbeef0312 // 报文魔数 #define MAX_EXTRA_INFO_LEN 20 #define USSL_BUF_LEN 256 typedef struct negotiation_head_t { // 固定 12 字节头部 uint32_t magic; uint32_t version; uint32_t len; // 载荷长度 } negotiation_head_t; typedef struct negotiation_message_t { // 载荷体 int type; // UsslAuthMethods 之一 uint64_t client_gid; // 客户端组 GID } negotiation_message_t;send_negotiation_messagemessage.c将头 载荷拼入 256 字节缓冲后一次性libc_write写出当前版本号USSL_DEFAULT_VERSION 1写失败返回-EIO。接收侧在 handle-event.c 用MSG_PEEK先偷看头部、校验 magic 与长度完整性再正式recv消费避免半包导致状态错乱。client_gid字段则把协商中的连接与业务侧的线程/分组调度关联起来——oblib 的 pnio 网络栈在 inet.c 中正是用SO_OB_SET_CLIENT_GID把dispatch_id注入 fd协商完成后再据此把 fd 分发给对应的工作线程组。SSL 加密传输与国密支持SSL 上下文管理ssl_config.c 维护两组核心状态gs_ssl_ctx_array[SSL_CTX_ID_MAX][2]SSL_CTX_ID_MAX 10个上下文槽位 × 客户端/服务端两个角色SSL_ROLE_CLIENT/SSL_ROLE_SERVER通过读写锁保护支持ssl_load_config热更新旧 ctx 被SSL_CTX_free替换gs_fd_ssl_array[FD_MAX]fd → SSL 对象映射FD_MAX 100w记录SSL *、握手完成标记与认证类型仅握手 or 全 IO 加密。创建 SSL 上下文时ob_ssl_create_ssl_ctxssl_config.c的关键策略客户端SSL_VERIFY_NONE不强制校验服务端证书服务端SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT强制校验对端证书缺证书直接握手失败——这保证了只有持有合法证书的客户端才能通过认证OpenSSL 1.1.1 显式关闭 TLS 1.3SSL_OP_NO_TLSv1_3并关闭SSL_OP_NO_RENEGOTIATION预置了经过筛选的 TLS 密码套件列表tls_ciphers_listssl_config.c排除aNULL/eNULL/EXPORT/LOW/MD5/DES/RC2/RC4/PSK等弱套件以 ECDHE/ECDSA/AES-GCM 系列为主在OB_USE_BABASSL编译开关下支持国密使用NTLS_method()SSL_CTX_enable_ntls(ctx)密码套件列表baba_tls_ciphers_list增加了ECC-SM2-WITH-SM4-SM3与ECDHE-SM2-WITH-SM4-SM3签名证书/加密证书sign/enc 双证书分别加载。证书配置结构typedef struct ssl_config_item_t { int is_from_file; // 证书来源1文件路径0内存字符串 int is_sm; // 是否国密SM2/SM4/SM3 const char *ca_cert; // CA 证书 const char *sign_cert; // 签名证书 const char *sign_private_key; // 签名私钥 const char *enc_cert; // 加密证书国密模式必填 const char *enc_private_key; // 加密私钥国密模式必填 const char *ssl_invited_nodes; // 需要开启 SSL 的 observer 列表 } ssl_config_item_t;ob_ssl_config_checkssl_config.c强制校验ca_cert、sign_cert、sign_private_key非空国密模式下enc_cert/enc_private_key也必须提供。加载路径支持两种来源is_from_file1时走SSL_CTX_use_certificate_chain_file/SSL_CTX_use_PrivateKey_file等文件接口否则从内存 BIO 解析 PEM。CA 校验模式通过SSL_CTX_load_verify_locations文件或X509_STORE_add_cert内存注入服务端还会设置SSL_load_client_CA_file客户端 CA 列表。加密读写路径fd 一旦绑定 SSL 对象fd_enable_ssl_for_server/fd_enable_ssl_for_clientssl_config.c后续read/write/writev全部走 SSL 通道write_regard_sslL705-L720有 SSL 走SSL_write否则libc_writeread_regard_sslL747-L794循环SSL_read直到填满缓冲区或出现EAGAIN精确处理SSL_ERROR_WANT_READ返回EAGAIN、SSL_ERROR_ZERO_RETURN对端关闭返回ECONNRESET等语义writev_regard_sslL796-L846逐个 iovec 调用SSL_write累积已写字节EAGAIN时保留部分写入结果EIO时整体失败。USSL_AUTH_SSL_HANDSHAKE模式下ssl_do_handshake成功后立即fd_disable_sslssl_config.c 与 L496-L513只把 SSL 当作一次性认证通道握手完成即释放 SSL 对象后续业务 IO 回落到明文——这正是认证与加密分离设计集群节点间可以用一次性握手完成双向身份认证再按需决定业务数据是否加密。ussl_close也会调用fd_disable_ssl确保 fd 关闭时 SSL 资源正确释放。在 OceanBase oblib 中的集成ussl-hook 不是孤立的实验代码而是 OceanBase 网络栈的正式组成部分集成证据集中在deps/oblib编译接入deps/oblib/src/CMakeLists.txt 把deps/ussl-hook与deps/ussl-hook/loop加入头文件搜索路径客户端接入inet.c 的async_connect依次调用ussl_setsockopt(fd, SOL_OB_SOCKET, SO_OB_SET_CLIENT_GID, ...)注入 dispatch_id、SO_OB_SET_CLIENT_SSL_CTX_ID、SO_OB_SET_SEND_NEGOTIATION_FLAG再ussl_connect监听侧则使用ussl_setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, ...)、ussl_listen(fd, 1024)等接口同文件 L63-L91即把 ussl 的协商能力挂接在 pnio 网络框架之上服务端接入ob_listener.cpp 通过ussl_accept(listen_fd_, NULL, NULL)获取协商完成的连接并在 L433 直接#include ussl-hook.c编译整套实现配套判定逻辑ob_is_bypass_pcode、ob_judge_is_tableapi_pcode_from_raw_packetob_rpc_authentication_utility.cpp与is_net_keepalive_connectionob_net_keepalive.cpp以extern C形式提供被 handle-event.c 的服务端首包裁决逻辑调用构成完整的认证 例外放行策略。可见 ussl-hook 的定位是在 OceanBase 的 pnio / rpc 网络层之下、libc socket 之上用透明的 hook 机制统一实现集群节点间的连接认证与可选的 SSL 加密同时保留对 TableAPI、libobcdc、心跳等特殊链路的旁路通道。总结回顾 deps/ussl-hook/README.md 与源码实现可以提炼出 ussl-hook 的完整技术画像接入成本极低既可用LD_PRELOADussl-hook.so零侵入注入任意程序配合OVERRIDE_SYSCALL符号覆盖也可作为普通源文件编入 CMake 工程、显式调用ussl_*API配置语义清晰ussl-cfg目录的key本端随机身份串、authorized信任的 key 列表、enabled是否开启服务端校验三文件构成明文认证的完整配置面头文件中的SO_OB_CTX_SET_PLAIN_KEY_DIR/SO_OB_CTX_SET_PLAIN_AUTH_LIST_DIR与其对应机制分层扎实dlsym(RTLD_NEXT)解析原始函数 → 自定义SOL_OB_SOCKET/SOL_OB_CTXsetsockopt 协议传递配置 → 后台 epoll 事件循环 pipe 完成 fd 的接管与归还 → 12 字节协商头 载荷体完成双端握手 → 可选 SSL/国密通道承载业务 IO生产可用细节丰富3 秒协商超时、自连接检测、本机回环/keepalive/TableAPI 三类旁路、SSL_VERIFY_PEER双向认证、TLS 弱套件过滤以及 OB_USE_BABASSL 下的 SM2/SM4/SM3 国密支持均已沉淀在 oblib 网络栈的真实调用链中。对于希望在自己的分布式系统里无侵入地加一层连接认证的开发者ussl-hook 的协商报文设计、fd 移交管道与状态机实现是极具参考价值的范本而阅读其与 oblib 的集成点也能帮你更完整地理解 OceanBase 集群节点间 RPC 连接的安全模型。【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
