OpenSSL 在 Windows 上的网络轮询与 IOCP 适配分析从 WSAPoll/select 到 memory BIO 的实践指南【免费下载链接】opensslGeneral purpose TLS and crypto library项目地址: https://gitcode.com/GitHub_Trending/ope/openssl导读Windows 平台的 socket API 与 POSIX 存在一系列有趣的差异没有原生poll(2)WSAPoll(2)长期存在缺陷而高性能 I/O 必须依赖 IOCPI/O Completion Ports这一与轮询范式完全不同的完成通知模型。本文基于 OpenSSL 仓库 doc/designs/ddd/WINDOWS.md 的官方设计文档系统分析 Windows 网络轮询的历史与现实、IOCP 与轮询模型的本质差异并逐一评估 DDDDemo-Driven Design演示驱动设计系列示例在 Windows 下的适配性最后结合 ddd-05-mem-nonblocking.c 与 ddd-06-mem-uv.c 的源码给出memory BIO 打通 IOCP这一经过验证的实战方案。读完本文你将理解为什么 libssl 不需要也无法直接支持 IOCP以及如何在自己基于 OpenSSL 的应用中接入 Windows 异步 I/O 模型。Windows 网络轮询的现实poll(2) 缺失与 select() 的另类语义WSAPoll(2)一个迟到的、曾经有缺陷的替代品在 POSIX 平台上应用可以调用poll(2)系统调用以位掩码bitmask的方式批量监听文件描述符FD的可读、可写与错误事件。但Windows 并不提供poll(2)系统调用。微软在 Vista 中引入了WSAPoll(2)本意是补齐这一能力然而它携带一个微软拒绝修复的 bug使其在很长一段时间内形同虚设。直到 Windows 10 的某个构建版本该 bug 才终于被修复。由此得到的结论是WSAPoll(2)在今天是一种可行的方案但仅适用于较新版本的 Windows。对于需要兼容老系统的应用它并不是一个安全的默认选择。select()Windows 版其实更接近 POSIX poll()在传统上Windows 上的轮询工作一直由select()承担。但与 POSIX 平台相比select()的调用方式存在一个重要差异POSIXselect()接收一个 FD 位掩码bitmaskWindowsselect()接收一个内嵌固定长度 socket 句柄数组的结构体。这种差异并非设计者的任性而是由 Windows 的对象模型决定的——Windows 上的 socket 是 NT 内核句柄NT kernel handles并非像 FD 那样连续分配因此无法用简单的位掩码表达。讽刺的是正因为如此Windows 的select()在语义上非常接近 POSIX 的poll()——它们都是在给定的一组 socket 句柄上等待事件。所以对 Windows 开发者而言select()一直是轮询polling场景下可行的选择。IOCPWindows 的高性能异步模型与轮询范式不相容为什么 select()/poll() 都不是高性能选项无论是select()还是poll()都属于就绪通知readiness notification模型内核告诉应用某个 socket 现在可以读/写了应用随后自行发起实际的数据读写。这种模型在多连接、高吞吐场景下存在可扩展性瓶颈这也是 Linux 上 epoll、BSD/macOS 上 kqueue 应运而生的原因。而在 Windows 上系统不提供任何类似 epoll 或 kqueue 的机制。官方给出的高性能网络 I/O 路径是I/O Completion PortsIOCP。轮询报告就绪IOCP 报告完成文档 WINDOWS.md 点明了两种模型最本质的区别轮询polling报告的是就绪readiness而 IOCP 报告的是操作完成completion of an operation。在 IOCP 模型下你对 socket 发起一次读或写当该读/写真正完成时一个完成事件才会被投递到关联的 IOCP 队列。这是一种与轮询根本不同的模型从概念上讲它更像 libuv 这类高层异步 I/O 库的工作方式libuv 内部在 Windows 上正是基于 IOCP 实现的。为什么在 IOCP 之上做轮询几乎不可能文档给出了一个非常精辟的工程观察IOCP 是一种比轮询更高层的接口——在轮询之上构建一个 IOCP 风格的接口是容易的你可以在可读/可写事件触发后立即发起 I/O并在完成时投递完成事件但在 IOCP 之上构建一个轮询风格的接口却几乎不可能因为轮询要求应用在事件循环中主动询问现在能不能读而 IOCP 只能在异步操作结束后通知你二者无法互相模拟。正是这种阻抗失配impedance discontinuity导致现实中绝大多数异步 I/O 库内部都维护着两套实现一套基于轮询用于 Linux/macOS 等一套基于 IOCP用于 Windows。文档明确列举了libuv 与 nanomsg作为例子——与其费尽心思弥合两种模型的差异不如分别为轮询式 I/O 反应器和IOCP 式实现各写一份代码这反而更简单、更可靠。逐一评估DDD 系列示例在 Windows/IOCP 下的适用性DDDDemo-Driven Design是 OpenSSL 项目为支撑 QUIC 等 API 演进而维护的一套代表性 API 用法示例目录说明见 doc/designs/ddd/README.md。WINDOWS.md 对其中 6 个示例在 Windows IOCP 场景下的适用性逐一给出了结论示例类型IOCP 适用性评估ddd-01-conn-blocking.cS-BIOc阻塞不适用阻塞式示例IOCP 无从谈起ddd-02-conn-nonblocking.cA-BIOc非阻塞不支持socket 由 OpenSSL 管理IOCP 不受支持ddd-03-fd-blocking.cS-AOSF阻塞不适用阻塞式示例IOCP 无从谈起ddd-04-fd-nonblocking.cA-AOSF非阻塞不支持libssl 经BIO_set_fd拿到 FDBIO_s_sock不支持 overlapped I/Oddd-05-mem-nonblocking.cA-BIOmmemory BIO可行应用完全掌控 memory BIO 与网络间的数据搬运可自由使用 IOCPddd-06-mem-uv.cA-BIOmmemory BIO libuv已证明libuv 在 Windows 上内部使用 IOCP直接验证了该路径阻塞示例ddd-01 / ddd-03与 IOCP 无关ddd-01-conn-blocking是最简单的阻塞式用法应用通过BIO_new_ssl_connect(ctx)创建连接 BIO把名称解析、连接建立乃至 TLS 握手全部交给 OpenSSL 内部处理对应BIO_s_connect家族即 README 中的 BIOc 模式。ddd-03-fd-blocking则是应用自己创建 socket 并通过SSL_set_fd交给 libssl 的阻塞版本AOSF 模式。阻塞模型本身与异步完成通知的 IOCP 属于不同世界因此文档的结论直截了当IOCP 不适用not applicable。ddd-02-conn-nonblockingsocket 归 OpenSSL 管IOCP 无门该示例的非阻塞版本中连接建立同样由BIO_s_connect驱动socket 的生命周期由 OpenSSL 内部管理应用拿不到可自行支配的 socket 句柄来发起异步 I/O因此文档判定IOCP 不受支持。如果应用需要 IOCP这条路从入口处就堵死了。ddd-04-fd-nonblockingBIO_s_sock 与 overlapped I/O 的鸿沟ddd-04-fd-nonblocking中应用自行创建 socket再通过BIO_set_fd把 FD 交给 libsslAOSF 模式。文档给出的关键判断是BIO_s_sock似乎不支持 overlapped即基于 IOCP 的I/O因为这会要求使用专门的WSASend()和WSARecv()函数而不是标准的send()/recv()。也就是说Windows 上要接入 IOCP必须以 overlapped 句柄 WSASend/WSARecv发起 I/O而BIO_s_sock实现在 crypto/bio/bio_sock.c 等文件中走的是标准send()/recv()路径两者无法兼容。文档在此补充了一个很务实的推论既然 libssl 的BIO_s_sock本来就不支持 IOCP那么任何正在使用BIO_s_sock的应用显然本身也没有在尝试使用 IOCP——因此我们完全不必为如何把 ddd-04 适配到 IOCP而担忧。这类应用的 I/O 模型与 IOCP 天然互斥保持现状即可。ddd-05-mem-nonblocking应用掌控一切IOCP 大门敞开ddd-05-mem-nonblocking是文档给出的 IOCP 可行路径由于应用完全掌控数据在 memory BIO 与网络之间的搬运无论是从网络读入再喂给 memory BIO还是从 memory BIO 取出再写出到网络应用完全可以按自己的意愿使用 IOCP。这为后续两个示例奠定了理论基础。memory BIO 方案源码剖析把 libssl 当作纯状态机ddd-05-mem-nonblocking.c 展示了这一模式的核心结构。其设计哲学在文件头注释中写得很清楚应用向 OpenSSL 传入 memory BIO意味着它既控制解密侧数据何时从 SSL 对象读写也控制网络加密数据何时送入/取出 OpenSSL。这样 OpenSSL 就被当作一个不做任何自身网络 I/O 调用的纯状态机它永远不会看到或创建任何网络 socket 的文件描述符。连接结构双向内存管道typedef struct app_conn_st { SSL *ssl; BIO *ssl_bio, *net_bio; int rx_need_tx, tx_need_rx; } APP_CONN;在new_conn()中应用通过 BIO 对BIO pair把 libssl 与网络彻底解耦BIO *internal_bio, *net_bio; if (BIO_new_bio_pair(internal_bio, 0, net_bio, 0) 0) { ... } SSL_set_bio(ssl, internal_bio, internal_bio);BIO_new_bio_pair创建一对双向内存缓冲区 BIO实现在 crypto/bio/bss_bio.cinternal_bio挂在 SSL 对象内部供 libssl 读写加解密数据net_bio留在应用手中用于与真实网络 socket 交互。libssl 从始至终只跟内存打交道网络字节流的进出完全由应用的read_net_tx/write_net_rx两个函数驱动分别对应BIO_read(net_bio, ...)与BIO_write(net_bio, ...)。值得一提的 QUIC 差异可见 REPORT.md编译时定义USE_QUIC时demo 改用BIO_new_bio_dgram_pair以获得带数据报datagram语义的双向内存 BIO保证 QUIC 报文的边界不被破坏同时文件注释明确警告QUIC 下应用用于缓冲数据报的缓冲区若小于 1472 字节必须调整否则报文会被截断行为类似read(2)。非阻塞收发WANT_READ / WANT_WRITE 驱动的状态记录tx()与rx()是非阻塞收发的核心它们通过SSL_get_error识别SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE并记录反向需求int tx(APP_CONN *conn, const void *buf, int buf_len) { l BIO_write(conn-ssl_bio, buf, buf_len); if (l 0) { rc SSL_get_error(conn-ssl, l); switch (rc) { case SSL_ERROR_WANT_READ: conn-tx_need_rx 1; /* 想写却需要先读 → 等 POLLIN */ case SSL_ERROR_WANT_CONNECT: case SSL_ERROR_WANT_WRITE: return -2; /* 等价 EWOULDBLOCK */ default: return -1; /* 错误 */ } } else { conn-tx_need_rx 0; } return l; }rx()对称地维护rx_need_tx。随后get_conn_pending_tx()/get_conn_pending_rx()把这两个状态翻译成应用事件循环需要的 poll 事件POLLIN/POLLOUT/POLLERR。对于 QUIC 构建事件判定改由SSL_net_read_desired/SSL_net_write_desired两个 API 驱动详见 REPORT.md 对 API 演进过程的记录。把 libssl 接上任意事件循环最后demo 中的pump()展示了应用侧的事件循环胶水层用net_rx_space()BIO_ctrl_get_write_guarantee与net_tx_avail()BIO_ctrl_pending决定要不要监听可读/可写事件然后网络可读时read(fd, ...)读入字节 →write_net_rx(conn, ...)喂给 libssl网络可写时read_net_tx(conn, ...)取出 libssl 产出的密文 →write(fd, ...)送出。这个pump内部的poll()调用在 Windows 上完全可以替换为select()/WSAPoll()甚至替换为IOCP 的异步读写——因为 demo 已经不再让 libssl 触碰任何 socket网络侧用什么 I/O 模型完全由应用决定。这正是 ddd-05 能够兼容 IOCP 的根本原因。实战验证memory BIO libuv 组合ddd-06libuv 与 IOCP 的关系ddd-06-mem-uv.c 将上面的模式搬到了libuv之上。libuv 是 Node.js 使用的异步 I/O 库在 Windows 上其内部正是基于 IOCP 实现而在 Unix 系平台基于 epoll/kqueue。因此libssl memory BIO libuv这个组合在 Windows 上运行时libssl 之上叠着的正是一条 IOCP 链路——它直接证明了 memory BIO 方案可以支撑 IOCP 场景。关键实现要点demo 的结构比 ddd-05 更工程化引入了上层写请求UPPER_WRITE_OP与网络层写请求LOWER_WRITE_OP两个队列上层写app_write()→write_deferred()把应用数据封装成UPPER_WRITE_OP入队随后try_write()循环调用SSL_write若返回SSL_ERROR_WANT_READ例如 TLS 重协商或 QUIC 流控该 op 留在队中待后续事件到达时由handle_pending_writes()续写。网络层写flush_write_buf()从net_bio读走 libssl 产出的密文封装为LOWER_WRITE_OP通过uv_write()TLS 场景或uv_udp_send()QUIC 场景交给 libuv完成回调net_write_done()释放缓冲并继续flush_write_buf()。网络层读net_read_done()在 libuv 读事件到达时把收到的字节BIO_write进net_bio再驱动handshake_ssl()或on_rx_push()内部SSL_read取出明文并回调应用。QUIC 定时器#ifdef USE_QUIC分支用SSL_get_event_timeout()获取事件处理截止时间通过uv_timer_t周期性调用SSL_handle_events()实现 QUIC 时钟驱动同样见 REPORT.md。这套双层队列 BIO 对 事件回调的骨架就是文档所说的用 memory BIO 支持 IOCP 用法的完整可运行示范。文档的外部佐证WINDOWS.md 还提到一个来自社区实践的观察粗略浏览 GitHub 上的代码可以发现人们确实在使用 IOCP 搭配 libssl 时几乎都是通过传入 memory BIO 的方式实现的。因此 ddd-05 与 ddd-06 本质上就是在复现这一真实用例尤其 ddd-06 在 Windows 上内部就直接走 IOCP是这一结论的最强证明。构建与运行把 demo 跑起来验证Makefile 提供了完整的构建规则每个 demo 都会生成-tls与-quic-DUSE_QUIC两个变体ddd-%-tls: ddd-%.c $(CC_CMD) ddd-%-quic: ddd-%.c $(CC_CMD) -DUSE_QUIC ddd-%-uv-tls: ddd-%-uv.c $(CC_CMD) -luv ddd-%-uv-quic: ddd-%-uv.c $(CC_CMD) -luv -DUSE_QUIC要点编译链接-lcrypto -lssl头文件路径为-I../../../include相对于 doc/designs/ddd 目录构建ddd-06-mem-uv需要 libuv 库与头文件Ubuntu 上安装libuv1-dev即可链接共享库运行时需把 libcrypto/libssl 加入库路径例如LD_LIBRARY_PATH../../.. ./ddd-01-conn-blocking-tls运行需要默认证书库可用必要时可设置SSL_CERT_DIR。结论与工程建议WINDOWS.md 给出的最终结论清晰而克制既然 libssl 本身就不支持 IOCP我们不必对此特别担忧但在最坏情况下总有可行的解决方案——正如 demo 5 和 demo 6 所示。整理成工程建议即阻塞式应用ddd-01/ddd-03 模式与 IOCP 无关维持现状即可无需改造socket 由 OpenSSL 管理的非阻塞应用ddd-02 模式本就不在 IOCP 路径上无需纠结应用自己持有 socket 的应用ddd-04 模式BIO_s_sock只走send()/recv()无法 overlapped如果确实需要 IOCP应转向 memory BIO 方案需要 IOCP 的高性能应用采用 ddd-05/ddd-06 的 memory BIO 模式让 libssl 做纯状态机网络侧自由选择select()、WSAPoll()或完整的 IOCP 异步 I/O。ddd-06 已用 libuvWindows 上即 IOCP证明了这条路的可行性。这套结论并非局限于 Windows——memory BIO 模式同样是把 OpenSSL 接入任意第三方异步框架libuv、libevent、自研事件循环的通用钥匙也是 OpenSSL 为 QUIC 时代准备的 API 用法基线参见 REPORT.md 中对各 demo 的 QUIC 适配记录。【免费下载链接】opensslGeneral purpose TLS and crypto library项目地址: https://gitcode.com/GitHub_Trending/ope/openssl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考