1. 概述

不久前Intel发布了第三代英特尔® 至强® 可扩展处理器（代号Ice Lake），单核性能提升30%，整机算力提升50%以上（参考[2]）。龙蜥操作系统（Anolis OS）和Intel深入合作，输出加速特性，进一步提升性能和效率。

密码学计算加速是应用广泛的平台特性，本文在Anolis OS 8.4上实践输出：

英特尔®至强®可扩展处理器、AMD EPYC®Rome、Ampere®Altra®的OpenSSL性能对比；
OpenSSL和Nginx/Tengine SSL/TLS handshake的Ice Lake加速方案和优化分析；
云服务器的单核对比，以及裸金属服务器的整机多核对比；
BabaSSL兼容支持OpenSSL的Ice Lake CPU加速特性；
Tengine同时支持Intel® QuickAssist Technology (QAT)和Intel® Crypto Acceleration。

本文使用对应的简称：

Ice Lake：第三代英特尔® 至强® 可扩展处理器（代号Ice Lake）
Cascade Lake：第二代英特尔® 至强® 可扩展处理器（代号Cascade Lake）
Skylake：第一代英特尔® 至强® 可扩展处理器（代号Skylake）
Rome：AMD EPYC® Zen 2微处理器架构（代号Rome）
Ampere：Ampere® Altra®处理器

2. 技术背景

我们知道密码学是为了保证信息的可靠性、机密性和完整性。密码学计算包括加解密、校验、签名等计算，消耗较多CPU资源。因此各硬件厂商推出过不少加速卸载方案：

Intel在Leiwsburg PCH推出QAT，用于密码学和解压缩offload；
ARM KP920推出的KAE加速卡，封装在CPU die，作为PCIe设备交互；
ARMv8.0加入了crypto extension通过SIMD指令加速密码学计算；
云厂商Cloud HSM服务使用的SSl/TLS专用offload方案。

2.1. 新增指令集

在传统的AES-NI加速指令基础上，Ice Lake新增了基于Intel® Advanced Vector Extensions 512 (Intel® AVX-512)的Intel® Crypto Acceleration特性，包括Vector AES (VAES)、Integer Fused Multiply Add (IFMA大数计算)、Galois Field New Instructions (GFNI) 等（参考[3]）。通过multi-buffer lib配合，加速AES, RSA, EC等密码学计算，可用于OpenSSL (BabaSSL), Nginx (Tengine), DPDK Cryptodev, CDN, dm-crypt, ISA-L等。

图1 Ice Lake 新增Intel AVX512指令集

此外，Ice Lake补充支持了SHA extension (SHA-NI)，补足了前代Cascade Lake和Skylake的SHA256性能短板（参考4.2.1章节）。结合Intel AVX512的vpternlog三元逻辑运算指令，进一步减少SHA256中一半的vpxor/XOR指令，可以达到和AMD Rome持平的单核SHA256性能。

2.2. 加速软件栈

受益于以往的QAT方案，OpenSSL (BabaSSL, BoringSSL), Nginx (Tengine), DPDK, Envoy等主流软件已经支持offload SSL/TLS加速。Intel® Crypto Acceleration方案沿用和扩展了QAT的软件框架QAT Engine（参考[1]），使之从专用的硬件offload卡场景扩展到了通用的CPU指令加速场景，极大扩展了适用范围。

图2 Intel SSL/TLS加速软件栈

2.3. 方案对比

详细对比各个方案的加速软件栈（参考[16]）。

2.3.1. General CPU path

通用的CPU计算是最常见的SSL/TLS handshake软件栈，性能取决于libcrypto里对应的密码学算法在各型号CPU上的计算性能和效率。

图3 通用的CPU软件栈计算

下面通过bpftrace分析以上的处理流程和各阶段的latency分布。

通过单次handshake确认基本的流程和latency分布：

Ice Lake计算RSA的RSA_private_decrypt()耗时700us；
handshake全栈耗时1.3ms，其中RSA计算耗时超过一半；

# echo | openssl s_client -connect localhost:443  # https client

# bpftrace ./ssllat.bt  # nginx server
Attaching 16 probes...
Tracing SSL handshake... Hit Ctrl-C to end.
timestamp(ns)    tid    comm       probe                          LAT(us)   call/ret
418334008605     9743   nginx      ngx_http_ssl_handshake
418334044923     9743   nginx      ngx_ssl_handshake
418334050259     9743   nginx      SSL_do_handshake
418334155271     9743   nginx      SSL_do_handshake                  105         -1
418334158596     9743   nginx      ngx_ssl_handshake                 114  NGX_AGAIN
418334160291     9743   nginx      ngx_http_ssl_handshake            153       void
418334592115     9743   nginx      ngx_ssl_handshake_handler
418334594681     9743   nginx      ngx_ssl_handshake
418334596861     9743   nginx      SSL_do_handshake
418334606692     9743   nginx      RSA_private_decrypt
418335233243     9743   nginx      RSA_private_decrypt               626        256
418335312488     9743   nginx      SSL_do_handshake                  715          1
418335314354     9743   nginx      ngx_ssl_handshake                 719     NGX_OK
418335318827     9743   nginx      ngx_ssl_handshake_handler         727       void
^C

典型压测下的处理流程和latency分布：

运行3s完成3963次请求，采集到3985次SSL_do_handshake()，平均耗时700us；
同步模式采集的SSL_do_handshake()和RSA_private_decrypt()数量和耗时一致；

# wrk -t 1 -c 1000 -d 3s -H 'Connection: close' https://localhost:443/0kb.bin  # https client
Running 3s test @ https://localhost:443/0kb.bin
  1 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    98.48ms  181.13ms 611.10ms   83.42%
    Req/Sec     1.32k   112.42     1.72k    82.61%
  3963 requests in 3.09s, 1.15MB read
  Non-2xx or 3xx responses: 3963
Requests/sec:   1280.78
Transfer/sec:    378.98KB

# bpftrace ./sslstat.bt  # nginx server
Attaching 18 probes...
Tracing SSL handshake latency(us) stat... Hit Ctrl-C to end.
^C
@RSA_private_decrypt_hist:
[500, 1000)         3985 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
@RSA_private_decrypt_stat: count 3985, average 631, total 2515453
@SSL_do_handshake_hist:
[500, 1000)         3924 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1000, 1500)          61 |                                                    |
@SSL_do_handshake_stat: count 3985, average 691, total 2757568
@ngx_http_ssl_handshake_hist:
[0, 500)            4962 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[500, 1000)            0 |                                                    |
[1000, 1500)           1 |                                                    |
[1500, 2000)           0 |                                                    |
[2000, 2500)           1 |                                                    |
@ngx_http_ssl_handshake_stat: count 4964, average 36, total 180672
@ngx_ssl_handshake_handler_hist:
[0, 500)               1 |                                                    |
[500, 1000)         3903 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1000, 1500)          82 |@                                                   |
@ngx_ssl_handshake_handler_stat: count 3986, average 697, total 2780241
@ngx_ssl_handshake_hist:
[0, 500)            4962 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[500, 1000)         3916 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@           |
[1000, 1500)          70 |                                                    |
[1500, 2000)           0 |                                                    |
[2000, 2500)           1 |                                                    |
@ngx_ssl_handshake_stat: count 8949, average 325, total 2916631

2.3.2. Ice Lake acceleration path

Ice Lake的Intel® Crypto Acceleration方案（参考[3]）从QAT软件栈演进而来，区别是底层改用multi-buffer lib中的Ice Lake加速指令进行密码学计算，不需要QAT PCIe设备（参考2.3.3章节），对应的驱动中断、系统调用、CPU内存消耗、硬件维护也可以省略。

相对于默认的同步模式软件栈，Ice Lake加速软件栈和QAT一样需要异步SSL集中批量请求，通过multi-buffer lib配合Intel AVX512指令的并行计算实现加速。因此Ice Lake加速软件栈会更长，但相对QAT软件栈更短。RSA大数计算消耗大量CPU，超过了SSL/TLS handshake全栈耗时的一半（参考上节分析），异步SSL加速很有必要，也是典型的异步优化场景。

图4 Ice Lake Intel® Crypto Acceleration方案（qat_sw）

下面通过bpftrace分析以上的处理流程和各阶段的latency分布。

通过单次handshake确认基本的流程和latency分布：

libcrypto_mb中的mbx_rsa_private_crt_ssl_mb8()耗时1ms，比libcrypto的RSA_private_decrypt()慢；
默认polling模式下全栈耗时2.5ms，heuristic polling减少了context-switch（0.7ms），全栈耗时1.6ms；
由于异步SSL软件栈更长，无论哪种polling，单次无并发的handshake都比默认的同步模式更慢；

# Enable Intel Ice Lake CPU acceleration by using qat_sw. 
# bpftrace ./ssllat.bt
Attaching 24 probes...
Tracing SSL handshake... Hit Ctrl-C to end.
timestamp(ns)    tid    comm       probe                          LAT(us)   call/ret
2666757302579    41151  nginx      ngx_http_ssl_handshake
2666757342701    41151  nginx      ngx_ssl_handshake
2666757350070    41151  nginx      SSL_do_handshake
2666757458623    41151  nginx      SSL_do_handshake                  109         -1
2666757462219    41151  nginx      ngx_ssl_handshake                 120  NGX_AGAIN
2666757464261    41151  nginx      ngx_http_ssl_handshake            163       void
2666757879718    41151  nginx      ngx_ssl_handshake_handler
2666757882716    41151  nginx      ngx_ssl_handshake
2666757885080    41151  nginx      SSL_do_handshake
2666757900279    41151  nginx      SSL_do_handshake                   15         -1
2666757903407    41151  nginx      ngx_ssl_handshake                  20  NGX_AGAIN
2666757905386    41151  nginx      ngx_ssl_handshake_handler          26       void
2666758638204    41152  nginx      process_RSA_priv_reqs
2666758647378    41152  nginx      mbx_rsa_private_crt_ssl_mb8
2666759638971    41152  nginx      mbx_rsa_private_crt_ssl_mb8       992  572662304
2666759691623    41152  nginx      process_RSA_priv_reqs            1054       void
2666759693203    41151  nginx      ngx_ssl_handshake
2666759695588    41151  nginx      SSL_do_handshake
2666759794902    41151  nginx      SSL_do_handshake                   99          1
2666759797225    41151  nginx      ngx_ssl_handshake                 104     NGX_OK
^C

# Using heuristic polling in qat_sw.
# bpftrace ./ssllat.bt
Attaching 24 probes...
Tracing openssl SSL handshake... Hit Ctrl-C to end.
timestamp(ns)    tid    comm       probe                          LAT(us)   call/ret
2867041423142    43508  nginx      ngx_http_ssl_handshake
2867041447281    43508  nginx      ngx_ssl_handshake
2867041452981    43508  nginx      SSL_do_handshake
2867041517550    43508  nginx      SSL_do_handshake                   65         -1
2867041521154    43508  nginx      ngx_ssl_handshake                  74  NGX_AGAIN
2867041523144    43508  nginx      ngx_http_ssl_handshake            101       void
2867041894933    43508  nginx      ngx_ssl_handshake_handler
2867041897762    43508  nginx      ngx_ssl_handshake
2867041900060    43508  nginx      SSL_do_handshake
2867041912136    43508  nginx      SSL_do_handshake                   12         -1
2867041917432    43508  nginx      multibuff_poll
2867041922554    43508  nginx      process_RSA_priv_reqs
2867041926910    43508  nginx      mbx_rsa_private_crt_ssl_mb8
2867042914930    43508  nginx      mbx_rsa_private_crt_ssl_mb8       988  572662304
2867042960583    43508  nginx      process_RSA_priv_reqs            1038       void
2867042963325    43508  nginx      multibuff_poll                   1046          1
2867042965164    43508  nginx      ngx_ssl_handshake                1067  NGX_AGAIN
2867042967276    43508  nginx      ngx_ssl_handshake_handler        1073       void
2867042970120    43508  nginx      ngx_ssl_handshake
2867042972865    43508  nginx      SSL_do_handshake
2867043045962    43508  nginx      SSL_do_handshake                   73          1
2867043048452    43508  nginx      ngx_ssl_handshake                  78     NGX_OK
^C

典型压测下的处理流程和latency分布（对比默认无加速的同步阻塞式软件栈）：

运行3s完成16152次请求，采集到16678次SSL_do_handshake()，平均耗时50us。由于异步SSL，SSL_do_handshake()只处理异步任务，不再等待RSA计算完成；
采集到2085次mbx_rsa_private_crt_ssl_mb8()，是SSL_do_handshake()数量的1/8，平均耗时仍然是单次handshake时的1ms。由此得出，每次并行计算平均处理了8个异步RSA计算请求；
加上异步SSL处理开销，总的RPS（request per second）从1280提升了4倍到5312。

# wrk -t 1 -c 1000 -d 3s -H 'Connection: close' https://localhost:443/0kb.bin
Running 3s test @ https://localhost:443/0kb.bin
  1 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    36.79ms    5.75ms  71.64ms   83.10%
    Req/Sec     5.50k   608.73     6.66k    82.61%
  16152 requests in 3.04s, 4.67MB read
  Non-2xx or 3xx responses: 16152
Requests/sec:   5312.10
Transfer/sec:      1.54MB

# bpftrace ./sslstat.bt
Attaching 16 probes...
Tracing SSL handshake latency(us) stat... Hit Ctrl-C to end.
^C
@SSL_do_handshake_hist:
[0, 500)           16678 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[500, 1000)            2 |                                                    |
@SSL_do_handshake_stat: count 16680, average 49, total 830730
@mbx_rsa_private_crt_ssl_mb8_hist:
[500, 1000)         2044 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1000, 1500)          41 |@                                                   |
@mbx_rsa_private_crt_ssl_mb8_stat: count 2085, average 942, total 1965881
@ngx_http_ssl_handshake_hist:
[0, 500)           17153 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
@ngx_http_ssl_handshake_stat: count 17153, average 34, total 583903
@ngx_ssl_handshake_handler_hist:
[0, 500)           16904 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
@ngx_ssl_handshake_handler_stat: count 16904, average 11, total 199185
@ngx_ssl_handshake_hist:
[0, 500)           72823 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[500, 1000)            2 |                                                    |
@ngx_ssl_handshake_stat: count 72825, average 22, total 1615361
@process_RSA_priv_reqs_hist:
[500, 1000)         1946 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1000, 1500)         139 |@@@                                                 |
@process_RSA_priv_reqs_stat: count 2085, average 997, total 2080562

2.3.3. QAT PCIe offload path

QAT软件栈（参考[4]）是Skylake上推出的SSL/TLS加速方案，经过演进派生出了上面的Ice Lake CPU加速方案。两种方案都基于QAT Engine，区别在底层是用CPU加速还是PCIe设备。例如Tengine已经支持QAT，则也支持Ice Lake加速，类似的还有Envoy（参考[10]）, DPDK, ZFS（参考[17] QZFS只用了QAT的解压缩加速）等。

QAT硬件集成在PCH主板（Lewisburg和Lewisburg refresh），或者作为独立的PCIe AIC卡。支持Ice Lake, Cascade Lake, Skylake三代服务器平台，和部分Intel Atom® C Series, Intel Xeon® D Series的专用SoC平台。下一代产品按照目前的规划会作为加速器集成封装到CPU die，从系统看还是PCIe设备。

图5 Intel QAT方案（qat_hw）

同样可以用bpftrace分析QAT软件栈的处理流程和各阶段的latency分布。由于需要专用的QAT硬件平台，此处略过，以参考[11] 中发布的性能数据作为参考。

总的来说，QAT是专用的PCIe offload设备，可以协助CPU处理密码学和解压缩的大量计算消耗，释放CPU资源。但和所有PCIe设备一样需要专用的系统驱动、CPU内存消耗和硬件维护。QAT软件栈和延迟较长，计算能力上限也受系统和PCIe限制。Ice Lake强化了密码学计算能力，且同时支持QAT。CPU资源也比QAT更易获取和可扩展，参考7.4章节的整机对比。

3. 实践目标

我们关注通用CPU计算和Intel® Crypto Acceleration（qat_sw）方案的加速对比，同时参考QAT（qat_hw）方案的数据（参考[4]）。

期望效果 = core通用计算优化 + qat_sw优化（multi-buffer lib + SIMD指令加速）
加速优化倍数有多个文档版本，以Intel正式文档为目标：

参考[5] P27,P52: OpenSSL优化3~5.6倍（单核对比Ice Lake和Cascade Lake）
参考[5] P14,P39: Nginx SSL优化4.2倍（整机对比Ice Lake和Cascade Lake）

3.1. 系统环境

实例规格		CPU model	qat_sw	qat_hw	OS
ecs.g7.xlarge	4核16GB	Intel Xeon 8369B	有	无配置Intel QAT	Anolis OS 8.4
ecs.g5.xlarge		Intel Xeon 8163	无效
ecs.g6a.xlarge		AMD EPYC 7H12
ecs.g6r.xlarge		Ampere Altra

3.2. 软件包

Package name	Version	Anolis OS 8.4	Notes
tengine	2.3.3	已发布	推荐应用
asynch_mode_nginx	1.18.0	已发布	参考demo
openssl	1.1.1g	系统自带	系统自带
babassl	8.2.1	已发布	兼容性验证，待正式发布支持
qatengine	0.6.6	已发布	openssl qat engine加速lib
intel-ipp-crypto-mb	0.5.3	已发布	Ice Lake密码学计算加速lib
intel-ipsec-mb	1.0.0	已发布	Ice Lake IPSec加速lib

3.3. 兼容性

参考[9] Anolis BabaSSL文档，BabaSSL兼容openssl-1.1.1的全部能力。下面在AnolisOS 8.4上验证BabaSSL兼容qatengine，支持Ice Lake加速和QAT offload。

# openssl-1.1.1g-15.an8.x86_64
# openssl version
OpenSSL 1.1.1g FIPS  21 Apr 2020
# openssl speed -elapsed -seconds 3 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000616s 0.000018s   1623.3  55965.7
# openssl speed -elapsed -seconds 3 -engine qatengine -async_jobs 16 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000125s 0.000006s   8000.0 160303.3

# babassl-8.2.1-1.shangmi.an8.x86_64
# openssl version
OpenSSL 1.1.1h  22 Sep 2020
# openssl speed -elapsed -seconds 3 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000608s 0.000018s   1643.7  55100.3
# openssl speed -elapsed -seconds 3 -engine qatengine -async_jobs 16 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000125s 0.000006s   8024.3 161224.0

4. OpenSSL性能

CPU指令加速属于底层特性，我们按照自下而上的方法逐层验证，首先对比OpenSSL底层的基础加解密算力。

4.1. 安装步骤

OpenSSL-1.1.0版本已支持加速engine.so，安装engine lib和依赖的底层加速lib即可；
启用Anolis OS 8.4 ShangMi仓库后安装：

# yum --enablerepo=ShangMi install qatengine  # for AnolisOS 8.4

参考3.3章节兼容性或7.1章节HyperThread，测试加速效果。

4.2. 通用计算

# openssl speed [algo] #默认测试全部算法，无加速引擎

4.2.1. 对称密码

Ice Lake单核平均比Skylake高42%，比Rome高12%，比Ampere高20%：

符合Intel发布的Ice Lake单核1.4倍于Cascade Lake（参考[5]）；
符合ECS发布的实时音视频通信加密的场景性能最大提升40%（参考[2]）。

4.2.2. 非对称密码

Ice Lake单核平均比Skylake高35%，比Rome高15%，是Ampere的3.5倍：

符合RSA特点：sign签名计算的消耗高运行慢，verify验证计算的消耗低运行快；
符合EC特性：sign签名计算比RSA快一个量级以上，verify验证计算比RSA慢；
Ampere的公钥密码计算性能较低（ARMv8 crypto extension）。

4.3. 加速性能

# openssl speed -engine qatengine [algo] #包含qat_sw加速效果，无qat_hw offload

4.3.1. 对称密码

Ice Lake加速效果符合预期的最高3.1倍：

block size大于256Byte时，AES-GCM能达到加速3~4倍。
block size小于64Byte时，AES-GCM有少量20%回退。小于64Byte场景较少，参考[8] Nginx默认ssl_buffer_size为16KB，可选4KB加速time to first byte响应。

4.3.2. 非对称密码

部分场景可以达到预期的优化3~6倍：

同步模式没有指令加速效果，有30%左右单核通用计算的提升；
异步模式jobs大于8时有优化，RSA 2K sign 6倍，verify 3倍，ECDSA P256 sign 2倍，ECDH 3~4倍；
异步模式jobs小于8时有回退。参考2.3.2章节分析，低负载场景没有加速需求，应该关闭加速。

5. Nginx性能

在OpenSSL底层加解密算力基础上，继续验证典型的端到端场景Nginx SSL/TLS性能：

参考[3] Intel文档：复用QAT加速Nginx方案（需要Nginx支持SSL/TLS异步加速）；
参考[6][7] Nginx文档：Nginx https SSL/TLS handshake的标准性能测试方法文档。

5.1. 压测配置

复用上面测试OpenSSL的4核16GB实例，参考4.1章节安装openssl加速包；
安装asynch_mode_nginx，创建/etc/nginx/cert/密钥证书目录；

# yum install asynch_mode_nginx
# mkdir /etc/nginx/cert/
# cd /etc/nginx/cert/

分别创建RSA 2K和ECDSA P256的密钥和证书；

# openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt -subj "/C=CN/ST=Beijing/O=Example Inc./OU=Web
Security/CN=example1.com"
# openssl req -x509 -sha256 -nodes -days 365 -newkey ec:<(openssl ecparam -name prime256v1) -keyout ecdsa.key -out ecdsa.crt -subj "/C=CN/ST=Beijing/L=Beijing/O=Example Inc./OU=Web
Security/CN=example1.com"

参考配置文件 /etc/nginx/nginx.crypto-ni.conf 对比开关SSL加速；

ssl_asynch  on; #off

通过配置文件按测试需要绑核，cpu#2和cpu#3是超线程，在同一个CPU core；

worker_processes  2;
worker_cpu_affinity  1100; # bind cpu2 cpu3 (HT) for nginx worker

通过配置文件选择使用RSA或ECDSA key；

ssl_certificate      /etc/nginx/cert/server.crt;
ssl_certificate_key  /etc/nginx/cert/server.key;
# ssl_certificate      /etc/nginx/cert/ecdsa.crt;
# ssl_certificate_key  /etc/nginx/cert/ecdsa.key;

使用ECDSA key时，注释掉配置文件的ssl_ciphers配置，使用自动选择的配置；

# ssl_ciphers         AES256-GCM-SHA384;
# ssl_ciphers         ECDHE-RSA-AES256-GCM-SHA384;

启动nginx server；

# nginx -s quit # in case of existing nginx
# nginx -c /etc/nginx/nginx.crypto-ni.conf

确认cipher suite配置是否符合预期；

# echo | openssl s_client -connect localhost:443

安装使用wrk作为https client压测nginx SSL/TLS性能。

# yum install wrk-4.1.0
# taskset -c 1 wrk -t 1 -c 1000 -d 10s --latency -H 'Connection: close' https://localhost:443/0kb.bin

5.2. 加速效果

Nginx SSL/TLS性能在单核Ice Lake加速后可提升2~3倍，是单核Skylake的3~4倍：

RSA有以上加速效果，ECDSA有60%通用计算提升。经分析是由于4核的client压力不足，参考7.4章节的整机对比，在core通用提升基础上，nginx还有17%的加速效果。
Client connect数少于10时有回退，和OpenSSL异步低负载回退一致，同样参考2.3.2章节分析，低负载场景没有加速需求，应该关闭加速；
TLSv1.2的加速效果比TLSv1.3更好；

6. Tengine性能

Tengine从2.2.2版本开始支持async SSL，使用QAT offload SSL/TLS（参考[12]），支持的底层lib版本为：OpenSSL-1.1.0f和QAT_Engine-0.5.30（参考[13]）。我们引入CPU加速后升级到：OpenSSL-1.1.1g和QAT_Engine-0.6.6，同时不需要QAT驱动和qatlib。

6.1. 压测配置

参考5.1章节的nginx配置文件（参考[14]），基本一致。

复用上面测试OpenSSL的4核16GB实例，参考4.1章节安装openssl加速包；
安装tengine，创建/etc/tengine/cert/密钥证书目录；

# yum install tengine
# mkdir /etc/tengine/cert/
# cd /etc/tengine/cert/

分别创建RSA 2K和ECDSA P256的密钥和证书；

# openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt -subj "/C=CN/ST=Beijing/O=Example Inc./OU=Web
Security/CN=example1.com"
# openssl req -x509 -sha256 -nodes -days 365 -newkey ec:<(openssl ecparam -name prime256v1) -keyout ecdsa.key -out ecdsa.crt -subj "/C=CN/ST=Beijing/L=Beijing/O=Example Inc./OU=Web
Security/CN=example1.com"

如下修改 /etc/pki/tls/openssl.cnf 全局配置。nginx是按需在nginx.conf配置，不用改全局配置。由于是系统openssl的全局配置，不是Ice Lake CPU的平台不要改；

openssl_conf = openssl_def
[openssl_def]
engines = engine_section
[engine_section]
qat = qat_section
[qat_section]
engine_id = qat
dynamic_path = /lib64/engines-1.1/qatengine.so
default_algorithms = ALL

参考配置文件 /etc/tengine/nginx.conf 对比开关SSL加速。注意这里是ssl_async，不是nginx的ssl_asynch；

ssl_async  on; #off #note async vs asynch

通过配置文件按测试需要绑核，cpu#2和cpu#3是超线程，在同一个CPU core；

worker_processes  2;
worker_cpu_affinity  1100; # no heuristic polling, use taskset for polling thread

通过配置文件选择使用RSA或ECDSA key；

ssl_certificate      /etc/tengine/cert/server.crt;
ssl_certificate_key  /etc/tengine/cert/server.key;
# ssl_certificate      /etc/tengine/cert/ecdsa.crt;
# ssl_certificate_key  /etc/tengine/cert/ecdsa.key;

使用ECDSA key时，注释掉配置文件的ssl_ciphers配置，使用自动选择的配置；

# ssl_ciphers         AES256-GCM-SHA384;
# ssl_ciphers         ECDHE-RSA-AES256-GCM-SHA384;

启动tengine server；

# tengine -s quit # in case of existing tengine
# tengine -c /etc/tengine/nginx.conf # use taskset if necessary

确认cipher suite配置是否符合预期；

# echo | openssl s_client -connect localhost:443

安装使用wrk作为了https client压测tengine SSL/TLS性能。

# yum install wrk-4.1.0
# taskset -c 1 wrk -t 1 -c 1000 -d 10s --latency -H 'Connection: close' https://localhost:443/0kb.bin

6.2. 加速效果

Tengine SSL/TLS性能在单核Ice Lake加速后可提升2.7~3.2倍，是单核Skylake的3.5~4.2倍：

RSA有以上加速效果，ECDSA有60%通用计算提升。经分析是由于4核的client压力不足，参考7.5章节的整机对比，在core通用提升基础上，tengine还有36%的加速效果；
tengine效果和asynch_mode_nginx类似；
仅对比TLSv1.2，TLSv1.3 tengine有专门的实践方案（参考[15]），此处略过。

7. 整机多核对比

经过上面自下而上的单核对比，我们已经看到Intel® Crypto Acceleration加速效果非常好。上层业务应用也关注整机多核性价比，下面对比裸金属服务器，Ice Lake比Cascade Lake核数多，整机性能的提升效果更好。

实例规格		CPU model	物理核	HT	qat_sw	qat_hw
ecs.sccc7.32xlarge	128核256GB	Intel Xeon 8369B	64	off	有	无配置Intel QAT
ecs.ebmg6e.26xlarge	104核384GB	Intel Xeon 8269CY	52	on	无效	无配置Intel QAT

7.1. HyperThread

目前新的Ice Lake裸金属仅针对HPC计算密集型业务，关闭了超线程（HyperThread/HT）。正好密码学计算同样是计算密集型负载，开关超线程不影响整机对比（上层的SSL/TLS handshake性能会有少量提升），下面进行验证。

Cascade Lake裸金属打开HT，相同core的HT#0和#52并行计算RSA无明显提升，不同core的HT#0和#1翻倍。

# lscpu
CPU(s):              104
On-line CPU(s) list: 0-103
Thread(s) per core:  2
Core(s) per socket:  26
Socket(s):           2
NUMA node(s):        2
NUMA node0 CPU(s):   0-25,52-77
NUMA node1 CPU(s):   26-51,78-103
# taskset -c 0 openssl speed -elapsed -seconds 3 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000624s 0.000018s   1603.3  54270.3
# taskset -c 0,52 openssl speed -elapsed -seconds 3 -multi 2 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000606s 0.000018s   1649.0  56688.7
# taskset -c 0-1 openssl speed -elapsed -seconds 3 -multi 2 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000313s 0.000009s   3194.0 107583.0

Ice Lake裸金属关闭HT，任意core并行计算RSA都线性扩展。

# lscpu
CPU(s):              64
On-line CPU(s) list: 0-63
Thread(s) per core:  1
Core(s) per socket:  32
Socket(s):           2
NUMA node(s):        2
NUMA node0 CPU(s):   0-31
NUMA node1 CPU(s):   32-63
# taskset -c 0 openssl speed -elapsed -seconds 3 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000611s 0.000018s   1635.3  56227.7
# taskset -c 0,32 openssl speed -elapsed -seconds 3 -multi 2 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000302s 0.000009s   3311.0 112587.3
# taskset -c 0,1 openssl speed -elapsed -seconds 3 -multi 2 rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000302s 0.000009s   3311.3 112519.0

7.2. 压测配置

参考5.1章节本地压测SSL/TLS handshake性能，裸金属双路CPU的一路作为client压测另一个路。本地localhost简化硬件配置，排除网络影响，得到最佳优化效果以供业务参考。同时用户也可以快速验证加速效果。

7.3. OpenSSL整机对比

参考4.3章节，从虚拟机改为对比裸金属。OpenSSL底层加解密计算按照core数量并发扩展，实际上有的应用以OpenSSL来评估CPU的计算能力。以下对比Ice Lake和Cascade Lake裸金属。

AES-256-GCM在16KB buffer size下的计算带宽：

单核对比3.4倍，3.6 GB/s -> 12.3 GB/s；
整机多核是3.8倍，185 GB/s -> 710 GB/s；

RSA 2K sign/s：

单核对比5.1倍，1589 op/s -> 8072 op/s；
整机多核是5.7倍，83338 op/s -> 474289 op/s；

ECDSA P256 sign/s：

单核对比2倍，42192 op/s -> 84970 op/s；
整机对比2倍，2261825 op/s -> 4594025 op/s；

7.4. Nginx整机对比

Nginx worker并发性良好，多核性能按core数并发扩展。以下对比Ice Lake和Cascade Lake裸金属的Nginx SSL/TLS hanshake RPS性能。

RSA 2K：

单核对比3.2倍，1243 req/s -> 3987 req/s；
整机对比4.3倍，23445 req/s -> 101921 req/s；

ECDHE + RSA 2K：

单核对比3倍，1132 req/s -> 3430 req/s；
整机对比4.1倍，21095 req/s -> 87569 req/s；

ECDHE + ECDSA P256：

单核对比1.5倍，3847 req/s -> 5723 req/s；
整机对比1.5倍，64262 req/s -> 86983 req/s；

注意是一路socket压另一路socket，整机双路的绝对性能值x2，开HT后还会有少量提升；
图右侧是上一代QAT发布的优化数据（非本地），作为参考。

7.5. Tengine整机对比

Tengine继承了nginx的良好并发性，多核性能同样按core数并发扩展。以下是Ice Lake和Cascade Lake裸金属的Tengine SSL/TLS hanshake RPS性能对比。

RSA 2K：

单核对比3.3倍，1233 req/s -> 4082 req/s；
整机对比3.8倍，28313 req/s -> 107497 req/s；

ECDHE + RSA 2K：

单核对比3.2倍，1161 req/s -> 3687 req/s；
整机对比3.6倍，26924 req/s -> 96423 req/s；

ECDHE + ECDSA P256：

单核对比1.6倍，4000 req/s -> 6435 req/s；
整机对比4.1倍，22398 req/s -> 92348 req/s；

同样是一路socket压另一路socket，整机双路的绝对性能值x2，开HT后还有少量提升；
ECDSA的server端消耗大幅降低，本地socket压力已经不够，增加client压力后整机性能还可以提升。

8. 结论

经过实践分析，Intel® Crypto Acceleration在Anolis OS 8.4可以达到理想的SSL/TLS加速效果。

传统主流的AES和RSA加速效果最好，Ice Lake的底层OpenSSL计算AES和RSA达到上一代Cascade Lake的3.4和5.1倍。应用层Nginx SSL/TLS性能相应地加速到Cascade Lake的3.2倍，Tengine是3.3倍。整机多核性能随核数并发扩展，OpenSSL的AES和RSA加速效果增加到3.8和5.7倍，Nginx增加到4.3倍，Tengine是3.8倍。

新兴的ECDSA加速效果相对较小，底层的OpenSSL计算ECDSA和ECDH加速了2倍和4.3倍，但应用层Nginx SSL/TLS性能小幅加速1.5倍，Tengine是1.6倍，和上一代Intel® QAT的1.26倍效果类似。EC椭圆密码算法大幅优化了以往server端RSA的计算消耗，同等安全性保证下的OpenSSL计算ECDSA性能已经达到RSA的10倍了。因此SSL/TLS性能中的密码学计算瓶颈不再凸显，端到端效果小于底层加速是合理的结果。

兼容性方面，BabaSSL全兼容OpenSSL支持Intel® Crypto Acceleration。适配过QAT的应用也支持Ice Lake的CPU指令加速SSL/TLS，例如Tengine, Envoy, DPDK等。其他应用可以参考asynch_mode_nginx进行异步SSL改造。tengine承载大量应用稳定运行多年，我们推荐tengine作为Anolis OS 8.4的最佳SSL/TLS性能实践方案。

参考