高精度流量重放工具：GapReplay

随着互联网的不断发展，网络流量变得越来越复杂和多样化。对于流量生成工具（Traffic Generation）来说，很难在保证流量真实性的同时构建大量不同种类的流量。因此可以通过使用流量重放工具（Traffic Replay）重放来自生产网络的流量，来最大限度地提高流量的真实性，从而有助于在网络试验中评估算法的有效性。近年来，网络领域的许多研究，尤其是基于机器学习的算法，对流量的统计特性极为敏感，例如基于机器学习的流量分类、流量检测、流量预测等。然而，对于不断增长的加密流量，只有少数的统计特征能够被我们使用，例如数据包大小和到达间隔时间(inter-arrival time, IAT)。

但是，已有的流量重放工具在对原始流量进行重放时，流量的统计特征难以被准确复现，特别是数据报文之间的到达时间间隔与原始流量相比有较大的误差。例如，tcpreplay是一个广泛使用的基于内核网络协议栈的流量重放工具，由于从用户态切换到内核态的昂贵开销，由tcpreplay发送的重放流量的IAT与原始流量的IAT相差甚远；除此之外，MoonGen作为一个基于DPDK的脚本化的流量生成工具，也可以通过编写重放脚本达到流量重放的目的，然而，由于MoonGen只能够解析精度为微秒级别的pcap文件，使得MoonGen在高性能网络的环境下很难做到精确的流量重放，因为在10Gbps甚至100Gbps的网络环境下，pcap文件中很可能会存在两个数据包的时间戳在微秒层级是相同的，只在纳秒层级有些许的差别。

我们认为，两个数据包之间存在的间隔是产生重放误差的根本原因，因为在重放时很难精确控制间隔的时间。然而，现有的流量重放工具的主要思路就是尽可能精确地控制相邻数据包之间的间隔。因此，我们建议通过使流量达到线速来消除所有相邻数据包之间的间隔，再将线速流量恢复原样，从而达到精确重放流量的目的。基于以上思路，我们开发了一种高精度的流量重放算法：GapReplay，通过将数据报文到达时间间隔的误差控制在纳秒级别，尽最大可能保持重放流量的统计特征与原始流量相同。

1. 整体架构

GapReplay的整体架构如图1所示，主要由两部分组成：Gap Replayer和Gap Handler。Gap Replayer通过延长、重放、插入等操作消除所有数据包之间的间隔，生成线速流量，这部分线速流量将会发送到一台可编程的硬件，即架构中的Gap Handler。在本篇文章中，我们选择使用Tofino的可编程交换机对Gap Handler进行实现。

图1：GapReplay整体架构

Gap Replayer由两个填充器构成，即数据包填充器packet-filler和间隔填充器gap-filler。数据包填充器从pcap文件中解析出所有数据报文，并且将它们重放到链路上。这些原流量中的数据报文大多数都没有任何变化，在本篇文章中被称为普通数据报文，例如和，然而也有一些类似于的数据报文被延长了一定的长度（最多延长95字节），在图1中被标记为，这些数据报文被称作延长数据报文。间隔填充器生成间隔数据报文并将其发送到链路上，间隔数据报文是带有非法以太类型0x0801的巨型帧，例如。

在我们的实现中，所有的数据报文被分为了三种情况，对每种类型的数据报文所做的操作分别为：

• No Action:即不做任何操作。普通数据报文与pcap文件中的数据报文完全相同，因此Gap Hander不需要对它们做任何处理，只需要将它们发送到Egress并正常转发即可。

• Drop:即丢包。间隔数据报文是由间隔生成器生成并发送到链路上的无效数据报文，它们并不存在于原始的pcap文件中，这些无效的数据报文不能被转发出去，因此Gap Handler应该对它们做丢包的操作。

• Trim:即裁剪操作。延长数据报文和普通数据报文十分类似，只是略微地被延长了一定的长度。这部分报文应该恢复为原本的长度，因此它们将根据自身的一些特定字段被截断一定的长度，具体的字段和截断方式将在之后详细描述。

这里我们选择的是可编程的硬件设备来实现Gap Handler，主要考虑的是由硬件流水线来处理所有的数据报文操作，这样才能够保证对每个数据报文的处理时间都是完全相同的，从而避免处理时间不同，额外引入其它误差，对流量重放的精度造成影响。

通过数据包填充器和间隔填充器将pcap文件中所有的数据报文间隔都填满后，Gap Replayer将达到线速，由于数据报文之间不再存在任何间隔，由到达时间间隔引起的误差也就不复存在了。因此，间隔填充的机制是避免误差、达到高精度重放的关键。

2. 数据报文间隔分类

根据到达时间间隔、网卡的线速速率以及前一个数据报文的长度，可以将数据报文之间的间隔分为两种类型。为了简化后续的描述，我们将未被数据报文占用的链路上的可用空闲容量视为数据报文间隔，可以表示为等式：

其中，G是数据报文间隔的长度，I表示到达时间间隔，N代表网卡的线速速率，L表示前一个数据报文的长度。

由RFC 2544可知，在以太网中的最小帧长度为64字节^[1]，除此之外每个以太网帧还有7字节的前导码preamble以及1字节的帧开始符SFD，在每两个相邻的以太网帧之间还有长度至少为12字节的帧间距IPG。由于在插入帧时需要在前后两侧都预留至少12字节的帧间距，因此想要在相邻数据报文之间的间隔中插入帧，该间隔的长度需要大于或者等于96字节，否则即使是长度最小的帧也无法插入。因此我们将根据数据报文间隔的长度对其进行分类，将长度小于96字节的数据报文间隔分类为小间隔，长度大于或者等于96字节的数据报文间隔分类为大间隔。

3. 数据报文间隔处理办法

根据上述对数据报文间隔的分类，在GapReplay中，对大间隔和小间隔的处理办法分别为：

• 大间隔：大间隔应该由一定数量的、带有非法以太类型的巨型帧来进行填充。我们采用巨型帧来进行填充操作的原因是尽量减少填充数据报文的数量，从而在一定程度上简化填充操作。在计算填充帧的大小和数量时，需要注意将前导码、帧开始符以及帧间距的长度考虑在内。在我们的实现中，巨型帧的标准长度为8880字节（包含帧校验序列FCS）。另外，如果计算得出最后一个填充帧的大小小于64字节，则需要对最后两个填充帧的长度做平均操作，以避免最后一个填充帧出现无法传输的问题。

• 小间隔：由于小于96字节的小间隔不能插入任何以太网帧，而通过等待特定的时间间隔又会引入新的重放误差，因此需要其它的方法来使得小间隔也被填满，从而让网卡达到线速速率。在小间隔中，无法进行无效帧插入操作的原因是帧的长度不合法，然而在原流量中，小间隔的前一个数据报文的长度是合法有效的，因此可以将前一个数据报文进行一定的延长来填充小间隔，就不需要插入无效的数据报文了。

被发送到链路上的数据报文除了pcap文件中的原始数据报文，还有无效的间隔数据报文以及被延长的原始数据报文，这些数据报文应该被Gap Handler丢弃以及裁剪。因此，需要给这些数据报文做一定的标记，指示Gap Handler做相应的操作。我们采用的办法是赋予这些报文未分配或者几乎不使用的以太类型，Gap Handler就可以根据相应的以太类型执行对应的硬件操作。

1. 普通数据报文

普通数据报文的以太类型维持不变，与pcap文件中原始数据报文的以太类型相同。

2. 间隔数据报文

间隔数据报文在原始流量中不存在，因此需要被Gap Handler丢包，我们选择赋予间隔数据报文0x0801的以太类型，指示Gap Handler丢弃带有该以太类型的数据报文。

3. 延长数据报文

延长数据报文的情况相对于普通数据报文以及间隔数据报文要复杂许多，因为为了使得重放的数据报文长度与原始数据报文的长度保持一致，在对数据报文进行延长操作之后还需要对其进行裁剪以恢复原样。因此除了使用以太类型对延长数据报文进行标识以外，还需要记录具体被延长了多少长度。

由于在数据传输时是以字节作为单位进行计算的，因此如果一个数据报文被延长了，至少会比原始数据报文长1个字节，即8比特。小间隙的最大长度为95字节，减去与后面数据报文之间12字节长的帧间距，因此最大的延长长度为83字节。因此，除了用于存储延长长度的开销（对于最大为83的数字，需要占用7比特的空间）之外，还剩下1个比特位来指示该数据报文为需要截断的延长数据报文。

图2:数据报文延长机制

如图2所示，在2个字节长的以太类型中，我们选择以太类型字段的第一个字节来存储上述8比特的信息，其中第四位指示是否应裁剪该数据报文，第四位为1则表示该数据报文是延长数据报文，因为根据IANA IEEE 802 Numbers所记录的以太类型[2]，第四位为1的以太类型最为罕见，并且这些以太类型基本都是不被使用的。剩余的7位则合并起来表示数据报文应该被裁剪的长度，即将第1、2、3、5、6、7、8位分别置为1来指示可编程硬件设备需要将数据报文分别截断64字节、32字节、16字节、8字节、4字节、2字节和1字节的长度。通过这7位存储单元，可以标识裁剪0到127字节长度的数据报文，足以达到83字节的要求。数据报文的延长部分在图2中以带有阴影的交叉线表示，其中原始报文以太类型的第一个字节被备份在延长部分的开头。

在P4交换机中处理延长数据报文时，首先会将延长部分中原始以太类型的第一个字节存储在自定义的元数据中，然后调用P4函数pkt.advance()，根据上述7个比特的定义，使数据报文处理指针前移一定的长度以完成裁剪的操作。裁剪操作完成后，元数据中存储的原始以太类型的第一个字节将被恢复写入到其原本的位置，从而将数据报文恢复原样。

1. 试验拓扑

图3展示了我们实验的拓扑，Gap Replayer生成的线速流量通过Intel 82599ES网卡传输到P4交换机的10 Gbps SFP+ 端口，数据报文在P4交换机中被丢弃、截断以及转发。在Gap Handler完成硬件处理后，P4交换机会将所有经过处理的数据报文重定向到QSFP28端口的其中一个通道，该QSFP28端口将通过一条一分四的线缆被分为四个SFP28端口，其中与上述通道相对应的端口将被连接到Mellanox ConnectX-4 Lx网卡，并且使其运行在25 Gbps的速率，从而保证我们有足够的带宽来抓取所有传入的流量。

图3:实验拓扑

2. 评估指标

为了评估和对比GapReplay与其它流量重放工具的准确性，我们在流量重放的实验中主要使用了两个评估指标，分别为累积延迟和数据报文到达时间间隔差值分布。

• 累积延迟：我们指定原流量pcap文件中第个数据报文的时间戳为，重放流量pcap文件中第个数据报文的时间戳为，那么在流量重放时第个数据报文的累积延迟可以表示为。通过观察累积延迟这个评估指标，我们可以比较明显地观测到重放延迟的变化趋势，从而评估流量重放工具的准确性。

• 数据报文到达时间间隔差值分布 ： 我们指定与的定义与累积延迟中相同，则重放流量与原始流量在第个数据报文处到达时间间隔之间的差值可以用来表达。我们使用该评估指标来提供清晰的数据报文到达时间间隔差值的分布图，从而评估各个流量重放工具的精度。

3. 试验结果

在实验中，我们将GapReplay与另外两个流量重放工具进行了比较，分别为tcpreplay和MoonGen。虽然MoonGen是作为一个流量生成工具被研究和开发的，但由于其脚本化的特点，可以通过编写流量重放的脚本将MoonGen用于流量重放的目的。但MoonGen作者仅提供了一个基于其软件速率控制机制的示例流量重放脚本，没有用到其硬件速率控制的功能，因此我们实现了另一个基于其硬件速率控制机制的流量重放脚本，并在实验中同时运用这两个脚本进行实验、对比与评估。

实验结果如图4、图5以及图6所示。图4展示了四种场景下的累积延迟，图5对比了四种场景下数据报文到达时间间隔差值的分布，而图6则详细绘制了GapReplay的数据报文到达时间间隔差值的分布图。从这几个图中，我们可以得出下面两个结论：

1. GapReplay实现了最佳的准确度：从图4中可以看出，GapReplay的累积延迟最低，大概在60纳秒左右，实现了最佳的准确度。与之对比，MoonGen基于软件速率控制机制的脚本的累积延迟大约为400微秒，MoonGen基于硬件速率控制机制的脚本的累积延迟为16毫秒上下，而tcpreplay的累积延迟更是达到了1秒以上，与GapReplay都是数量级上的差异，流量重放的准确度相比于GapReplay差了很多。

2. GapReplay实现了最佳的精度 ：从箱形图图5可以看出，GapReplay的数据报文到达时间间隔差值的分布最为集中，实现了最佳的精度，并且在详细分布图图6中可知，该差值的范围也仅为纳秒，进一步印证了其最佳的准确度。相比之下，其它三种场景的数据报文到达时间间隔差值的分布就十分分散，并且有非常多的离散值，表明其流量重放的精度明显差于GapReplay。

图4:累积延迟对比

图5:数据报文到达时间间隔差值分布对比

图6：GapReplay数据报文到达时间间隔差值详细分布图

我们提出了GapReplay——一种高精度的流量重放工具，可以重复性地重放pcap文件。评估结果表明，与其它工具相比，GapReplay重放的数据包的IAT更接近原始数据包。未来，我们计划将GapReplay扩展到更多的平台，比如NetFPGA^[3]和其它的可编程硬件，以进一步提高重放流量的准确性，并将GapReplay扩展到100 Gbps的场景以提高吞吐量。

参考文献