Online Internet Traffic Monitoring System Using Spark Streaming 基于Spark Streaming的在线网络交通监管系统

基于Spark Streaming的在线网络交通监管系统

摘要

​ 由于爆炸增长的网络流量数据，网络管理者必须能够监管整个网络的状况并高效地管理网络资源。传统的网络分析方法通常是单机执行，而这种方式因其较差的计算能力不再适用于大规模的流量数据。大数据框架例如Hadoop和Spark可以处理大规模的网络数据。然而，Hadoop和Spark本是为离线数据而设计的。为了应对流式数据，许多流处理框架被提出，例如Storm，Flink和Spark Streaming。在这篇论文的研究中，我们基于Spark Streaming提出一个在线网络流量监管系统。该系统包括三部分，即收集器，消息系统和流处理器。我们考虑使用TCP性能监管作为特殊用例来展现我们的系统在网络监管方面的性能表现。我们使用standalone模式的集群进行典型试验，该实验表明了我们的系统在大规模流量处理和监管上表现很好。

1 介绍 Introduction

​ 为了为不断变化的网络空间提供一个安全且高性能的网络环境，网络监管者需要实时监管和分析网络的状况。然而，由于如此巨大的网络规模以及如此大规模的流量需要处理，所以这对监管者来说是一个大挑战。根据Cisco的最新调查，在2016年每年全球的IP流量高达1.2 ZB，并预测在2021年将要达到3.3 ZB。高速增长的流量体量对于传统网络监管平台来说已经成为一个巨大的挑战。

​ 传统上，网络流量管理和分析通常由一个高性能的中央服务器来执行。然而，由于计算能力的局限性，中央服务器无法在短时间内处理大体量的数据。如今，这使得他们无法适应今天的大规模网络流量。例如，当DDos网络攻击发生的时候，为了处理大规模的网络流量需要一个监管系统，而这对于一台单节点服务器来说是相当艰难的。许多监管方法采用数据包采样的方法减少数据输入量。但是，这会产生一个不正确的结果。而且，一旦单节点服务器宕机，我们无法在不影响正在进行的任务的情况下快速恢复。

​ 在本文中，我们基于Spark Streaming提出了一个在线网络流量监管系统，该系统是一个大数据平台，可以高效地处理大规模的流量数据从而可以实时监管网络状态，并且系统鲁棒性足够强大可以在不打扰整体监管程序的情况下经受宕机。

​ 大数据平台，例如Hadoop和Spark提供了一个高效地处理大规模数据的方式。例如，MapReduce模型及其开源版本由于其简单性和易编程性已经被大数据分析社区广泛接受。但是，Hadoop的中间数据被存储在磁盘中（这使得其IO性能较差）；因此，对于需要多次迭代的算法来说这种做法会导致性能急剧下降。为了提高Hadoop的性能，内存中的计算方法被提出，例如Apache Spark。Spark的中间数据被存储在弹性分布式数据集（ Resilient Distributed Datasets ，RDD）中，该数据集存储在内存中；因此，与Hadoop相比数据处理速度快得多。

​ 一些在线流量监管系统使用了大数据平台来提高其效率。然而，只有极少数的关于在线网络监管方面的研究。

​ Hadoop和Spark都是基于批处理的，这种方式适合离线数据分析。批处理被应用于处理大数据集，为了提高效率这些操作可以应用于多种可以被batch的数据。批处理要求输入数据在计算开始时易于获取从而所有的数据可以被同时处理。在线网络流量监管与流式分析问题类似，这些输入数据是一个无边界的数据序列。尽管MapReduce不支持流式处理，但它可以使用微批（micro-batching）技术来部分地解决数据流。通过这种方式流被看成是一系列的小批量数据块。在短时间间隔中，输入的数据流被打包成一个数据块并且被送至批系统中处理。比如，Spark提供了Spark Streaming库来支持这项技术。并且，也有其他平台天生设计就是为了处理大数据流，比如Apache Storm和S4，在这些平台中数据在多个计算节点中被处理。每个节点可以处理一个或多个数据流并且生成一系列的输出流。数据在他们到达的时候就被处理。

​ 网络流量分析和监管可以被认为是一个处理一段时间段内的数据包的统计学问题。因此，微簇（micro-batching）对于网络监管系统来说应该是一个更好的选择。在本篇论文中，我们提出了一个基于Spark Streaming的在线网络流量监管系统。该系统可以用于数据流量性能分析，例如TCP性能。

• 我们这篇文章的贡献如下：
• 我们为在线网络流量处理和监管系统设计了分布式架构。
• 我们为监管TCP性能参数（例如延迟和极短延迟重传率）设计了并行算法。
• 我们进行了经典实验，这些实验表明本次提出的系统是可行、高效的。

​ 本研究的其余部分组织如下。在第二部分，我们介绍了实时网络监管的各种相关工作。在第三部分，我们介绍了本次提出的系统的架构并且介绍了我们所使用的相关工具。在第四部分，我们将TCP性能分析作为我们的系统如何通过流式处理解决网络监管问题的案例。在第五部分，我们评估了本次提出的系统的性能并展示了实验结果。最后，我们在第六章对本次研究做了总结。

2 相关工作 Related Work

​ 网络空间是动态且容易受到攻击的。因此，它要求网络服务提供者实时地监管网络的状态。在线网络流量监管技术已经被广泛研究。在1999年，Paxson提出了可以实时发现网络入侵者的Bro系统。Bro系统首先通过libpcap来捕捉一个数据包，然后通过一个事件引擎来减少数据流进入一系列更高级事件。他们也提供了一个定制的脚本语言Bro Scripts，该脚本语言可以通过策略脚本编译器的编译来处理事件。尽管Bro语言是单线程的，它依然可以在高吞吐量的集群环境中设置。类似的研究包括Snort和Suricata，他们本质上都是基于单机计算设计的。

​ 我们基于Spark的在线流量监管系统包含了大量相关研究。Gupta 等人使用Spark Streaming分析实时网络。他们提出的三个网络监管应用可以表示成流分析问题；即反射攻击监管，应用性能分析，和端口扫描检测。他们利用可编程交换机，例如OpenFlow交换机，来提取所需的流量，这一步骤减少了需要处理的数据量。然而，他们的系统没有可编程交换机就不能用了。在本次研究中，我们提出的网络流量监管和处理系统可以在有可编程交换机和无可编程交换机两种情况下使用。Karimi等人基于Spark为实时入侵检测系统提出了分布式网络流量特征抽取方法。他们使用收集器组件（collector component）从交换机捕捉数据包并从包头中抽取需要的信息。这些数据包头被写入CSV文件并且以时间窗口为单位分类。接下来，Spark程序会在小到接近实时级别的时间窗口中定期读取CSV文件中的数据。但是，定期的读写文件操作减少了Spark作为在线网络流量监管系统的性能。我们本次提出的系统使用Spark Streaming直接对数据流做处理从而实现高效率。

3 在线网络流量监管系统的架构 Architecture of the Online Internet Traffic Monitoring System

​ 如图1所展示的，本文所提出的监管系统包括三个组件，即收集器，消息系统，和流处理器。收集器是用于从网络中收集数据包的设备。它使用端口镜像来捕捉所有出入站的数据包。为了能从多个交换机（switches）中捕捉数据包，可以在系统中设置多个收集器。流处理器是我们系统的核心组件，它可以处理从收集器中转来的输入数据。首先，收集器对捕捉到的数据包做处理并且只向流处理器发送必要的协议头数据，从而减少了输入数据量。而且，我们使用了消息系统作为中间桥梁来实现数据从收集器到流处理器的传输。

​ 图1 本文所提出的在线监管系统架构图

3.1 收集器 Collector

​ 为了实现收集器组件，我们使用了Jpcap，Jpcap是一个开源的Java库，可以捕捉数据包并高效地从数据包中抽取出所需部分例如时间戳和TCP片段数。为了减少捕捉到的数据包数量，我们为Jpcap设计了一系列的过滤器（协议，目标IP地址等）从而它可以只捕捉我们感兴趣的数据包。

3.2 消息系统 Messaging system

​ 我们的消息系统是在Kafka基础上设计的。Kafka是一个记录流的高性能分布式消息系统。收集器将符合要求的数据包包头数据作为消息通过相同的topic发布至Kafka。然后，流处理器订阅topic并消费从Kafka发送来的消息流。

3.3 流处理器 Stream processor

​ 流处理器组件是一个运行着Spark Streaming的集群。它负责处理从收集器收集来的数据包信息并将监管结果展示给操作者。这类似于批处理的Spark程序，Spark程序的处理逻辑通过RDD的转换来表达。而Spark Streaming的逻辑通过DStream（Discretized Stream）来表达，DStream的内部是一系列的RDD和转换操作。Spark Streaming提供了许多转换接口（APIs），例如flapMap()算子可以将源DStream中的每个输入项映射到0或者更多输出项，而groupByKey()算子可以通过他们的键将键值对组合在一起。一些有用的操作接口被列在了表1中。

​ 表1 许多有用的Spark Streaming转换操作接口

4 TCP性能监测CP Performance Monitoring

​ TCP是一个被广泛应用的网络协议。在本文研究中，我们将关注TCP性能监测。其他协议的性能监测问题可以使用相似的方法处理。我们使用本文提出的系统来计算TCP片段吞吐量，平均往返时间（Round-Trip Time，RTT），重传率以及实时网络交通流的无序率（out-of-order ratio）。

4.1 参数 Metrics

4.1.1 吞吐量 Throughput

​ 本系统每秒可以处理的数据总数和TCP片段长度。

4.1.2 重传和无序 Retransmission and out-of-order

​ TCP提供了数据的有序传送。每个片段的协议头包含了序列号（SEQ），序列号标志了本片段所处的位置。当TCP连接成功，连接双方的发送者和接受者都被分配一个初始序列号。片段中的实际序列号与初始序列号之间的偏移量被称为相对序列号，代表发送者在发送本片段之前需要发送的字节数。

​ 从序列号和和一个片段的负载（数据长度），我们可以计算下一个序列号，下一个序列号就是从主机发送来的下一个片段的序列号。对于不是SYN/FIN的普通TCP数据片下一个期望序列号应该等于当前序列号和数据长度之和。但是，对于SYN/FIN片段，下一个期望序列号应该等于前一个期望序列号加1，因为SYN/FIN也作为数据的一部分要发送给接受者。

​ 在普通TCP连接中，带有SYN/FIN的序列号或者片段包含的数据不应当比上一个片段的期望序列号的最小值少。否则，就必须是重传或无序的片段。重传意味着该片段被认为丢失，需要发送者重新发送；无序意味着该片段该片段没有按照发送的顺序到达接收者。事实上，在某些情况下是很难区分该片段是重传还是无序的。我们使用一个简单的假设来判断一个片段是否是无序片段。也就是说，如果该片段的时间戳非常接近（在3毫秒以内）下一期望序列号的最大值片段的时间戳，我们就认为这个片段是一个无序片段。高重传率和高无序率将会导致网络性能下降，并代表了传输路径的问题；因此，这两个参数在TCP性能监测中非常重要。

​ 此外，我们也在重传和无序检测中考虑了意外；即持久连接（keep-alive）。一个TCP的持久连接片段是一个确认段（ACK），该确认段的序列号被设置为比期望序列号少1并且用0或1字节表示数据长度。持久连接通常被用来确认与远程主机的连接是否可用。尽管它需要携带1字节的数据但不推进序列号，它不是重传或无序片段。一个典型的TCP持久连接在图2中展示。

​ 图2 典型TCP持久连接

4.1.3 往返时间 RTT

​ RTT是网络通信从起点到终点并返回所需要的时间。在TCP中，当接收者成功接受一个片段，接收者会回送一个包含ACK号的响应片段。前一个TCP片段和它的ACK之间的延迟可以用来计算RTT。这是一个不单可以反映网络质量也可以反映服务器响应时间的重要网络参数。ACK号可以告诉发送者有多少字节成功被接收者接收，ACK号应该等于接收到的TCP片段的下一期望序列号。换句话说，除了点到IP地址/端口，TCP片段和对应的ACK片段应该同时满足：
$$序列号+数据长度（在TCP片段中）=ACK号（在ACK片段中）(1)$$
​ 尤其对于SYN/FIN片段：
$$序列号+数据长度+1（在TCP片段中）=ACK号（在ACK片段中）(2)$$
​ 我们使用（1）和（2）的关系式在包列表中找对应的TCP和ACK片段。RTT通过二者的时间差来计算。然而，如果TCP通信中有重传，问题就会变得复杂，比如当一个重传片段的ACK被接收，我们无法判断ACK对应的是重传片段还是原始片段。即便我们认为该片段已经丢失并重传它，丢失的片段仍然可能经过长时间后最终到达或者丢失的片段在ACK发送至接收者之前到达。这被称为确认歧义（acknowledgment ambiguity）。在我们的算法中，我们选择用原始片段去计算RTT。尽管它可能不是真实的RTT，但我们认为它比真实的RTT更有意义，因为通过发送者发送片段到知晓接收者成功接收到片段的时间差可以计算出延迟。

4.2 基于本文提出的系统做TCP性能监测 TCP performance monitoring with the proposed system

TCP性能分析被分解成五步，即预处理，吞吐量计算，重传与无序统计，RTT计算和加和。

4.2.1 预处理 Preprocessing

​ 我们设置多个收集器从网络中做只针对TCP片段的收集。Spark Streaming通过sockets从这些片段中获取头信息。每个片段的信息被格式化成字符串类型，格式化的信息包括时间戳（被分割成高低两部分），源IP，源端口，目的IP，目的端口，SYN/FIN标志位，ACK标志位，序列号，ACK号，数据长度，和包长度。我们将这些信息作为输入流DStream0。

​ 输入流数据预处理要求从片段中抽取出下一阶段需要用于计算和展示的信息。我们将每个输入数据映射成元组tuple(时间戳，源IP，源端口，目的IP，目的端口，SYN/FIN值，ACK，序列号，确认号，下一期望序列号，数据长度，包长度)。对于不是SYN/FIN且不携带数据的片段，下一期望序列号就是他的序列号。这些元组被存储在DStream1。

4.2.2 吞吐量计算 Throughput calculation

​ 通过Spark Streaming是非常容易计算吞吐量的。首先，我们将DStream1中的每个元组转换成一个键值对，(源IP，目的IP)作为键，(包长度，1)作为值。接下来，我们使用reduceByKey算子将相同键的值做累加。最后，我们得到了从每个源IP地址到对应的目的IP地址下的所有包的总长度和包的数目，并将其保存在DStream2中。

4.2.3 重传和无序的统计 Retransmission and out-of-order statistics

​ 我们计算重传和无序的数量。首先，我们将DStream1中的元组映射成键值对，(源IP，源端口，目的IP，目的端口)作为键，(SYN/FIN标志位，序列号，数据长度，下一期望序列号，时间戳)作为值。我们将相同的键对应的键值对聚合，并得到了一系列具有相同源IP，源端口，目的IP，目的端口的片段。然后我们可以通过算法1去计算每个列表中的片段的重传和无序片段。我们只能计算重传和SYN/FIN片段或者携带数据的片段。

​ 我们为每个列表生成了新的键值对。元组(源IP，目的IP)作为键，元组(重传片段数，无序片段数)作为值。因为每个列表值包含了从源IP/端口到目的IP/端口的片段，生成的键值对仅包含了特定IP/端口之间的片段的统计信息。因此我们使用reduceByKey()对所有拥有相同源IP、目的IP的键值对做聚合，并计算出他们的总数。这个结果存储在DStream3中。

​ 算法1 计算每个片段列表的统计信息

4.2.4 RTT计算 RTT calculation

​ 通过TCP和ACK对的关系，如果我们使用元组(源IP地址，源端口，目的IP地址，目的端口，下一期望序列号)作为TCP片段的键，元组(目的IP地址，目的端口，源IP地址，源端口，确认值)作为ACK片段的键，那么TCP片段和对应的ACK片段应该共享同样的键。因此，我们可以在Spark Streaming中使用groupByKey()算子将TCP片段和对应的ACK片段聚合起来，并且为每个TCP片段并行计算RTT。

​ 首先，我们将每个DStream1中的片段映射成若干键值对。如果是SYN/FIN片段或有数据的片段，我们生成一个键值对，键值对的键是元组(源IP地址，源端口，目的IP地址，目的端口，下一期望序列号)，值是元组(时间戳，true[表示该片段是数据片段])。若是ACK标志位为true的片段，我们生成的键值对，键是元组(目的IP地址，目的端口，源IP地址，源端口，确认值)，值是元组(时间戳，false[表示该片段是ACK片段])。注意ACK片段也可以携带数据（piggyback），而一个片段不是数据片段就是ACK/FIN/SYN片段，所以每个片段可以通过他们的类型最终生成0，1或2个对。因为前一个TCP片段是从发送者到接收者的，并且ACK片段是从接收者到发送者的，键值对的键分别是元组(发送者IP地址，发送者端口，接收者IP地址，接收者端口，下一期望序列号)和元组(发送者IP地址，发送者端口，接收者IP地址，接收者端口，确认号)。

​ 我们使用groupByKey()来将键值对化的TCP/ACK片段组合进相同的列表里。然后，我们使用算法2来计算每个片段的RTT。

​ 算法2 从键值对化的TCP/ACK列表中计算RTTs

​ 我们为每个发送者和接收者的IP/端口对生成键值对集合，键值对是元组(发送者IP地址，接收者IP地址)，值是元组(RTT，1)。然后我们使用reduceByKey()将相同键的值加和，每个IP对包括(总RTT，总次数)，并且使用mapValues来计算平均RTT，将其保存在DStream4中。

4.2.5 加和 Sum up

​ 在步骤2，3和4中，我们得到了数据包数，总长度，重传数，无序统计，每个源IP/端口到目的IP/端口的RTT并将这些数据分别保存在DStream2，DStream3和DStream4中，所以我们可以使用join()方法将这些结果都汇合到一个流中。

​ 为了将Spark Streaming的计算结果表现出来，我们开发了一个图形用户接口来展示指定源IP到目的IP的被监听网络的性能参数的折线图。

5 实验结果 Experimental Result

我们使用Amazon Web Services的八个服务器来实现所提到的TCP性能测量系统。这些服务器的配置在表2可以看到。架构细节在图3中。

​ 表2 每个组件的配置

​ 图3 系统架构

​ 目前，在实验环境中收集器只能捕捉单个电脑的数据包。批处理间隔设置为1秒，这意味着Spark Streaming每1秒钟会开始一个计算并且在这个时间间隔内的所有片段的信息将会作为一个批处理任务被收集并处理。

​ 我们提出的系统实时地为每个源和目的IP对监控数据包速率（packet/s），吞吐量（byte/s），平均RTT（ms），重传比率（%）和无序比率（%）。图4展示了被我们的系统监控的网络性能。网络性能的参数通过折线图表现出来从而网络的状况可以被清楚地监控。

​ 我们从时间成本和鲁棒性两个角度来分析所提出的TCP监听系统的性能。

​ 图4 通过我们的系统计算网络性能

5.1 时间成本 Time cost

​ 我们开发了一个特殊的收集器来评估我们系统的性能。与传统的收集器从互联网上实时地捕捉数据包不同，这个特殊的收集器从一个大数据包捕获文件中读取数据包记录。

​ 图5展示了我们的流处理器的性能统计。在本次实验中，输入流的平均速度大约是75000条记录/秒。我们发现我们所提出的系统处理输入流的速度非常快。因为我们设置批处理时间间隔为1秒，若批处理任务可以在这个时间间隔内处理完成，我们的系统将会是稳定的。我们发现平均总延迟是621毫秒，这个延迟是在1秒的间隔之内的。因此，我们的系统可以处理如此高速度（75000条记录/秒）的输入流。

​ 我们提高了数据包流速并且发现系统可以处理近150000数据包每秒。

图5 在Spark UI中流处理器的性能统计，处理时间是指一个批次处理所有job所需要的实践，调度延迟是指将 job从scheduler传输到executor所需要的时间。

5.2 鲁棒性 Robustness

​ 传统的网络监视系统运行在单节点服务器中并且当服务器崩溃时终止。在Spark的standalone模式下的集群，作业（jobs）会被分发至多台从节点并在从节点中完成。当其中一个从节点崩溃，其他从节点会继续崩溃节点接下来的工作而不会中断整个处理流程。

我们进行了一个典型实验来研究我们系统的鲁棒性。我们在程序运行时手动地关闭一个从节点并重启它。系统状态在图6中展示。当从节点崩溃，它的任务被重新传输至其他从节点，并且我们可以在调度延迟和处理时间中观察到一个抖动。主节点必须在节点恢复后将作业重传到节点中。所以，在调度延迟中也有一个抖动。尽管从节点的崩溃和恢复会影响系统的性能，系统非常快就恢复正常状态并且整个作业没有被终止。这个实验的结果表示系统是鲁棒的。

​ 图6 当一个从节点崩溃时系统性能变化

6 结论和接下来的工作 Conclusion and Future Work

​ 随着网络流量的增长，传统在单机工作的网络分析方法不再适用。现有方法利用大数据框架来提高处理效率。然而这些方法主要关注于离线数据分析。在本次研究中，我们利用Spark Streaming提出了一个在线网络流量监管系统。我们论证了网络测量和监管可以看成一个流式分析问题并且可以通过流式处理平台来解决。广泛的实验结果表明我们的系统具有很好的性能和鲁棒性。

​ 在未来，我们将实现可以通过端口监听从交换机中获取数据包的收集器，从而我们的系统可以分析所有经过被监听网络的流量。最后，我们会测试收集器的实际性能并与一些传统的单节点服务器系统在可拓展性和可靠性方面做比较。

致谢

部分工作受到日本科学促进会科研补助金（JSPS），青海省联合研究基金(No. 2016-HZ-804)和日本NII研究合作基金的支持。

结果表明我们的系统具有很好的性能和鲁棒性。

​ 在未来，我们将实现可以通过端口监听从交换机中获取数据包的收集器，从而我们的系统可以分析所有经过被监听网络的流量。最后，我们会测试收集器的实际性能并与一些传统的单节点服务器系统在可拓展性和可靠性方面做比较。

致谢

部分工作受到日本科学促进会科研补助金（JSPS），青海省联合研究基金(No. 2016-HZ-804)和日本NII研究合作基金的支持。