HTTPS的优化|HTTP协议篇
# HTTPS的优化
30 秒速记
HTTPS的主要额外延迟集中在连接建立阶段，而不是握手完成后的报文传输阶段。- 相较于
HTTP，HTTPS在TCP建连后增加TLS握手；原文所述未优化流程最长可增加约2-RTT。 - 握手成本不仅来自网络往返，还包括生成
ECDHE临时密钥、验证证书状态以及非对称解密等计算或外部访问。 AES、ChaCha20等对称算法性能较好，并可获得硬件加速，因此正文认为持续传输阶段的额外损耗通常很小。- 优化目标应聚焦握手路径；原文指出合理优化可将额外耗时降至几十毫秒，特定情况下甚至接近零，但未给出具体方案与适用条件。
HTTPS 优化应优先缩短连接建立阶段的耗时，因为主要额外成本集中在 TLS 握手。 相比 HTTP，它在 TCP 建连后还可能增加约 2-RTT，并涉及 ECDHE 密钥计算、证书验证和非对称加解密。握手完成后使用 AES、ChaCha20 等对称算法，传输损耗通常较小。实际排查要区分首次连接与连接复用，分别观察 DNS、TCP、TLS 和首字节时间，避免把服务端处理慢误判成握手问题。
你可能或多或少听别人说过，“HTTPS 的连接很慢”。那么“慢”的原因是什么呢？
通过前两讲的学习，你可以看到，HTTPS 连接大致上可以划分为两个部分，第一个是建立连接时的非对称加密握手，第二个是握手后的对称加密报文传输。
由于目前流行的 AES、ChaCha20 性能都很好，还有硬件优化，报文传输的性能损耗可以说是非常地小，小到几乎可以忽略不计了。所以，通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。
在 TCP 建连之后，正式数据传输之前，HTTPS 比 HTTP 增加了一个 TLS 握手的步骤，这个步骤最长可以花费两个消息往返，也就是 2-RTT。而且在握手消息的网络耗时之外，还会有其他的一些“隐形”消耗，比如：
产生用于密钥交换的临时公私钥对（ECDHE）； 验证证书时访问 CA 获取 CRL 或者 OCSP； 非对称加密解密处理“Pre-Master”。 在最差的情况下，也就是不做任何的优化措施，HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒，这其中既有网络耗时，也有计算耗时，就会让人产生“打开一个 HTTPS 网站好慢啊”的感觉。
不过刚才说的情况早就是“过去时”了，现在已经有了很多行之有效的 HTTPS 优化手段，运用得好可以把连接的额外耗时降低到几十毫秒甚至是“零”。
我画了一张图，把 TLS 握手过程中影响性能的部分都标记了出来，对照着它就可以“有的放矢”地来优化 HTTPS。
原理拆解： 一次新的 HTTPS 访问先完成 TCP 建连，再完成 TLS 握手，应用层请求只能在握手允许后发送。额外成本由两部分叠加：网络侧是握手消息产生的往返等待；本机和服务端侧是 ECDHE 临时密钥计算、证书链验证及签名验签。证书状态检查还可能引入外部访问。会话建立后改用 AES 或 ChaCha20 等对称算法持续加密，单位报文成本远低于握手阶段，因此短连接、高延迟网络最容易放大差异。
最小验证： 输入为可访问的 example.com:443，用系统安装的 OpenSSL 发起一次 TLS 1.3 连接；要验证证书校验成功、协商出的协议和对称密码套件，并观察握手耗时集中在连接开始阶段。
openssl s_client \
-connect example.com:443 \
-servername example.com \
-tls1_3 \
-brief \
-verify_return_error \
</dev/null
-servername 发送 SNI，避免多域名服务器返回错误证书；-verify_return_error 让证书验证失败直接体现为非成功连接。预期输出包含 Protocol version: TLSv1.3、协商密码套件以及证书验证成功信息。命令依赖本机信任库、DNS 和外网，失败也可能来自网络阻断或缺少根证书，不能直接归因于服务器性能。
边界与排查： 降低握手成本的方向包括复用已有连接、减少不必要的新建连接，以及利用会话恢复减少完整握手工作，但能否接近零额外等待取决于协议版本、客户端是否持有有效会话状态和网络条件。评估时应区分首次连接与复用连接，分别记录 DNS、TCP、TLS、首字节时间；只看页面总耗时会把服务端计算、资源排队和 TLS 混在一起。持续大文件传输若变慢，还应检查 CPU、密码套件和硬件加速，而不能一概认定握手是唯一瓶颈。
面试官追问
追问 1页面下载一个数百兆文件时速度持续偏低，开发直接把原因归结为“TLS 握手天然很慢”，你认可这个判断吗？
不认可直接归因，握手成本主要集中在连接开始阶段，持续传输使用 AES 或 ChaCha20 等对称算法，单位报文开销通常较低。大文件持续变慢还应检查 CPU、密码套件、硬件加速和网络吞吐，不能把全程瓶颈都算到握手上。
追问 2前端瀑布图里同一域名出现大量短连接，每条请求的 TLS 阶段都很明显，你会给出什么落地优化方向？
应先减少不必要的新建连接并尽量复用已有连接，让多个请求分摊一次 TCP 与 TLS 建连成本。还可评估会话恢复以减少完整握手工作；实际收益取决于协议版本、客户端是否持有有效会话状态和网络条件。
追问 3移动端处于高延迟网络，服务端 CPU 却很空闲，团队仍准备优先升级加密计算硬件来降低首屏时间，你会怎么调整方案？
此时更应先量化握手消息的往返等待，因为高延迟网络会放大 TCP 建连和 TLS 握手的网络成本，空闲 CPU 不支持计算瓶颈假设。应分别记录 DNS、TCP、TLS 和首字节时间；只有确认密钥计算或验签耗时突出，硬件优化才更有针对性。
追问 4只有首次打开站点偶发慢几秒，复用连接后的接口都正常，证书近期又刚更换，你会怎样定位？
应聚焦新连接阶段，分别查看 DNS、TCP、TLS 和首字节耗时，并检查证书链验证及状态检查是否引入外部访问。可用 openssl s_client 验证协议、密码套件与证书校验，但命令失败也可能来自 DNS、网络阻断或本机缺少根证书。
追问 5架构师提出只优化 AES 吞吐，安全负责人则要求优先减少会话恢复，两边都声称能解决首次连接慢，你如何取舍？
若问题集中在首次连接，单独优化 AES 通常不是首要方向，因为主要额外成本来自握手往返、ECDHE、证书验证和签名验签。会话恢复可能减少完整握手工作，但需满足客户端状态和协议条件；安全策略是否允许也必须单独评估。
追问 6测试报告只给出页面总加载时间，并据此宣称 HTTPS 比 HTTP 慢两秒，你会要求怎样补证？
页面总耗时混合了服务端计算、资源排队、网络传输和握手，无法直接证明差值来自 HTTPS。应区分首次连接与复用连接，并拆出 DNS、TCP、TLS、首字节时间；还要保持资源、网络和服务端条件一致，否则比较结论缺乏归因能力。
# 硬件优化
30 秒速记
HTTPS连接的核心负载偏计算密集，硬件投入应优先面向加解密计算能力。- 更快且具备
AES加速能力的CPU，既能改善握手计算，也能提升加密报文处理效率。 SSL加速卡可通过专用硬件承担非对称加解密，降低通用CPU的计算压力。- 加速卡存在升级较慢、算法覆盖有限和定制灵活性不足等约束，不能只比较峰值性能。
SSL加速服务器可用专门集群卸载TLS握手计算，能力强于单卡方案，但正文未提供成本、部署方式和收益数据。
HTTPS 的硬件优化应优先提升加解密计算能力，而不是盲目增加带宽、网卡或存储。 简单来说，它更偏计算密集型，更快且支持 AES 加速的 CPU，既能改善握手计算，也能提升加密报文的处理效率。负载更高时可以用 SSL 加速卡分担非对称加解密，或者通过专用服务器集群卸载 TLS 握手。取舍在于加速卡升级较慢、算法支持有限，而集群方案虽然能力更强，仍需结合部署成本和适配难度评估。
在计算机世界里的“优化”可以分成“硬件优化”和“软件优化”两种方式，先来看看有哪些硬件的手段。
硬件优化，说白了就是“花钱”。但花钱也是有门道的，要“有钱用在刀刃上”，不能大把的银子撒出去“只听见响”。
HTTPS 连接是计算密集型，而不是 I/O 密集型。所以，如果你花大价钱去买网卡、带宽、SSD 存储就是“南辕北辙”了，起不到优化的效果。
那该用什么样的硬件来做优化呢？
首先，你可以选择更快的 CPU，最好还内建 AES 优化，这样即可以加速握手，也可以加速传输。
其次，你可以选择“SSL 加速卡”，加解密时调用它的 API，让专门的硬件来做非对称加解密，分担 CPU 的计算压力。
不过“SSL 加速卡”也有一些缺点，比如升级慢、支持算法有限，不能灵活定制解决方案等。
所以，就出现了第三种硬件加速方式：“SSL 加速服务器”，用专门的服务器集群来彻底“卸载”TLS 握手时的加密解密计算，性能自然要比单纯的“加速卡”要强大的多
面试官追问
追问 1入口机房的 TLS 握手延迟升高，但磁盘繁忙度也很高，采购负责人主张先换 SSD，你会直接同意吗？
不会直接同意，因为 HTTPS 连接主要是计算密集型，磁盘繁忙与握手慢同时出现不代表存在因果关系。应先确认 CPU 与加解密计算是否饱和；若瓶颈确在握手，升级 SSD 或网卡通常不能直接解决核心压力。
追问 2监控确认 CPU 被大量加解密计算占满，基础设施团队只能先做一次硬件升级，你会优先评估什么能力？
应优先评估更快且内建 AES 优化的 CPU，它既能承担握手计算，也能改善对称加密传输阶段的处理能力。升级前仍需用负载数据确认瓶颈并验证软件能利用硬件能力，否则采购成本可能无法转化为实际收益。
追问 3业务半年内可能更换密码算法，但供应商的 SSL 加速卡只支持固定算法集合，性能团队仍要求立即全量采购，你会怎样评审？
不宜只看当前吞吐就全量采购，加速卡能够卸载非对称加解密，却存在算法支持有限、升级慢和定制不灵活的约束。应核对未来算法兼容性并预留回退路径；若变化频繁，专用硬件可能很快成为架构限制。
追问 4部署 SSL 加速卡后，应用 CPU 下降不明显，握手吞吐也没有改善，你会优先检查哪些环节？
先确认加解密请求是否确实通过设备 API 交给加速卡，以及当前瓶颈是否属于它负责的非对称计算。还应检查调用和数据传递是否带来额外开销；若瓶颈在网络往返、证书外部检查或应用排队，单卡卸载不会明显改善。
追问 5单机加速卡已接近容量上限，平台团队在“继续堆卡”和“建设 SSL 加速服务器集群”之间争论，你会依据什么取舍？
高流量入口可评估由专用服务器集群集中卸载 TLS 握手计算，其能力通常强于只依靠单张加速卡。选择前仍要评估开发适配、通信链路、故障域和成本；原始材料没有给出容量阈值，不能仅凭流量大就直接迁移。
# 软件优化
30 秒速记
- 除更换
CPU外，硬件加速通常还需要开发适配；例如加速服务器必须采用异步通信，避免阻塞应用服务器。 - 软件侧优化分为软件版本升级和协议层优化，通常实施成本与性价比更有优势。
- 升级内核、
Nginx、OpenSSL可以获得新版本中的性能改进与缺陷修复，是相对直接的优化路径。 - 正文中的
Linux 4.x、Nginx 1.16、OpenSSL 1.1.0/1.1.1均是原文时代的示例版本，不能作为当前最新版本依据。 - 大规模机房逐台升级需要大量人力并存在生产风险；无法升级软硬件时，应转向挖掘现有协议能力。
软件侧可以从升级基础软件和挖掘协议能力两条路径优化 HTTPS，通常比专用硬件更容易落地。 升级内核、Nginx 和 OpenSSL，能够获得新版本里的性能改进与缺陷修复，但原文列出的版本只是当时的示例，不能当作当前版本建议。专用加速方案还需要开发适配，例如加速服务器必须异步通信，否则会阻塞应用服务器。对于机器规模大、升级风险高的环境，更稳妥的做法是在现有软硬件条件下利用协议优化能力。
