默默的点滴

试题一 软件架构（架构风格、质量属性）

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1 和问题2。

【说明】

某公司拟开发-套机器学习应用开发平台,支持用户使用浏览器在线进行基于机器学习的智能应用开发活动。
该评台的核心应用场景是用户通过拖拽算法组件灵活定义机器学习流程，采用自助方式进行智能应用设计、实现与部署，并可以开发新算法组件加入平台中。在需求分析与架构设计阶段,公司提出的需求和质量属性描述如下:

1. 平台用户分为算法工程师、软件工程师和管理员等三种角色，不同角色的功能界面有所不同；
2. 平台应该具备数据库保护措施，能够预防核心数据库被非授权用户访问；
3. 平台支持分布式部署,当主站点断电后，应在20 秒内将请求重定向到备用站点；
4. 平台支持初学者和高级用户两种界面操作模式，用户可以根据自己的情况灵活选择合适的模式；
5. 平台主站点宕机后，需要在15 秒内发现错误并启用备用系统；
6. 在正常负载情况下，机器学习流程从提交到开始执行，时间间隔不大于5 秒；
7. 平台支持硬件扩容与升级，能够在3 人天内完成所有部署与测试工作；
8. 平台需要对用户的所有操作过程进行详细记录，便于审计工作；
9. 平台部署后，针对界面风格的修改需要在3 人天内完成;
10. 在正常负载情况下，平台应在0.5 秒内对用户的界面操作请求进行响应；
11. 平台应该与目前国内外主流的机器学习应用开发平台的界面风格保持一致；
12. 平台提供机器学习算法的远程调试功能，支持算法工程师进行远程调试。

在对平台需求、质量属性描述和架构特性进行分析的基础上，公司的架构师给出了三种候选的架构设计方案，公司目前正在组织相关专家对平台架构进行评估。

问题：1.1    (9分)
在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。 请将合适的质量属性名称填入图1-1中(1)、(2)空白处，并从题干中的(a)-(i)中选择合适的质量属性描述,填入(3)-(6)空白处，完成该平台的效用树。

问题：1.2    (16分)
针对该系统的功能，赵工建议采用解释器(interpreter)架构风格，李工建议采用管道过滤器(pipe-and-filter)的架构风格，王工则建议采用隐式调用(implicit invocation)架构风格。请针对平台的核心应用场景，从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析，并指出该平台更适合采用哪种架构风格。

【问题1】（9分）

在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。 请将合适的质量属性名称填入图1-1中(1)、(2)空白处，并从题干中的(a)-(i)中选择合适的质量属性描述，填入(3)-(6)空白处，完成该平台的效用树。

【问题2】（16分）
针对该系统的功能，赵工建议采用解释器(interpreter)架构风格，李工建议采用管道过滤器(pipe-and-filter)的架构风格，王工则建议采用隐式调用(implicit invocation)架构风格。请针对平台的核心应用场景，从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析，并指出该平台更适合采用哪种架构风格。

试题二 系统开发（用例图、顺序图填空、模型对比）

某医院拟委托软件公司开发一套预约挂号管理系统，以便为患者提供更好的就医体验，为医院提供更加科学的预约管理。本系统的主要功能描述如下：
(a)注册登录，(b)信息浏览，(c)账号管理，(d)预约挂号，(e)查询与取消预约，(f)号源管理，(g)报告查询，(h)预约管理，(i)报表管理和(j)信用管理等。

问题：3.1    (6 分)
若采用面向对象方法对预约挂号管理系统进行分析,得到如图2-1所示的用例图。请将合适的参与者名称填入图2-1中的(1)和(2)处，使用题干给出的功能描述(a)~(j)，完善用例(3)~(12)的名称，将正确答案填在答题纸上。

问题：3.2    (10分)
预约人员(患者)登录系统后发起预约挂号请求，进入预约界面。进行预约挂号时使用数据库访问类获取医生的相关信息，在数据库中调用医生列表，并调取医生出诊时段表，将医生出诊时段反馈到预约界面，并显示给预约人员；预约人员选择医生及就诊时间后确认预约，系统反馈预约结果，并向用户显示是否预约成功。
采用面向对象方法对预约挂号过程进行分析，得到如图2-2所示的顺序图，使用题干中给出的描述，完善图2-2中对象(1),及消息(2)~(4)的名称，将正确答案填在答题纸上，请简要说明在描述对象之间的动态交互关系时，协作图与顺序图存在哪些区别。

问题：3.3   (9分)
采用面向对象方法开发软件，通常需要建立对象模型、动态模型和功能模型，请分别介绍这3种模型，并详细说明它们之间的关联关系，针对上述模型，说明哪些模型可用于软件的需求分析？

（1）系统管理员 （2）患者 （3）（a）注册登录 （4）（c）账号管理 （5）（f）号源管理 （6）（h）预约管理 （7）（i）报表管理 （8）（j）信用管理号（4）~（8）答案可以互换 （9）（b）信息浏览 （10）（d）预约挂号 （11）（e）查询与取消预约 （12）（g）报告查询（9）~（12）答案可以互换

（1）预约人员（患者） （2）预约挂号请求 （3）显示医生可预约时段 （4）显示预约是否成功

顺序图强调的是消息的时间次序。
协作图强调的是发送和接收消息的对象之间的组织结构。

【问题3】（9分）
采用面向对象方法开发软件，通常需要建立对象模型、动态模型和功能模型，请分别介绍这3种模型，并详细说明它们之间的关联关系，针对上述模型，说明哪些模型可用于软件的需求分析？

试题三 嵌入式

阅读以下关于嵌入式数据架构设计的相关描述，回答问题1至问题3。
【说明】
数据架构（Data architecture）是系统架构设计的主要工作之一。它主要用于描述业务数据以及数据间的关系。数据架构着重考虑“数据需求”，关注的是持久化数据的组织。数据架构的设计过程主要包括：数据定义、数据分布与数据管理。某公司为了适应宇航装备的持续发展，提升本公司的核心竞争力，改变原来事件驱动的架构设计模式。公司领导将新产品架构规划工作交给张工。张工经过分析、调研给出了本企业宇航产品的未来架构规划方案。

【问题1】（9分）
张工在规划方案中指出：宇航装备要实现以数据为中心的架构设计模式，就应改变传统的各个子系统独立的设计方式，打破原宇航装备的生产关系。为了达到这个目标，我们首先要解决装备数据的共享、管理和存储等问题，做好顶层的数据架构规划工作。请用 300 字以内的文字说明数据定义、数据分布与数据管理的具体内涵。
【问题2】（7分）
张工在规划方案中提出公司未来产品设计要遵从一种开放式的架构体系，并在此基础上完善数据架构的设计工作，形成一套规格化的数据模型语言。张工给出了基于 FACE（Future Airborne Capability Environment) 架构的新产品架构，其中，图 3-1 说明了数据模型语言在架构模型中的作用。

请根据你所掌握的数据架构的相关知识，从以下a~g中进行选择，填充完善 图 3-1 中的（1）~（7）空。
a.数据模型定义
b.平台数据模型（PDM）
c.UoP（Unit of Portability）数据模型（UM）
d.提炼
e.传输定义
f.代码和配置
g.概念数据模型（CDM）
【问题3】（9分）
“数据需求”是数据架构设计中需要着重考虑的问题。在张工给出的基于FACE架构的新产品架构中，分别就架构中的各个部分逐条给出了需求项。请判断 表3-1 给出的 9 项需求是否属于数据需求。

试题四 数据库（反规范化设计方法、数据不一致、Redis 同步）

某医药销售企业因业务发展，需要建立线上药品销售系统，为用户提供便捷的互联网药品销售服务、该系统除了常规药品展示、订单、用户交流与反馈功能外，还需要提供当前热销产品排名、评价分类管理等功能。通过对需求的分析，在数据管理上初步决定采用关系数据库（MySQL）和数据库缓存（Redis）的混合架构实现。
经过规范化设计之后，该系统的部分数据库表结构如下所示。

供应商（供应商ID，供应商名称，联系方式，供应商地址）；
药品（药品ID，药品名称，药品型号，药品价格，供应商ID）；
药品库存（药品ID，当前库存数量）；
订单（订单号码，药品ID，供应商ID，药品数量，订单金额）。

问题：2.1    (9分)
在系统初步运行后，发现系统数据访问性能较差。经过分析，刘工认为原来数据库规范化设计后，关系表过于细分,造成了大量的多表关联查询，影响了性能。例如当用户查询商品信息时，需要同时显示该药品的信息、供应商的信息、当前库存等信息。
为此，刘工认为可以采用反规范化设计来改造药品关系的结构，以提高查询性能。修改后的药品关系结构为:
药品（药品ID，药品名称，药品型号，药品价格，供应商ID，供应商名称，当前库存数量）;
请用 200 字以内的文字说明常见的反规范化设计方法，并说明用户查询商品信息应该采用哪种反规范化设计方法。

问题：2.2    (9分)
王工认为，反规范化设计可提高查询的性能，但必然会带来数据的不一致性问题。请用 200 字以内的文字说明在反规范化设计中，解决数据不一致性问题的三种常见方法，并说明该系统应该采用哪种方法。

问题：2.3    (7分)
该系统采用了 Redis 来实现某些特定功能(如当前热销药品排名等)，同时将药品关系数据放到内存以提高商品查询的性能，但必然会造成 Redis 和 MySQL 的数据实时同步问题。
(1) Redis的数据类型包括 String、 Hash、 List、 Set和 ZSet 等，请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。
(2)请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。

【问题2】（9分）
王工认为，反规范化设计可提高查询的性能，但必然会带来数据的不一致性问题。请用200字以内的文字说明在反规范化设计中，解决数据不一致性问题的三种常见方法，并说明该系统应该采用哪种方法。

【问题3】（7分）
该系统采用了Redis来实现某些特定功能(如当前热销药品排名等)，同时将药品关系数据放到内存以提高商品查询的性能，但必然会造成Redis和MySQL的数据实时同步问题。
(1) Redis的数据类型包括String、 Hash、 List、 Set和ZSet等，请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。
(2)请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。

试题五 Web应用（云平台智能家居，看图填空，TCP/UDP 区别）

某公司拟开发一个智能家居管理系统，该系统的主要功能需求如下：

1)用户可使用该系统客户端实现对家居设备的控制，且家居设备可向客户端反馈实时状态；
2)支持家居设备数据的实时存储和查询；
3)基于用户数据，挖掘用户生活习惯，向用户提供家居设备智能化使用建议。

基于上述需求，该公司组建了项目组，在项目会议上，张工给出了基于家庭网关的传统智能家居管理系统的设计思路，李工给出了基于云平台的智能家居系统的设计思路。经过深入讨论，公司决定采用李工的设计思路。

问题：4.1    (8分)
请用400字以内的文字简要描述基于家庭网关的传统智能家居管理系统和基于云平台的智能家居管理系统在网关管理、数据处理和系统性能等方面的特点，以说明项目组选择李工设计思路的原因。

问题：4.2    (12分)
请从下面给出的(a) ~ (j) 中进行选择，补充完善 图  5-1 中空 (1) ~ (6) 处的内容，协助李工完成该系统的架构设计方案。

(a) Wi-Fi
(b) 蓝牙
(c)驱动程序
(d)数据库
(e)家庭网关
(f)云平台
(g)微服务
(h)用户终端
(i)鸿蒙
(j)TCP/IP

问题：4.3    (5分)
该系统需实现用户终端与服务端的双向可靠通信，请用300字以内的文字从数据传输可靠性的角度对比分析TCP和UDP通信协议的不同，并说明该系统应采用哪种通信协议。

【问题1】（8分）
请用400字以内的文字简要描述基于家庭网关的传统智能家居管理系统和基于云平台的智能家居管理系统在网关管理、数据处理和系统性能等方面的特点，以说明项目组选择李工设计思路的原因。

【问题3】（5分）
该系统需实现用户终端与服务端的双向可靠通信，请用300字以内的文字从数据传输可靠性的角度对比分析TCP和UDP通信协议的不同，并说明该系统应采用哪种通信协议。

参考链接

• 软考系列（系统架构师）- 2021年系统架构师软考案例分析考点
• 2021年下半年 系统架构设计师 下午试卷 案例
• 2021年下半年系统架构设计师考试下午真题（试题三）

ZipCrypto，也称为 PKZIP Stream Cipher，是一种弱加密手段，在1994年就已经被攻破，该加密方式不能经受已知明文攻击（Known Plaintext Attack，KPA）。

明文攻击主要利用大于 12 字节的一段已知明文数据进行攻击，从而获取整个加密文档的数据。也就是说，如果手里有一个未知密码的压缩包和压缩包内某个文件的一部分明文（不一定非要从头开始，能确定偏移就行），那么就可以通过这种攻击来解开整个压缩包。比如压缩包里有一个常见的 license 文件，或者是某个常用的 dll 库，或者是带有固定头部的文件（比如 xml、exe、png 等容易推导出原始内容的文件），那么就可以运用这种攻击。

Biham和Kocher文中回顾了PKZIP Stream Cipher加密解密过程。

原始论文链接： A Known Plaintext Attack on the PKZIP Stream Cipher

本站链接： A Known Plaintext Attack on the PKZIP Stream Cipher

首先，文件压缩后形成压缩包，PKZIP在压缩包中每个文件头部加上12字节的文件头，用于随机化，也用于在解密时识别错误的密钥，然后该文件头和文件内容一起进行加密。

加密过程如下：

• 首先初始化，key为用户输入的二进制的密钥序列。key0，key1，key2为三个全局变量，在加/解密每个字节时都会用到。小写L表示第L个字节

Update_keys()函数定义如下，输入为一个字节。

• 然后就是加文件头，开始加密。Pi代表明文第i字节

解密过程如下：

• 首先初始化，和加密过程初始化完全相同
• 然后解密，Ci代表加密的内容。解密后P1-P12是文件头，仅留作校验，解密后不再需要

附上一段代码，实现PKZIP解密，加密类似。

总结：PKZIP Stream Cipher是一种按照文件顺序、逐个字节进行加密/解密的算法。实际使用中，还需要注意到每遇到一个压缩包内的文件，就会从头进行一遍加密/解密过程。实现一个已知密钥zip archive的解密还需要了解ZIP格式等问题，这里就不再赘述了。

参考链接

• ZipCrypto算法回顾
• ZIP明文攻击
• ZIP 明文攻击原理

调试前端页面的时候，有时候会遇到点击弹窗后从另外一个标签页打开页面的情况，这个时候如果手工去打开调试工具，页面加载之前的网络接口调用就追踪不到了，这个问题查询了一下，从 Chrome 50 版本开始支持页面跳转调试器自动跟踪。只是默认情况下，此功能没有开启，需要手工开启此功能。

具体开启此功能的操作如下：

1. 打开浏览器控制台(F12)/开发者工具

2.使用三点菜单(F1，控制台右上角X号旁边的那个按钮打开 setting 栏)

继续阅读chrome浏览器如何跟踪新开标签的网络请求？

本文介绍了 Intel QAT 技术方案，通过 Multi-Buffer 技术和 QAT 硬件加速卡的两种方式实现对 TLS 的加速

一、背景

当前 TLS 已经成为了互联网安全的主要传输协议，TLS 带来更高的安全性的同时，也带来了更多的性能开销。特别是在建连握手阶段，TLS 的 CPU 开销，相对于 TCP 要大很多。

业界在优化 TLS 性能上已经做了很多软件和协议层面的优化，包括：Session 复用、OCSP Stapling、TLS1.3等。然而在摩尔定律"失效"的今日，软件层面的优化很难满足日益增长的流量，使用专用的硬件技术卸载 CPU 计算成为目前通用的解决方案。本文将介绍 Intel 在 TLS 加速领域提供的 QAT 技术方案。

二、Intel QuickAssist Technology（QAT）技术方案

Intel 提供了 TLS 异步加速的完整解决方案: Intel QuickAssist Technology（QAT），简称 Intel QAT 技术。

如下图所示，QAT 支持加速的密码算法覆盖了 TLS 的整个流程，包括：握手阶段的签名、秘钥交换算法，数据传输的 AES 加解密算法等。

QAT 提供了对称与非对称两类密码算法的支持，主要包括：

1. 非对称加密算法：RSA, ECDSA, ECDHE
2. 对称加密算法：AES-GCM(128,192,256) 

注：QAT 加速的优势主要体现在非对称加密上，从官方的整体性能数据看，非对称算法性能提升 1.6~2 倍，对称算法性能提升 10%~15%

2.1 QAT Engine 软件栈

QAT Engine 是 QAT 技术方案的核心模块，主要的作用是作为应用程序和硬件之间的中间层，负责 “加解密操作的输入输出数据” 在用户应用程序与硬件卡之间进行传递，主要操作就是IO的读写。

QAT Engine 是以 OpenSSL 第三方插件的方式提供给用户，这个意味用户可以使用 OpenSSL 标准的 API，就可以实现对 TLS 的加速，只需要对原有代码做 OpenSSL 异步改造，就可以享受 QAT 技术带来的 TLS 性能加速，业务侵入性较小。

如上图所示，QAT  Engine 支持两种加速方式：

• 软件加速（qat_sw）：使用 Multi-Buffer （SIMD）技术，对密码算法进行并行处理优化。
• 硬件加速（qat_hw）：使用 QAT 硬件加速卡，将密码算法计算从 CPU OffLoad 到硬件加速卡。

下面将介绍软件和硬件两种加速路径的实现方式。

三、软件加速：采用 Intel Multi-Buffer 技术

Intel 从 Whitely 平台开始加入了新的指令集，结合 Intel Multi-Buffer 技术，实现对密码算法的 SIMD 优化方案。

3.1 Intel Multi-Buffer 技术

Intel Multi-buffer 基本原理就是使用 CPU 的 SIMD 机制，通过 AVX-512 指令集并行处理数据，来提升RSA/ECDSA算法性能。

• SIMD (Single Instruction Multiple Data) 即单指令流多数据流，是一种采用一个控制器来控制多个处理器，同时对一组数据（又称“数据向量”）中的每一个分别执行相同的操作从而实现空间上的并行性的技术。简单来说就是一个指令能够同时处理多个数据。
• Multi-Buffer 技术基于 SIMD AVX-512 指令集，通过队列和批量提交策略，结合 OpenSSL 的异步能力，每次可以最多并行处理8个密码算法操作。

Intel 的 Multi-Buffer 方案，实际上是对应 Intel 两个开源工程（ Multi Buffer 技术实现的通用密码算法底层lib库），集成在 QAT Engine 里，从而实现软件加速。

1、IP SEC lib

• 提供了 Multi-Buffer 技术优化的对称加解密算法，如：AES-GCM
• 开源项目：https://github.com/intel/intel-ipsec-mb

2、IPP CRYPTO lib

• 提供了 Multi-Buffer 技术优化的 RSA/EDCSA/EDCHE 算法接口，基于 Intel® Advanced Vector Extensions 512 (Intel® AVX-512) integer fused multiply-add (IFMA) 指令实现SIMD优化。
• 开源项目：https://github.com/intel/ippcrypto/tree/develop/sources/ippcp/crypto_mb

简而言之，QAT 的软件加速的本质就是通过 AVX-512 指令集进行并行处理优化，针对并发场景性能有显著提升（下文有针对 Multi-Buffer 优化场景的性能测试）。

四、 硬件加速：采用QAT硬件加速卡卸载

除了通过 Multi-Buffer 技术进行软件加速外，QAT Engine 还支持 QAT 硬件加速卡，通过将密码算法的计算卸载（OffLoad）到硬件加速卡，实现性能加速。

硬件加速核心是将 TLS 中的非对称加解密操作剥离出来，放到硬件加速卡里计算，即解放了 CPU，同时专用的硬件加速卡也提供了更高的加解密性能，这是典型的硬件 OffLoad 技术方案。

下图为典型的 Nginx+ Intel QAT Software Stack + QAT 硬件加速卡的典型应用场景：

这个典型应用场景包括四个部分：

1. Nginx （Async Mode）:  Intel 基于官方 Nginx（Version 1.18）提供了 Patch，支持 Nginx 工作在 OpenSSL 的异步模式。Patch开源在：https://github.com/intel/asynch_mode_nginx
2. OpenSSL（支持Async Mode）:  OpenSSL-1.1.1 新增了 async mode 特性，应用层软件可以通过标准的 OpenSSL 接口，实现异步调用，提升性能。
3. QAT Engine:   OpenSSL Engine 插件。向下和 QAT API 交互，将处理请求提交给硬件。详见项目开源地址: https://github.com/intel/QAT_Engine
4. QAT Driver：QAT 加速卡的驱动程序。分为用户态和内核态两个部分。用户态的 LIB 库提供 QAT API，内核态的driver则直接和 QAT 硬件加速卡打交道。

Intel QAT 依赖了 OpenSSL 的两个特性 OpenSSL Async Mode 和 OpenSSL Engine：

• OpenSSL Async Mode 能够在 async_job 执行过程中，在等待加速卡结果的时候，将 CPU 让出去；如果没有开启 async 模式，调用 OpenSSL 函数会阻塞，CPU 会阻塞等待。
• OpenSSL Engine 则是提供了自定义注册加解密的方法，可以不使用 OpenSSL 自带的加解密库，指定调用第三方的加解密库。

基于两个特性，应用程序的加解密操作只需要保持使用原来相同 OpenSSL API，只需要做异步模式的兼容。另外，可以在调用 OpenSSL 的 API 时，指定到 Engine QAT上就行，不需要做任何额外的修改，就可以使用 QAT 卡进行加解密加速。

4.1 OpenSSL 的Async Mode特性

通过上面的介绍，我们可以看到 QAT 卡的本质是让一部分原本由 CPU 进行的计算转移到 QAT 卡上进行，因此提高 QAT 的利用率，降低 CPU 的切换开销和等待时间是性能最大化的核心工作。

OpenSSL 未启用异步ASYNC模式时，OpenSSL 调用是同步阻塞的，直到QAT_Engine返回结果。如下图的同步模式，在并发处理执行流的场景，大量CPU处于空闲等待的状态（图中虚线表示CPU处于空闲状态），无法有效地利用CPU。

OpenSSL 开启异步 ASYNC 模式后，OpenSSL 调用是非阻塞的。如下图的异步模式，OpenSSL 的调用不需要等待QAT_engine的处理完成，可以有效地利用 CPU，提高 QAT 的利用率，提升并发处理性能。

通过 OpenSSL 的同步和异步模式的对比，可以看到 OpenSSL-1.1.1 新增的异步 Async 特性，支持了异步非阻塞调用，提高了 QAT 的利用率，可以显著提升加解密性能。

4.2 QAT Engine ASYNC运行流程

接下来还有一个问题，CPU 如何知道 QAT 卡完成了计算呢？ 

Async模块为了达到并行的目的，在单线程中实现了协程（async job）。加解密操作抽象为job，多个job同时运行，使用协程进行调度。

在async job执行的过程中，当计算操作提交给QAT卡后，CPU 可以把当前任务暂停，切换上下文（保存/恢复栈，寄存器等）返回给用户态。

用户态需要主动去poll这个async job的状态，是否是ASYNC_FINISHED状态。如果是，说明之前的任务已经完成，则可以继续后面的操作（取回加密/解密结果）。

注：QAT Engine 通过轮询来获取QAT卡的计算状态，基本原理是启动一个线程，不停的调用qatdriver的polling api，轮询获取qat的计算状态，得到相应结果后，写入eventfd，唤醒async job。

如上图所示，QAT Engine Async的基本流程为：

1. 主 job 调用 SSL_accept，等待 TLS 客户端发起 TLS handshake。
2. SSL 内部组织了一个状态机，将握手，读写等操作抽象为两个job，ssl_io_intern(读写), ssl_do_handshake_intern(握手), 统一通过api ASYNC_start_job()进行job调度。这里启动了一个握手的job协程。
3. 握手job执行 RSA_sign 签名操作时，将sign算法卸载到硬件上计算。调用 ASYNC_pause_job()  切回主job, 并将job状态设置为 ASYNC_PAUSE ，这个时候 CPU 会交还给主 job 进行其它计算工作，同时 QAT 并行的进行自己的计算。
4. 主job通过SSL_waiting_for_async() 接口获得的一个eventfd，并epoll这个eventfd。当 QAT 卡计算完成，会执行回调写入eventfd，通知主job计算已完成。
5. 主job切换回握手job，握手job的完成剩余流程后，再调用ASYNC_pause_job()切换主job，并将job状态设置为ASYNC_FINISH，结束协程完成握手动作。

五、QAT 性能评测

通过上面的介绍，我们了解了 QAT 技术方案的基本原理，下面我们看下 QAT 的实际加速效果。

QAT Multi-Buffer 加速方案，依赖的 OpenSSL、QAT Engine、ipp-crypto、 Intel-ipsec-mb 软件栈都是开源项目，我们可以方便的使用 OpenSSL Speed 原生加解密算法对 Multi-Buffer 方案进行性能评估。

硬件环境

• Intel(R) Xeon(R) Platinum 8369B CPU @ 2.70GHz
• CPU(s): 8

软件环境

• Linux Kernel: 4.19.91-24.1.al7.x86_64
• OpenSSL 1.1.1g
• gcc (GCC) 8.3.0
• cmake version 3.15.5
• NASM version 2.15.05
• GNU Binutils 2.32
• 安装 QAT Engine
• 安装 ipp-crypto、 Intel-ipsec-mb 开源lib库

测试数据

• numactl -C 0 ./openssl speed rsa2048
• numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 rsa2048

• numactl -C 0 ./openssl speed ecdhp384
• numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 ecdhp384

• numactl -C 0 ./openssl speed aes-256-cbc
• numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 aes-256-cbc

TLS 握手阶段的签名和秘钥交换算法

• RSA 2048 Sign/Verify  提升 4.9/2.9倍
• ECDH Key Exchange 提升 12倍

对称加解密算法

• AES-256-CBC 性能持平

根据性能测试结果，QAT 的加速优势在于 TLS 握手阶段的签名和秘钥交换算法，适合频繁进行 TLS 建连的应用场景，比如：Nginx 网关、长连接网关等。

六、总结

本文介绍了 Intel QAT 技术方案，并讨论了方案提供的 Multi-Buffer 软件加速以及 QAT 硬件加速两种方式。同时，通过性能评估测试，我们可以看到 QAT 技术对 TLS 握手阶段的加解密算法有显著的性能提升。

最后，我们讨论一下 Intel QAT 技术的优缺点和应用场景：

6.1 优点和缺点

主要的优点

• 高性能：可以显著提高计算密集型任务的性能，减少 CPU 的负载，提高系统吞吐量和响应速度。
• 低功耗：可以将计算密集型任务卸载到专用硬件上，降低系统功耗，提高能效比。

主要的缺点

• 成本较高：需要额外的硬件支持，增加了系统的成本。
• 应用范围受限：主要适用于计算密集型任务，对于其他类型的任务可能没有显著的性能提升。
• 不支持所有处理器：只支持 Intel 特定系列的处理器，需要特定的硬件和软件支持。
• 改造成本高：需要对应用程序进行 QAT 异步化改造，需要一定的学习成本和技术支持。

6.2 应用场景

除了加解密算法之外，Intel QAT 还支持压缩和解压缩、随机数生成、数字签名、视频编解码等算法。Intel QAT 主要可以用于以下场景：

• 接入网关：比如 Nginx 网关、长连接网关。QAT 可以加速 TLS 协议处理，提升网关的性能
• 虚拟私人网络（VPN）：QAT 可以加速 VPN 流量的加密和解密过程，提高吞吐量，减少延迟
• 存储加速：QAT 可以加速数据压缩和解压缩，减少需要传输和存储的数据量
• 视频编解码：QAT 可以加速视频编解码算法，提高视频处理的效率和质量

总的来说，Intel QAT 可以将计算密集型任务从 CPU 中分离出来，显著提高系统的性能和能效比，可以广泛应用于计算密集型任务的加速，包括网络安全、数据处理、云计算、存储加速、视频处理等多个领域。

参考资料

• Github：intel/QAT_Engine
• Intel® QuickAssist Technology (Intel® QAT)
• Intel® QuickAssist Technology & OpenSSL-1.1.0: Performance
• TLS
• Intel® Processor Architecture: SIMD InstructionsSIMD Instructions
• [openssl] openssl async模块框架分析
• TLS 加速技术：Intel QuickAssist Technology（QAT）解决方案
• Keyless SSL: The Nitty Gritty Technical Details
• TLS 加速技术：Intel QuickAssist Technology（QAT）解决方案

一. 引言

现在低功耗蓝牙（BLE）连接都是建立在 GATT (Generic Attribute Profile) 协议之上。GATT 是一个在蓝牙连接之上的发送和接收很短的数据段的通用规范，这些很短的数据段被称为属性（Attribute）。

二. GAP

详细介绍 GATT 之前，需要了解 GAP（Generic Access Profile），它在用来控制设备连接和广播。GAP 使你的设备被其他设备可见，并决定了你的设备是否可以或者怎样与合同设备进行交互。例如 Beacon 设备就只是向外广播，不支持连接，小米手环就等设备就可以与中心设备连接。

2.1 设备角色

GAP 给设备定义了若干角色，其中主要的两个是：外围设备（Peripheral）和中心设备（Central）。

外围设备：这一般就是非常小或者简单的低功耗设备，用来提供数据，并连接到一个更加相对强大的中心设备。例如小米手环。
中心设备：中心设备相对比较强大，用来连接其他外围设备。例如手机等。

2.2 广播数据

在 GAP 中外围设备通过两种方式向外广播数据： Advertising Data Payload（广播数据）和 Scan Response Data Payload（扫描回复），每种数据最长可以包含 31 byte。这里广播数据是必需的，因为外设必需不停的向外广播，让中心设备知道它的存在。扫描回复是可选的，中心设备可以向外设请求扫描回复，这里包含一些设备额外的信息，例如设备的名字。（广播的数据格式我将另外专门写一个篇博客来讲。）

2.3 广播流程

GAP 的广播工作流程如下图所示。

从图中我们可以清晰看出广播数据和扫描回复数据是怎么工作的。外围设备会设定一个广播间隔，每个广播间隔中，它会重新发送自己的广播数据。广播间隔越长，越省电，同时也不太容易扫描到。

2.4 广播的网络拓扑结构

大部分情况下，外设通过广播自己来让中心设备发现自己，并建立GATT连接，从而进行更多的数据交换。也有些情况是不需要连接的，只要外设广播自己的数据即可。用这种方式主要目的是让外围设备，把自己的信息发送给多个中心设备。因为基于GATT连接的方式的，只能是一个外设连接一个中心设备。使用广播这种方式最典型的应用就是苹果的iBeacon。广播工作模式下的网络拓扑图如下：

三. GATT

GATT 的全名是 Generic Attribute Profile（姑且翻译成：普通属性协议），它定义两个 BLE 设备通过叫做 Service 和 Characteristic 的东西进行通信。GATT 就是使用了 ATT（Attribute Protocol）协议，ATT 协议把 Service, Characteristic遗迹对应的数据保存在一个查找表中，次查找表使用 16 bit ID 作为每一项的索引。

一旦两个设备建立起了连接，GATT 就开始起作用了，这也意味着，你必需完成前面的 GAP 协议。这里需要说明的是，GATT 连接，必需先经过 GAP 协议。实际上，我们在 Android 开发中，可以直接使用设备的 MAC 地址，发起连接，可以不经过扫描的步骤。这并不意味不需要经过 GAP，实际上在芯片级别已经给你做好了，蓝牙芯片发起连接，总是先扫描设备，扫描到了才会发起连接。

GATT 连接需要特别注意的是：GATT 连接是独占的。也就是一个 BLE 外设同时只能被一个中心设备连接。一旦外设被连接，它就会马上停止广播，这样它就对其他设备不可见了。当设备断开，它又开始广播。

中心设备和外设需要双向通信的话，唯一的方式就是建立 GATT 连接。

3.1 GATT连接的网络拓扑

下图展示了 GTT 连接网络拓扑结构。这里很清楚的显示，一个外设只能连接一个中心设备，而一个中心设备可以连接多个外设。

 一旦建立了连接，通信就是双向的了，对比前面的GAP广播的网络塔扑，GAP通信是单向的。如果你要让两个外围设备能通信，就只能通过中心设备中转。

3.2 GATT 通信事务

GATT通信的双方是C/S关系。外设作为GATT服务端（Server），它维持了ATT的查找表以及service和characteristic的定义。中心设备是GATT客户端（Client），他向Server发起请求。需要注意的是，所有的通信事件，都是由客户端（也叫主设备，Master）发起，并且接收服务端（也叫从设备，Slava）的响应。
一旦连接建立，外设将会给中心设备建议一个 连接间隔（Connection Interval），这样，中心设备就会在每个连接间隔尝试去重新连接，检查是否有新的数据。但是，这个连接间隔只是一个建议，你的中心设备可能并不会严格按照这个间隔来执行，例如你的中心设备正在忙于连接其他的外设，或者中心设备资源太忙。

下图展示一个外设（GATT服务端）和中心设备（GATT客户端）之间的数据交流流程，可以看到的是，每次都是主设备发起请求：

3.3 GATT 结构

GATT事务是建立在嵌套的Profiles，Services和Characteristics之上的，如下如所示：

• Profile Profile并不是实际存在于BLE外设上的，它只是一个被Bluetooth SIG或者外设设计者预先定义的Service的集合。例如心率Profile（Heart Rate Profile）就是结合了Heart Rate Service和Device Information Sercvice。所有官方通过GATT Profile的列表可以从这里找到。

• Service Service是把数据分成一个个的独立逻辑项，它包含一个或者多个Characteristic。每个Service有一个UUID唯一标识。UUID有16bit的，或者128bit的。16bit的UUID是官方通过认证的，需要花钱购买，128bit是自定义的，这个就可以自己随便设置。

  官方通过了一些标准Service，完整列表在这里。以Heart Rate Service为例，可以看到它的官方通过16bitUUID是 0x180D，包含3个Characteristic：Heart Rate Measurement，Body Sensor Location和Heart Control Point，并且定义了只有一个第一个必须的，它是可选实现的。

• Characteristic 在GATT事务中的最低界别的是Characteristic，Characteristic是最小的逻辑数据单元，当然它可能包含一个组关联的数据，例如加速度计的X/Y/Z三轴值。与Service类似，每个Characteristic用16bit或者128bit的UUID唯一标识。你可以免费使用Bluetooth SIG官方定义的标准Characteristic，使用官方定义的，可以确保BLE的软件和硬件能相互理解。当然，你可以自定义Characteristic，这样的话，就只有你自己的软件和外设能够相互理解。

  举个例子，Heart Rate Measurement Characteristic,这是上面提到的Heart Rate Service必需实现的Characteristic，它的UUID是 0x2A37。它的数据结构是，开始8bit定义心率数据格式（是UINT8还是UINT16？），接下来就是对应格式的实际心率数据。

  实际上，和BLE外设打交道，主要是通过Characteristic。你可以从Characteristic读取数据，也可以往Characteristic写数据。这样就实现了双向的通信。所以你可以自己实现一个类似串口（UART）的service，这个Service中包含两个Characteristic，一个被配置只读的通道（RX），另一个配置为只写的通道（TX）。

更多内容

• Bluetooth SIG 官方文档

  • 蓝牙核心协议文档
  • Bluetooth Developer Portal
  • 官方通过的 BLE Profile
  • 官方通过的 BLE Service
  • 官方通过的 BLE Characteristic

• 移动开发资源

  • Android BLE GUIDE - Android developer 官网的入门文章，里面有实例代码和讲解视频。
  • Application Accelerator Kit - iOS, Android or Windows Phone 移动开发样例
  • 视频: Core Bluetooth 101 - WWDC 2012 关于 BLE 开发的视频。

参考链接

蓝牙BLE: GATT Profile 简介(GATT 与 GAP)