Hi~朋友，关注置顶防止错过消息
摘要
- HTTPS的性能损耗
- 硬件优化
- 软件优化
- 证书优化
- 会话复用
HTTPS的性能损耗
- 数据传输需要通过对称加密进行传输
- 对称加密密钥需要经历TLS握手才可获得
- 证书验证需要耗时
硬件优化
选择支持AES-NI特性的CPU，该CPU在指令级别优化了AES算法，加速了数据的加解密过程。
代码语言：javascript复制sort -u /proc/crypto | grep module | grep aes
在CPU支持AES-NI特性，我们的对称加密算法尽量选择AES，否则可以选择ChaCha20对称加密算法。
软件优化
软件上的优化分为：
- 软件升级
- 协议升级
软件升级
软件升级相比硬件升级可能会节省money，但是如果服务器数量庞大，软件升级也需要较大的人力和升级，软件升级主要包括以下：
- Linux内核升级
- OpenSSL升级
协议升级
- 密钥协商算法优化
- 对称加密算法优化
- TLS1.2升级为1.3
密钥协商算法优化
密钥协商算法尽量选取ECDHE算法，该算法相比RSA算法具有向前保密，且在第三次握手以后就可以发送数据，减少了一个RTT时间。
ECDHE算法在选择椭圆曲线时尽量选择X25519的曲线，该曲线是目前最快的曲线。
在Nginx上可以使用ssl_ecdh_curve 指令配置想使用的椭圆曲线，把优先使用的放在前面。
代码语言：javascript复制ssl_ecdh_curve X25519:prime256v1:secp384r1;
对称加密算法优化
对称加密算法在安全性要求不是很高的情况下尽量选择AES_128_GCM，因为AES_128_GCM相比于AES_256_GCM生成的速度更快，但密钥长度较短。
在Nginx上可以使用ssl_ciphers 指令配置想使用的密钥套件(非对称加密算法和对称加密算法)，比如：
代码语言：javascript复制ssl_ciphers ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA;
使用以下命令可以查看本地Open SSL的密码套件
代码语言：javascript复制openssl ciphers
TLS1.2升级为1.3
TLS1.3的握手简化为一个1RTT，大大减少了网络IO的耗时。
TLS1.3如何将握手减少到1个RTT
上图是TLS1.3整个握手的过程，从图中可以看出经历过1个RTT以后，我们的客户端和服务端就可以发送加密数据了（Application Data）。
Client Hello中包含一个key_share，key_share中是椭圆曲线类型及其对应的公钥，第一个是预留的空值，第二个是我们这里选择的x25519曲线类型对应的公钥
Server Hello会确认椭圆曲线的类型及参数，并且生成公钥通过key_share消息发送给客户端。
至此，客户端和服务端都拥有了生成对称密钥的所有信息，客户端和服务端经历过一个RTT以后便可进行加密数据传输。
TLS1.3废除了RSA和DH加密算法，只支持ECDHE算法。
证书优化
证书优化主要优化：
- 传输优化
- 验证优化
如何进行传输优化
服务器证书应该选择椭圆曲线(ECDSA)证书，相同安全强度下，ECDS证书相比RSA证书密钥更短，这样可以减少证书的大小，减小网络传输耗时。
证书验证优化
证书验证需要通过CA公钥解密证书以及使用签名算法验证证书的完整性，并且为了知道证书是否被CA吊销，需要再去访问CA来获取证书的有效性，这一步就产生了额外的网络开销。
CRL
CRL是证书吊销列表，列表定期由CA更新，如果服务器的证书在该列表中，证书则失效。
CRL的缺点：
- 定期刷新，实时性差，在未刷新期间该证书依然有效
- 列表不断增大，下载耗时增加，同时客户端遍历证书验证列表耗时也增加
OCSP
OCSP就是向CA发送查询请求，CA返回证书的有效状态。
OCSP的速度依赖CA服务器的状态和与CA服务器之间的网络状态，如果服务器响应慢或中间网络慢，都会导致证书验证变慢。
OCSP Stapling
OCSP Stapling就是服务器周期性的向CA查询证书状态，获得一个带有时间戳和签名的结果响应并且进行缓存。然后在客户端和服务端建立TLS连接时，服务器会把上面的响应结果发送给客户端。客户端通过该结果就可以知道证书是否被吊销，不需要再向CA发起网络请求。
会话复用
TLS握手是为了协商对称密钥，如果将密钥进行缓存，下次HTTPS连接建立时直接复用缓存的密钥即可减少TLS握手的消耗。
会话复用的形式有：
- Session Id
- Session Ticket
- Pre-shared Key
Session Id
Session Id是客户端段和服务端在完成TLS握手连接后，双方会各自缓存一份密钥，使用唯一标识Session Id作为key，会话对称密钥为value。
客户端在下次建立连接时会带上Session Id，服务器接到Session Id后会在内存中进行查找，如果可以找到跳过密钥协商环节，直接使用以前的会话密钥恢复会话进行数据加密传输。
为了安全性，会话密钥的缓存注意设置过期时间。
Session Id的缺点
- 客户端增多，服务器缓存的密钥会越来越多，吃掉过多内存
- 现在的服务端基本都是多台服务器部署，客户端在下次连接时如果连接的是一台从未访问过的服务器，还是需要TLS握手
Session Ticket
服务器不再缓存会话密钥，客户端和服务端首次建立连接时，服务器会加密会话密钥作为Ticket发送给客户端，客户端会缓存该Ticket。
客户端和再次连接服务器时，会发送次Ticket，服务器收到解密以后即可拿到会话密钥，然后验证有效期，如果有效就可以恢复会话进行加密通信。
Session Ticket在多台服务器下，需要保证生成的会话密钥一样，这样才可以在多服务器间恢复会话。
Session ID和Session Ticket
这两种方式虽然可以复用会话减少TLS握手，但是这两种方式都不具备向前保密，一旦会话密钥泄漏即可破解过往截获的密文。
因为密钥泄漏，密文可以被破解，因此很容易对服务器进行重放攻击，破坏数据库数据。
避免重放攻击的方式就是需要对会话密钥设定一个合理的过期时间。
Pre-shared Key
Pre-shared Key是TLS1.3出现的优化方式，它的原理类似于Session Ticket，但Session Ticket需要1个RTT才能进行加密数据传输，但Pre-shared Key会在重连时将Ticket和HTTP请求一起发送给服务端，0个RTT即可加密传输数据。
Pre-shared Key的缺点和Session Ticket的缺点一样无法抵御重放攻击.
