• 1. https优化
  • 1.1 性能损耗的点在哪里
  • 1.2 硬件优化
  • 1.3 软件优化
  • 1.4 证书优化
    • 1.4.1 证书传输优化
    • 1.4.2 证书验证优化
      • 1.4.2.1 CRL
      • 1.4.2.2 OCSP
  • 1.5 会话复用
    • 1.5.1 Session ID
    • 1.5.2 Session Ticket
    • 1.5.3 Pre-shared Key
  • 1.6 协议优化
  • 1.7 证书优化

1. https优化

1.1 性能损耗的点在哪里

• 第一个环节， TLS 协议握手过程。TLS 协议握手过程不仅增加了网络延时（最长可以花费掉 2 RTT），而且握手过程中的一些步骤也会产生性能损耗，比如：
• 对于 ECDHE 密钥协商算法，握手过程中会客户端和服务端都需要临时生成椭圆曲线公私钥；
• 客户端验证证书时，会访问 CA 获取 CRL 或者 OCSP，目的是验证服务器的证书是否有被吊销；
• 双方计算 Pre-Master，也就是对称加密密钥；
• 第二个环节，握手后的对称加密报文传输。这个环节的性能消耗非常小。

1.2 硬件优化

HTTPS 协议是计算密集型，而不是 I/O 密集型，所以不能把钱花在网卡、硬盘等地方，应该花在 CPU 上。

1.3 软件优化

• 软件升级。 最新版本不仅提供了最新的特性，也优化了以前软件的问题或性能。
• 协议优化。
  • 密钥交换算法优化 RSA 密钥交换算法的 TLS 握手过程，不仅慢，而且安全性也不高。选用 ECDHE 密钥交换算法替换 RSA 算法，因为该算法由于支持False Start，它是“抢跑”的意思，客户端可以在 TLS 协议的第 3 次握手后，第 4 次握手前，发送加密的应用数据，以此将 TLS 握手的消息往返由 2 RTT 减少到 1 RTT，而且安全性也高，具备前向安全性。 ECDHE 算法是基于椭圆曲线实现的，不同的椭圆曲线性能也不同，应该尽量选择 x25519 曲线，该曲线是目前最快的椭圆曲线。
  • TLS 升级 TLS 1.3 把 Hello 和公钥交换这两个消息合并成了一个消息，于是这样就减少到只需 1 RTT 就能完成 TLS 握手。 合并原理：客户端在 Client Hello 消息里带上了支持的椭圆曲线，以及这些椭圆曲线对应的公钥。服务端收到后，选定一个椭圆曲线等参数，然后返回消息时，带上服务端这边的公钥。经过这 1 个 RTT，双方手上已经有生成会话密钥的材料了，于是客户端计算出会话密钥，就可以进行应用数据的加密传输了。 而且，TLS1.3 对于密钥交换算法，废除了不支持前向安全性的 RSA 和 DH 算法，只支持 ECDHE 算法。 之所以 TLS1.3 仅支持这么少的密码套件，是因为 TLS1.2 由于支持各种古老且不安全的密码套件，中间人可以利用降级攻击，伪造客户端的 Client Hello 消息，替换客户端支持的密码套件为一些不安全的密码套件，使得服务器被迫使用这个密码套件进行 HTTPS 连接，从而破解密文。

1.4 证书优化

1.4.1 证书传输优化

必然是减少证书的大小，这样可以节约带宽，也能减少客户端的运算量。所以，对于服务器的证书应该选择椭圆曲线（ECDSA）证书，而不是 RSA 证书，因为在相同安全强度下， ECC 密钥长度比 RSA 短的多。

1.4.2 证书验证优化

客户端在验证证书时，是个复杂的过程，会走证书链逐级验证，验证的过程不仅需要用 CA 公钥解密证书以及用签名算法验证证书的完整性，而且为了知道证书是否被 CA 吊销，客户端有时还会再去访问 CA， 下载 CRL 或者 OCSP 数据，以此确认证书的有效性，造成网络通信开销。

1.4.2.1 CRL

CRL 称为证书吊销列表（Certificate Revocation List），这个列表是由 CA 定期更新，列表内容都是被撤销信任的证书序号，如果服务器的证书在此列表，就认为证书已经失效，不在的话，则认为证书是有效的。

存在的问题： - 时效性差。由于 CRL 列表是由 CA 维护的，定期更新。 - 随着吊销证书的增多，列表会越来越大，下载的速度就会越慢，客户端还得遍历这么大的列表。

1.4.2.2 OCSP

在线证书状态协议（Online Certificate Status Protocol）来查询证书的有效性，它的工作方式是向 CA 发送查询请求，让 CA 返回证书的有效状态。

问题： OCSP 需要向 CA 查询，因此也是要发生网络请求，依赖网络状况和 CA 服务器状况。 解决： 为了解决这一个网络开销，就出现了 OCSP Stapling，其原理是：服务器向 CA 周期性地查询证书状态，获得一个带有时间戳和签名的响应结果并缓存它。 当有客户端发起连接请求时，服务器会把这个「响应结果」在 TLS 握手过程中发给客户端。由于有签名的存在，服务器无法篡改，因此客户端就能得知证书是否已被吊销了，这样客户端就不需要再去查询。

1.5 会话复用

把首次 TLS 握手协商的对称加密密钥缓存起来，待下次需要建立 HTTPS 连接时，直接「复用」这个密钥，这种方式就是会话复用（TLS session resumption），会话复用分两种：

• 第一种叫 Session ID
• 第二种叫 Session Ticket

1.5.1 Session ID

客户端和服务器首次 TLS 握手连接后，双方会在内存缓存会话密钥，并用唯一的 Session ID 来标识，Session ID 和会话密钥相当于 key-value 的关系。

当客户端再次连接时，hello 消息里会带上 Session ID，服务器收到后就会从内存找，如果找到就直接用该会话密钥恢复会话状态，跳过其余的过程，只用一个消息往返就可以建立安全通信。当然为了安全性，内存中的会话密钥会定期失效。

但是它有两个缺点：

• 服务器必须保持每一个客户端的会话密钥，随着客户端的增多，服务器的内存压力也会越大。
• 现在网站服务一般是由多台服务器通过负载均衡提供服务的，客户端再次连接不一定会命中上次访问过的服务器，于是还要走完整的 TLS 握手过程；

1.5.2 Session Ticket

服务器不再缓存每个客户端的会话密钥，而是把缓存的工作交给了客户端，类似于 HTTP 的 Cookie。

客户端与服务器首次建立连接时，服务器会加密「会话密钥」作为 Ticket 发给客户端，交给客户端缓存该 Ticket。

客户端再次连接服务器时，客户端会发送 Ticket，服务器解密后就可以获取上一次的会话密钥，然后验证有效期，如果没问题，就可以恢复会话了，开始加密通信。 对于集群服务器的话，要确保每台服务器加密 「会话密钥」的密钥是一致的，这样客户端携带 Ticket 访问任意一台服务器时，都能恢复会话。

1.5.3 Pre-shared Key

前面的 Session ID 和 Session Ticket 方式都需要在 1 RTT 才能恢复会话。

而对于重连 TLS1.3 只需要 0 RTT，原理和 Ticket 类似，只不过在重连时，客户端会把 Ticket 和 HTTP 请求一同发送给服务端，这种方式叫 Pre-shared Key。

Session ID、 Session Ticket 和 Pre-shared Key 都不具备前向安全性。重放攻击的危险之处在于，如果中间人截获了某个客户端的 Session ID 或 Session Ticket 以及 POST 报文，而一般 POST 请求会改变数据库的数据。避免重放攻击的方式就是需要对会话密钥设定一个合理的过期时间，以及只针对安全的 HTTP 请求如 GET/HEAD 使用会话重用。

1.6 协议优化

1.7 证书优化