【http】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 号,内存里存储主密钥和其他相关的信息。
- 当客户端再次连接时发一个 ID 过来,服务器就在内存里找,找到就直接用主密钥恢复会话状态,跳过证书验证和密钥交换,只用一个消息往返就可以建立安全通信。
- 缺点:服务器保存每一个客户端的会话数据,对于拥有百万、千万级别用户的网站来说存储量就成了大问题,加重了服务器的负担。
-
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 验证,或者 一次性票证 限制重放。
标签:http,证书,握手,Session,https,服务器,优化,OCSP 来源: https://www.cnblogs.com/lizhuming/p/15486943.html