面向密码资源池的单任务高性能通信调度技术研究与实现

4　结　语

随着信息化的深入，业务系统处理的数据容量设计已经达到PB级甚至EB级，业务处理要求达到几十万甚至上百万TPS。为更好地满足数据中心、云计算等海量业务场景的高性能密码保障需求，国内外厂商也在积极探索高效运算、调度灵活的密码资源池应用方案。当前，各厂商一般通过集群扩充的方式将密码硬件资源进行整合，并配合服务层调度管理程序为业务系统提供高性能、高并发的密码服务。

密码资源池通过以太网与业务系统计算机，采用传输控制协议/网际协议（Transmission Control Protocol/Internet Protocol，TCP/IP）承载密码服务数据包。密码资源池工作原理如图1所示。

图1　密码资源池工作原理

密码服务应用接口主要分为密钥管理、密码运算、随机数和证书管理等服务。其中，密钥管理和证书管理服务的数据包长度短且相对固定，因此，仅需要通过单次调度即可完成运算请求。但密码运算服务的数据包长度依赖应用系统的业务数据大小，在视频监控数据、测绘地理空间等大包数据场景下，需要进行分片操作，并经过多次调度才能完成运算请求。

在分组算法和杂凑算法串行运算的背景下，传统调度机制为：密码服务应用接口在处理大包数据密码运算请求时，首先对大包数据分片，其次对分片包进行密码运算同步调度控制，待所有的分片包运算完成后，最后将合片后的整包数据返回应用程序。传统分片调度控制原理如图2所示。

图2　传统分片调度控制原理

2.1　网络通信机制设计

2.1.1　异步调度机制设计

为充分利用网络通道的传输效率，本文采用多发多收的异步调度控制机制，在该机制下，密码服务应用接口和密码资源池服务系统之间自动进行调度协作，当密码服务应用接口收到大包数据运算请求后，由密码服务应用接口进行分片（假设分片包总数为n）。在首轮运算时，密码服务应用接口依托多个 TCP套接字同时发送m个分片数据包（m为首轮发送基数，其中m≤n），当收到第k个密码运算返回分片数据包后，再根据动态发包策略计算本次发送的分片包个数x，以此类推，直到所有的数据包均发送完成。网络通信异步调度控制原理如图3所示。

图3　网络通信异步调度控制原理

相较于传统方式，该机制实现首轮m个数据包的并行网络传输，且打破不同分片包之间的同步等待依赖条件，实现了数据传输和密码运算的并行操作。

2.1.2　动态发包策略设计

由于密码资源池服务系统需要为多台计算机应用系统的多个会话同时提供密码服务，为防止单个会话过度抢占密码设备资源，密码资源池服务系统需要根据自身并发压力情况，动态调节并限制分配给每个会话的缓存资源。此外，应用系统所在的计算机网络，在收发数据时，缓存也存在限值，当发送数据出现缓存空间不足的情况时，会增加系统写入输入/输出（Input/Output，I/O）的访问次数，导致系统调度开销增大。因此，需设计一种策略控制机制，动态控制每次发送的数据分片包个数，解决网络缓存空间和密码资源池服务系统分片数据缓存空间的限制问题。

策略控制机制为：密码服务应用接口在处理多个分片数据包时，首先，按照预置值连续发送m个分片请求包，密码资源池服务系统在收到请求数据包后，按分片序号排队进行密码运算操作；其次，每完成一个分片运算后，根据自身并发处理的压力和系统资源消耗情况，计算本会话承载的最大分片窗口个数p，并把窗口值依附到运算后的分片数据包中，返回客户端；最后，客户端根据自身网络吞吐情况计算当前分片窗口个数q，并结合队列中的已发送未返回的分片包个数s，计算最小值min(p-s,q)，得到本次连续发送的分片包个数x。依据以上方案，客户端分片队列状态可分为已返回分片包、等待返回分片包、可发送分片包和不可发送分片包，其中等待返回分片包的个数加上可发送分片包的个数即为服务端能承载的最大分片包个数。客户端的分片包队列状态如图4所示。

图4　客户端分片包队列状态

2.2　异步服务框架设计

在同步工作模式下，大包数据只有一个分片数据存在于网络通信链路或密码资源服务系统。在异步工作模式下，多个分片数据包的密码运算请求同时发往密码资源服务系统，由于分片包间存在依赖关系，需要管理同一个任务的多个分片包及按序密码运算调用，因而服务框架依据任务号需解决分片包的多发多收异步调度问题。

该框架采用Multi-reactor多线程模型思想进行异步调度设计，从原理上主要包含mainReactor、subReactor和工作线程池逻辑模块。其中，mainReactor负责处理所有的网络连接事件，并根据负载均衡规则把连接分配到不同的subReactor；subReactor处理所辖套接字之间的数据读和数据写操作及将所有请求运算的数据帧合片后放入运算队列；工作线程池逻辑模块从运算队列中获取运算任务，并进行协议解封、密码运算调度和协议封装等操作。密码服务程序异步调度框架如图5所示。

图5　密码服务程序异步调度框架

该框架通过epoll_wait 实现I/O多路复用，工作流程如下：

（1）主线程负责监听和创建套接字，并注册套接字上的读就绪事件。

（2）网络收发线程池通过epoll_wait函数监听所有套接字上的数据读、数据写和套接字关闭事件。为保障线程安全，需要为套接字注册 EPOLLONESHOT事件。

（3）当 socket上有数据读事件时，网络收发线程被唤醒，完成数据读取操作后，根据会话号插入待处理的事件队列，并通知业务处理线程。

（4）业务处理线程被唤醒后，为解决分片包间的依赖关系，需要依据算法模式特性对上一个分片包运算结果和当前分片数据包进行密码运算前的预处理操作，进而保障分片包间的关联性。

（5）预处理完成后，执行密码运算操作，根据当前设备的并发运算情况计算当前会话接收的窗口大小，最后封装返回数据包，并将返回数据包插入到队列，注册数据写事件。

（6）写事件触发后，网络收发线程被唤醒，依据返回数据包队列，循环、按序地进行数据写操作。

（7）套接字关闭事件触发后，网络收发线程被唤醒，回收套接字和套接字绑定的分片数据包资源。

2.3　密码资源服务系统通信协议设计

为实现异步通信调度控制，密码服务应用接口和密码资源服务系统之间需要设计专用的网络通信协议，以支撑分片数据包的并行收发。根据数据流方向，通信协议分为密码运算请求包和应答包。通信协议帧格式如图6所示。

图6　通信协议帧格式

硬件采用x86架构服务器，配备48个CPU核心和64GB的内存资源，运行64位CentOS7。

3.2　测试结果与分析

3.2.1　单任务测试

在单任务场景下，对同步密码服务、异步密码服务和直连密码设备性能进行对比测试，测试数据总包长基于1MB、8MB、16MB、32MB、64MB、128MB和256MB，分片数据包长基于16KB、32KB、64KB和128KB，测试结论如图7所示。

图7　单任务测试

从测试数据分析可知，传统同步服务性能远低于直连设备运算性能，性能损耗超50%；异步服务性能则趋近于直连密码设备时的运算性能，在数据包长较小时，性能损耗在15%左右，当数据包长增加到16MB后，性能趋于稳定，且损耗低于10%。

3.2.2　并发测试

在并发任务场景下，对同步密码服务、异步密码服务和直连密码设备进行对比测试，测试基于32MB数据总包长和16KB分片数据包长，测试结论如图8 所示。

图8　多任务测试

此外，本文提出的技术方案由密码服务应用接口和密码资源服务系统间自动协作完成，应用系统无须开展额外的适配开发工作，具备良好的前向兼容能力。