Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange

本文通过实验室架构对 TLS 1.3 协议中传统、混合及纯后量子密钥交换算法在 TCP 握手、TLS 握手及 HTTP 应用层等多个层面的性能影响进行了实证研究与统计分析。

要点

这篇论文就像是一份**“量子安全升级体检报告”**。

想象一下，我们现在的互联网通信（比如你用手机银行、网购）就像是在一条高速公路上开车，而TLS 1.3就是那层保护你隐私的“防弹玻璃罩”。现在，科学家担心未来的“量子超级计算机”能像一把万能钥匙一样，轻易撬开这把锁。为了应对，我们需要换一种更坚固的“新锁”（后量子密码，PQC）。

但这篇论文问了一个很实际的问题：换上这把新锁，会不会让车跑得太慢，或者让引擎过热？

作者没有只盯着“总时间”看，而是把一次完整的网络请求（从你点击链接到页面加载完成）像剥洋葱一样，一层一层地拆开，看看每一层到底发生了什么。

🧩 他们把一次网络请求拆成了哪五层？

想象你去一家高级餐厅（服务器）点菜：

1. TCP 握手（进门）： 你走到餐厅门口，保安和你确认“你好，我是来吃饭的”。（这是建立连接的第一步，还没开始谈密码）。
2. TCP 到 TLS 的过渡（换鞋）： 你走到门口，开始准备换鞋（生成密钥），准备进入安全区。
3. TLS 握手（对暗号）： 你和餐厅经理互相出示身份证、对暗号，确认彼此身份，并交换一把只有你们知道的“新钥匙”。
4. TLS 到应用（入座）： 门开了，你走进包厢，准备点菜。
5. 应用响应（上菜）： 厨房把菜（数据）端上来，你开始吃。

🔍 他们发现了什么？（核心结论）

作者测试了三种情况：

• 老式锁（经典算法）： 现在的标准，但怕量子计算机。
• 混合锁（经典 + 新锁）： 既用老锁，又用新锁，双重保险。
• 纯新锁（纯后量子算法）： 完全不用老锁，只用新锁。

1. 进门和换鞋（TCP 和过渡层）：新锁最慢的地方

• 比喻： 就像换鞋。用新锁（后量子算法）时，你需要花更多时间准备那把复杂的“新钥匙”（生成密钥材料）。
• 结果： 在“换鞋”这一步，新锁比老锁慢了大约 6 倍（从 0.3 毫秒变成 1.9 毫秒）。这是整个过程中唯一明显变慢的地方。
• 原因： 主要是客户端（你的手机或电脑）在忙着计算和生成那把新钥匙。

2. 对暗号（TLS 握手层）：意外地快！

• 比喻： 就像交换钥匙。大家以为新钥匙很大、很复杂，交换起来会很慢。
• 结果： 完全没变慢！ 无论是混合锁还是纯新锁，这一步的速度和老锁几乎一模一样。
• 原因： 虽然新钥匙的“个头”（数据量）变大了，但现代计算机处理这种新算法非常高效，就像用流水线生产大箱子，效率反而很高。所以，这一步大家感觉不到区别。

3. 上菜（应用层）：完全不受影响

• 比喻： 菜端上来的速度。
• 结果： 无论你用哪种锁，菜端上来的速度只取决于菜的大小（数据量）和路堵不堵（网络延迟），跟锁没关系。

📊 整体影响有多大？

如果把整个过程加起来：

• 总耗时： 用新锁比老锁只多了大约 3-4 毫秒。
• 比喻： 这就像你等红绿灯，本来要等 16 秒，现在多等了 3 秒。虽然确实慢了，但在人类的感觉里，这几乎可以忽略不计。
• 比例： 新锁带来的额外负担，只占整个连接时间的 6% 到 14%。

💻 对电脑和手机的影响（CPU 和流量）

• 手机/电脑（客户端）： 因为要忙着算那把新钥匙，CPU 的负担大约翻了一倍（从 3.7% 升到 8% 左右）。
  • 警示： 对于老式手机或物联网小设备，这可能有点累，需要留意。
• 服务器（餐厅）： 负担增加很小，几乎感觉不到。
• 网络流量： 因为新钥匙比较大，传输的数据包稍微大了一点，但完全在可接受范围内，不会把路堵死。

🍽️ 菜越大，影响越小（稀释效应）

作者还测试了如果“菜”很大（比如下载一个大文件，40KB vs 4KB）会怎样？

• 结果： 换锁的时间是固定的（比如多花 3 秒），但如果菜很大，总时间变长了，这多出来的 3 秒在总时间里占比就变小了。
• 比喻： 如果你只吃一口饭，多花 3 秒找筷子很烦人；但如果你要吃一顿大餐，多花 3 秒找筷子就完全不算事儿了。

🚀 总结：我们要换锁吗？

结论是：放心换！

这篇论文告诉我们，虽然为了对抗未来的量子计算机，我们需要换一把更复杂的“新锁”，但这把锁并不会让互联网变慢到无法忍受。

• 它只在连接建立的最初一瞬间（换鞋）有一点点延迟。
• 一旦连接建立，后续的速度和体验几乎和现在一样。
• 对于大多数现代设备，这个代价是完全可以接受的。

未来的方向：
虽然目前测试很完美，但作者建议未来还要在更真实的网络环境（比如有很多中间人检查设备的公司网络）和更高负载下进行测试，确保在“早高峰”时也不会堵车。

简单来说：为了未来的安全，现在稍微多花一点点时间“换鞋”，是非常值得的，而且完全不会让你“跑不动”。

技术摘要

1. 研究背景与问题 (Problem)

随着量子计算的发展，现有的公钥基础设施（如 ECDH、RSA）面临“现在存储，以后解密”（Store Now, Decrypt Later）的威胁。NIST 于 2024 年 8 月 finalized 了首批后量子密码（PQC）标准（FIPS 203/204/205），其中包括 ML-KEM 算法。

核心问题：
在将 PQC 算法迁移到生产环境（特别是 TLS 1.3）之前，业界缺乏对其性能影响的量化数据。虽然已有研究评估了 PQC 对 TLS 握手整体延迟的影响，但缺乏分层分解的分析。现有的研究通常只关注端到端（End-to-End）的总延迟，无法精确定位 PQC 带来的开销具体发生在协议栈的哪一层（是 TCP 建立、密钥生成、握手协商还是应用层传输？）。

2. 方法论与实验设置 (Methodology)

本研究提出了一种五层延迟分解方法，将 HTTP over TLS 事务细分为五个协议阶段，以精确归因 PQC 带来的开销：

1. TCP 握手层 (SYN → SYN-ACK)
2. TCP 到 TLS 延迟层 (SYN-ACK → ClientHello)：客户端上下文初始化和密钥材料生成。
3. TLS 握手层 (ClientHello → Finished)：密钥交换、证书传输和验证。
4. TLS 到应用延迟层 (Finished → HTTP GET)：安全通道建立后的残留开销。
5. 应用响应层 (HTTP GET → HTTP 200 OK)：后端响应时间。

实验环境：

• 架构：模拟真实负载场景，包含客户端（Keysight CyPerf）、负载均衡器/反向代理（Nginx + OpenSSL 3.4 + libOQS）和后端服务器。
• 负载：持续 100 TPS（每秒事务数），持续 5 分钟，总请求量约 100 万次（30 次实验，每次 3 万次请求）。
• 算法配置：
  • 经典：x25519 (ECDH)。
  • 混合 (Hybrid)：x25519 + MLKEM512/768。
  • 纯后量子 (Pure PQC)：MLKEM512/1024。
• 变量：后端响应大小（直接响应、4KB、40KB）。
• 数据分析：使用自定义工具解密 pcap 文件，提取每层的时间戳，计算均值、中位数（p50）、分位数（p90/p95/p99）及标准差。使用 Glass's $\Delta$ 效应量指标来评估差异的实际意义（Cohen 标准：$|\Delta| < 0.2$ 为可忽略）。

3. 主要贡献 (Key Contributions)

1. 五层延迟分解方法论：首次将 TLS 1.3 连接细分为五个协议层，能够精确定位 PQC 开销的来源。
2. 大规模实证对比：在 100 TPS 的高负载下，对比了经典、混合和纯 PQC 配置，进行了超过 30 次实验（约 100 万次请求）。
3. 关键发现：TLS 握手层的算法中立性：发现 TLS 握手层（ClientHello 到 Finished）实际上对算法是“中立”的。经典、混合和纯 ML-KEM 配置在该层的延迟差异极小（Glass's $\Delta < 0.2-0.33$），没有可测量的性能惩罚或优势。
4. 开源工具与数据集：发布了用于从数据包捕获中提取分层统计数据的工具，以及包含解密后的 TLS 数据包和密钥日志的公开数据集，支持可复现的分层分析。

4. 实验结果 (Results)

4.1 分层延迟分析

• TCP 握手层：完全独立于加密算法。所有配置的中位数延迟在 0.36ms - 0.40ms 之间，差异可忽略不计。
• TCP 到 TLS 延迟层 (关键瓶颈)：这是 PQC 开销最显著的地方。
  • 经典 (x25519) 中位数：~0.29ms。
  • PQC/混合配置中位数：~1.7ms - 1.9ms。
  • 开销倍数：约 6 倍。
  • 原因：客户端生成密钥材料（Key Material Generation）和构造 ClientHello 的序列化成本。
  • 统计显著性：Glass's $\Delta \approx 7.7$，远超“大效应”阈值。
• TLS 握手层：
  • 经典：~5.55ms。
  • 混合：~5.88ms - 6.50ms。
  • 纯 PQC：~5.25ms - 5.45ms。
  • 结论：差异在 0.1ms - 0.9ms 之间，Glass's $\Delta$ 为 0.03 - 0.33，属于可忽略范围。纯 ML-KEM 并未表现出比经典算法更慢，甚至微基准测试中更快，但在协议层被网络抖动和系统调度噪声掩盖。
• 应用响应层：主要受网络路径和响应包大小影响。PQC 算法对此层无显著影响（最大偏差 0.74ms，$\Delta = 0.21$，可忽略）。

4.2 归一化开销指标

• 开销因子 (Overhead Factor, OF)：TCP 到 TLS 层的开销因子约为 6.0 - 6.5。
• 密码学开销占比 (Cryptographic Overhead Share, COS)：尽管 TCP 到 TLS 层有巨大开销，但仅占总端到端连接时间的 6% - 14%。
  • 混合配置 COS 最高 (10.6% - 14.1%)。
  • 纯 PQC 配置 COS 较低 (6.0% - 7.9%)。

4.3 响应包大小的影响

• 将响应包从 4KB 增加到 40KB：
  • 加密层开销不变：TCP 到 TLS、TLS 握手等层的延迟基本保持不变。
  • 应用层延迟增加：随包大小线性增加。
  • 相对开销稀释：由于总时间增加，PQC 带来的相对延迟占比从 ~15% (4KB) 下降到 ~8% (40KB)。

4.4 资源利用率

• 客户端 CPU：PQC 配置下客户端 CPU 使用率翻倍（从 ~3.7% 升至 ~8.2% - 8.7%），主要消耗在密钥生成。
• 服务器 CPU：变化较小（~14% - 15%），混合配置相对增加约 5.8%。
• 网络流量：随密钥交换大小增加（从 32B 到 1568B），但带宽增加可控（5.2 Mb/s 到 6.6 Mb/s）。

5. 意义与结论 (Significance & Conclusions)

1. 迁移风险较低：PQC 迁移对用户体验（端到端延迟）的影响是适度且可控的。在 100 TPS 负载下，PQC 仅增加约 3-4ms 的总延迟，且随着响应包增大，相对影响进一步减小。
2. 瓶颈定位明确：PQC 的主要性能瓶颈在于客户端的初始化阶段（TCP 到 TLS 延迟），而非握手协商本身。这意味着优化重点应放在客户端的密钥生成效率上。
3. 算法选择建议：
   • 纯 PQC (ML-KEM) 在握手延迟上与经典算法无异，且 CPU 开销略低于混合方案，是未来的理想选择。
   • 混合方案 虽然提供了向后兼容性，但引入了额外的 ECDH 计算成本，导致 CPU 和延迟略高于纯 PQC 方案。
4. 对网络设备的警示：虽然服务器端 CPU 影响较小，但对于执行中间人（MiTM）解密/检查/重加密的网络设备（如防火墙、WAF），由于需要同时处理客户端和服务端的 PQC 开销，在高并发下可能会面临显著的性能下降，需提前评估。
5. 未来工作：需要在真实网络环境（含负载均衡器和 MiTM 设备）中进行测试，并评估更高负载（>100 TPS）下的压力点，以及 PQC 数字签名算法（如 ML-DSA）的影响。

总结：该研究通过精细的分层分析证明，尽管 PQC 在客户端初始化阶段引入了显著的延迟（约 6 倍），但由于该阶段在总事务时间中占比较小，且握手层本身是算法中立的，因此 TLS 1.3 迁移到后量子密码在性能上是可行且风险可控的。