作者：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）测试组网