目录
HTTPS 中的“S”代表“安全”，安全性由 SSL（又名 TLS）提供。您想要保护您的网站是有道理的，对吧？毕竟，每分钟有多达 90,000 次攻击 WordPress 网站。
但出于某种原因，人们普遍认为 SSL 很慢。在您的站点上安装 SSL 证书会带来太多开销并减慢速度。十多年前可能是这种情况，但现在是 2018 年，现在 Google 搜索都通过 HTTPS 完成，默认每秒 40,000 个搜索查询。
事实上，当 Google 默认切换到 HTTPS 时，这家搜索巨头并没有部署额外的机器或特殊硬件。高级软件工程师 Adam Langley 负责 Google 的 HTTPS 服务基础设施和 Chrome 的网络堆栈，他写道，SSL 对 Web 性能的影响有限：
在我们的生产前端机器上，SSL/TLS 占 CPU 负载的不到 1%，每个连接的内存不到 10KB，网络开销不到 2%。
如果 Google 可以实施 SSL，您也可以。另外，你不得不这样做——从 7 月 Chrome 68 发布时开始，不使用 HTTPS 的网站将在地址栏中被标记为“不安全”。
在这篇文章中，我们将了解 HTTPS 如何影响网站性能，以及有关如何提高网站的 HTTPS 性能的一些提示。
SSL 和 TLS 有什么区别？
但首先，您可能想知道 SSL（安全套接字层）和 TLS（传输层安全性）有什么区别。有趣的是，没有区别。
TLS 于 1999 年作为 SSL 3.0 的继任者推出，旨在解决 SSL 协议中的不安全性。
那么，为什么这么长时间后人们仍然说 SSL 而不是 TLS？
安全行业的人非常喜欢 SSL，以至于他们继续使用这个首字母缩略词，直到今天仍然如此。像 Comodo 这样的公司没有将 SSL 证书的名称更改为 TLS 证书。在服务器上启用 SSL 的软件（如 OpenSSL）未将其名称更改为 OpenTLS。SSL 这个名字根深蒂固，一直沿用至今。
至于重命名 SSL 协议，似乎是出于政治原因而不是技术原因。Google 数据保护总监 Tim Dierks 写道，在 90 年代中期，在 Netscape 和 Microsoft 浏览器大战期间，在开发 SSL 协议以及最终成为该标准的领导（和所有权）时，涉及了很多讨价还价：
作为马术交易的一部分，我们不得不对 SSL 3.0 进行一些更改（这样看起来 [Internet 工程任务组] IETF 就不是在给 Netscape 的协议盖橡皮图章），我们不得不重命名协议（出于同样的原因）。因此，TLS 1.0（实际上是 SSL 3.1）诞生了。当然，现在回想起来，整件事看起来很愚蠢。
TLS 就这样诞生了。但每个人都继续说 SSL。
注意：在本文的其余部分，将交替使用 SSL 和 TSL。
HTTP 与 HTTPS？
HTTP 代表超文本传输协议。当您在地址栏中输入一个前面有 http:// 的 URL 时，它会告诉浏览器通过 HTTP 连接到该网站。反过来，HTTP 使用传输控制协议 （TCP） 通过 Web 发送和接收数据包，以加载您要访问的站点。
HTTPS 代表安全超文本传输协议。当您输入前面带有 https:// 的 URL 时，它会告诉浏览器通过 HTTPS 进行连接，HTTPS 也使用 TCP。但它是在由 TLS 加密的连接中执行此操作的。
基本上，它采用 HTTP 协议，并简单地在其上分层一个 TLS 加密层。服务器和客户端之间仍然使用完全相同的 HTTP 进行通信，但通过一个安全的 TLS 连接来加密和解密它们的请求和响应。
SSL 层有两个主要用途：
- 它验证您是否正在直接与您认为正在与之通信的发球进行通信，并且
- 它确保只有服务器可以读取您发送的内容，并且只有您可以读取它发回的内容。
TLS/SSL 的聪明之处在于，任何人都可以拦截您与服务器交换的消息，包括您同意要使用的密钥和加密策略的消息，但他们仍然无法读取发送的任何实际数据。
TLS 握手
切换到 HTTPS 时会增加一些延迟 – 初始 TLS 握手需要额外的两次往返才能建立连接，而通过未加密的 HTTP 端口只需一次。但是，就像我之前提到的 Google 示例一样，它是最小的。
2010 年，Google 推出了 False Start，该技术可将 TLS 握手的延迟降低 30%。但它在一年后放弃了该项目，因为它仍然与大量使用 SSL 终止符的网站不兼容，这些终止符从服务器卸载了 SSL 处理。
但是，False Start 并没有完全消亡——它仍然适用于支持 NPN 扩展的服务器上的站点。
非对称加密
浏览器和服务器之间还有一个加密过程，它们使用称为非对称加密的过程来交换信息。它建立了一个安全的通信通道，通过该通道交换会话密钥，允许浏览器和服务器切换到更快的加密过程，称为对称加密。
非对称加密比对称加密慢，因为前者的密钥长度较长，并且使用的加密算法很复杂。但是，加密和未加密连接之间的测试显示，差异仅为 5 毫秒，CPU 使用率的峰值增加仅为 2%。由于有数十个并行请求和数百个顺序请求，测试期间的 CPU 使用率从未超过 5%。
会话恢复
会话恢复通过调用以前成功的 TLS 会话协商中的信息来绕过 TLS 会话密钥协商中计算最密集的部分，从而大大提高了 TLS 性能。
TLS 提供两种会话恢复机制：会话 ID（服务器和客户端各自存储自己的密钥状态）和会话票证（客户端存储服务器状态，由服务器加密）。
对于会话 ID，服务器需要跟踪可以在某个时间点继续的先前会话。这会导致服务器的额外工作。
引入会话票证是为了解决大型服务器缓存的问题。使用会话票证时，服务器在将会话信息存储在客户端之前使用密钥对其进行加密。因此，下次客户端连接到服务器时，服务器会解密并重用会话信息。这意味着服务器可以在不保留任何信息的情况下恢复会话，并且所有额外的负载都在客户端上完成。
使用会话票证进行会话恢复是一种有益的技术，原因有很多 – 更少的往返、更少的计算和更低的拥塞窗口，所有这些都不会给您的服务器带来负担。
提高 HTTPS 性能
当然，SSL/TLS 和 HTTPS 确实会带来一些轻微的延迟，这可能会影响您网站的页面加载速度。但速度延迟是如此微不足道，以至于安全优势超过了对速度的任何潜在影响。
尽管如此，安装 SSL 证书后，您可以在您的网站上实施一些性能优化，使其既安全又快速。
1. HTTP/2 协议
HTTP/2 是 HTTP 协议的主要修订版，试图解决 HTTP/1.1 的许多缺点和不灵活性。它的好处和功能包括：
- 多路复用和并发：可以在同一个 TCP 连接上快速连续发送多个请求，并且可以不按顺序接收响应。
- 标头压缩：HTTP 标头大小大幅减少。
- 流依赖项：客户端可以向服务器指示哪些资源比其他资源更重要
。 - 服务端推送：服务端可以发送客户端尚未请求的资源，避免延迟。
KeyCDN 有一个很棒的免费 HTTP/2 测试工具，如果您想检查您的服务器或 CDN 是否支持 HTTP/2。
2. Brotli 压缩
Brotli 是由 Google 开发的一种开源无损压缩算法，作为 Gzip、Zopfli 和 Deflate 的替代品，可减少带宽消耗并帮助更快地加载内容。
根据 Google 案例研究，该格式的压缩率比 Zopfli 高 20-26%，CPU 使用率更低。
为了使用 Brotli，客户端和服务器都必须与 Brotli 兼容并通过 HTTPS 连接运行才能使用它。
您可以使用 KeyCDN 的免费测试工具测试您的服务器或 CDN 是否支持 Brotli。
3. HPACK 压缩
使用 HTTP/2 的站点可以充分利用 HPACK 压缩。该技术使用 Huffman 编码将标头大小平均减少 30%。
使用 HPACK 有三个主要好处：
它能够抵御基于压缩的攻击，例如 CRIME（压缩比信息泄漏变得简单，
它能够使用固定的霍夫曼编码对大型标头进行编码，以及
它能够将常用的标头编码为可变长度整数，而不是每次都重新发送整个标头。
4. OCSP 装订
OCSP 装订是一种快速确定 SSL 证书是否有效的方法。它允许服务器提供有关其自身证书有效性的信息，而不必向证书的供应商请求信息。这确保了机密数据的安全性和隐私性，并且无需客户联系证书颁发机构，从而减少了另一个请求。
要在服务器上启用 OCSP 装订，请查看 DigiCert 的详细说明。
5. 使用 CDN
虽然您可能无法使包裹在物理上传输得更快，但可以使它们的传输距离更短。使用 CDN 可以显著减少 TCP 和 TLS 握手的往返时间和总成本。
通过允许用户终止与附近边缘服务器的连接，而不是跨越国家和海洋到您的源站，客户端可以获得“提前终止”的好处，往返时间更短。
利用提前终止对于静态和动态内容同样有用：虽然静态内容也可以由边缘服务器缓存和提供，但动态请求可以通过已建立的连接从边缘服务器路由到源服务器。
结论
是的，SSL 确实会影响您网站的性能。但它的努力是如此之小，以至于节省几毫秒不会超过 SSL 提供的更高安全级别。
使用 HTTP/2，HTTPS 只会越来越快，因此 SSL 对连接的任何性能影响都会迅速下降。
请看这个：HTTP 与 HTTPS 测试。此站点提供了同一页面的不安全 HTTP 和加密 HTTPS HTTP/s 版本的加载时间的视觉比较。结果不言自明。
发表回复