我以为 HTTPS 一定会慢很多

迁移到 HTTPS 之前，我最担心速度。上线后一测，确实慢了一点，但没慢到影响体验。

后来有人跟我说他的站慢了好几倍，我看了下配置，问题不在加密本身。那次之后我不再拿「HTTPS 慢」当借口。

理论上只多一次握手

HTTP 是 TCP 建连之后直接发请求。

HTTPS 在 TCP 之后多一次 TLS 握手，TLS 1.3 是一个往返，1.2 是两个；会话复用时还能更少。

握手完成后，加密解密的开销对现代 CPU 来说很小，传输阶段两者几乎一样。

所以差异基本就是一个 RTT 的量级。跨省或跨国的 RTT 越大，差异越明显。RTT 决定了这个差值的下限，物理距离绕不开。

为什么有人测出几倍

常见的是没有开 TLS 1.3，或者没有会话复用，每次访问都完整握手。

证书链带得太长，握手时多传几轮数据。

页面里有资源还在走 http，触发混合内容或者额外跳转，整体时间就上去了。还有一种是把 http 的跳转也算进了对比里。

还有一种：HTTP 站点用了 HTTP/2，HTTPS 站点反而没配好，结果新技术没用上。

用五段对比

用宝塔拨测的网站测速分别测 http 和 https 的同一个路径，看五段。两次测试要确保路径和请求方法一致。

DNS、TCP 两段应该接近。TLS 只存在于 https 那一次。

关键就是这一段的长度。它接近一次 RTT，说明正常；远大于 RTT，说明握手过程有额外往返。

TTFB 和下载两段如果也差很多，那就不是 TLS 的问题，往别处查。首字节时间会被握手推后，但影响大小仍然是一次握手的级别，别把后端慢算到加密头上。

什么算异常

TLS 段明显高于 TCP 段，且每次都是完整握手，没有复用。

证书链很长，或者服务器在握手时做了额外校验，比如每个请求都去查 OCSP。

跨地区测试时，TLS 差异应该和 RTT 差异同步放大。如果某地 TLS 特别离谱，查那条链路。TLS 段波动很大，先看负载均衡后面多台机器配置是不是不一致。

复测

同一批节点、相近时间，http 和 https 各测三次，对比 TLS 段的分布。

改完协议版本或者开启会话复用，再测一次，看这一段有没有收窄。记录里写清协议版本和是否复用，对比时看增量，不看绝对耗时。

HTTPS 的成本是可预期的，超出预期的那部分，才是要查的地方。