TLS 握手需要多长时间？

TLS 握手需要多长时间？

在标准的网络环境下，一次完整的 TLS 握手通常需要 50 毫秒到 300 毫秒。具体的耗时并不是固定数值，主要取决于客户端与服务器之间的物理地理距离、网络 RTT（往返延迟）以及所使用的 TLS 协议版本。

TLS 握手的耗时构成与 RTT 关系

TLS 握手的时间长短，本质上取决于在建立加密连接前需要进行多少次网络往返（RTT，Round-Trip Time）。

1. 传统 TLS 1.2 握手耗时

在传统的 TLS 1.2 协议中，整个过程通常需要消耗 2 个完整的 RTT（如果同时计算底层的 TCP 三次握手，则整个建立过程需要 3 个 RTT）：

• TCP 三次握手：消耗 1 个 RTT。
• TLS 密钥交换与证书验证：消耗 2 个 RTT。
• 总延迟计算：如果服务器与客户端异地，网络 RTT 为 50ms，那么仅在建立加密连接阶段，纯网络传输耗时就会达到 150ms 至 200ms 左右。

2. 现代 TLS 1.3 握手耗时

为了降低延迟，TLS 1.3 将握手流程进行了大幅精简，标准握手仅需 1 个 RTT：

• 客户端在发送 TCP 握手或初次请求时，即可直接带上支持的加密套件和参数（Key Share）。
• 服务器收到后直接返回证书和密钥确认，省去了多余的协商回合。
• 对于曾经访问过的网站，TLS 1.3 还支持 0-RTT（Zero Round Trip Time） 恢复机制，客户端可以直接在第一条请求报文中携带加密的业务数据，将握手延迟降到最低。

影响 TLS 握手延迟的核心原因

在实际运维和业务访问中，如果发现 TLS 握手耗时异常偏高（超过 500ms 甚至更高），通常是由以下几个因素导致的：

• 物理距离过远：服务器部署在海外或异地，跨国光缆传输带来的基础 RTT 本身就很高。
• 证书链过长或过大：服务器在握手阶段需要向客户端发送整条证书链。如果中间证书体积庞大或层级过多，会导致单次 TCP 传输的报文分片增多，增加传输耗时。
• 密码套件性能开销：如果服务器启用了过于复杂的加密算法（如部分高强度但计算较慢的非对称加密），会拉长服务端证书签名验证的 CPU 处理时间。
• 没有开启 Session Resumption（会话恢复）：导致每次刷新或重新请求都要完整走一遍耗时的完整握手。

如何优化并缩短 TLS 握手时间？

1. 升级至 TLS 1.3 协议：在 Nginx 或 Apache 中关闭老旧的 TLS 1.0/1.1，全面启用 TLS 1.3，将握手轮次缩减至 1 个 RTT。
2. 合理部署 CDN 或边缘节点：将 HTTPS 终结在距离用户最近的 CDN 边缘节点上。通过就近接入，把原本跨省或跨国的长距离 RTT 缩短至几毫秒。
3. 保持证书链精简：避免配置冗余的多级中间证书，确保在握手时传输的数据包能在一个 TCP 拥塞窗口内发完。

如果在优化过程中遇到证书配置问题，可以参考 HTTPS配置 进行排查，或者使用 SSL检测工具 检测当前域名的握手协议支持情况。

常见问题 FAQ

TLS 握手时间长会影响网站的 SEO 排名吗？

A：会产生间接影响。搜索引擎（如 Google）将页面的加载速度和 Core Web Vitals（核心网页指标）作为重要的排名信号。过长的 TLS 握手会导致首字节时间（TTFB）变长，进而对排名产生负面作用。

如何测量自己网站的真实 TLS 握手耗时？

A：可以在浏览器的开发者工具（F12）中切换到“Network”面板，勾选“Protocol”和“Timing”列，查看具体请求中的 SSL/TLS 耗时；也可以通过命令行测试：

curl -so /dev/null -w "TCP Handshake: %{time_connect}s\nTLS Handshake: %{time_appconnect}s\n" https://yourdomain.com

HTTPS 每次点击都要重新握手吗？

A：不需要。现代浏览器和服务器支持会话保持与复用（Session Resumption / TLS Session Tickets）。在一定的时间窗口内，后续的请求可以复用之前的加密会话，跳过繁琐的握手过程。