计算机网络——HTTPS的优化方式

摘要

由裸数据传输的HTTP协议转成加密数据传输的HTTPS 协议，给应⽤数据套了个保护伞，虽然提⾼安全性，但是同时也带来了性能消耗。 因为HTTPS 相⽐HTTP 协议多⼀个 TLS 协议握⼿过程，通过非对称加密握⼿协商或者交换出对称加密密钥，这个过程最长可以花费 2RTT，后续传输的应⽤数据都得使⽤对称加密密钥来加密/解密。 但是有的时候为了数据的安全性，我们不得不使⽤ HTTPS 协议，⾄今⼤部分网址都已从HTTP 迁移⾄ HTTPS 协议，因此针对 HTTPS 的优化是非常重要的。本博文将从提供多个角度的优化HTTPS的方案。

计算机网络知识脑图

计算机网络——计算机网络知识脑图_庄小焱的博客-CSDN博客_计算机网络面试题总结

计算机网络大厂面试问题集合

计算机网络——大厂面试问题集合_庄小焱的博客-CSDN博客

计算机网络基础知识

计算机网络——网络基础知识_庄小焱的博客-CSDN博客_数据转发服务器

IP相关基础原理

计算机网络——IP协议基础原理_庄小焱的博客-CSDN博客_ip网络技术

HTTP协议原理

计算机网络——HTTP协议原理_庄小焱的博客-CSDN博客_http协议原理

HTTP的优化方式

计算机网络——HTTP的优化方式_庄小焱的博客-CSDN博客

HTTPS协议原理

计算机网络——HTTPS协议原理_庄小焱的博客-CSDN博客_https协议原理

HTTPS的优化方式

计算机网络——HTTPS的优化方式_庄小焱的博客-CSDN博客

TCP可靠性传输原理

计算机网络——TCP可靠性传输原理_庄小焱的博客-CSDN博客_tcp的可靠性是如何实现的

TCP/IP三次握手四次挥手原理

计算机网络——HTTP的三次握手与四次挥手原理_庄小焱的博客-CSDN博客_三次握手和四次挥手原理

TCP的优化方式

计算机网络——TCP的优化方式_庄小焱的博客-CSDN博客_tcp协议优化技术

DNS协议（域名解析）原理

计算机网络——DNS协议（域名解析）原理_庄小焱的博客-CSDN博客_计算机网络dns

ARP协议(地址解析)原理

计算机网络——ARP协议(地址解析)原理_庄小焱的博客-CSDN博客_地址解析协议的工作原理

ARQ协议(自动重传请求)原理

计算机网络——ARQ协议(自动重传请求)原理_庄小焱的博客-CSDN博客_连续arq协议的原理

DHCP协议原理

计算机网络——DHCP（动态获取IP）原理_庄小焱的博客-CSDN博客_计算机网络dhcp

NAT协议原理

计算机网络——NAT协议（网络地址转换）原理_庄小焱的博客-CSDN博客

ICMP/IGMP协议原理

计算机网络——ICMP/IGMP协议原理_庄小焱的博客-CSDN博客_计算机网络igmp

HTTP网络访问全流程

计算机网络——HTTP网络访问全流程_庄小焱的博客-CSDN博客_网络访问流程

虚拟网路模型原理

计算机网络——虚拟网路模型原理_庄小焱的博客-CSDN博客

其他网络知识

计算机网络——select/poll/epoll底层原理_庄小焱的博客-CSDN博客

计算机网络——cookie/session/token原理_庄小焱的博客-CSDN博客

计算机网络——网络通信加密原理_庄小焱的博客-CSDN博客_网络通信加密

计算机网络——GRPC通信原理_庄小焱的博客-CSDN博客_grpc原理

计算机网络——tcpdump/Wireshark抓包实战_庄小焱的博客-CSDN博客_网络抓包

计算机网络——TCP抓包连接实战_庄小焱的博客-CSDN博客_tcp全连接和半连接

一、性能损失分析

既然要对 HTTPS 优化，那得清楚哪些步骤会产⽣性能消耗，再对症下药产⽣性能消耗的两个环节：

• 第⼀个环节， TLS 协议握⼿过程
• 第⼆个环节，握⼿后的对称加密报⽂传输。

对于第⼆环节，现在主流的对称加密算法 AES、ChaCha20 性能都是不错的，而且⼀些CPU⼚商还针对它们做了 硬件级别的优化，因此这个环节的性能消耗可以说⾮常地⼩。

而第⼀个环节，TLS 协议握⼿过程不仅增加了⽹络延时（最长可以花费掉 2 RTT），而且握⼿过程中的⼀些步骤也 会产⽣性能损耗，比如：

• 对于 ECDHE 密钥协商算法，握⼿过程中会客户端和服务端都需要临时⽣成椭圆曲线公私钥；
• 客户端验证证书时，会访问 CA 获取 CRL 或者 OCSP，⽬的是验证服务器的证书是否有被吊销；
• 双⽅计算 Pre-Master，也就是对称加密密钥；

二、硬件优化

对于计算机⾥也是⼀样，软件都是跑在物理硬件上，硬件越⽜逼，软件跑的也越快，所以如果要优化 HTTPS 优 化，最直接的⽅式就是花钱买性能参数更⽜逼的硬件。

但是花钱也要花对方向，HTTPS 协议是计算密集型，⽽不是I/O密集型，所以不能把钱花在⽹卡、硬盘等地⽅，应该花在 CPU上。

⼀个好的CPU，可以提⾼计算性能，因为HTTPS连接过程中就有⼤量需要计算密钥的过程，所以这样可以加速 TLS握⼿过程。

另外，如果可以，应该选择可以⽀持 AES-NI 特性的 CPU，因为这种款式的 CPU 能在指令级别优化了 AES 算 法，这样便加速了数据的加解密传输过程。

如果你的服务器是 Linux 系统，那么你可以使⽤下⾯这⾏命令查看CPU是否⽀持 AES-NI 指令集：

sort -u /proc/crypto | grep module | grep aes module : aesni_intel

三、软件优化

如果公司预算充⾜对于新的服务器是可以考虑购买更好的 CPU，但是对于已经在使⽤的服务器，硬件优化的⽅式 可能就不太适合了，于是就要从软件的⽅向来优化了。

软件的优化⽅向可以分层两种，⼀个是软件升级，⼀个是协议优化。

先说第⼀个软件升级，软件升级就是将正在使⽤的软件升级到最新版本，因为最新版本不仅提供了最新的特性，也优化了以前软件的问题或性能。⽐如：

• 将 Linux 内核从 2.x 升级到 4.x；
• 将 OpenSSL 从 1.0.1 升级到 1.1.1；

看似简单的软件升级，对于有成百上千服务器的公司来说，软件升级也跟硬件升级同样是⼀个棘⼿的问题，因为要实⾏软件升级，会花费时间和⼈⼒，同时也存在⼀定的⻛险，也可能会影响正常的线上服务。既然如此，我们把⽬光放到协议优化，也就是在现有的环节下，通过较⼩的改动，来进行优化。

四、Session回话复用

TLS 握⼿的⽬的就是为了协商出会话密钥，也就是对称加密密钥，那我们如果我们把⾸次 TLS 握⼿协商的对称加 密密钥缓存起来，待下次需要建⽴ HTTPS 连接时，直接「复⽤」这个密钥，不就减少 TLS 握⼿的性能损耗了吗？

这种⽅式就是会话复⽤（TLS session resumption），会话复⽤分两种：

• 第⼀种叫 Session ID
• 第⼆种叫 Session Ticket

Session ID

工作原理：客户端和服务器⾸次 TLS 握⼿连接后，双⽅会在内存缓存会话密钥，并⽤唯⼀的 Session ID 来标识，Session ID 和会话密钥相当于 key-value 的关系。当客户端再次连接时，hello 消息⾥会带上 Session ID，服务器收到后就会从内存找，如果找到就直接⽤该会话密 钥恢复会话状态，跳过其余的过程，只⽤⼀个消息往返就可以建⽴安全通信。当然为了安全性，内存中的会话密钥会定期失效。

但是它有两个缺点：服务器必须保持每⼀个客户端的会话密钥，随着客户端的增多，服务器的内存压⼒也会越⼤。 现在⽹站服务⼀般是由多台服务器通过负载均衡提供服务的，客户端再次连接不⼀定会命中上次访问过的服 务器，于是还要⾛完整的 TLS 握⼿过程；

Session Ticket

为了解决 Session ID 的问题，就出现了 Session Ticket，服务器不再缓存每个客户端的会话密钥，⽽是把缓存的⼯ 作交给了客户端，类似于 HTTP 的 Cookie。客户端与服务器⾸次建⽴连接时，服务器会加密「会话密钥」作为 Ticket 发给客户端，交给客户端缓存该 Ticket。客户端再次连接服务器时，客户端会发送 Ticket，服务器解密后就可以获取上⼀次的会话密钥，然后验证有效期， 如果没问题，就可以恢复会话了，开始加密通信。

对于集群服务器的话，要确保每台服务器加密 会话密钥的密钥是⼀致的，这样客户端携带 Ticket 访问任意⼀ 台服务器时，都能恢复会话。Session ID 和 Session Ticket 都不具备前向安全性，因为⼀旦加密会话密钥的密钥被破解或者服务器泄漏会话密钥，前⾯劫持的通信密⽂都会被破解。同时应对重放攻击也很困难，这⾥简单介绍下重放攻击⼯作的原理。

假设 Alice 想向 Bob 证明⾃⼰的身份。 Bob 要求 Alice 的密码作为身份证明，爱丽丝应尽全⼒提供（可能是在经过 如哈希函数的转换之后）。与此同时，Eve 窃听了对话并保留了密码（或哈希）。交换结束后，Eve（冒充 Alice ）连接到 Bob。当被要求提供身份证明时，Eve 发送从 Bob 接受的最后⼀个会话中 读取的 Alice 的密码（或哈希），从⽽授予 Eve 访问权限。

᯿放攻击的危险之处在于，如果中间⼈截获了某个客户端的 Session ID 或 Session Ticket 以及 POST 报⽂，⽽⼀ 般 POST 请求会改变数据库的数据，中间⼈就可以利⽤此截获的报⽂，不断向服务器发送该报⽂，这样就会导致数 据库的数据被中间⼈改变了，⽽客户是不知情的。避免᯿放攻击的⽅式就是需要对会话密钥设定⼀个合理的过期时间。

Pre-shared Key

前⾯的 Session ID 和 Session Ticket ⽅式都需要在 1 RTT 才能恢复会话。⽽ TLS1.3 更为⽜逼，对于᯿连 TLS1.3 只需要 0 RTT，原理和 Ticket 类似，只不过在᯿连时，客户端会把 Ticket 和 HTTP 请求⼀同发送给服务端，这种⽅式叫 Pre-shared Key。

如上图，假设中间⼈通过某种⽅式，截获了客户端使⽤会话᯿⽤技术的 POST 请求，通常 POST 请求是会改变数 据库的数据，然后中间⼈就可以把截获的这个报⽂发送给服务器，服务器收到后，也认为是合法的，于是就恢复会话，致使数据库的数据⼜被更改，但是此时⽤户是不知情的。 所以，应对重放攻击可以给会话密钥设定⼀个合理的过期时间，以及只针对安全的 HTTP 请求如 GET/HEAD 使⽤ 会话重⽤。

五、协议优化

 协议的优化:协议的优化就是对密钥交换过程进⾏优化。

密钥交换算法优化

TLS1.2 版本如果使⽤的是RSA密钥交换算法，那么需要4次握⼿，也就是要花费2RTT，才可以进⾏应⽤数据的传输，⽽且 RSA 密钥交换算法不具备前向安全性。总之使⽤ RSA 密钥交换算法的 TLS 握⼿过程，不仅慢，⽽且安全性也不⾼。

因此如果可以，尽量选⽤ECDHE密钥交换算法替换RSA算法，因为该算法由于⽀持False Start，它是抢跑的意思，客户端可以在 TLS 协议的第 3 次握⼿后，第 4 次握⼿前，发送加密的应⽤数据，以此将 TLS 握⼿的消息 往返由 2 RTT 减少到 1 RTT，⽽且安全性也⾼，具备前向安全性。

ECDHE算法是基于椭圆曲线实现的，不同的椭圆曲线性能也不同，应该尽量选择x25519曲线，该曲线是⽬前最快的椭圆曲线。

⽐如在Nginx上，可以使⽤ssl_ecdh_curve 指令配置想使⽤的椭圆曲线，把优先使⽤的放在前⾯：

ssl_ecdh_curve X25519:secp384r1

对于对称加密算法⽅⾯，如果对安全性不是特别⾼的要求，可以选⽤AES_128_GCM，它⽐ AES_256_GCM快⼀ 些，因为密钥的⻓度短⼀些。

⽐如在Nginx 上，可以使⽤ssl_ciphers 指令配置想使⽤的⾮对称加密算法和对称加密算法，也就是密钥套件，⽽ 且把性能最快最安全的算法放在最前⾯：

ssl_ciphers 'EECDH+ECDSA+AES128+SHA:RSA+AES128+SHA'

TLS升级:当然，如果可以，直接把 TLS 1.2 升级成 TLS 1.3，TLS 1.3 ⼤幅度简化了握⼿的步骤，完成 TLS 握⼿只要1RTT，⽽且安全性更⾼。

在 TLS 1.2 的握⼿中，⼀般是需要 4 次握⼿，先要通过 Client Hello （第 1 次握⼿）和 Server Hello（第 2 次握 ⼿） 消息协商出后续使⽤的加密算法，再互相交换公钥（第 3 和 第 4 次握⼿），然后计算出最终的会话密钥，下 图的左边部分就是 TLS 1.2 的握⼿过程：

上图的右边部分就是 TLS 1.3 的握⼿过程，可以发现 TLS 1.3 把 Hello 和公钥交换这两个消息合并成了⼀个消息， 于是这样就减少到只需 1 RTT 就能完成 TLS 握⼿。

怎么合并的呢？具体的做法是，客户端在 Client Hello 消息⾥带上了⽀持的椭圆曲线，以及这些椭圆曲线对应的公钥。服务端收到后，选定⼀个椭圆曲线等参数，然后返回消息时，带上服务端这边的公钥。经过这 1 个 RTT，双⽅⼿上 已经有⽣成会话密钥的材料了，于是客户端计算出会话密钥，就可以进⾏应⽤数据的加密传输了。而且TLS1.3 对密码套件进⾏“减肥”了， 对于密钥交换算法，废除了不⽀持前向安全性的 RSA 和 DH 算法，只⽀持 ECDHE 算法。

对于对称加密和签名算法，只⽀持⽬前最安全的⼏个密码套件，⽐如 openssl 中仅⽀持下⾯ 5 种密码套件：

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

六、CA证书优化

为了验证的服务器的身份，服务器会在 TSL 握⼿过程中，把⾃⼰的证书发给客户端，以此证明⾃⼰身份是可信 的。 对于证书的优化，可以有两个⽅向：

• ⼀个是证书传输，
• ⼀个是证书验证；

证书传输优化

要让证书更便于传输，那必然是减少证书的大小，这样可以节约带宽，也能减少客户端的运算量。所以，对于服务 器的证书应该选择椭圆曲线（ECDSA）证书，⽽不是 RSA 证书，因为在相同安全强度下， ECC 密钥⻓度⽐ RSA 短的多。

证书验证优化

客户端在验证证书时，是个复杂的过程，会⾛证书链逐级验证，验证的过程不仅需要「⽤ CA 公钥解密证书」以及 「⽤签名算法验证证书的完整性」，⽽且为了知道证书是否被 CA 吊销，客户端有时还会再去访问 CA， 下载 CRL 或者 OCSP 数据，以此确认证书的有效性。 这个访问过程是 HTTP 访问，因此⼜会产⽣⼀系列⽹络通信的开销，如 DNS 查询、建⽴连接、收发数据等。

CRL

CRL 称为证书吊销列表（Certificate Revocation List），这个列表是由 CA 定期更新，列表内容都是被撤销信任的证书序号，如果服务器的证书在此列表，就认为证书已经失效，不在的话，则认为证书是有效的。

但是 CRL 存在两个问题：

• 第⼀，由于 CRL 列表是由 CA 维护的，定期更新，如果⼀个证书刚被吊销后，客户端在更新 CRL 之 前还是会信任这个证书，实时性较差；
• 第⼆，随着吊销证书的增多，列表会越来越⼤，下载的速度就会越慢，下载完客户端还得遍历这么⼤ 的列表，那么就会导致客户端在校验证书这⼀环节的延时很⼤，进⽽拖慢了 HTTPS 连接。

OCSP

因此，现在基本都是使⽤OCSP ，名为在线证书状态协议（Online Certificate Status Protocol）来查询证书的有效 性，它的⼯作⽅式是向 CA 发送查询请求，让CA 返回证书的有效状态。

不必像CRL⽅式客户端需要下载⼤⼤的列表，还要从列表查询，同时因为可以实时查询每⼀张证书的有效性，解 决了 CRL 的实时性问题。 OCSP 需要向 CA 查询，因此也是要发⽣⽹络请求，⽽且还得看 CA 服务器的“脸⾊”，如果⽹络状态不好，或者 CA 服务器繁忙，也会导致客户端在校验证书这⼀环节的延时变⼤。

OCSP Stapling

于是为了解决这⼀个⽹络开销，就出现了 OCSP Stapling，其原理是：服务器向 CA 周期性地查询证书状态，获得 ⼀个带有时间戳和签名的响应结果并缓存它。

当有客户端发起连接请求时，服务器会把这个「响应结果」在 TLS 握⼿过程中发给客户端。由于有签名的存在， 服务器⽆法篡改，因此客户端就能得知证书是否已被吊销了，这样客户端就不需要再去查询。

博文参考

《小林图解网络》