与 HTTP 相比，使用 HTTPS 的开销是多少？答案

【问题标题】：What is the overhead of using HTTPS compared to HTTP?与 HTTP 相比，使用 HTTPS 的开销是多少？
【发布时间】：2009-12-12 04:57:19
【问题描述】：

我正在阅读 google 发布的关于默认情况下不为 gmail 启用 HTTPS 的博客 (http://googlepublicpolicy.blogspot.com/2009/06/https-security-for-web-applications.html)。其中一段如下所述。

除非对用户体验有负面影响或不切实际，否则我们打算在默认情况下更广泛地启用 HTTPS，希望对所有 Gmail 用户都适用。我们还在考虑如何使这项功能最适用于其他应用，包括 Google Docs 和 Google Calendar（我们也为这些应用提供免费的 HTTPS）。

我不明白转移到 HTTPS 会产生什么负面影响。是否对 HTTP 和 HTTPS 的性能进行了基准测试。

我觉得https其实一开始就涉及到一些额外的协议消息和后来的数据加密。不能通过默认加载 SSL 浏览器代码等来解决这些问题。

谢谢巴拉

【问题讨论】：

【解决方案1】：

https 的主要成本通常是会话开始时的密钥交换，这是 CPU 密集型的。可以使用硬加速来处理这个问题。如果它是 EV 证书，那么它还需要吊销检查。流的实际加密相对便宜。 Sun Niagara II 具有“零开销”加密，它使用备用 FPU 周期进行处理。

【讨论】：

Sun Niagra 处理器线对于加密来说是可怕的，除非（并且只有除非）您已经重新编译以使用加密加速器运行 SSL：基本 CPU 有 32 个整数管道，但它们都共享一个FPU - 加密速度太慢了
哇。为什么不编译让操作系统处理 SSL？这对我来说似乎是一个合理的事情。 Niagara 1 确实有一个 FPU，但没有这个功能。 Niagara 2（已在服务器中发布两年多）有 8 个 FPU - 每个内核一个。这似乎是一个不寻常的工作负载，它总是让浮点和加密都忙——可能其中一个将是微不足道的。 en.wikipedia.org/wiki/UltraSPARC_T2

【解决方案2】：

https 的开销完全在会话开始期间的密钥协商阶段。如果密钥设置为短期到期，则可能需要经常重新协商。

但是，如果您使用 128 位 SSL（我见过的最常见的），密钥生成和交换是一个非常短的过程。

尝试从网络上的两台机器上计时 - 一台使用 SSL 连接，另一台使用明文连接：它以个位数的百分比显示，并且只有在会话开始时才能真正注意到。

基于浏览器的活动几乎始终是用户绑定的，而不是机器绑定的。

【讨论】：

【解决方案3】：

使用 HTTPS，用户和托管信息的服务器之间的所有流量都经过加密，只有用户和服务器才能看到。这使得中间攻击的人非常困难。这需要双方的额外资源来解释所传达的内容。

通常在 HTTPS 上的高需求服务器上，网站的哪些部分使用 SSL 或存在卸载加密过程的加密卡。

【讨论】：