HTTPS性能压测与调优是系统性工作，需协同优化连接复用、密钥交换（如启用ECDHE-ECDSA）、证书链精简、OCSP Stapling缓存、内核参数（tcp_tw_reuse）及HTTP/2流控匹配，最终实现握手耗时降67%、QPS升3.2倍。
HTTPS 性能压测与调优不是单纯提升 TLS 握手速度，而是围绕连接复用、密钥交换效率、证书链优化和内核参数协同展开的系统性工作。该平台在双十一前发现 HTTPS 请求平均延迟上升 42%，首字节时间（TTFB）毛刺明显，最终通过分层定位与精准干预，将 TLS 握手耗时降低 67%，QPS 提升 3.2 倍。
聚焦 TLS 层：从握手耗时定位瓶颈压测初期使用openssl s_time和curl -w发现 85% 的 HTTPS 请求握手耗时 >120ms，远超 HTTP 的 8ms。抓包分析显示，大量连接卡在 ServerHello 后等待 Certificate 消息，且 ClientKeyExchange 出现重传。进一步确认是服务端证书链过长（含 4 级中间 CA）+ 默认启用 RSA 密钥交换导致 CPU 解密压力集中。禁用 RSA、强制启用 ECDHE-ECDSA-AES128-GCM-SHA256 后，单核 TLS 握手吞吐从 1.8k/s 提升至 5.3k/s。
连接复用策略：让 keepalive 真正“活”起来Nginx 默认 keepalive_timeout=75s，但压测中发现大量连接在 30s 内被客户端主动关闭，造成重复握手。调整为：• u ps tream keepalive 1024（非默认的 32）
• client_header_timeout / client_body_timeout 统一设为 30s• 启用ssl_buffer_size 4k减少小包碎片• 在 ALB 层开启 HTTP/2 并限制 SETTINGS 帧频次，避免流控引发队头阻塞实测复用率从 41% 提升至 89%，TLS 握手请求数下降 76%。
内核与 OpenSSL 协同调优观察到大量 TIME_WAIT 连接堆积（峰值 24 万），且ss -s显示 retransmit 失败率突增。根本原因在于：• net.ipv4.tcp_tw_reuse = 0（未启用）
• OpenSSL 1.1.1f 默认未启用SSL_MODE_RELEASE_BUFFERS• TLS record 层缓冲区未适配高并发场景
修复动作：
• 开启 tcp_tw_reuse + 调整 tcp_fin_timeout=30• 升级 OpenSSL 至 3.0.7，启用SSL_CTX_set_mode(ctx, SSL_MODE_RELEASE_BUFFERS)• Nginx 编译时添加 --with-openssl-opt="enable-ec_nistp_64_gcc_128"TIME_WAIT 数量回落至 1.2 万以内，重传率归零。
证书与 OCSP Stapling 实战取舍原方案启用 OCSP Stapling + fullchain.pem，但 stapling 响应平均耗时 86ms（依赖上游 OCSP 响应器）。压测中发现 12% 的请求因 OCSP 超时退化为 CRL 查询，加剧延迟。最终采用折中方案：• 仅保留根 CA + 一级中间 CA 的精简证书链（体积从 4.2KB → 1.8KB）
• OCSP Stapling 保留但设置ssl_stapling_responder指向内部缓存代理（TTL=3600s）
• 关闭ssl_stapling_verify（信任链完整性由签发流程保障）
OCSP 相关延迟降至 3ms 以内，证书传输开销减少 57%。
不复杂但容易忽略：真正的性能拐点往往不在算法选型，而在证书链长度、TIME_WAIT 回收节奏、以及 HTTP/2 流控参数与 TLS record 大小的匹配关系。