【http】https加速优化

前言
HTTPS 的连接很慢
硬件优化
软件优化

前言

主要记录 https 加速的优化手段。

李柱明博客：https://www.cnblogs.com/lizhuming/p/15486943.html

HTTPS 的连接很慢

https 步骤简要划分

HTTPS 连接大致分为两个部分：

非对称加密握手（TLS 握手）；
对称加密报文传输。

平时说的 HTTPS 很慢是前面第一部分，非对称加密握手阶段很慢。

而握手成功后是很快的。

握手耗时

TLS 握手最长可以花费两个消息往返（2-RTT)。

除了在握手消息的网络耗时之外，还有：

产生用于密钥交换的临时公私钥对（ECDHE）；
验证证书时访问 CA 获取 CRL 或者 OCSP；（这两个知识点可以看后面）
非对称加密解密处理“Pre-Master”。

不做优化的情况下，HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒。

TLS 握手过程中主要耗时图参考：

优化就按照下图耗时段进行优化。

证书验证

本点只是做理解记录，如果对 CRL 和 OCSP 有所理解，可以跳过。

CRL

CRL（Certificate revocation list）即是证书吊销列表。

由 CA 定期发布，里面是所有被撤销信任的证书序号。

查其内容即可知道本证书是否失效。

缺点：

CRL 是定期发布，如果证书失效了，但是 CA 机构还没有及时更新 CRL，会导致误判的安全隐患。
随着吊销的证书越来越多，下载的 CRL 就会越来越大了，检索也越来越耗时。简直就是越来越浪费空间浪费时间。

所以现在用 OCSP 取代 CRL。

OCSP

OCSP（Online Certificate Status Protocol）在线证书状态协议。

客户端将请求发到一个 OCSP 应答器（服务器），应答器建立与 CA 证书库链接查询该证书的状态，然后回复“ 有效 ”、“ 注销 ”或“ 未知 ”的响应。

优点：

在线验证比 CRL 处理速度更快、更方便，也更具独立性。
并避免了令人头痛的逻辑问题和处理开销。

问题&解决：

OCSP 也要多出一次网络请求的消耗，而且还依赖于 CA 服务器，如果 CA 服务器很忙，也是很耗时的。
- 解决：OCSP Stapling：OCSP 装订，是一个补丁。可以让服务器预先访问 CA 获取 OCSP 响应，然后在握手时随着证书一起发给客户端，免去了客户端连接 CA 服务器查询的时间。

硬件优化

HTTPS 连接是计算密集型，而不是 I/O 密集型：

计算密集型解决方法：加速计算。升级 CPU，硬件加速卡等等。
I/O 密集型解决方法：升级网卡、带宽、SSD 存储等等数据通信设备。

HTTPS 连接是计算密集型，而不是 I/O 密集型，其硬件优化手段有：

升级 CPU：如果内建 AES 优化，可以加速握手，也可以加速传输。
SSL 加速卡：加解密时调用它的 API，让专门的硬件来做非对称加解密，分担 CPU 的计算压力。
SSL 加速服务器：用专门的服务器集群解决 TLS 握手时的加密解密计算，性能要比单纯的“加速卡”要强大。

软件优化

软件方面的优化还可以再分成两部分：一个是 软件升级 ，一个是 协议优化 。

软件升级

软件升级，如升级 linux 内核，升级 OpenSSL 等等。

这些软件在更新版本的时候都会做性能优化、修复错误，只要运维能够主动配合，这种软件优化是最容易做的，也是最容易达成优化效果的。

但是升级内核兼容性要解决，版本跨度大，升级也是很棘手的。

协议优化

目前尽量采用 TLS1.3。
- 它大幅度简化了握手的过程，完全握手只要 1-RTT，而且更加安全。
握手时使用的密钥交换协议尽量选用椭圆曲线的 ECDHE 算法。（RSA 在 TLS 1.3 中已经被废弃）
- 运算速度快。
- 安全性高。
- 支持“False Start”，能够把 TLS1.2 握手的消息往返由 2-RTT 减少到 1-RTT，达到与 TLS1.3 类似的效果。
椭圆曲线也要选择高性能的曲线。
- 最好是 x25519，次优选择是 P-256。
对称加密算法方面，可以选用“AES_128_GCM”，比“AES_256_GCM”略快一点点。

证书优化

握手过程中的证书验证也是一个比较耗时的操作，服务器需要把自己的证书链全发给客户端，然后客户端接收后再逐一验证。

两个可优化点：

证书传输。
证书验证。
服务器的证书可以选择椭圆曲线（ECDSA）证书而不是 RSA 证书。
- 因为 224 位的 ECC 相当于 2048 位的 RSA。证书小，传输就少，计算也少。
采用 OCSP 验证证书。开启 OCSP Stapling。

会话复用

大杀器。

连接同一服务器时，明明证书、公钥都一样，但是每次通信都需要重新 TLS 握手，重新验证证书来获取公钥，算出对称秘钥。

这样太浪费时间了，我们可以使用缓存功能，双方把会话 ID 和对称秘钥记录下来，下次链接时直接使用岂不是更加方便快捷吗，其实这就是会话复用。

会话复用（TLS session resumption），复用分两种：

Session ID：客户端和服务器首次连接后各自保存一个会话的 ID 号，内存里存储主密钥和其他相关的信息。
1. 当客户端再次连接时发一个 ID 过来，服务器就在内存里找，找到就直接用主密钥恢复会话状态，跳过证书验证和密钥交换，只用一个消息往返就可以建立安全通信。
2. 缺点：服务器保存每一个客户端的会话数据，对于拥有百万、千万级别用户的网站来说存储量就成了大问题，加重了服务器的负担。
Session Ticket：会话票证。下述。

Session ID：

会话票证

由于 Session ID 方案加重了服务器负担，所以出现了另一种方案，Session Ticket（会话票证）。

Session Ticket：会话票证。

存储的责任由服务器转移到客户端，即是服务器会对会话记录进行加密（如对称主秘钥、加密算法等等）得到的 Ticket ，然后用 New Session Ticket 消息发给客户端，让客户端保存。
重连的时候，客户端使用扩展 session_ticket 发送 Ticket 而不是 Session ID，服务器解密后验证有效期，就可以恢复会话，开始加密通信。
不过 Session Ticket 方案需要使用一个固定的密钥文件（ticket_key）来加密 Ticket，为了防止密钥被破解，保证“前向安全”，密钥文件需要定期轮换。

预共享密钥

Pre-shared Key，简称为“PSK”，预共享密钥。

False Start、Session ID、Session Ticket 等方式只能实现 1-RTT，而 TLS1.3 的 PSK 更进一步实现了 0-RTT。

原理和 Session Ticket 差不多，但在发送 Ticket 的同时会带上应用数据（Early Data），免去了服务器确认步骤。

注意：

PSK 也不是完美的，它为了追求效率而牺牲了一点安全性，容易受到 重放攻击（Replay attack）的威胁。黑客可以截获 PSK 的数据，像复读机那样反复向服务器发送。
- 解决：在消息里加入时间戳、nonce 验证，或者 一次性票证 限制重放。