大促峰值下，SSL握手耗掉的RTT和CPU会让单机可建立的HTTPS连接数明显缩水，优先做会话复用、TLS1.3升级和边缘SSL卸载，比单纯按量扩容更划算。
大促时HTTPS连接数上不去？先看SSL握手怎么吃掉连接槽
大促流量一冲进来,最怕的不是带宽不够，而是单机连接数卡在某个数值上不去，表面看是并发连接数到了瓶颈，实际多数情况下，SSL握手正在悄悄占用连接槽位，这里说的连接槽位，不是简单的端口号，而是服务器为每个连接分配的文件描述符、内存块和CPU处理时间，TCP连接建立后，如果还要完成TLS握手，连接就处于半成品状态，既不释放，也不能传递业务数据。
从Nginx官方文档可以看到,worker_connections定义了每个worker进程能同时处理的最大连接数，大促时大量客户端使用短连接，每个请求都要新建TCP连接，再叠加TLS握手，连接在握手阶段会停留几十毫秒到几百毫秒，期间worker进程还要执行证书校验、密钥协商，于是新的连接请求要么排队等待，要么直接被丢弃，这就是很多运维同学看到的“QPS还没到顶，HTTPS连接数先上不去”的原因。
- SSL握手比TCP握手多出的非对称运算，会占用worker进程的CPU时间片。
- 每个半握手连接都占用一个文件描述符，直到握手完成或超时。
- 大促短连接场景下，连接建立频率远高于长连接场景，握手开销被成倍放大。
- 单机文件描述符上限通常固定，半握手连接太多，后续连接自然进不来。
高并发下SSL握手和TCP握手耗时对比，多出来的每一步都在抢资源
很多人把HTTPS慢怪到加密头上,但真正拖慢连接建立的是握手往返，TCP三次握手只需要1个RTT，TLS握手则要在这个基础上继续加，TLS1.2全握手在TCP之上还要额外2个RTT，TLS1.3全握手额外1个RTT，如果开启会话复用，TLS1.2可以省掉1个RTT，TLS1.3的0-RTT模式则能把应用数据合并到TCP握手的第一个往返里。
| 握手类型 | 总RTT（含TCP） | 主要CPU开销 | 适用场景 |
|---|---|---|---|
| TCP三次握手 | 1个RTT | 极低 | 所有TCP连接 |
| TLS1.2全握手 | 3个RTT | RSA或ECDHE，证书校验 | 首次访问，无会话缓存 |
| TLS1.3全握手 | 2个RTT | ECDHE为主 | 首次访问，无会话缓存 |
| TLS1.2会话复用 | 2个RTT | 对称密钥派生 | 客户端或服务端有缓存 |
| TLS1.3 0-RTT | 1个RTT | 极低 | 仅适合幂等请求 |
移动网络或跨地域机房访问时,单个RTT可能达到几十毫秒甚至上百毫秒，一个TLS1.2全握手比纯TCP多出2个RTT，连接占用时间直接拉长，大促期间每秒新建连接数很高，多出来的握手RTT会迅速吃掉连接槽，CPU侧的开销同样不能忽视，RSA私钥运算在较老的证书体系里属于较重负担，ECDHE虽然计算量低一些，但大促峰值下依然会占用相当比例的CPU周期。
大促服务器扩容成本高吗？先算SSL卸载这笔账
有些团队看到连接数上不去,第一反应是扩容，临时增加云服务器实例、提升按量计费带宽，在华东地域、北京地域的峰时价格都不低，大促期间按量计费实例和带宽费用会比日常高出较多，而且扩容的机器同样要面对SSL握手开销，如果不解决握手效率，单纯加机器只是把问题平摊到更多节点上，成本却直线上升。
更划算的做法是先把SSL卸载到边缘节点或者专用网关,边缘CDN节点在离用户更近的位置完成TLS握手，回源时走长连接或者直接走HTTP，按量计费的成本大头在计算和带宽，边缘卸载能把大量握手请求拦截在源站之外，中型电商常用的做法是CDN边缘TLS终止加源站Nginx会话复用，配合少量按量实例应对突发流量，北京地域某电商团队的经验是，先做CDN卸载再用按量扩容，比直接对源站做水平扩容少启动相当数量的实例。
用Nginx配置SSL会话复用降低握手开销的实操步骤
开启共享SSL会话缓存
在/etc/nginx/nginx.conf的http块里加入：
http {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
}
shared:SSL:10m表示所有worker进程共享一个10MB的会话缓存，这个缓存让同一个客户端再次连接时能直接复用上次协商好的会话参数，跳过证书校验和非对称密钥交换，会话超时控制在10分钟，大促期间客户端短时间重连命中率较高。
启用TLS1.3并调整加密套件
在server块里配置：
server {
listen 443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;
}
TLS1.3移除了RSA密钥交换，只保留ECDHE，握手RTT更少，同时关掉TLS1.0、TLS1.1，既减少协商分支，也避免旧协议带来的额外消耗。
开启OCSP装订
证书状态查询也是握手里的隐藏成本,客户端在握手时可能去CA服务器查询证书是否被吊销，这一跳延迟不属于TCP和TLS的标准RTT，却会拖慢连接建立，在Nginx里开启OCSP Stapling：
server {
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 valid=300s;
resolver_timeout 5s;
}
这样Nginx在握手时直接把缓存的证书状态响应发给客户端,客户端不用再单独外呼查询。
验证配置与压测
改完配置先检查再重载：
nginx -t nginx -s reload
用openssl s_time测试新建连接和复用连接的握手耗时：
openssl s_time -connect yourdomain.com:443 -new -time 10 openssl s_time -connect yourdomain.com:443 -reuse -time 10
前者模拟每次都用新会话,后者模拟复用，两者耗时差距越大，说明会话复用优化空间越大。
电商大促场景下如何判断SSL握手正在拖垮连接数
看系统层连接状态
先看文件描述符上限,再看半握手队列：
ulimit -n ss -s ss -tan state syn-recv dmesg | grep -i 'possible syn flooding'
如果syn-recv队列里有大量连接堆积，同时ulimit -n还没到顶，说明连接建立速度被握手处理拖住了，如果ulimit -n已经用满，先把worker_rlimit_nofile调大，再观察SSL握手消耗。
抓包看握手耗时
在Nginx所在机器上抓包：
tcpdump -i eth0 port 443 -s 0 -w handshake.pcap
用Wireshark打开,过滤tls.handshake.type==1看ClientHello，再追踪到ServerHelloDone或Finished，重点关注ClientHello和ServerHello之间是否出现较大时间差，以及是否有大量重复ClientHello但看不到ServerHello，这通常说明服务端CPU在处理握手时已经饱和。
临时应急手段
- 调大
worker_connections和worker_rlimit_nofile，给连接槽位留出缓冲。 - 缩短空闲连接超时,避免TIME_WAIT和空闲keepalive连接占坑。
- 在Linux层面打开TCP Fast Open，减少TCP阶段的RTT消耗：
sysctl -w net.ipv4.tcp_fastopen=3
- 把静态资源和接口域名分离,静态资源走CDN边缘TLS终止，源站只处理核心API。
大促前的压测阶段,建议用同样的配置跑一次“新建连接压测”和“会话复用压测”，两者新建连接速率差距如果过大，就把优化重点放在会话复用和TLS1.3上，行业共识认为，大促高并发下的HTTPS连接数瓶颈，多数时候不是硬件不够，而是握手路径没有优化到最短。
大促时SSL握手开销对连接数的消耗常见问题
大促高并发下HTTPS连接数上不去，怎么快速判断是不是SSL握手导致的？
先执行ss -tan state syn-recv看半连接队列，如果堆积明显，再看top里Nginx worker进程的CPU使用率，半连接堆积加worker CPU高，基本可以判定SSL握手在抢资源，如果CPU不高但报too many open files，先调ulimit -n和Nginx的worker_rlimit_nofile，两个场景的优化方向完全不同。
SSL握手和TCP握手耗时对比，在大促时影响到底有多大？
TLS1.2全握手比纯TCP多2个RTT，TLS1.3多1个RTT，跨机房或移动网络下，一个RTT可能几十毫秒，连接在握手期间占用文件描述符和内存，每秒新建连接数会被这个额外时长限制住，大促短连接占比高，每多一个RTT，单机每秒能扛的新建连接数就掉一截。
电商大促临时扩容服务器成本高吗，先做SSL优化能省多少？
按量计费实例加带宽在峰时叠加,成本相当可观，先做CDN边缘SSL卸载，再在源站启用会话复用和TLS1.3，通常能减少相当一部分源站新增实例，具体省多少取决于业务峰值和延迟分布，但SSL优化成本接近于调配置和压测，比起直接堆机器，投入产出比更高。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635765.html
