HTTPS 如何优化
作者：互联网
多角度优化 HTTPS
分析性能损耗
产生性能消耗的两个环节：
- TLS 协议握手过程；（TLS 协议握手过程最长可以花费 2 RTT<mean：网络延时>）
- 握手后的对称加密报文传输。
解决方案：
对于1，暂时没有办法。
对于2， 现在主流的对称加密算法 AES、ChaCha20 性能都是不错的，⽽且⼀些 CPU ⼚商还针对它们做了 硬件级别的优化，因此这个环节的性能消耗可以说⾮常地⼩。
硬件优化
HTTPS 协议是计算密集型，而不是 I/O 密集型。所以应该把钱花在 CPU 上，尽量选择可以支持 AES-NI 特性的 CPU。
软件优化
将正在使用的软件升级到最新版本。
协议优化
密钥交换算法优化
选用 ECDHE 算法替代 RSA 算法，同时尽量选择 x25519 椭圆曲线。
TLS 升级
把 TLS 1.2 升级成 TLS 1.3 。
证书优化
证书传输优化
对于服务器的证书应该选择椭圆曲线（ECDSA）证书，而不是 RSA 证书。
因为在相同按全强度下，ECC 密钥长度比 RSA 短得多。
证书验证优化
CRL称为证书吊销列表（Certificate Revocation List）。由 CA 维护。
- 实时性较差。
- 下载速度会随着吊销证书的增多越来越慢。
OCSP
OCSP 替代 CRL。
OCSP 称为在线证书状态协议（Online Certificate Status Protocol）。在线查询。
OCSP Stapling
OCSP Stapling 解决了 OCSP 的网络开销问题。
原理：服务器向 CA 周期性地查询证书状态，获得一个带有时间戳和签名的响应结果并缓存。
会话复用
Session ID
原理：
客户端和服务器首次 TLS 握手连接后，双方会在内存缓存会话密钥，并用唯一的 Session ID 来标识。（ Session ID 和会话密钥相当于 key-value 的关系 ）
具体过程：
当客户端再次连接时，hello 消息⾥会带上 Session ID，服务器收到后就会从内存找，如果找到就直接⽤该会话密 钥恢复会话状态，跳过其余的过程，只⽤⼀个消息往返就可以建⽴安全通信。当然为了安全性，内存中的会话密钥 会定期失效。
缺点：
- 服务器必须保持每⼀个客户端的会话密钥，随着客户端的增多，服务器的内存压⼒也会越⼤。
- 现在⽹站服务⼀般是由多台服务器通过负载均衡提供服务的，客户端再次连接不⼀定会命中上次访问过的服务器，于是还要⾛完整的 TLS 握⼿过程；
Session Ticket
解决了 Session ID 的问题：
服务器不再缓存每个客户端的会话密钥，而是把缓存的工作交给客户端。
缺点：
Session ID 和 Session Ticket 都不具备前向安全性，因为⼀旦加密「会话密钥」的密钥被破解或者服务器泄漏「会 话密钥」，前⾯劫持的通信密⽂都会被破解 。且难以应对 【重放攻击】。
重放攻击：
重放攻击的危险之处在于，如果中间人截获了某个客户端的 Session ID 或 Session Ticket 以及 POST 报文，而一般 POST 请求会改变数据库的数据，中间人就可以利用此截获的报文，不断向服务器发送该报文，这样就会导致数据库的数据被中间人改变了，而客户是不知情的。
如何避免重放攻击：
- 对 会话密钥 设定一个合理的过期时间。
- 只针对安全的 HTTP 请求如 GET/HEAD 使用会话重用。
Pre-shared Key
前⾯的 Session ID 和 Session Ticket ⽅式都需要在 1 RTT 才能恢复会话。
对于重连，TLS1.3 只需要 0 RTT，原理和 Ticket 类似，只不过在重连时，客户端会把 Ticket 和 HTTP 请求⼀同发送给服务端，这种⽅式叫 Pre-shared Key。
同样的，Pre-shared Key 也有重放攻击的危险。
标签：证书,如何,Session,密钥,HTTPS,服务器,优化,ID,客户端 来源： https://www.cnblogs.com/tiddler/p/16651119.html