nginx非阻塞i/o在https下面临tls握手延迟、加密缓冲延迟、证书验证同步等待及会话复用限制四大挑战，需通过超时控制、缓冲调优、ocsp缓存和会话票据等配置主动适配。
Nginx 的非阻塞 I/O 本身不因协议类型（HTTP 或 HTTPS）而改变行为，但它在处理加密连接时，会因 TLS 层引入的额外开销和状态复杂性，暴露出若干隐性挑战——这些不是非阻塞模型的缺陷，而是其与加密层协同时需主动适配的现实约束。
TLS 握手放大延迟敏感度
非阻塞 I/O 能避免线程卡在 read/write 上，但无法缩短 TLS 握手本身的物理耗时。一次完整的 TLS 1.2/1.3 握手在跨洲际链路上可能消耗 3–5 个 RTT。Nginx 必须在非阻塞前提下，安全地维持握手状态：
- 每个未完成握手的连接仍占用一个 socket fd 和内存上下文，但不会阻塞 worker；
- 若客户端在 ClientHello 后迟迟不发 CertificateVerify（如弱网重传失败），该连接会持续处于“等待就绪”状态，需靠 ssl_handshake_timeout 主动中断，否则可能堆积；
- 启用 ssl_prefer_server_ciphers on 和合理 cipher suite 可减少协商轮次，间接压缩非阻塞等待窗口。
加密缓冲导致流式响应延迟
HTTPS 下，Nginx 在发送响应前需对数据进行 TLS 加密分帧。默认 TLS 记录大小为 16KB，若启用 proxy_buffering on，Nginx 可能攒满缓冲区才触发加密发送，造成数百毫秒“假延迟”，尤其影响 SSE、WebSocket 或 chunked 流式接口：
- 对实时性要求高的接口，建议设 proxy_buffering off 或调小 proxy_buffer_size（如 4k）；
- 禁用 tcp_nodelay off（即保持默认）可合并小包，减少 PSH 包数量，避免 TLS 记录碎片化；
- 大文件传输场景下，启用 sendfile on + tcp_nopush on，让内核在加密前批量组装数据帧，提升吞吐效率。
证书验证与 OCSP Stapling 增加同步等待点
当配置了 ssl_trusted_certificate 或启用 OCSP Stapling（ssl_stapling on），Nginx 在首次 TLS 握手时需校验证书链或获取 OCSP 响应。这部分操作默认是同步阻塞的：
- OCSP 查询若超时（默认无 timeout），会拖慢整个 handshake 流程；务必设置 ssl_stapling_responder 和 ssl_stapling_verify on，并配合 resolver 指令指定 DNS 服务器；
- 建议启用 ssl_stapling_cache shared:StaplingCache:128k 复用 stapling 结果，避免重复查询；
- 若后端证书由私有 CA 签发，确保 ssl_trusted_certificate 文件路径正确且权限受限（仅 nginx worker 可读），否则 handshake 会静默失败。
keepalive 复用受 TLS 会话复用机制制约
HTTP keepalive 减少 TCP 开销，而 HTTPS 还需依赖 TLS session resumption（会话复用）来跳过完整握手。Nginx 默认支持两种机制：
- Session ID：服务端缓存会话密钥，默认开启，但缓存有限且不共享于多 worker；
- Session Ticket：客户端保存加密票据，服务端无需存储，需配置 ssl_session_tickets on 和 ssl_session_ticket_key；
- 若未启用任一机制，每个新请求都会触发完整 TLS 握手，非阻塞 I/O 只能缓解等待，无法消除握手延迟本身。
