其他分享
首页 > 其他分享> > 【http】https加速优化

【http】https加速优化

作者:互联网

目录


前言

主要记录 https 加速的优化手段。

李柱明博客:https://www.cnblogs.com/lizhuming/p/15486943.html

HTTPS 的连接很慢

https 步骤简要划分

HTTPS 连接大致分为两个部分:

  1. 非对称加密握手(TLS 握手);
  2. 对称加密报文传输。

平时说的 HTTPS 很慢是前面第一部分,非对称加密握手阶段很慢。

而握手成功后是很快的。

握手耗时

TLS 握手最长可以花费两个消息往返(2-RTT)。

除了在握手消息的网络耗时之外,还有:

  1. 产生用于密钥交换的临时公私钥对(ECDHE);
  2. 验证证书时访问 CA 获取 CRL 或者 OCSP;(这两个知识点可以看后面)
  3. 非对称加密解密处理“Pre-Master”。

不做优化的情况下,HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒。

TLS 握手过程中主要耗时图参考:

证书验证

本点只是做理解记录,如果对 CRL 和 OCSP 有所理解,可以跳过。

CRL

CRL(Certificate revocation list)即是证书吊销列表。

由 CA 定期发布,里面是所有被撤销信任的证书序号。

查其内容即可知道本证书是否失效。

缺点:

  1. CRL 是定期发布,如果证书失效了,但是 CA 机构还没有及时更新 CRL,会导致误判的安全隐患。
  2. 随着吊销的证书越来越多,下载的 CRL 就会越来越大了,检索也越来越耗时。简直就是越来越浪费空间浪费时间。

所以现在用 OCSP 取代 CRL。

OCSP

OCSP(Online Certificate Status Protocol)在线证书状态协议。

客户端将请求发到一个 OCSP 应答器(服务器),应答器建立与 CA 证书库链接查询该证书的状态,然后回复“ 有效 ”、“ 注销 ”或“ 未知 ”的响应。

优点:

  1. 在线验证比 CRL 处理速度更快、更方便,也更具独立性。
  2. 并避免了令人头痛的逻辑问题和处理开销。

问题&解决:

  1. OCSP 也要多出一次网络请求的消耗,而且还依赖于 CA 服务器,如果 CA 服务器很忙,也是很耗时的。

    • 解决:OCSP Stapling:OCSP 装订,是一个补丁。可以让服务器预先访问 CA 获取 OCSP 响应,然后在握手时随着证书一起发给客户端,免去了客户端连接 CA 服务器查询的时间。

硬件优化

HTTPS 连接是计算密集型,而不是 I/O 密集型:

HTTPS 连接是计算密集型,而不是 I/O 密集型,其硬件优化手段有:

  1. 升级 CPU:如果内建 AES 优化,可以加速握手,也可以加速传输。
  2. SSL 加速卡:加解密时调用它的 API,让专门的硬件来做非对称加解密,分担 CPU 的计算压力。
  3. SSL 加速服务器:用专门的服务器集群解决 TLS 握手时的加密解密计算,性能要比单纯的“加速卡”要强大。

软件优化

软件方面的优化还可以再分成两部分:一个是 软件升级 ,一个是 协议优化

软件升级

软件升级,如升级 linux 内核,升级 OpenSSL 等等。

这些软件在更新版本的时候都会做性能优化、修复错误,只要运维能够主动配合,这种软件优化是最容易做的,也是最容易达成优化效果的。

但是升级内核兼容性要解决,版本跨度大,升级也是很棘手的。

协议优化

  1. 目前尽量采用 TLS1.3。

    • 它大幅度简化了握手的过程,完全握手只要 1-RTT,而且更加安全。
  2. 握手时使用的密钥交换协议尽量选用椭圆曲线的 ECDHE 算法。(RSA 在 TLS 1.3 中已经被废弃)

    • 运算速度快。
    • 安全性高。
    • 支持“False Start”,能够把 TLS1.2 握手的消息往返由 2-RTT 减少到 1-RTT,达到与 TLS1.3 类似的效果。
  3. 椭圆曲线也要选择高性能的曲线。

    • 最好是 x25519,次优选择是 P-256。
  4. 对称加密算法方面,可以选用“AES_128_GCM”,比“AES_256_GCM”略快一点点。

证书优化

握手过程中的证书验证也是一个比较耗时的操作,服务器需要把自己的证书链全发给客户端,然后客户端接收后再逐一验证。

两个可优化点:

  1. 证书传输。

  2. 证书验证。

  3. 服务器的证书可以选择椭圆曲线(ECDSA)证书而不是 RSA 证书。

    • 因为 224 位的 ECC 相当于 2048 位的 RSA。证书小,传输就少,计算也少。
  4. 采用 OCSP 验证证书。开启 OCSP Stapling。

会话复用

大杀器。

连接同一服务器时,明明证书、公钥都一样,但是每次通信都需要重新 TLS 握手,重新验证证书来获取公钥,算出对称秘钥。

这样太浪费时间了,我们可以使用缓存功能,双方把会话 ID 和对称秘钥记录下来,下次链接时直接使用岂不是更加方便快捷吗,其实这就是会话复用。

会话复用(TLS session resumption),复用分两种:

  1. Session ID:客户端和服务器首次连接后各自保存一个会话的 ID 号,内存里存储主密钥和其他相关的信息。

    1. 当客户端再次连接时发一个 ID 过来,服务器就在内存里找,找到就直接用主密钥恢复会话状态,跳过证书验证和密钥交换,只用一个消息往返就可以建立安全通信。
    2. 缺点:服务器保存每一个客户端的会话数据,对于拥有百万、千万级别用户的网站来说存储量就成了大问题,加重了服务器的负担。
  2. Session Ticket:会话票证。下述。

Session ID:

会话票证

由于 Session ID 方案加重了服务器负担,所以出现了另一种方案,Session Ticket(会话票证)。

Session Ticket:会话票证。

预共享密钥

Pre-shared Key,简称为“PSK”,预共享密钥。

False StartSession IDSession Ticket 等方式只能实现 1-RTT,而 TLS1.3 的 PSK 更进一步实现了 0-RTT。

原理和 Session Ticket 差不多,但在发送 Ticket 的同时会带上应用数据(Early Data),免去了服务器确认步骤。

注意:

  1. PSK 也不是完美的,它为了追求效率而牺牲了一点安全性,容易受到 重放攻击(Replay attack)的威胁。黑客可以截获 PSK 的数据,像复读机那样反复向服务器发送。

    • 解决:在消息里加入时间戳、nonce 验证,或者 一次性票证 限制重放。

标签:http,证书,握手,Session,https,服务器,优化,OCSP
来源: https://www.cnblogs.com/lizhuming/p/15486943.html