HTTPS 之 TLS 性能调优

HTTPS（HTTP over SSL）是以安全为目标的 HTTP 通道，能够理解为 HTTP + SSL/TLS，即在 HTTP 下加入 SSL/TLS 层做为安全基础。其中 TLS 的前身是 SSL，目前普遍使用的是 TLS 1.2。

TLS性能调优

TLS 被广泛认为会使服务变慢，主要是早期 CPU 还很慢，只有少数站点买得起加密服务。可是今天计算能力再也不是 TLS 的瓶颈。2010年，Google 默认状况下对其电子邮件服务上启用了加密，以后他们表示 SSL/TLS 再也不花费昂贵的计算成本：

在咱们的前端服务上，SSL/TLS 计算只占 CPU 负载的不到 1%，每一个链接只占不到 10KB 的内存，以及不到 2% 的网络开销。

 

1. 延迟和链接管理

网络通信的速度由两个主要因素决定：带宽和延迟。

• 带宽：用来衡量在单位时间内有多少数据可发送
• 延迟：描述一个消息从一端发送到另外一端接收所需的时间

其中，带宽是次要因素，由于一般你能够随时购买更多带宽；而延迟则是没法避免的，由于它是在数据经过网络链接传输时被强加的限制。

延迟对 TLS 影响特别大，由于它有本身精心设计的握手，在链接初始化的时候额外增长了两个往返。

 

1.1 TCP优化

每一个 TCP 链接都有一个称为 拥塞窗口 的速度极限，这个窗口最初时较小，在可靠性能保证的状况下随时间增加。这种机制被称为 慢启动。

所以，对于全部的 TCP 链接，启动速度很慢，对于 TLS 链接状况则更糟糕，由于 TLS 握手协议消耗了宝贵的初始链接字节（当拥塞窗口较小时）。若是拥塞窗口足够大，那么慢启动不会有额外的延迟。可是，若是较长的握手协议超过了拥塞窗口的大小，发送方必须将它拆分为两块，先发送一块，等待确认（一个往返），增长拥塞窗口，而后再发送剩下的部分。

 

1.1.1 拥塞窗口调优

启动速度限制被称为 初始拥塞窗口。RFC6928 建议初始拥塞窗口设置为10个网络段（约15KB）。早期的建议是使用2-4个网络段起步。

在旧版本的Linux平台上，能够改变路由的初始拥塞窗口：

# ip route | while read p; do ip route change $p initcwnd 10; done

 

1.1.2 防止空闲时慢启动

慢启动能够做用于一段时间内没有任何流量的链接上，下降其速度，而且速度降低地很是快。 在 Linux 上，能够在链接空闲时禁用慢启动：

# sysctl -w net.ipv4.tcp_slow_start_after_idle=0

能够经过将该设置添加到 /etc/sysctl.conf 配置使其永久生效。

 

1.2 长链接

大部分状况下 TLS 性能影响集中在每个链接的开始握手阶段。一个重要的优化技术是在链接数容许的状况下尽量保持每一个链接不断开。

如今的趋势是使用事件驱动的 WEB 服务器，经过使用固定的线程池（甚至单个线程）处理全部通信，从而减小每一个链接的成本以及被攻击的可能性。

长链接的缺点是在最后一个 HTTP 链接完成以后，服务器在关闭链接以前会等待必定时间，虽然一个链接不会消耗太多的资源，可是下降了服务器的整体伸缩性。长链接适用于客户端突发大量请求的场景。

当配置较大的长链接超时时间时，限制并发链接数以避免服务器超负荷是相当重要的。经过测试调整服务器，使其运行在容量限制内。若是 TLS 是由 OpenSSL 处理的，请确保服务器正确设置 SSL_MODE_RELEASE_BUFFERS 标识。

 

1.3 HTTP/2.0

HTTP/2.0 是 二进制协议，具有 多路复用 和 头部压缩 等特性，能够提高性能。

 

1.4 CDN

使用 CDN 能够实现世界级的性能，它利用地理上分散的服务器提供边缘缓存和流量优化。

当用户离你的服务器越远，访问网络就越慢，在这种状况下链接创建是一个很大的限制因素。为了服务器尽量靠近最终用户，CDN 经营着大量的地理分布的服务器，它能够提供两种下降延迟的方式，即边缘缓存和链接管理。

 

1.4.1 边缘缓存

因为 CDN 服务器贴近用户，能够将你的文件提供给用户，就像你的服务器真的在那里同样。

 

1.4.2 链接管理

若是你的内容是动态的、用户特定的，那么久没法经过 CDN 缓存数据。可是，一个不错的 CDN 即便没有任何缓存，也能经过链接管理提供帮助，那就是它能够经过长时间保持的长链接消除大部分创建链接的成本。

创建链接期间大部分的时间都花在等待上面。为了尽可能较少等待，CDN 经过本身的基础设置将流量路由到距离目的地最近的一个点。由于是 CDN 本身彻底可控的服务器，它能够内部保持长链接很长一段时间。

当使用 CDN 时，用户链接到最近的 CDN 节点，这只有很短的距离，TLS 握手的网络延迟也很短；而 CDN 与服务器之间能够直接复用已有的远距离长链接。这意味着与 CDN 快速初始 TLS 握手后，用户与服务器就创建了有效链接。

 

2. TLS协议优化

在链接管理以后咱们能够专一于 TLS 的性能特征，具有对 TLS 协议进行安全和速度调优的知识。

 

2.1 密钥交换

使用 TLS 最大的成本除了延迟之外，就是用于安全参数协商的 CPU 密集型加密操做。这部分通信称为密钥交换（key exchange）。密钥交换的 CPU 消耗很大程度上取决于服务器选择的私钥算法、私钥长度和密钥交换算法。

• 密钥长度

破解密钥的难度取决于密钥的长度，密钥越长越安全。但较长的密钥同时也意味着须要花费更多时间进行加密和解密。

• 密钥算法

目前有两种密钥算法可用：RSA 和 ECDSA。当前 RSA密钥算法推荐最小长度2048位（112位加密强度），未来更多会部署3072位（128位加密强度）。ECDSA在性能和安全性上要优于 RSA，256位的 ECDSA （128位加密强度）提供和 3072位的 RSA 同样的安全性，却有更好地性能。

• 密钥交换

目前有两种可用的密钥交换算法：DHE 和 ECDHE。其中 DHE 太慢不推荐使用。 密钥交换算法的性能取决于配置的协商参数长度。对于 DHE，经常使用的1024和2048位，分别提供80和112位安全等级。对于 ECDHE，安全和性能取决于一种称为 **曲线** 的东西。secp256r1提供128位安全等级。

 

你在实践中不能随意组合密钥钥和密钥交换算法，但可使用由协议指定的组合。

 

2.2 证书

一次完整的 TLS 握手期间，服务器会把它的证书链发送给客户端验证。证书链的长度和正确性对握手的性能有很大影响。

• 使用尽量少的证书

证书链里的每一个证书都会增大握手数据包，证书链中包含太多证书有可能致使 TCP 初始拥塞窗口溢出。

• 只包含必需的证书

证书链里包含非必需证书是个常见错误，每一个这样的证书会给握手协议额外增长1-2KB。

• 提供完整的证书链

服务器必须提供一个被根证书信任的完整证书链。

• 使用椭圆曲线证书链

由于 ECDSA 私钥长度使用更少的位，因此 ECDSA 证书会更小。

• 避免同一张证书绑定过多域名

每增长一个域名都会增长证书的大小，对于大量域名来讲会有明显的影响。

 

2.3 吊销检查

虽然证书吊销状态在不断变化，而且用户代理对证书吊销的行为差别很大，可是做为服务器，要作的就是尽量快地传递吊销信息。

• 使用 OCSP

信息的证书 OCSP 被设计用于提供实时查询，容许用户代理只请求访问网站的吊销信息，查询简短而快速（一个HTTP请求）。相比之下 CRL 是一个包含大量被吊销证书的列表。

• 使用具备快速且可靠的 OCSP 响应程序的 CA

不一样 CA 之间的 OCSP 响应程序性能不一样，在你向 CA 提交以前先检查他们的历史 OCSP 响应程序。 另外一个选择 CA 的标准是它更新 OCSP 响应程序的速度。

• 部署 OCSP stapling

OCSP stapling 是一种容许在 TLS 握手中包含吊销信息（整个OCSP响应）的协议功能。启用以后，经过给予用户代理进行吊销检查的所有信息以带来更好地性能，能够省去用户代理经过独立的链接获取 CA 的 OCSP 响应程序来查询吊销信息。

 

2.4 协议兼容

若是你的服务器与一些新版本协议的特性（例如TLS 1.2）不兼容，浏览器可能须要经过与服务器进行屡次尝试，才能协商一个加密的链接。确保良好的 TLS 性能的最好方式是升级最新的 TLS 协议栈以支持较新的协议版本和扩展。

 

2.5 硬件加速

随着 CPU 速度的不断提升，基于软件的 TLS 实如今普通 CPU 上已经运行得足够快，无需专门的加密硬件就能处理大量的 HTTPS 请求。但安装加速卡或许可以提高速度。

 

 

参考文章

《HTTPS权威指南：在服务器和Web应用上部署SSL/TLS和PKI》