【研究型论文】MAppGraph: Mobile-App Classification on Encrypted Network Traffic using Deep GNN

MAppGraph: Mobile-App Classification on Encrypted Network Traffic using Deep Graph Convolution Neural Networks

中文题目：MAppGraph：使用深度图卷积神经网络对加密网络流量的移动应用程序分类
发表会议：Annual Computer Security Applications Conference
发表年份：2021-12-06
作者：Thai-Dien Pham，Thien-Lac Ho，Tram Truong-Huu，Tien-Dung Cao，Hong-Linh Truong
latex引用：

@inproceedings{pham2021mappgraph,
  title={Mappgraph: Mobile-app classification on encrypted network traffic using deep graph convolution neural networks},
  author={Pham, Thai-Dien and Ho, Thien-Lac and Truong-Huu, Tram and Cao, Tien-Dung and Truong, Hong-Linh},
  booktitle={Annual Computer Security Applications Conference},
  pages={1025--1038},
  year={2021}
}

摘要

基于网络流量识别移动应用程序对于安全和网络管理有多种好处。然而，由于多种原因，这是一项具有挑战性的任务。

首先，使用端到端加密机制对网络流量进行加密，以保护数据隐私。
其次，用户在使用移动应用程序的不同功能时，行为是动态变化的。
第三，由于现代移动应用程序中普遍存在共享库和内容交付，因此很难区分流量行为。

现有的技术设法解决了加密问题，但没有解决其他问题，因此实现了低检测/分类精度。在本文中，我们提出了一种新的移动应用程序分类技术MAppGraph，解决了上述所有问题。对于移动应用产生的一大块网络流量，MAppGraph构造一个通信图，其节点由该应用连接的服务的IP地址和端口元组定义，节点之间的加权通信相关性建立边。我们在不分析加密有效载荷的情况下，从数据包头部提取信息，形成节点的特征向量。我们利用深度图卷积神经网络，从大量图中学习移动应用程序的各种通信行为，并实现快速分类。为了验证我们的技术，我们在Android平台上收集了100个移动应用程序的流量，并在各种实验场景下进行了广泛的实验。实验结果表明，与最近开发的技术相比，MAppGraph在各种指标上的分类精度显著提高了20%，并证明了其在移动业务安全和网络管理方面的实用性。

存在的问题

1. 超过80%的移动流量是加密的或采用传输层安全(TLS)，因此可能不可能使用基于有效载荷的方法来分析应用层协议的某些领域。
2. 基于端口的分类方法无法对移动流量进行分类。因为应用程序主要使用HTTPS传输数据，并使用XML或JSON等文本格式来回发送数据。有些信息，如文件数量或文件大小，无法进行网页分类。
3. 用户行为随着时间的推移而动态变化，这取决于所使用的功能。一个移动应用在短时间内（例如5分钟）捕获的流量可能并不代表其完整的流量行为。
4. 为了优化性能，现代移动应用程序的设计和开发使用共享相同库的微服务，并使用内容分发网络(cdn)和第三方服务[50]。这使得它们的TCP流非常相似，从而导致应用程序更难识别。对于这样的应用程序，使用域名解析或IP地址查找来进行应用程序分类可能没有用处。况且，如果使用本地缓存，可能根本观察不到DNS和TLS交换。

需求：

需要一种具有以下三种性质的流量分类方法：

1. 可以处理加密流量
2. 能够意识到移动应用程序的不同功能
3. 共享第三方服务

现有工作提出的方法大多具备了第一个性质，但是其他性质通常并不具备。

论文贡献

1. 开发了一种处理网络流量的方法，并生成具有节点特征和边缘权重的图形，从而更好地代表移动应用程序的通信行为。
2. 开发了一个DGCNN模型，能够从大量的图中学习移动应用程序的流量行为，并实现快速的移动应用程序分类。
3. 收集了101个移动应用程序的流量，并进行了大量的实验来证明MAppGraph的有效性。
4. 增强了AppScanner和FlowPrint，并将其作为与MAppGraph性能比较的基线。

论文解决上述问题的方法：

1. 只从包头中提取包大小、包到达间时间等信息，并推导出统计特征，作为图节点的属性来表示应用程序和服务之间通信的流量行为。而没有提取数据包的有效载荷。
2. 在不同的时间收集移动应用程序的网络流量，导致每个应用程序需要处理大量的网络流量。每个流量块(例如，在5分钟内)形成一个通信图。在收集了大量的流量数据后，一个移动应用程序会有一组图，每个图代表不同时刻的流量行为。通过这一大组图学习或识别每个移动应用程序的指纹。

论文的任务：

对应用程序进行多分类。（这是一个graph-level的图神经网络分类问题）

1. 流量收集

假设网络运营商允许使用可用的网络监控工具[20]来收集移动流量，该工具可以在不干扰应用程序功能的情况下捕获流量。由于我们的技术不需要有效载荷，它可以被丢弃来减少所需存储空间。

为了给分类器准备训练数据集，需要收集和处理大量的流量。虽然这项任务可以以离线方式完成，但推理阶段需要实时完成，以便对移动应用程序的异常行为做出反应。推理阶段收集的流量样本经过分类器分析后，还可以丢弃或存储，以丰富训练数据集。

2. 流量行为图的构建

• 图的构造

  移动应用程序的网络流量是通过预定义的时间窗口捕获的（记为$T_{window}$，比如5分钟），时间窗口越长，所捕捉到的流量就越多，应用行为也就越多样。显然，时间窗口越长，应用程序被分类所需的时间就越长。这可能会影响网络或移动服务平台的安全，因为应用程序可能会表现出需要尽快检测的恶意行为。

  节点的构造：

  • 以IP地址作为节点：
    缺点：

  

  • 会使得所有的图形都是星型的，其中应用程序所在的设备IP地址是连接到所有其余节点（各种服务）的中心节点。如上图所示。
  • 由于移动应用程序共享第三方服务，许多应用程序的星状图将在相同数量的节点下相似。

  为了克服这个问题，并产生一个更好的图形表示移动应用程序的流量行为，我们通过目的IP地址和应用程序连接的服务的端口号的元组定义一个图节点。

  • 以（目的IP，目的端口）二元组作为节点：
    优点：

  • 多个第三方服务可能部署在同一台服务器（即同一IP地址）下，但端口号不同。例如，SMTP电子邮件和DNS服务的IP地址相同，端口号不同（安全电子邮件为587,DNS为53）。
  • 同个第三方服务通常部署在多个服务器上（不同的IP地址），以提供负载均衡。来自移动应用程序的请求将根据其负载分配到特定的服务。因此，对目的IP地址使用基于规则的分类方法可能效果不佳（因为虽然IP不同，但是提供的功能一致）。但这种情况下，端口号不变，涉及到的节点数量不变。

  边的构造：

  1. 构造时间切片

  给定在时间窗口中捕获的流量，时间窗口进一步划分为多个具有预定义的切片持续时间的切片（记为$t_{slice}$，比如10秒钟）。用 $T$ 表示该时间窗口中切片的数量

  2. 构造边

  在每个切片期间，如果移动应用程序向部署在目的IP地址和端口号上的服务发送或接收了至少一个流量数据包，我们就认为该服务节点是活跃的。用 $a_i(t)$表示在时间切片 $t$ 上第 $i$ 个节点是否活跃。具体如下：$$a_i(t)=\{\begin{array}{l}1,节点i是活跃的\\ 0,节点i是非活跃的\end{array}$$

  3. 构造节点之间的边的权重

  节点 $i$ 和节点 $j$ 在这 $T$ 个时间切片的权重表示为：$$C_{i,j}=\sum _{t=1}^T{a}_i(t)\cdot a_j(t)$$ 为了避免在将图送到DCGNN进行训练和预测时的特征偏差，我们使用min-max方法将权值归一化到[0,1]范围内

  利用上面的图构造技术，我们用Facebook和Spotify的三个例子图实现了移动应用程序传播行为的图表示，如图3所示。两个节点之间的边的厚度表示了边的权值（即节点之间的互相关）。
  

• 节点特征提取

  由于移动应用程序连接到各种服务，每个服务都由图中的节点表示为IP地址和端口的元组，因此从移动设备到每个服务的服务器的流量行为可能在各种流量特征（如数据包大小、数据包数量、流量持续时间等）方面有所不同。为了将我们的技术（MAppGraph）推广到加密和未加密的流量，我们只从数据包头部提取信息，而不分析数据包有效负载。除了数据包特征，我们还考虑流特征，如流的数量，每个流中的平均数据包数和平均流大小（以字节为单位）。

  在这项工作中，我们只考虑TCP和UDP流，并依赖于Wireshark来收集流量特征。在实际场景中，需要使用在线流量特征提取工具(如[43])对流量流进行动态处理。

  收集到的特征如下：

  • Aggregated features（聚合特征）：这些特征是在流量捕获的时间窗口（例如5分钟）内以基本特征的总和、总数、最大值和最小值计算出来的特征。其中包括数据包总数、字节总数和流总数。
  • Temporal features（时间特征）：时间特征包括流持续时间、流持续时间的均值和标准差。
  • Statistical features（统计特征）：在流量捕获的时间窗口内(例如，5分钟)，数据包大小（以字节为单位）的平均值，中位数绝对偏差(MAD)，方差，偏度，峰度和标准偏差（在短期内）、数据包数量、字节数、流量大小（以字节为单位）。我们分离传入和传出的数据包，并在聚合它们之前提取特征，以提供更多的统计特征。
  • Categorical features（分类特征）：包括传输协议和IP地址等分类特性。但在提供给MAppGraph之前，需要对其进行分解。每个IP地址被分解并归一化为4个特征，每个特征代表地址的一个组成部分。例如，IP地址223.12.45.68被分解为4个特征（223/255,12/255,45/255,68/255）
    

总结：

图的构建：

节点构建：以（目的ip，目的端口）来构造节点。每个节点具有63个特征
边构建：$C_{i,j}={\sum }_{t=1}^T{a}_i(t)\cdot a_j(t)$

这样一来，在一个图中，如果一个应用程序（IP相同）使用了多种服务（即多个不同的端口），那么这个图中就会生成多个该应用程序的节点，这样就避免了单节点的星型拓扑结构。

3. MAppGraph模型

模型总结（基于PyG 和 pytorch）：

• 输入层：

输入：[x, number_features] ,x==batch_size*node_num

• 隐藏层：

• Graphconv1层：

输入：[x, number_features（63）] ,x==batch_size*node_num
输出：[x, hidden_channels（1024）] ,x==batch_size*node_num

• Graphconv2层：

输入：[x, hidden_channels（1024）] ,x==batch_size*node_num
输出：[x, hidden_channels（1024）] ,x==batch_size*node_num

• Graphconv3层：

输入：[x, hidden_channels（1024）] ,x==batch_size*node_num
输出：[x, hidden_channels（1024）] ,x==batch_size*node_num

• Graphconv4层：

输入：[x, hidden_channels（1024）] ,x==batch_size*node_num
输出：[x, hidden_channels1（512）] ,x==batch_size*node_num

• concat层（对上面四层的结果进行按列concat）：

输出：[x, hidden_channels2（1024+1024+1024+512）] ,x==batch_size*node_num

• sortpooling层：

输入：[x, hidden_channels2（1024+1024+1024+512）] ,x==batch_size*node_num
输出：[batch_size, hidden_channels2（1024+1024+1024+512）]

• reshape层：

输入：[batch_size, hidden_channels2（1024+1024+1024+512）]
输出：[batch_size, 1, hidden_channels2（1024+1024+1024+512）]

• Conv1D层：
  Conv1D(in_channels=1, out_channels=256, kernel_size=1024+1024+1024+512, strides=1024+1024+1024+512)
  output_shape = (input_shape（1024+1024+1024+512） - kernel_size（1024+1024+1024+512） + 2*padding（0）)/stride（1024+1024+1024+512） + 1 = 1

输入：[batch_size, 1, hidden_channels2（1024+1024+1024+512）]
输出：[batch_size, 1, hidden_channels3（256）]

• reshape层：

输入：[batch_size, 1, hidden_channels3（256）]
输出：[batch_size, hidden_channels3（256）]

• MaxPooling层：
  MaxPool1d(kernel_size=2, stride=2)
  output_shape = (input_shape（256） - kernel_size（2） + 2*padding（0）)/stride（2） + 1 = 128

输入：[batch_size, hidden_channels3（256）]
输出：[batch_size, hidden_channels4（128）]

• reshape层：

输入：[batch_size, hidden_channels4（128）]
输出：[batch_size, 1, hidden_channels4（128）]

• Conv1D层：
  Conv1D(in_channels=1, out_channels=512, kernel_size=5, strides=1)
  output_shape = (input_shape（128） - kernel_size（5） + 2*padding（0）)/stride（1） + 1 = 124

输入：[batch_size, 1, hidden_channels4（128）]
输出：[batch_size, 1, hidden_channels5（124）]

• reshape层：

输入：[batch_size, 1, hidden_channels5（124）]
输出：[batch_size, hidden_channels5（124）]

• dense层：

输入：[batch_size, hidden_channels5（124）]
输出：[batch_size, hidden_channels6（1024）]

• dropout层：

• 输出层：

输入：[batch_size, hidden_channels6（1024）]
输出：[batch_size, num_classes（10）]

4. 实验评估

• 数据收集

  由于现有数据集中每个移动应用程序的流量捕获持续时间不够长（最长平均持续时间为339.4秒[44]），无法观察到应用程序的各种行为和各种功能。因此，为了捕捉不同用户行为的流量和移动应用程序的各种功能，我们决定进行自己的流量数据采集。

  我们设法收集了101个手机应用的流量，这些应用在谷歌Play中很受欢迎(通过安装数量证明)。对于每个应用程序，我们故意捕获了存储在PCAP文件中的超过30小时的流量，每个流量都属于一个特定的应用程序。在附录B的表6中，我们展示了我们收集到的所有移动应用程序的流量。

  使用PCAP文件，我们为每个移动应用程序执行图形构造，滑动窗口为$T_{window}=5分钟$（如果没有另行说明）。为了提供更多的图来训练MAppGraph模型，我们将重叠持续时间窗口设置为3分钟。这导致在我们的实验中，每个移动应用程序至少有800个图表。

  在图5中，我们给出了数据预处理图，以及实验和性能比较的工作流程。我们以8:2的比例将这些图随机分为训练集和测试集。
  

• 效果评估指标与模型比较

  评估指标：

  • Precision、 Recall、F1-Score、Accuracy

  模型：

  • MLP：我们将图节点的特征聚合到单个向量中。由于图中节点数量的异质性，我们固定了拥有最多流量包数的节点来构造特征向量。所选节点按照流量报文数降序排列，构成特征向量。选择前 $N$ 个节点。由于我们只使用节点特征，因此在模型中不使用节点之间的相关性。MLP的架构由3个隐藏层组成，每个隐藏层有1024个隐藏节点。在每个密集层之后，在馈送到下一个密集层之前，添加一个批规范化层来规范化数据。我们使用ReLU进行MLP。

  超参数：

  • N：
  • epoch：150
  • 初始learning_rate：0.0001
  • StepLR：每隔10个epoch，学习率衰减为原来的0.9

  • AppScanner[40]：AppScanner[40]是一种基于流量的移动应用程序分类技术，通过分析50分钟的移动应用程序流量捕获，提取流量特征，训练机器学习模型(随机森林和支持向量机)对移动应用程序流量进行分类。作者提取了40个流量特征，这些特征也被用于表1所示的工作中。为了进行公平的比较，我们使用了AppScanner从其website下载的源代码，并使用我们收集的数据运行。如图5所示，每个AppScanner模型对每个应用程序都需要50分钟的流量。对于我们实验中使用的所有应用程序，每个应用程序至少有16个持续时间为50分钟的流量块。因此，我们考虑了16个AppScanner模型来评估性能。除了展示每个单独模型的性能外，我们还使用了朴素投票方案来使用所有16个模型进行分类。对于一个移动应用程序，由最多的模型预测的类别被认为是该应用程序的最终预测。我们在实验中将这种技术称为Enhanced AppScanner。
  • FlowPrint[44]：FlowPrint[44]考虑相互关联来分类或检测移动应用程序。在一个时间窗口内(例如，5分钟)收集的流量中，FlowPrint没有使用机器学习，而是将应用程序指纹定义为“在相关图中形成最大派系的网络目的地的集合”。给出两个指纹，作者使用Jaccard相似性[17]来比较它们之间的相似性。如果相似度大于预定义的阈值，则认为两个指纹属于同一个应用。与AppScanner类似，FlowPrint仅使用5分钟的流量捕获为每个应用创建指纹。在我们的实验中，当流量超过30小时时，我们可以为每个应用创建多达544个5分钟的流量块。如图5所示，我们使用朴素投票方案来确定测试流量样本属于哪个移动应用程序。给出一个测试流量示例，获得的指纹将与从544个流量块中获得的所有预先计算的指纹进行比较。与测试指纹相似的预计算指纹数量最多的移动应用程序将成为最终预测。我们使用了从作者网站上下载的FlowPrint源代码3来运行实验。在实验中，我们也将采用的FlowPrint标记为Enhanced FlowPrint。
  • MAppGraph：可以以脱机方式训练MAppGraph模型。在实际部署中，在生产中使用预训练的模型，同时并行训练另一个模型，以反映移动应用程序行为的任何变化(例如，版本升级或被攻击)。还可以采用增量学习[7]等先进的训练方法，在收集新数据时减少模型的训练时间。为了确保可重复性，我们将每个实验进行多次随机播种。

  超参数

  • epoch：150
  • 初始learning_rate：0.0001
  • StepLR：每隔10个epoch，学习率衰减为原来的0.9

  实验设置：

  • AMD Ryzen Threadripper 2950X 16核处理器@ 3.5GHz, 64 GB RAM和2个Nvidia GeForce RTX 2080Ti gpu，每个gpu有11 GB内存。

• 结果分析

  总体性能比较：
  

  • 有趣的是，与Enhanced AppScanner相比，MLP具有更好的性能。这表明，使用基于流量的检测或分类移动应用程序并不是一个合适的方法，因为现在大多数应用程序都共享相同的第三方服务。这使得移动应用程序和第三方服务服务器之间的流量具有相似的行为，从而在应用程序之间无法区分。尽管MLP不处理节点间有节点和边的图，但我们选择用于隐式训练模型的图节点的方式考虑了移动应用程序和应用程序使用的各种第三方服务之间的通信相关性。
    

  • 有趣的是，使用基于上面讨论的投票方案的Enhanced AppScanner获得的结果与单个模型的性能相比要好得多。表3展示了使用单个模型获得的AppScanner的性能。实验结果表明，在用于训练模型的不同流量块中，AppScanner的单个模型具有稳定的性能（可通过所有性能指标的低标准差证明）。
    与最差和最好的单个模型相比，增强的AppScanner分别显著提高了25%和20%的性能。这说明了当用户使用各种功能时，移动应用流量行为的多样性。

  • 与Enhanced FlowPrint相比，MAppGraph通过构建通信图来考虑应用服务器和第三方服务之间的相互关系，性能提高了7%。这种改进是先进的深度学习技术和考虑移动应用程序的多样化行为相结合的结果。

  • 使用DGCNN(具有多个图卷积层)可以使分类模型从图拓扑和节点属性更好地学习移动应用程序的通信行为。
  • MAppGraph通过在多个图上训练单个DGCNN模型来考虑移动应用程序行为的多样性。

  • 在图6中，我们展示了Enhanced FlowPrint在投票方案中使用的每个应用程序的流量块数量(5分钟)方面的性能。结果表明，当我们将用于推理的每个应用程序的流量块数量从1增加到20时，性能的改善是显著的。
    

  图节点的数量对模型的影响：

  • 取很多节点：
    当取一个很高的 $N$ 值（$N$ 值是按照流量报文数降序排列后所选择的节点数量）或 $k$ 值（$k$ 值是sortpooling时的超参数）时，所有节点较少的图必须对特征向量（在MLP的情况下）或潜在的表示向量（在MAppGraph的情况下）使用零填充。这些零值特征可能会误导模型的学习。

  • 取很少节点：
    使用少量的节点可能会从被丢弃的节点中丢失有用的信息，从而影响模型的性能。

  • 
    根据上图可以看出，大多数图都有大约10个节点。90%的图小于35个节点，86%的图小于30个节点。

  • 
    根据上图可以看出，对于MLP和MAppGraph而言，最优节点个数的选择是不同的。原因可能是MAppGraph需要更多关于图拓扑的信息来区分移动应用程序。

  流量采集时间窗长度对图构造的影响：

  • 使用较短的流量捕获窗口，所需的计算资源就会降低，从而能够在出现安全漏洞时能迅速做出反应。
    
    从上图可以看出，当我们使用较短的流量捕获窗口时，所有技术的性能都会下降。结果表明，当流量捕获时间从5分钟减少到1分钟时，MAppGraph的性能下降了7%。我们认为，与性能损失相比，减少流量捕获持续时间所获得的收益(例如，更快的应用程序分类和检测，所需的存储和计算资源更少)更为显著。在实践中，这个参数可以由网络运营商根据他们想要的性能和目标来配置。

  图构造中切片时间对互相关的影响：

  • 切片持续时间越短，图中的边就越少。切片持续时间越长，图就变得完全连接。原因在于，如果切片时间很短的话，那么该切片内可能单纯只有接收数据包或发送数据包，根据上面的公式，$$C_{i,j}=\sum _{t=1}^T{a}_i(t)\cdot a_j(t)$$只有当两个节点进行了交互（即既接收了对方的数据包，又向对方发送了数据包），乘积才能不为0（即才能相连）
    

  在特征向量中使用和不使用IP地址的性能：

  • 如前所述，由于负载均衡，目标服务的IP地址可能会发生变化。在这个实验中，我们在特征向量中不使用目的地服务的IP地址来训练MAppGraph。在图9中，我们展示了在特征向量中有和没有IP地址的MAppGraph的性能比较。结果表明，不使用IP地址训练MAppGraph时，性能略有下降。
  • 然而，我们相信这种性能是可以接受的，因为在目标服务的不同网络域中部署时，模型不需要重新训练。值得一提的是，不使用IP地址作为特征的MAppGraph的性能仍然明显优于FlowPrint，从而证明了所提技术的有效性。
    

  功能相似的移动应用程序分类：

  • 当应用程序具有相似的功能时，我们评估了MAppGraph的性能。我们创建了2个数据集（SIM-APP和DIFF-APP），每个数据集包含17个应用程序。第一个数据集包括17个与音频和音乐播放器相关的应用程序，如Spotify和SoundCloud，这些应用程序应该具有类似的流量特征，如数据包大小、流量大小等。第二个数据集包括具有不同功能的应用程序。
    
    和预期的一样，SIM-APP的性能比DIFF-APP要低。在具有不同功能的数据集上训练的模型(DIFF-APP)对所有性能指标均达到0.9750。然而，当相似的应用程序出现在数据集中时，性能下降并不显著(即4%)。
    这表明，将应用程序使用的服务之间的相互关联（即边权重）考虑到图中，并结合流量特征（即从数据包头部提取的信息）作为图节点的属性，即使它们具有相似的功能，我们也可以准确地区分移动应用程序。

  不同应用程序数量下的性能：

  • 图11显示的结果显示，随着应用程序数量的增加，这些技术的性能会下降。这是意料之中的，因为应用程序的数量越多，应用程序具有类似行为的可能性就越大。
  • 相比而言，DGCNN模型的性能略有下降，即使在数据集中应用程序数量最多的情况下仍能获得较高的性能。这说明了MAppGraph的有效性。
    

  关于检测看不见/身份不明的应用程序的讨论：

  • 虽然所提出的技术主要适用于移动应用程序的分类问题，但它也可以用于检测不可见或未识别的应用程序。注意，类决策的softmax层(即DGCNN体系结构的输出层)的输出是一个概率，选择概率最高的类。将此概率作为模型的置信度，以决定该流量样本是否属于所选应用程序。
  • 我们可以将置信度与预定义的阈值(例如0.5)进行比较。如果概率小于阈值，则可以确认该应用程序未被看到或未被识别。也可以采用更高级的方法，使用无监督学习方法，如图聚类。这种无监督学习方法不需要大量的标记数据集，从而将我们从数据标记的工作中解放出来。我们把它作为我们未来的工作。

总结

论文内容

1. 学到的方法

   理论上的方法：

   1. 学到了一种构造边权重的方法。对某个应用收集一段时间的流量，记为$T_{windows}$。然后对这段时间进行进一步切片，每段时间用 $t_{slice}$ 表示，共 $T$ 段时间。对于每个 $t_{slice}$ 而言，若两个节点之间存在数据包交换（即既有接收又有发送数据包），则将这两个节点在这个$t_{slice}$时间段的权值设为1，否则设为0。最后在整个$T_{windows}$时间段内，这两个节点的边权重为所有$t_{slice}$时间段的权值之和。
   2. 大概清楚了当前实际场景中流量交互的模式。

   • 多个第三方服务可能部署在同一台服务器（即同一IP地址）下，但端口号不同
   • 同个第三方服务通常部署在多个服务器上（不同的IP地址），以提供负载均衡。

   3. 单纯使用IP地址来构造节点会导致产生一个以应用程序为中心的星型拓扑，这样一来，大部分图就会具有相同结构。为了避免这种情况发生，可以使用（目的IP地址，目的端口）来代替使用单一IP地址来构建图节点。

2. 论文优缺点

   优点：

   1. 论文的模型在实时预测时，将收集到的数据存储下来以丰富训练集，这样能避免数据漂移问题。数据漂移问题具体来说就是当应用程序的流量行为发生变化时，应用程序的指纹也会发生变化。但如果模型的训练样本还是之前收集的样本而没有进行更新的话，就会导致模型无法识别这些应用程序新的流量行为，从而导致准确率大幅下降。

   缺点：

   1. 论文的重点放在了已知应用程序的流量识别，缺少未知应用程序的识别。但是在结尾处对该方向进行了讨论，这也是之后可以创新的方向。

数据集

• ReCon [34]，应用程序加密流量数据集
• Cross Platform[33]，应用程序加密流量数据集
• ANDRUBIS[23]，应用程序加密流量数据集
• 该论文自行收集的数据集

可读的引用文献

• FLOWPRINT: Semi-Supervised Mobile-App Fingerprinting on Encrypted Network Traffic
• A Network Monitoring System for High Speed Network Traffic（一种收集流量的系统，可以读一读，看能不能安装一下）

一些学术单词

• Mathematically,：从数学上来讲，（后面一般接数学语言，比如符号，公式之类的）