24 HTTPS 连接慢 - 优化

Posted by CodingWithAlice on April 29, 2021

24 HTTPS 连接慢 - 优化

  • 总结

    1、可以有多种硬件和软件手段减少网络耗时和计算耗时,让 HTTPS 变得和 HTTP 一样快,最可行的是软件优化

    2、应当尽量使用 ECDHE 椭圆曲线密码套件,节约带宽和计算量,还能实现 False Start

    3、服务器端应当开启OCSP Stapling功能,避免客户端访问 CA 去验证证书

    4、会话复用的效果类似 Cache,前提是客户端必须之前成功建立连接,后面就可以用Session ID Session Ticket等凭据跳过密钥交换、证书验证等步骤,直接开始加密通信

优化

  • HTTPS 连接划分为两个部分:

    1、建立连接时的 非对称加密握手

    2、握手后的 对称加密报文传输(算法性能好且有硬件优化,传输的性能损耗小到忽略不计)

  • 还有一些隐形消耗:

    1、产生用于密钥交换的临时公私钥对(ECDHE)

    2、验证证书时访问 CA 获取 CRL 或者 OCSP

    3、非对称加密解密处理 Pre-Master

硬件优化

花钱 :

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

2、SSL 加速卡:加解密时调用它的 API,让专门的硬件来做非对称加解密,分担 CPU 的计算压力

3、SSL 加速服务器:用专门的服务器集群来彻底卸载TLS 握手时的加密解密计算

但是硬件优化有一些开发适配工作,有一定的实施难度

软件优化

1、软件升级:正在使用的软件尽量升级到最新版本

但是对于很多大中型公司来说,硬件/软件升级有较高的风险,可能会影响线上

2、协议优化

先看下影响性能的主要几个问题点:

image-20210429135556547

  • 握手过程中的优化方案:

    1、尽量采用 TLS1.3,它大幅度简化了握手的过程,完全握手只要 1-RTT,而且更加安全

    2、如果暂时不能升级到 1.3,只能用 1.2,那么握手时使用的密钥交换协议应当尽量选用 椭圆曲线的 ECDHE 算法。它不仅运算速度快,安全性高,还支持False Start,能够把握手的消息往返由 2-RTT 减少到 1-RTT,达到与 TLS1.3 类似的效果

    3、椭圆曲线也要选择高性能的曲线,最好是 x25519,次优选择是 P-256

    4、对称加密算法方面,也可以选用AES_128_GCM,它能比AES_256_GCM略快一点点

  • 证书优化

    已知:服务器需要把自己的证书链全发给客户端,然后客户端接收后再逐一验证

    优化点:证书传输、证书验证

    • 证书传输:

      选择椭圆曲线(ECDSA)证书而不是 RSA 证书,因为 224 位的 ECC 相当于 2048 位的 RSA,所以椭圆曲线证书的个头要比 RSA 小很多,即能够节约带宽也能减少客户端的运算量

    • 证书验证:

      除了要公钥解密验证多个证书签名外,因为证书还有可能会被撤销失效,客户端有时还会再去访问 CA,下载 CRL 或者 OCSP 数据,这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信,增加好几个 RTT

      1、 OCSP(在线证书状态协议,Online Certificate Status Protocol),向 CA 发送查询请求,让 CA 返回证书的有效状态

      2、由于1中多出一次网络请求,且依赖于CA服务器性能,于是又出来了一个补丁,叫OCSP Stapling(OCSP 装订),它可以让服务器预先访问 CA 获取 OCSP 响应,然后在握手时随着证书一起发给客户端,免去了客户端连接 CA 服务器查询的时间

  • 会话复用

    定义: TLS 握手的重点是算出主密钥 Master Secret,不优化的话主密钥每次连接都要重新计算,优化方式就是将算出来的主密钥缓存一下重用

    • Session ID

      客户端和服务器首次连接后各自保存一个 会话的 ID 号服务器内存里存储 主密钥和其他相关的信息 –> 当客户端再次连接时发一个 ID 过来,服务器就在内存里找,找到就直接用主密钥 恢复会话状态,跳过证书验证和密钥交换,只用一个消息往返就可以建立安全通信

    • Session Ticket

      存储的责任由服务器转移到了客户端,服务器加密会话信息,用New Session Ticket消息发给客户端,让 客户端保存 –> 重连的时候,客户端使用扩展session_ticket发送Ticket,服务器解密后验证有效期,就可以恢复会话,开始加密通信

      注意:需要使用一个固定的密钥文件(ticket_key)来加密 Ticket,为了防止密钥被破解,保证“前向安全”,密钥文件需要定期轮换,比如设置为一小时或者一天

预共享密钥

在客户端发送 ticket 的同时会带上应用数据(Early Data),免去了 1.2 里的服务器确认步骤,这种方式叫Pre-shared Key,简称为PSK

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