作者：vivo 互联网服务器团队 - Qiu Xiangcun

本文将探讨如何通过使用 Intel QuickAssist Technology（QAT）来优化 VUA 的 HTTPS 转发性能。我们将介绍如何使用 QAT 通过硬件加速来提高 HTTPS 转发的性能，并探讨 QAT 在不同应用场景中的表现。最后，我们将讨论如何根据实际情况进行优化，以获得最佳转发性能。

VLB 全称 vivo load balance。

vivo 负载均衡作为 vivo 互联网业务的 IDC 流量入口，承接了很多重要业务的公网流量。本文针对 VLB 的七层负载 VUA HTTPS 性能优化进行探索，以获取最佳转发性能。

一、vivo VLB 整体架构

▲  图 1 vivo VLB 整体架构

VLB 整体架构的核心包括：基于 DPDK 的四层负载 VGW，基于 Apache APISIX 和 NGINX 扩展功能的七层负载 VUA，以及统一管控运维平台。

其主要特点为：

• 高性能：具备千万级并发和百万级新建能力。

• 高可用：通过 ECMP、健康检查等，提供由负载本身至业务服务器多层次的高可用。

• 可拓展：支持四层/七层负载集群、业务服务器的横向弹性伸缩、灰度发布。

• 四层负载能力：通过 BGP 向交换机宣告 VIP；支持均衡算法如轮询、加权轮询、加权最小连接数、一致性哈希；FullNAT 转发模式方便部署等。

• 七层负载能力：支持基于域名和 URL 的转发规则配置；支持均衡算法如轮询、加权轮询等。

• SSL/TLS 能力：证书、私钥、握手策略的管理配置；支持 SNI 配置；支持基于多种加速卡的 SSL 卸载硬件加速等。

• 流量防控：提供一定的 Syn-Flood 防护能力；提供网络流量控制手段如 QoS 流控、ACL 访问控制等。

• 管控平台：支持多种维度的网络和业务指标配置、监控和告警。

本文针对 VLB 中七层负载 VUA 的 SSL/TLS 性能优化两种方法进行概述性介绍：

• 基于硬件技术的 QAT_HW

• 基于指令集优化的 QAT_SW

二、VUA 七层负载均衡

2.1 VUA 介绍

目前公司接入层最大的能力痛点，就是动态上游、动态路由、动态证书、流量灰度、黑白名单、动态调度、日志查询与追踪等。为了支持公司业务的持续发展，特别是业务的全面容器化，亟需建设一个统一接入平台，融合目前线上的 NGINX 集群及 Ingress NGINX，用于承载公司 web 端、移动端、合作伙伴、内部系统、IOT 设备流量，对齐行业的接入层能力，保障业务的顺利发展。

VUA 定义：vivo Unified Access。

vivo 统一接入层，是基于 APISIX-2.4 的二次开发。

2.2 VUA 架构

▲ 图 2 APISIX 架构

（图片来源：Github-apache/apisix）

• Apache APISIX：OpenResty 1.19.3.1 + Lua 组成（组件本身是无状态的）。

• Manager-api：由 Go 语言开发，用于配置的管理和变更。

• APISIX-Ingress-Controller：基于 K8S 原生 Controller 机制开发完成，支持多副本 Leader-Election 热备机制。主要监听 K8s api server，用于 pod 信息上报到 Manager-api。

• Etcd：用于保存路由、upstream 等配置信息。

▲ 图 3 VUA 架构

三、QAT 加速技术

Intel QuickAssist 技术 OpenSSL 引擎 (QAT_Engine) 支持硬件加速以及基于矢量化指令的优化软件。这一特性始于第三代 Intel® Xeon®可扩展处理器，为用户提供了更多加速其工作负载的选项。

3.1 异步架构

VUA 基于 NGINX 原生的异步处理框架上拓展出针对异步硬件引擎的异步事件处理机制，整体交互流程如下图所示：

• ASYNC_start_job：NGINX 调用 ssl lib 库接口 SSL_do_handshake, 开启一个异步任务。

• RSA/ECDH 加解密操作。

• QAT 引擎将加密消息发送给驱动，创建异步事件监听 fd，将 fd 绑定到异步任务的上下文中。

• qat_pause_job: 调用该接口保存异步任务执行的堆栈信息，任务暂时被挂起，等待硬件加解密操作完成。同时进程堆栈切换到 NGINX IO 调用主流程，ssl 返回 WANT_ASYNC，NGINX 开始处理其他等待时间。

• NGINX IO 处理框架获取保存在异步任务上下文中的 asyncfd，并添加到 epoll 队列中启动监听。

• 加速卡处理任务完成，QAT 引擎调用 qat_wake_job 接口唤醒任务（也就是将 async fd 标记为可读）。QAT 为 NGINX 提供了多种轮询方式去轮询加速卡响应队列，目前 VUA 采用的是启发式轮询的方式，具体参数可以在配置文件中定义。

• NGINX 处理异步事件重新调用异步任务框架的 ASYNC_start_job 接口，这时候程序切换上下文，堆栈执行后跳回之前 pause job 的地方。

3.2 QAT 组件架构概览

• Application

应用层主要包含两块内容：

（1）QAT 异步框架的 patch，该 patch 提供对异步模式的支持；

（2）QAT 引擎，engine 是 openssl 本身支持的一种机制，用以抽象各种加密算法的实现方式，intel 提供了 QAT 引擎的开源代码用以专门支持 QAT 加速。

• SAL（service access layer）

服务接入层，给上层 Application 提供加速卡接入服务，目前 QAT 主要提供 crypto 和 compression 两种服务，每一种服务都相互独立，接入层封装了一系列实用的接口，包括创建实例，初始化消息队列、发送\接受请求等。

• ADF（acceleration driver framework）

加速卡驱动框架，提供 SAL 需要的驱动支持，如上图，包括 intel_qat.ko、8950pci 驱动、usdm 内存管理驱动等。

3.3 QAT_HW 和 QAT_SW

QAT_HW 基于 QAT 硬件加速卡，通过 Openssl 引擎使用qatengine.so库中链接的 QAT 驱动程序。

QAT_SW 是基于 QAT 软件加速，通过 Openssl 引擎使用qatengine.so库中链接的 crypto_mb 和 ipsec_mb 库。基于 intel AVX-512 整数乘加 (IFMA) 操作缓冲区库，当用户构建指令支持 qat_sw 时，通过批处理队列中维护的多个请求执行操作，并使用 OpenSSL 异步基础架构将批处理请求最多提交到 8 个 Crypto Multi-buffer API，后者使用 AVX512 矢量指令并行处理它们。主要面向非对称 PKE 和 AES-GCM 的英特尔® QAT 软件加速，RSA 支持密钥大小 2048、3072、4096，AES128-GCM、AES192-GCM 和 AES256-GCM。

如果平台同时支持 QAT_HW 和 QAT_SW，则默认是使用 QAT 硬件加速非对称算法和对称链式密码，使用 QAT 软件加速对称 GCM 密码。如果平台没有 QAT 硬件支持，那么它将使用 QAT_SW 加速来实现 qatengine 中支持的非对称算法。

下图说明了 QAT_Engine 的高级软件架构。NGINX 和 HAProxy 等应用程序是与 OpenSSL 接口的常见应用程序。OpenSSL 是一个用于 TLS/SSL 协议的工具包，从 1.1.0 版本开始，它开发了一个模块化系统来插入特定于设备的引擎。如上所述，QAT_Engine 中有两个独立的内部实体，通过它们可以执行加速。

▲（图片来源：Github-intel/QAT_Engine）

四、优化方案性能提升对比

4.1 QAT_HW

本方案采用 intel 8970 型号加速卡进行测试，采用 RSA 证书进行 HTTPS 加解密。

（1）测试方法

执行机部署适配 QAT 引擎后的 VUA，发包测试机进行压测灌包，在 CPU 负载达到 100%后比较得出 VUA 在进行 QAT 优化后的新建 QPS 对比。

（2）测试场景

（3）本地测试数据对比

使用 QAT 加速卡性能对比

QAT 卡优化方案，通过 VUA 进行 HTTPS 打流业务实测，与采用 OpenSSL 软件加解密场景做对比：

• 使用 QAT 加速卡，同 worker 下，RSA 平均 QPS 提升 1.27 倍。

• 随着进程数的增加，QAT 加速卡达到瓶颈，趋于稳定，在 56 worker 下，最高可达 4.4w qps。

此优化方案所带来的性能提升主要依赖于：

• QAT 采用用户态驱动的方式，实现了内核态到用户态内存零拷贝。

• VUA 采用异步模式调用 OpenSSL API，代替传统的同步模式调用。

• QAT 驱动程序支持多加速卡同时进行卸载加速。

4.2 QAT_SW

本方案采用 icelake 6330 型号（支持 AVX512 指令集）进行测试，采用 RSA 证书进行 HTTPS 加解密。

（1）测试方法

执行机部署适配指令集优化的 VUA，发包测试机进行压测灌包，在 CPU 负载达到 100%后比较得出 VUA 在进行指令集优化后的新建 QPS 对比。

（2）测试组网

（3）本地测试数据对比

使用指令集优化性能对比

指令集优化方案，通过 VUA 进行 HTTPS 打流业务实测，与采用 openssl 软件加解密场景做对比：

• 使用指令集优化，同 worker 下，RSA 平均 QPS 提升 1 倍。

• 随着进程数的增加，指令集优化加速会成线性增长，在 56 worker 下，最高可达 5.1w qps。

 此优化方案所带来的性能提升主要依赖于：

• 使用 AVX512 指令优化加解密

五、总结与思考

截止目前，vivo VLB 在软硬件加速领域，已经同时支持 exar 加速卡与 intel QAT 硬件和软件指令集加速等方案，成功实现核心网络组件自主可控，为构建高性能的网关架构赋能行业打下坚实的基础。

未来 vivo VLB 将持续构建接入层网关能力体系。

• 安全与合规

  作为 vivo 统一流量接入入口，VLB 将持续构建安全可靠的通信安全基础设施，打造全方位的安全防护体系。

• 多协议支持

  VLB 在高效接入能力建设方面将持续投入，通过引入 QUIC 协议，将提升用户在弱网场景下的用户体验。

  通过 MQTT 协议可以通过非常小的接入成本实现新设备和协议接入，积极拥抱万物互联。