HTTPS中的优化策略

1.握手阶段的慢

通常所说的“HTTPS连接慢”指的就是刚开始建立连接的那段时间。在TCP建联后，正式数据传输之前，HTTPS比HTTP增加了一个TLS握手的步骤，这个步骤最长可以花费两个消息往返，也就是2-RTT。而且在握手消息的网络耗时之外，还会有其他一些“隐形消耗”，比如：产生用于密钥交换的临时公私钥对（ECDHE）；验证证书时访问CA获取CRL或者OCSP；非对称加密处理“Pre-Master”.

2.硬件优化

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

• 可以选择更快的 CPU，最好还内建 AES 优化，这样即可以加速握手，也可以加速传输。

• 可以选择“SSL 加速卡”，加解密时调用它的 API，让专门的硬件来做非对称加解密，分担 CPU 的计算压力。

• 第三种硬件加速方式：“SSL 加速服务器”，用专门的服务器集群来彻底“卸载”TLS 握手时的加密解密计算，性能自然要比单纯的“加速卡”要强大的多。

3.软件优化

软件升级实施起来比较简单，就是把现在正在使用的软件尽量升级到最新版本，比如把 Linux 内核由 2.x 升级到 4.x，把 Nginx 由 1.6 升级到 1.16，把 OpenSSL 由 1.0.1 升级到 1.1.0/1.1.1。由于这些软件在更新版本的时候都会做性能优化、修复错误，只要运维能够主动配合，这种软件优化是最容易做的，也是最容易达成优化效果的。

4.协议优化

如果有可能，应当尽量采用 TLS1.3，它大幅度简化了握手的过程，完全握手只要 1-RTT，而且更加安全。
如果暂时不能升级到 1.3，只能用 1.2，那么握手时使用的密钥交换协议应当尽量选用椭圆曲线的 ECDHE 算法。它不仅运算速度快，安全性高，还支持“False Start”，能够把握手的消息往返由 2-RTT 减少到 1-RTT，达到与 TLS1.3 类似的效果。

5.会话复用

HTTPS 建立连接的过程：先是 TCP 三次握手，然后是 TLS 一次握手。这后一次握手的重点是算出主密钥“Master Secret”，而主密钥每次连接都要重新计算，如果能够把算出来的主密钥缓存一下“重用”，不就可以免去了握手和计算的成本了。

这种做法就叫“会话复用”（TLS session resumption），和 HTTP Cache 一样，也是提高 HTTPS 性能的“大杀器”，被浏览器和服务器广泛应用。

会话复用分两种，第一种叫“Session ID”,就是客户端和服务器首次
连接后各自保存一个会话的ID号，内存里存储主密钥和其他相关的信息。当客户端
再次连接就直接用主密钥恢复会话状态，跳过证书验证和密钥交换，只用一个消息
往返就可以建立安全的通信
第二种：
Session ticket重用
　　在会话ticket复用中，服务器不用为每个session保存状态，它用一个blob数据保存状态，然后将它发给客户端用来维护后来连接，会话ticket允许服务器将其存储状态委托给客户端，类似HTTP cookie一样。
　　一个会话ticket是一个加密的数据blob，
　　其中包含需要重用的TLS连接信息，
　　如会话key等，它一般是使用ticket key加密，
　　因为ticket key服务器端也知道，在初始握手
　　中服务器发送一个会话ticket到客户端，存储到客户端本地，
　　当重用会话时，客户端发送会话ticket到服务器，服务器解密然后重用会话。

图片描述