与非加密连接相比，TLS 增加了多少网络开销？答案

【问题标题】：How much network overhead does TLS add compared to a non-encrypted connection?与非加密连接相比，TLS 增加了多少网络开销？
【发布时间】：2010-12-09 14:36:46
【问题描述】：

（大约）与未加密连接相比，在加密连接期间必须通过网络传输多少位数据？

IIUC，一旦 TLS 握手完成，传输的位数等于未加密连接期间传输的位数。这准确吗？

作为后续措施，考虑到快速的处理器和相同（理想）的网络条件，通过 https 传输大文件是否比通过 http 传输文件慢得多？

【问题讨论】：

标签： http networking https ssl

【解决方案1】：

这个问题我已经问过几次了，所以我决定用一些基于常见情况的示例数字来写一个关于开销的小解释。你可以在我的博客http://netsekure.org/2010/03/tls-overhead/阅读。

博文摘要：

建立新 TLS 会话的总开销平均约为 6.5k 字节。
恢复现有 TLS 会话的总开销平均约为 330 字节。
加密数据的总开销约为 40 字节。

【讨论】：

绝对值得一读。这就像 TLS 工作原理的速成课程。

【解决方案2】：

简短的回答是：您的里程数可能会有所不同 (YMMV) - 这完全取决于您的流量模式。有许多因素需要考虑：

额外的握手和证书将为 TCP 流增加 4-6KB，这也会导致更多的以太网帧通过网络
客户应该下载certificate revocation list。一些工具（如 cURL）省略了这一步。 crl 可能会被浏览器缓存，但是，它通常与它没有长期关联。 Verisign 将它们设置为在四分钟后过期。在我的测试中，我看到 Windows 上的 Safari 下载同一个 91KB 文件两次。
TLS Session resumption 可以避免握手的公钥交换部分，以及证书验证。
HTTP keep-alives 将保持套接字打开，与 http 相同，但当套接字为 TLS 时节省更多。
SSL compression 支持开始出现在服务器端，但是据我所知，大多数浏览器还没有实现这一点。此外，如果您已经在 http 层进行压缩，那么这里将不会有太多收获。如果客户端向服务器发送大量文本，这些文本通常不会在 http 层进行压缩，则可能会获得巨大的收益。

【讨论】：

【解决方案3】：

在 2020 年，TLS 1.2 和 1.3 更为典型，AES-GCM 是一种开销较低的流式密码模式。

见https://tools.ietf.org/id/draft-mattsson-uta-tls-overhead-01.xml#rfc.section.3。

每个数据包，AES-GCM 的开销为 29 个字节。 TCP MSS 可能高达 1460 (https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/)。因此，对于大型下载（使用最大 MSS），开销将为 29:1431，即 2.03%。

（握手开销是一次性的）

【讨论】：

【解决方案4】：

一个数量级。见this。如果受保护的信息值得保护，这并不太重要。请记住，处理器速度只会提高，因此性能会不断提高。

【讨论】：

每个连接设置不是“大约 10 倍”，而是“额外大约 12KB”。
有启动开销，还有每个数据包的开销。每个数据包的开销可能在 30-50 字节的数量级上用于填充和散列。 12K 用于启动听起来似乎是合理的，但客户端和服务器在握手期间提供的证书数量可能会有很大差异。正如另一个答案所说，复杂的客户端和服务器可以减少会话恢复。