TLS握手是一个计算密集型过程，尤其是RSA密钥交换，每次握手都需要进行一次昂贵的私钥解密运算。当网站流量上升时，SSL握手开销会迅速成为Debian服务器的性能瓶颈。会话复用技术通过缓存握手结果，让同一客户端再次连接时跳过完整握手流程，能将握手耗时从两三个往返降低到一次甚至零次往返。本文将从原理到实践，详细讲解在Debian环境下如何落地这套优化方案。
一、理解TLS握手与会话复用的底层原理
一次完整的TLS 1.2握手需要两个往返：客户端发送ClientHello，服务端回应证书并完成密钥交换，随后双方确认Finished消息。在这个过程中，RSA解密和密钥派生函数的计算量都不小。根据经验数据，一台普通4核服务器每秒能处理的完整RSA握手通常只有几千次，而会话复用后的握手吞吐可以提升数倍到数十倍。
会话复用有两种机制。第一种是Session ID方式，服务端缓存会话信息，客户端重连时携带Session ID，服务端查到缓存即可跳过证书验证和密钥交换，直接进入简化的握手流程。这种方式的历史包袱是服务端需要维护一个会话缓存表，占用内存且在多机部署时需要共享存储。
第二种是Session Ticket方式，服务端把会话信息加密后作为Ticket发给客户端保存，客户端重连时出示Ticket，服务端用密钥解密即可恢复会话。会话状态存储在客户端，服务端几乎没有内存负担，也更容易在集群间做负载均衡。两种机制在Nginx中都默认开启，但默认配置往往不是最优的，需要手动调整参数。
二、Nginx中的会话复用配置实战
在Debian上，Nginx的SSL配置文件通常位于/etc/nginx/sites-available/目录下。以下是一份针对会话复用优化的配置片段，可以直接加到server块中：
server {
listen 443 ssl;
server_name example.ipipp.com;
# 会话缓存：所有worker进程共享，分配10MB内存
ssl_session_cache shared:SSL:10m;
# 会话超时时间，适当调长可提高复用率
ssl_session_timeout 1h;
# 启用会话票据
ssl_session_tickets on;
# 票据密钥，多机部署时保持一致
ssl_session_ticket_key /etc/nginx/ssl/ticket.key;
# 协议版本
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
}ssl_session_cache设置为shared模式非常关键。默认情况下Nginx没有配置缓存，每个worker进程各自维护独立缓存，进程间无法共享会话，缓存命中率会大打折扣。shared:SSL:10m大约能存储4万个会话，流量大的站点可以适当增大到20m或50m。
关于ssl_session_timeout，默认值只有5分钟，对于访问频率中等的站点来说偏短，用户很可能在缓存过期后才回来，复用完全失效。建议设为1小时，对安全性影响可控。需要注意的是，从Nginx 1.19.4开始引入了ssl_session_timeout与Ticket刷新时间的区分，Ticket的实际有效期还受密钥轮换策略影响。
多台Debian服务器做负载均衡时，务必统一Ticket密钥。可以手动生成密钥文件并同步到所有节点：
mkdir -p /etc/nginx/ssl openssl rand 80 > /etc/nginx/ssl/ticket.key chmod 600 /etc/nginx/ssl/ticket.key # 同步到其他节点后重载配置 nginx -t && systemctl reload nginx
三、TLS 1.3带来的零往返握手
TLS 1.3对握手流程做了彻底重构，完整握手只需要一个往返，而会话复用时更是实现了0-RTT，也就是客户端在第一个数据包里就能携带应用数据。这在弱网环境下的体验提升非常明显。Debian 11及以上版本的Nginx和OpenSSL都完整支持TLS 1.3，只需在ssl_protocols中启用即可。
0-RTT有一个安全隐患需要了解：首个数据包存在重放攻击风险，只适合幂等的GET请求场景。Nginx默认关闭0-RTT，可以通过ssl_early_data on开启，但建议仅在明确知道业务风险的情况下使用。对于大多数站点，TLS 1.3的1-RTT会话复用已经足够快。
TLS 1.3的会话恢复机制与1.2不同，它使用的是基于PSK的握手，配合Session Ticket分发预共享密钥。旧的Session ID机制在1.3中已被移除，因此升级协议版本后不需要再担心缓存表的问题。
四、配合其他手段进一步压榨性能
会话复用只解决了握手开销，证书传输的体积和内核层面的调度也值得优化。启用OCSP装订可以让服务端代替客户端去查询证书状态，减少客户端额外的网络请求：
ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 5s;
证书链方面，启用ECDSA证书或者采用RSA与ECDSA双证书部署，能显著降低握手时的非对称运算量。ECDSA的签名验证速度比RSA快一个数量级，且证书体积更小，传输开销也更低。Let's Encrypt已免费提供ECDSA证书，切换成本很低。
系统层面还可以调整几个参数。开启TCP Fast Open可以与TLS 1.3配合进一步减少往返；调整net.core.somaxconn和backlog队列，避免高并发时握手请求被内核丢弃；启用BBR拥塞控制算法改善加密流量的传输效率：
sysctl -w net.ipv4.tcp_fastopen=3 sysctl -w net.core.default_qdisc=fq sysctl -w net.ipv4.tcp_congestion_control=bbr
最后建议用openssl命令行工具验证会话复用是否生效。用openssl s_client -connect 主机:443 -reconnect -sess_out /tmp/sess.pem保存会话，再用-sess_in参数重连，对比两次输出的握手轮次和Reused标志，就能直观看到优化效果。压测时可以用wrk配合lua脚本模拟HTTPS请求，观察开启会话复用前后QPS和CPU负载的变化，通常能拿到令人满意的提升幅度。