作者与发表信息
本文的主要作者包括Antonio Vincenzo Taddeo、Alberto Ferrante和Vincenzo Piuri。前两位作者隶属于瑞士卢加诺大学（University of Lugano）的ALARI研究所，第三位作者隶属于意大利米兰大学（University of Milano）的DTI系。该研究发表于《Journal of Communications》第2卷第2期，出版时间为2007年3月，出版方为Academy Publisher。本文基于作者团队此前在CCNC 2006国际会议上发表的论文扩展而成。
研究背景与目的
本研究属于网络安全与嵌入式系统交叉领域，具体聚焦于IPsec协议在高吞吐量网络环境中的硬件加速问题。IPsec是一套在IP层为通信提供安全保障的协议族，主要包括认证头（Authentication Header, AH）和封装安全载荷（Encapsulating Security Payload, ESP）两种协议。IPsec作为IPv6中强制性的安全机制，其重要性日益提升，尤其在虚拟专用网络（Virtual Private Network, VPN）的构建中应用广泛。
IPsec协议大量使用密码学算法，这些算法的计算密集度很高。为了支持较大的网络带宽，即使在小型安全网关中也必须引入硬件加速。然而，IPsec加速器的性能在很大程度上取决于所处理数据包的尺寸。当数据包较小时，数据传输和加速器初始化所需的时间可能超过软件直接处理数据包的时间，导致加密过程效率低下。根据互联网数据分析合作协会（CAIDA）的分析，互联网数据包最可能的尺寸约为40字节，因此小包问题不可忽视。
作者团队此前的研究已经提出了允许在多个密码加速器和CPU之间分配数据包处理任务的调度算法，并扩展支持了服务质量（Quality of Service, QoS），但尚未针对小数据包问题提出专门解决方案。本研究的目标就是通过设计一种滑动窗口调度算法，将属于同一安全关联（Security Association, SA）的小数据包捆绑成更大的多数据包，以减少DMA传输建立和密码算法初始化对系统整体性能的影响，并支持在多个加速器上进行调度。
研究工作流程与实验方法
本研究的核心工作包括三个主要环节：系统架构建模、滑动窗口调度算法设计、以及基于SystemC的高层仿真验证。
在系统架构方面，作者考虑了一个由主机计算机和一个通过PCI总线（32位、66MHz）连接的密码加速器组成的系统。CPU与内存之间的通信在更快的总线上完成，网络接口卡也连接到较快的CPU总线。只有密码学相关操作被卸载到加速器上执行，所有IPsec头部处理仍由CPU完成。待处理的数据存储在内存中，各处理器通过DMA方式加载到本地内存。作者明确说明这只是用于测试调度算法特性的示例架构，更高吞吐量的系统应当采用不同的架构。
在调度算法设计方面，作者提出了两个基本假设。第一，数据包的处理时间至少可以近似地预先知道。对于IPsec环境中通常使用的对称密钥密码算法而言，这一假设成立，因为其处理时间仅取决于需要处理的数据块数量。第二，每个数据包可以独立于其他数据包进行处理，即不同数据包之间不存在数据依赖关系。这一特性来源于IPsec规范本身，每个数据包都必须携带其处理所需的全部数据。
滑动窗口调度算法的核心思想包括两点：将待处理的数据包分配给能够提供最短完成时间的处理器（CPU或加速器），以及将属于同一SA的数据包捆绑在一起。算法使用滑动窗口观察输入数据流中特定大小的部分。具体操作流程是：取滑动窗口中第一个数据包的SA标识符作为参考，将后续数据包中具有相同SA标识符的数据包合并形成一个多数据包（multi-packet）；如果窗口中没有其他数据包具有相同的SA标识符，则多数据包仅由第一个数据包构成。当窗口填满或超时后，多数据包被送往选定的处理器进行处理。多数据包形成并发送后，相关的单个数据包从队列中移除，剩余数据包保持到达顺序并重新通过上述机制处理。
调度器对每个多数据包的处理方式是：计算每个处理器的完成时间（finishing time），定义为等待时间与处理时间之和，然后将数据包调度到完成时间最短的处理器。等待时间由队列中所有数据包的处理时间、排队时间以及当前正在处理数据包的剩余处理时间组成。密码算法的处理时间可以通过与算法对应的公式计算，公式参数取决于每个处理器的特性，这些特性可以由制造商提供或通过简单的速度测试确定。
在仿真验证方面，作者使用SystemC语言建立了基于队列的模型。SystemC被选择的原因是它能够描述软硬件混合系统，并且可以方便地建模操作延迟。模型描述了密码架构中的队列和与IPsec数据包相关的密码请求流。在建模时，作者只考虑了总线竞争，忽略了内存访问竞争和CPU与加速器之间的其他必要通信。PCI总线访问采用简化模型，总线传输时间的计算公式考虑了总线周期时间、地址断言时间和数据传输时间。
仿真中采用了AES加密作为唯一可用的操作，同时支持硬件实现和软件实现。加密时间的计算使用适用于所有以16字节为块单位的密码块算法的公式：初始化时间加上块处理时间乘以数据块数量。作者还引入了CPU处理速率可变性的修正版本，通过初始化时间比率和加密时间比率两个参数来定义CPU相对于加速器的处理能力。
为了研究数据包尺寸的影响，作者采用了七种不同的流量模式，每种模式包含500,000个样本。其中两种模式分别基于指数分布和均匀分布，四种模式具有固定的数据负载尺寸（0、24、472和984字节），所有模式内都考虑了100个SA的随机分布。此外，还使用了来自互联网流量档案（Internet Traffic Archive, ITA）的真实网络追踪文件，包含从2Mbit/s网关捕获的约300万个TCP数据包，实验中使用其中500,000个。实验中考虑的处理模式是ESP隧道模式，数据包尺寸增加了40字节以模拟TCP/IPv4头部。加速器的处理能力设定为约230Mbit/s，CPU的处理能力在32Mbit/s到230Mbit/s之间变化。滑动窗口尺寸考虑了10和30两种取值。
主要研究结果
在单加速器系统中，当滑动窗口尺寸为30时，真实网络追踪数据平均每个窗口形成2.57个多数据包，而其他模式仅形成1.33个。CPU处理数据包的相对数量随着加密时间比率的增加而降低，固定尺寸模式下降更快。调度器始终倾向于将多数据包分配给加速器，而将小数据包发送给CPU。加速器处理的数据包长度变化比CPU更大，但总体上偏向处理较大的数据包。
在系统吞吐量方面，滑动窗口机制显著改善了整体性能，尤其对小数据包的处理效率提升最为明显。然而，由于系统处于过载状态（网络速率为1Gbit/s而处理能力仅为500Mbit/s），当处理能力趋于饱和时，吞吐量会随着加密时间比率的增加而降低。平均处理延迟方面，滑动窗口机制会增加延迟，这是因为需要时间填充滑动窗口。对于平均数据包尺寸较大的流量模式，这种负面影响更为显著。作者指出可以通过引入滑动窗口的时间上限或总字节数上限来解决延迟增加的问题。
在两加速器系统中，随着加密时间比率的增加，CPU处理的数据包百分比下降，而加速器1的使用率上升。CPU处理的数据包平均长度随加密时间比率的增加而减小，加速器1处理的数据包平均长度则相应增加。系统吞吐量随加密时间比率的增加而降低，这是因为CPU的处理能力相应下降。关键的对比结果显示，当滑动窗口尺寸从1增加到30时，系统的平均处理延迟显著降低，吞吐量明显提高。w=1意味着禁用滑动窗口机制，因此这一结果表明滑动窗口机制在两加速器系统中同样能够有效改善系统性能。
此外，使用滑动窗口机制后，CPU和加速器处理的数据包平均长度都有所提高，说明多数据包的合并机制既增加了发送到加速器的数据包尺寸，也间接增大了CPU处理的数据包尺寸。在两加速器系统中，总线冲突次数保持在总总线访问次数的17%以下，作者建议可以通过采用预取和写缓冲机制来进一步减少冲突，提高系统效率。
研究结论与价值
本研究为IPsec系统中的“小数据包问题”提供了一种有效的解决方案。滑动窗口机制通过将属于同一SA的数据包捆绑在一起，避免了多次DMA建立和密码算法初始化过程的重复开销。高层仿真结果证明该算法能够按预期工作，并在系统过载时提供整体性能提升。
在科学价值方面，本研究提出了一种新颖的数据包调度思路，将数据包分组与多处理器调度问题相结合，为网络安全加速系统中的性能优化提供了新的理论视角。在应用价值方面，该算法可以直接应用于实际的安全网关系统，特别是那些需要处理大量小数据包的网络环境。作者团队已经在OpenBSD密码框架（OCF）上实现了此前提出的基础调度算法，并正在进行功能测试，本文提出的滑动窗口算法也将以相同方式实现和测试。这一实际实现的持续推进表明该研究具有较强的工程实用性。
此外，作者还指出了未来研究方向：需要解决QoS支持问题，研究超时机制和滑动窗口字节数限制以改善延迟性能，以及开发动态参数调整机制使算法能够适应不同的输入数据流特性。总线冲突的优化也是进一步提升系统效率的潜在方向。
研究亮点
本研究的核心亮点在于滑动窗口这一简洁而有效的机制设计。滑动窗口本质上只是对调度器输入队列的一种修改，实现成本较低，但能够在不改变IPsec协议本身的前提下显著改善系统性能。另一个重要特点是该算法利用IPsec协议中SA的内在属性——同一SA的数据包可以使用相同的密码算法参数进行批量处理——来减少重复的初始化开销。此外，通过完成时间计算实现在多个异构处理器之间的负载均衡，使得CPU和硬件加速器能够根据各自的实时负载和处理能力协同工作，这种软硬件协同调度的思想在嵌入式网络安全系统中具有广泛的适用性。真实网络追踪数据的使用也为仿真结果的实用性和可信度提供了有力支撑。