课程笔记：HTTPS 协议的性能损耗

课程名称：计算机网络应用 核心摘要：本讲围绕 HTTPS 性能损耗展开，从「网络耗时」与「计算耗时」两大维度剖析 HTTPS 相较 HTTP 变慢变重的根本原因。涵盖全球 HTTPS 普及现状、TCP/TLS 握手带来的 RTT 增加、非对称密钥交换、对称加解密、MAC 一致性校验、证书签名验证等计算环节，为后续 HTTPS 性能优化章节奠定分析基础。

一、 核心概念与原理

1.1 性能分析的两把标尺

分析任意 Web 应用访问瓶颈，均可归结为两类延迟：

1.2 关键术语速查

• HTTPS：HTTP + SSL/TLS 安全层，在 HTTP 之下、TCP 之上增加加密层。
• SSL / TLS：安全层协议；SSL 已淘汰，现主流为 TLS。
• RTT（Round Trip Time）：往返时间，即「一个请求 + 一个响应」构成的一次往返，记为 1 个 RTT。
• TCP 三次握手：建立 TCP 通道的 SYN / SYN-ACK / ACK 三步交互。
• TLS 握手：在 TCP 通道之上进行的密钥交换与证书验证过程，至少需要 2 个 RTT（TLS 1.2）。
• 非对称加密：用于密钥交换阶段（公钥加密、私钥解密），计算量大。
• 对称加密：用于应用数据传输阶段，双方共享同一会话密钥。
• MAC（Message Authentication Code）：消息认证码，用于消息一致性/完整性校验。
• 数字证书 / 数字签名：CA 用私钥对明文摘要加密生成签名，客户端用公钥解密并比对摘要以验证证书真实性。

1.3 核心结论

所有的安全性，都是以牺牲效率（速度/CPU）为代价的。

HTTPS 在提升安全性的同时，必然引入额外的网络往返与计算开销，这也是后续「HTTPS 性能优化」章节要解决的核心矛盾。

二、 技术细节与协议分析

2.1 HTTPS 全球普及现状（2019 年 10 月数据）

谷歌修改搜索引擎收录规则：非 HTTPS 站点不优先收录，反向驱动了 HTTPS 的全面普及。

2.2 国内 HTTPS 普及较慢的三大原因

2.3 网络耗时对比：HTTP vs HTTPS

HTTP 请求链路

客户端 ──SYN──> 服务端        ┐
客户端 <──SYN-ACK── 服务端     │  TCP 三次握手（1 个 RTT）
客户端 ──ACK──> 服务端        ┘
客户端 <══════> HTTP 报文收发   →  应用数据传输

• HTTP 无安全层，仅依赖 TCP 三次握手（耗时 1 个 RTT）。
• 握手完成后即可直接发送 HTTP 报文。

HTTPS 请求链路

客户端 ──SYN──> 服务端        ┐
客户端 <──SYN-ACK── 服务端     │  TCP 三次握手（1 个 RTT）
客户端 ──ACK──> 服务端        ┘
客户端 <──> ClientHello / ServerHello + 证书 + 随机数   ┐
客户端 <──> 密钥交换 + Finished                        │  TLS 握手（≥ 2 个 RTT）
                                                       ┘
客户端 <══════> 对称加密的应用数据传输                  →  应用数据传输

• HTTPS 在 TLS 握手前必须先完成 TCP 三次握手（无论上层是 HTTP 还是 TLS，都依托 TCP 工作）。
• TLS 握手至少增加 2 个 RTT（相对 HTTP 多出的网络耗时）。
• 应用数据采用对称加密，报文长度增加，且双方需先解密后处理。

2.4 计算耗时：HTTPS 的四大计算环节

2.5 TLS 握手过程详解（以 TLS 1.2 为例）

① Client ──ClientHello + 随机数1──────────────────> Server
② Client <──ServerHello + 证书 + 随机数2────────── Server
③ Client ──预主密钥(公钥加密)──────────────────────> Server
   ↓ 双方用 随机数1 + 随机数2 + 预主密钥 → 生成会话密钥
④ Client ──Finished(对称加密)──────────────────────> Server
⑤ Client <──Finished(对称加密)───────────────────── Server
   ↓ 握手完成
⑥ Client <══对称加密的应用数据══> Server

关键说明：

1. 第 ①②③④⑤ 步构成 TLS 握手，至少消耗 2 个 RTT。
2. 前三步交换的三个随机数（客户端随机数、服务端随机数、预主密钥）按相同算法派生出会话密钥。
3. 第 ④⑤ 步的 Finished 消息是首次对称加密通信：双方互发并用会话密钥解密，验证密钥一致性。
4. 第 ⑥ 步起进入正常数据通讯，全程使用对称加密，双方共享同一密钥加解密。
5. 握手阶段使用非对称加密（计算量大但只用一次），数据传输阶段使用对称加密（计算量小但持续使用）——这是性能与安全的折中设计。

2.6 HTTPS「重」在哪里：形象类比

大象个头大、跳不高跑不快；HTTPS 同样「很重」，重在三处：

• 大量计算：SSL/TLS 每一个字节都涉及较复杂的计算，即便发送一个 hello 也需握手后校验。
• 协议封装/解析：TLS 有自己的报文格式，所有数据必须按其格式封装与解析。
• 协议交互增加：RTT 交互数量增加，仅 TLS 握手就至少 2 个 RTT。

三、 实践应用与配置命令

本讲为理论分析章节，未涉及具体实操命令。相关优化配置（如会话复用、OCSP 装订、TLS 1.3 0-RTT、证书链优化等）将在下一讲「HTTPS 性能优化方案」中给出。

四、 重点与难点提示

考点速记

• ✅ HTTPS 性能损耗 = 网络耗时（RTT 增加） + 计算耗时（CPU 开销）。
• ✅ HTTPS 比 HTTP 多出 TLS 握手 2 个 RTT（TLS 1.2）；TLS 1.3 已优化为 1 个 RTT，甚至 0-RTT。
• ✅ TLS 握手前必须先完成 TCP 三次握手，二者不可并行（TLS 1.3 借助 TCP Fast Open 可部分优化）。
• ✅ 四大计算环节：非对称密钥交换、对称加解密、MAC 一致性校验、证书签名校验。
• ✅ 非对称加密用于握手期交换会话密钥；对称加密用于应用数据传输——混合加密体制。

易错点

• ⚠️ 误以为 HTTPS 的 RTT 增加只来自 TCP 握手——实际是 TLS 握手新增的 RTT。
• ⚠️ 误以为应用数据用非对称加密——实际应用数据全程用对称加密，非对称仅用于密钥交换。
• ⚠️ 混淆 SSL 与 TLS：SSL 已废弃，现行协议为 TLS，但习惯上仍常以「SSL/TLS」并称。
• ⚠️ 预主密钥 ≠ 会话密钥：会话密钥由「客户端随机数 + 服务端随机数 + 预主密钥」共同派生。

面试高频题

1. HTTPS 为什么比 HTTP 慢？从网络和计算两方面说明。
2. TLS 握手过程涉及哪几个随机数？会话密钥如何生成？
3. HTTPS 中非对称加密和对称加密分别用在什么阶段？为什么这样设计？
4. 证书签名校验的流程是什么？如何验证证书真实性？
5. 若不考虑任何计算开销，TLS 握手至少需要几个 RTT？为什么？

五、 课后疑问/遗留问题

1. TLS 1.3 如何将握手从 2-RTT 优化到 1-RTT 甚至 0-RTT？
2. 会话复用（Session ID / Session Ticket）如何减少重复握手的 RTT 与计算开销？
3. OCSP 装订（OCSP Stapling）如何解决证书状态在线查询的延迟问题？
4. 对称加密算法（如 AES-GCM、ChaCha20-Poly1305）在性能上各有何优劣？
5. 硬件加速（如 CPU AES-NI 指令集）如何降低 HTTPS 的计算耗时？
6. HTTP/2、HTTP/3（QUIC）如何从协议层面缓解 HTTPS 的性能劣势？

以上问题将在下一讲「HTTPS 性能优化方案」中从五个角度展开解答。