性能提升一倍！云原生网关支持 TLS 硬件加速

2021-11-10 19:28:44

作者｜井轶

审核&校对｜如葑

随着网络环境的日渐复杂，传统 HTTP 明文传输协议带来的传输安全风险也日渐升高，因此 HTTPS 的密文传输协议得到了业界的普遍认可与广泛应用；任何事情都有其两面性，HTTPS 带来更高传输安全性的同时，由于需要做认证及数据加解密，相比 HTTP 使用 HTTPS 后使得网站访问速度变“慢”，且导致服务器 CPU 消耗变高、从而机器成本变得更“贵”。

业界在优化 HTTPS 的性能上也做了诸多探索，传统的软件优化方案有 Session 复用、OCSP Stapling、False Start、dynamic record size、TLS1.3、HSTS 等, 但软件层面如何优化也无法满足流量日益增长的速度，加上 CPU 摩尔定律已入暮年，使得专用硬件卸载 CPU 密集型运算成为业界一个通用解决方案。

网关为什么是 HTTPS 优化（TLS 卸载优化）的最佳路径？

网关作为请求流量进入业务应用的桥头堡，对于 HTTPS 优化这种跨业务的通用诉求是非常适合的落脚点，具体优势如下：

运维降本：网关统一处理 HTTPS 显然相比各业务分散处理运维成本更低。
机器降本：通常网关采用集群化的规模部署，统一 HTTPS 优化能够带来显著的机器成本优化。
业务提效：网关处理 HTTPS 后，业务只需关注自身逻辑即可，提升业务开发效率。

阿里在硬件加速上的探索

阿里统一接入网关 Tengine 承担着集团所有的入口流量，随着 HTTPS 化的全面推进，对于网关的性能挑战也非常大。业务驱动了技术创新，2017 年接入网关在硬件加速领域也迈出了第一步，开始尝试 QAT 卡硬件加速方案。

基于 QAT 卡的 TLS 硬件加速方案

整体方案由三部分组成：Tengine的ssl_async 指令、OpenSSL + QAT Engine 及 QAT Driver。其中 Tengine 通过适配 OpenSSL-1.1.0 的异步接口，将私钥操作卸载至硬件的 QAT engine 中，引擎通过 QAT 驱动调用硬件完成非对称算法取回结果。方案图示如下：

方案优点

HTTPS 卸载由独立硬件 QAT 完成，不额外增加 CPU 消耗，使用不同的加密套件测试，整体上性能非常好。详细性能数据可见文末文章链接《在阿里的统一接入层上进行了硬件加速的探索》。

方案缺点

运维成本非常高，独立的 QAT 卡需要提前独立采购，尤其对于电商大促的突发流量场景无法做到弹性。
在目前容器化部署的大背景下，QAT 的使用有很多稳定性问题。

基于 CPU Multi-Buffer 特性的 TLS 卸载加速方案

在经历 Tengine QAT 的探索实践后，阿里云推出了基于开源 Envoy 构建的 MSE 云原生网关产品，读到这里有的同学可能会疑惑为什么选择 Envoy 而不是内部的 Tengine，关于这个问题的答案在《阿里巴巴云原生网关三位一体的选择与实践》中。

阿里云 2021 年发布了搭载最新至强处理器 Ice Lake 的 ECS 产品，利用 CPU 的硬件特性使得算力大幅提升 50% 以上。其中提供的 Crypto Acceleration 特性，包括 Vector AES ，通过 multi-buffer lib 配合，能够加速 AES、 RSA、EC 等密码学计算。利用该特性使得 HTTPS 硬件加速得以摆脱专用硬件加速卡的限制，使用 CPU 内置指令结合 SIMD 机制也可以大幅提升 HTTPS 的性能。基于此云原生网关率先完成了对其适配，将硬件加速的性能优势带给用户，在不增加用户资源成本的同时大幅度提升 HTTPS 的性能。

性能提升一倍！云原生网关支持 TLS 硬件加速

从上图压测数据可以看出使用 TLS 硬件加速后，相比普通 HTTPS 请求 TLS 握手时延降低一倍，极限 QPS 提升 80% 以上。

方案压测

1、压测基础环境

云原生网关规格: 1C2G * 1
压测工具：Grafana k6
请求大小: 1kb
证书：RSA2048
加密套件:

ECDHE-RSA-CHACHA20-POLY1305(TLS1.2) TLS_AES_256_GCM_SHA384(TLS1.3)

2、压测结论

1C2G 情况下，开启硬件加速后极限 QPS 提高 80% 以上，TLS 握手时间降低一倍。注：采用 1C2G 规格是因为更容易观察单核极限性能。

3、测试数据

TLS版本	是否开启硬件加速	并发度	QPS	TLS握手平均时间	TLS握手最长时间
1.2	未开启	200	1009	98.5ms	177.37ms
1.2	未开启	500	1004	313.84ms	457.56ms
1.3	未开启	200	995	77.81ms	177.24ms
1.3	开启	200	1886	48.71ms	104.04ms
1.2	开启	200	1876	59.98ms	113.55ms
1.2	开启	500	1873	145.81ms	262.91ms