CN118041674A - 流量检测方法和装置 - Google Patents

Abstract

本申请公开了一种流量检测方法和装置。该方法包括：获取基于服务器的多个通信参数创建的缓存表，其中，多个通信参数用于客户端通过多网卡与服务器交互，缓存表用于缓存至少一个呼叫标识；获取待检测的第一数据连接报文对应的第一通信参数；在多个通信参数包含第一通信参数时，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中；在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，对第一呼叫标识关联的至少两个数据连接报文进行检测。通过本申请，解决了相关技术中流量检测准确性较低的问题。

Description

流量检测方法和装置

技术领域

本申请涉及计算机领域，具体而言，涉及一种流量检测方法和装置。

背景技术

现有技术中，常常使用的防火墙技术只关注单个网卡/端口的应用层流量的解析和防护，对于客户端和服务器通过多网卡进行并行交互的多网卡流量(例如OPCDA(OPCData Access，OPC数据访问)协议下的流量，其中，OPC(OLE for Process Control),即过程控制对象链接及嵌入,是一种通信协议标准,用于连接工业自动化和过程控制***的不同设备和软件应用)的解析和防护，则无法提供相应完整准确的检测手段，进而导致无法解析到多网卡并行交互下的所有多网卡流量，从而造成流量检测准确性较低的技术问题。

发明内容

本申请的主要目的在于提供一种流量检测方法和装置，以解决相关技术中流量检测准确性较低的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种流量检测方法。该方法包括：获取基于服务器的多个通信参数创建的缓存表，其中，多个通信参数用于客户端通过多网卡与服务器交互，缓存表用于缓存至少一个呼叫标识，同一个呼叫标识关联属于同一个应用层会话的不同数据连接报文；获取待检测的第一数据连接报文对应的第一通信参数；在多个通信参数包含第一通信参数时，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中；在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，对第一呼叫标识关联的至少两个数据连接报文进行检测。

为了实现上述目的，根据本申请的另一方面，提供了一种流量检测装置。该装置包括：第一获取单元，用于获取基于服务器的多个通信参数创建的缓存表，其中，多个通信参数用于客户端通过多网卡与服务器交互，缓存表用于缓存至少一个呼叫标识，同一个呼叫标识关联属于同一个应用层会话的不同数据连接报文；第二获取单元，用于获取待检测的第一数据连接报文对应的第一通信参数；确定单元，用于在多个通信参数包含第一通信参数时，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中；检测单元，用于在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，对第一呼叫标识关联的至少两个数据连接报文进行检测。

为了实现上述目的，根据本申请的另一方面，提供了一种流量检测的处理器，上述处理器用于运行程序，其中，程序运行时执行上述流量检测方法。

为了实现上述目的，根据本申请的另一方面，提供了一种计算机可读的存储介质，其上存储有程序，该程序被处理器执行时实现上述流量检测方法。

为了实现上述目的，根据本申请的另一方面，提供了一种流量检测的电子设备，上述电子设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现上述流量检测方法。

通过本申请提供的实施例，获取客户端和服务器通过多网卡进行(并行)交互时所协商的多个通信参数，并建立多个通信参数关联的缓存表；进而在获取到待检测的数据连接报文后，对数据连接报文进行解析，得到数据连接报文的第一通信参数；如此，在数据连接报文的第一通信参数在多个通信参数中命中、且数据连接报文的呼叫标识符合缓存表的缓存条件的情况下，确定该数据连接报文为该缓存表对应的同一个应用层会话的报文，进而将该数据连接报文的呼叫标识在该缓存表中进行缓存。进一步，在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，确定该同一个应用层会话的报文已获取到，进而对上述同一个应用层会话的报文进行检测，达到了对于多网卡交互下的多网卡流量的完整、准确检测的目的，从而实现了提高流量检测准确性的技术效果，解决了流量检测准确性较低的问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例提供的流量检测方法的流程图；

图2是根据本申请实施例提供的安全设备的部署示意图；

图3是根据本申请实施例提供的流量解析处理模块的操作流程示意图；

图4是根据本申请实施例提供的流量检测装置的示意图；

图5是根据本申请实施例提供的流量检测的电子设备的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，本公开所涉及的相关信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。例如，本***和相关用户或机构间设置有接口，在获取相关信息之前，需要通过接口向前述的用户或机构发送获取请求，并在接收到前述的用户或机构反馈的同意信息后，获取相关信息。

需要说明的是，本公开的实施方式或实施例并非穷举，仅为部分实施方式或实施例的示意，不作为对本公开保护范围的具体限制。在不矛盾的情况下，某一实施方式或实施例中的每个步骤均可以作为独立实施例来实施，且各步骤之间可以任意组合，例如，在某一实施方式或实施例中去除部分步骤后的方案也可以作为独立实施例来实施，且在某一实施方式或实施例中各步骤的顺序可以任意交换，另外，某一实施方式或实施例中的可选方式或可选例可以任意组合；此外，各实施方式或实施例之间可以任意组合，例如，不同实施方式或实施例的部分或全部步骤可以任意组合，某一实施方式或实施例可以与其他实施方式或实施例的可选方式或可选例任意组合。

下面结合优选的实施步骤对本发明进行说明，图1是根据本申请实施例提供的流量检测方法的流程图，如图1所示，该方法包括如下步骤：

S101，获取基于服务器的多个通信参数创建的缓存表，其中，多个通信参数用于客户端通过多网卡与服务器交互，缓存表用于缓存至少一个呼叫标识，同一个呼叫标识关联属于同一个应用层会话的不同数据连接报文；

S102，获取待检测的第一数据连接报文对应的第一通信参数；

S103，在多个通信参数包含第一通信参数时，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中；

S104，在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，对第一呼叫标识关联的至少两个数据连接报文进行检测。

可选地，在本实施例中，上述流量检测方法可以但不限于应用在多网卡协议的流量检测和防护，例如OPCDA协议(OPCDA：OPC Data Access，OPC数据访问)。以OPCDA协议场景为例，客户端和服务器通过客户端的多网卡进行并行交互，对于同一个应用层的会话可能是通过多个网卡进行数据通信的。

需要说明的是，OPCDA协议是基于DCE(Data Communication Equipment,数据通信设备)/RPC(Remote Procedure Cal l,远程过程调用)协议的，分为控制连接和数据连接。在控制连接中，客户端通过获取服务器返回的DCERPC响应报文(DCERPC：DistributedComput ing Environment/Remote Procedure Cal l)中带有的多个可通信的ip/ipv6/域名+端口列表，将该表项进行缓存，并进行随机选择一个，用于后续的数据连接通信。但当单个通信路径有拥塞时，客户端会将部分业务报文采用缓存表项中的其他的ip/ipv6/域名+端口列表与服务器完成交互。

可以理解的是，现有的防火墙技术由于只关注单个网卡/端口的应用层流量的解析和防护，无法解析到OPCDA协议的所有流量，存在漏解析的情况，从而造成流量检测准确性较低。

对于上述问题，利用上述流量检测方法，获取客户端和服务器通过多网卡进行(并行)交互时所协商的多个通信参数，并建立多个通信参数关联的缓存表；进而在获取到待检测的数据连接报文后，对数据连接报文进行解析，得到数据连接报文的第一通信参数；如此，在数据连接报文的第一通信参数在多个通信参数中命中、且数据连接报文的呼叫标识符合缓存表的缓存条件的情况下，确定该数据连接报文为该缓存表对应的同一个应用层会话的报文，进而将该数据连接报文的呼叫标识在该缓存表中进行缓存。进一步，在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，确定该同一个应用层会话的报文已获取到，进而对上述同一个应用层会话的报文进行检测，达到了对于多网卡交互下的多网卡流量的完整、准确检测的目的，从而实现了提高流量检测准确性的技术效果，解决了流量检测准确性较低的问题。

可选地，在本实施例中，多个通信参数可以但不限于为服务器返回给客户端的响应报文中带有的多个可通信的ip/ipv6/域名+端口信息(即ip+端口或ipv6+端口或域名+端口)，其中，客户端可以但不限于对多个通信参数进行缓存，并在与服务器之间的数据连接通信过程中，先从多个通信参数中随机选择一个用于后续数据连接通信，并且在单个通信路径有拥塞时，客户端会将部分业务报文采用多个通信参数中的其他通信参数与服务器进一步完成数据连接通信。

可选地，在本实施例中，可以但不限于通过对目标动态端口(例如OPC服务器下的135端口)，获取服务器返回给客户端的响应报文，并行进行解析得到上述多个通信参数。

可选地，在本实施例中，创建与多个通信参数关联的缓存表，其中，缓存表用于存储属于同一个会话的至少两个数据连接报文的呼叫标识。

需要说明的是，在多网卡并行交互场景下，属于同一个会话的内容，在实际客户端与服务器的通信连接过程，由于各种原因(如网络堵塞或其他特定需求)，会分成多个报文并且按照多个网卡进行通信连接，而在分成多个报文过程中，则会为分成得到的多个报文分别标注呼叫标识(cal lid)，以用于后续判断是否属于同一个会话，其中，对于同一个会话的完整的多个报文而言，其对应的多个呼叫标识是递增的。

可以理解的是，在获取到上述多个通信参数并且建立与上述缓存表之后，可以但不限于获取从客户端发送到服务器的数据连接报文，并进行解析、检测等处理。

可选地，在本实施例中，以获取到待检测的第一数据连接报文为例，对第一数据连接报文进行解析，得到第一通信参数，其中，第一通信参数可以但不限于为ip/ipv6/域名+端口信息(即ip+端口或ipv6+端口或域名+端口)。

进一步，判断第一数据连接报文的第一通信参数是否命中上述多个通信参数，其中，在命中的情况下(即多个通信参数信息包括第一通信参数信息)，初步认为第一数据连接报文为缓存表的多网卡流量，进一步再对第一数据连接报文的第一呼叫标识进行校验，其中，在第一呼叫标识在缓存表的最新缓存的第二呼叫标识(即最近一次缓存的第二呼叫标识，后文同)的基础上递增的情况下，确定第一数据连接报文为缓存表的、属于同一应用层会话的报文，并将第一呼叫标识缓存至缓存表。

可选地，在本实施例中，在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，确定缓存表内存储的呼叫标识对应的至少两个数据连接报文已经为同一个应用层会话的多个报文，则对多个报文内容进行检测。

可选地，在本实施例中，在检测到缓存表中在第一时间段内无新增的呼叫标识的情况下，确定缓存表内存储的呼叫标识对应的至少两个数据连接报文已经为同一个应用层会话的多个报文，则对多个报文内容进行检测。

可以理解的是，考虑到不同的网卡的数据通信连接速度可能不同，且在不同的网卡通信连接时也可能会再次遇到网络堵塞等情况，因此是存在同一个会话的、不同呼叫标识的数据连接报文被获取到的时间不同，因此设置上述第一时间段以作为等待时间。当超过第一时间段的时间长度，都无新增呼叫标识情况下，认为同一个应用层会话的多个报文已经齐全，考虑到多网卡报文交互频繁，可能对设备的解析性能有较高要求，所以尽力而为的进行解析。

通过本申请提供的实施例，获取客户端和服务器通过多网卡进行(并行)交互时所协商的多个通信参数，并建立多个通信参数关联的缓存表；进而在获取到待检测的数据连接报文后，对数据连接报文进行解析，得到数据连接报文的第一通信参数；如此，在数据连接报文的第一通信参数在多个通信参数中命中、且数据连接报文的呼叫标识符合缓存表的缓存条件的情况下，确定该数据连接报文为该缓存表对应的同一个应用层会话的报文，进而将该数据连接报文的呼叫标识在该缓存表中进行缓存。进一步，在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，确定该同一个应用层会话的报文已获取到，进而对上述同一个应用层会话的报文进行检测，达到了对于多网卡交互下的多网卡流量的完整、准确检测的目的，从而实现了提高流量检测准确性的技术效果。

作为一种可选的方案，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中包括：

S11，在已缓存的呼叫标识不包括第一呼叫标识的情况下，从缓存表中确定出最新缓存的第二呼叫标识；

S12，在第一呼叫标识为第二呼叫标识以预设递增值递增得到的首个标识的情况下，确定将第一呼叫标识缓存至缓存表。

需要说明的是，在多网卡并行交互场景下，属于同一个会话的内容，在实际客户端与服务器的通信连接过程，由于各种原因(如网络堵塞或其他特定需求)，会分成多个报文并且按照多个网卡进行通信连接，而在分成多个报文过程中，则会为分成得到的多个报文分别标注呼叫标识(cal lid)，以用于后续判断是否属于同一个会话，其中，对于同一个会话的完整的多个报文而言，其对应的多个呼叫标识是递增的。

可选地，在本实施例中，在第一数据连接报文的第一通信参数命中多个通信参数的情况下，进一步再对第一数据连接报文的第一呼叫标识进行校验，其中，在第一呼叫标识在缓存表的最新缓存的第二呼叫标识的基础上递增的情况下，确定第一数据连接报文至少与第二呼叫标识对应的第二数据连接报文属于同一应用层会话。

需要说明的是，预设递增值可以被设置为1，也可以被设置为其他数值。以预设递增值为1进行举例说明，若第二呼叫标识的值为“3”，在第一呼叫标识值为“4”的情况下，则第一呼叫标识为第二呼叫标识以预设递增值递增得到的首个标识；在第一呼叫标识的值大于或等于5的情况下，则第一呼叫标识为第二呼叫标识以预设递增值递增得到的非首个标识。

通过本申请提供的实施例，在第一数据连接报文的第一通信参数命中多个通信参数且第一数据连接报文的第一呼叫标识在缓存表的最新缓存的第二呼叫标识基础上递增时，确定第一数据连接报文为缓存表对应的、与第二数据连接报文同一个应用层会话的报文之一。进而在确定该缓存集合对应的同一个应用层会话的报文已全部获取到之后，对上述同一个应用层会话的报文进行检测，达到了对于多网卡交互下的多网卡流量的完整、准确检测的目的，从而实现了提高流量检测准确性的技术效果。

作为一种可选的方案，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中包括：

S21，在已缓存的呼叫标识不包括第一呼叫标识的情况下，从缓存表中确定出最新缓存的第二呼叫标识；

S22，在第一呼叫标识为缓存表中最新缓存的第二呼叫标识以预设递增值递增得到的非首个标识的情况下，确定将第一呼叫标识缓存至缓存表，并开启定时器，其中，在定时器处于开启状态的情况下，允许将接收到的、处于第二呼叫标识和第一呼叫标识之间的其他呼叫标识缓存至缓存表。

可选地，在本实施例中，在第一呼叫标识为第二呼叫标识的后续标识、且非递增标识的情况下，说明第一数据连接报文为缓存表的、属于同一应用层会话的报文，且在第一数据连接报文之前，还存在其他中间的数据连接报文(对应第二呼叫标识和第一呼叫标识之间的其他呼叫标识)。

进一步，开启定时器，定时器进入开启状态，可以但不限于在第二时间段内，进行上述其他中间的数据连接报文的其他呼叫标识在缓存表的补全处理，若定时器超时(即，定时器由开启状态进入关闭状态)，则跳过上述中间的数据连接报文，继续在当前第一数据连接报文的基础上等待新的数据连接报文的获取、解析。

可以理解的是，考虑到多网卡流量的报文交互频繁，可能对设备的解析性能有很高要求，所以尽力而为的进行解析。因此设置第二时间段的时间长度，且小于上述第一时间段的时间长度，进而不会影响对整体报文的完整性的判断标准。

需要说明的是，预设递增值可以被设置为1，也可以被设置为其他数值。以预设递增值为1为例，在第一呼叫标识为“4”的情况下，若第二呼叫标识为“2”，则确定第一呼叫标识为第二呼叫标识以预设递增值递增得到的非首个标识。

通过本申请提供的实施例，在从缓存表中确定出最新缓存的第二数据连接报文的第二呼叫标识之后，根据第一呼叫标识和第二呼叫标识的关系，进而确定出相应的处理操作，并且处理过程中能够完整、准确地实现对多网卡流量的防护，进而实现了提高多网卡流量的的检测准确性的技术效果。

作为一种可选的方案，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中包括：

S31，在已缓存的呼叫标识不包括第一呼叫标识的情况下，从缓存表中确定出最新缓存的第二呼叫标识；

S32，在所述缓存表中最新缓存的第二呼叫标识为所述第一呼叫标识以预设递增值递增得到的标识的情况下，判断定时器是否处于开启状态；

S33，在定时器处于开启状态的情况下，确定将第一呼叫标识缓存至缓存表；

S34，在定时器未处于开启状态的情况下，确定不将第一呼叫标识缓存至缓存表。

可选地，在本实施例中，在所述缓存表中最新缓存的第二呼叫标识为所述第一呼叫标识以预设递增值递增得到的标识的情况下，说明第一数据连接报文为第二呼叫标识对应的第二数据连接报文之前的报文，进一步获取第二呼叫标识在缓存至缓存表时，所开启的定时器是否仍在开启，若仍在开启，确定第一数据连接报文仍可被接收检测，因此将第一呼叫标识缓存至缓存表。反之若未开启的情况下，说明第一数据连接报文已不被接收检测，因此不将第一呼叫标识缓存至缓存表。

作为一种可选的方案，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中包括：

S41，在已缓存的呼叫标识包括第一呼叫标识的情况下，确定不将第一呼叫标识缓存至缓存表，以及确定第一数据连接报文为风险报文。

可以理解的是，在第一呼叫标识与缓存表中已有呼叫标识重复的情况下，确定第一数据连接报文为风险报文。进一步，将该风险报文的信息同步到相应的安全防御模块进行告警，并执行相应防护动作(如舍弃报文)。

作为一种可选的方案，获取客户端和服务器之间通过多网卡进行并行交互时的多个通信参数，包括：

S31，在获取到客户端和服务器之间的控制连接报文的情况下，对控制连接报文进行解析，得到客户端和服务器之间通过多网卡进行并行交互时的协商信息，其中，协商信息包括客户端的ip、服务器的ip和服务器提供的N个端口信息，N为大于1的正整数；

S32，将服务器的ip和N个端口信息组合得到多个通信参数，其中，一个通信参数对应一个服务器的ip和一个端口信息。

可选地，在本实施例中，控制连接报文可以但不限于为用于事先协商建立客户端与服务器之间的数据连接通信的空间信息，可以但不限于包括客户端和服务器之间通过多网卡进行并行交互时的协商信息，数据连接报文可以但不限于为用来传输数据的报文，包含了实际的数据内容，比如文件、文本、图像等。

可选地，在本实施例中，协商信息可以但不限于包括客户端的ip、服务器的ip和服务器提供的N个端口信息，并将服务器的ip和N个端口信息组合得到的N个连接端口信息(连接端口信息的组合形式与下文白名单连接端口信息的组合形式一直，即格式一致)确定为多个通信参数。

可选地，在本实施例中，协商信息还可以但不限于包括客户端的ip、服务器的ipv6和服务器提供的N个端口信息，并将服务器的ipv6和N个端口信息组合得到的N个连接端口信息确定为多个通信参数。

可选地，在本实施例中，协商信息还可以但不限于包括客户端的ip、服务器的域名和服务器提供的N个端口信息，并将服务器的域名和N个端口信息组合得到的N个连接端口信息确定为多个通信参数。

通过本申请提供的实施例，采用控制连接的特定报文来获取多个通信参数，并以此建立客户端和服务器之间的缓存集合，以用于对客户端和服务器之间通过多网卡进行并行交互时的同一个会话(即同一个应用层会话)的多个数据连接报文的呼叫标识的存储，进而达到了保障多网卡流量检测的完整性的目的，从而实现了提高流量检测准确性的技术效果。

作为一种可选的方案，对缓存表存储的呼叫标识对应的至少两个数据连接报文进行检测包括：

S41，获取用于对缓存集合进行检测的白名单，其中，白名单存储有至少一条白名单连接端口信息，每条白名单连接端口信息由服务器的ip和服务器的端口信息组成；

S42，在至少两个数据连接报文中存在通信参数与至少一条白名单连接端口信息中的任一白名单连接端口信息一致的情况下，确定至少两个数据连接报文命中白名单；

S43，对至少两个数据连接报文进行接口匹配检测和方法匹配检测；

S44，在接口匹配检测未通过、或方法匹配检测未通过、或至少两个数据连接报文中任一数据连接报文的通信参数与至少一条白名单连接端口信息均不一致的情况下，确定至少两个数据连接报文为风险报文。

可选地，在本实施例中，白名单可以但不限于为预先设置的，还可以但不限于为基于神经网络模型进行训练得到的，其中，白模型存储由至少一条白名单连接端口信息，每条白名单连接端口信息由服务器的ip和服务器的端口信息组成。

需要说明的是，白名单连接端口信息与上述多个通信参数的格式一致，也即，白名单连接端口信息还可以但不限于由服务器的ipv6和服务器的端口信息组成，以及还可以但不限于由服务器的域名和服务器的端口信息组成。

可选地，在本实施例中，在缓存表存储的呼叫标识对应的至少两个数据连接报文中，存在通信参数与至少一条白名单连接端口信息中的任一白名单连接端口信息一致的情况下，确定至少两个数据连接报文命中白名单。

需要说明的是，在上述至少两个数据连接报文都未命中白名单的情况下，确定上述至少两个数据报文为风险报文，并根据相关网络信息进行告警。

需要说明的是，在上述至少两个数据连接报文命中白名单的情况下，进一步对至少两个数据连接报文进行接口匹配检测和方法匹配检测，例如，接口匹配包括：解析报文(对收到的报文进行解析，提取出报文中的关键信息)、匹配接口(根据报文中的信息，确定需要调用的接口，即确定处理该报文的模块或服务)、调用接口(将解析后的报文传递给匹配到的接口进行处理)，方法匹配包括：解析报文(对收到的报文进行解析，提取出报文中的关键信息)、匹配方法(根据报文中的信息，确定需要调用的方法，即确定具体的处理逻辑或操作)、调用方法(将解析后的报文传递给匹配到的方法进行具体的处理)。

可以理解的是，在接口匹配检测通过、方法匹配检测通过的情况下，确定至少两个数据连接报文为安全报文、以及确定至少两个数据连接报文对应的同一会话为安全会话。在接口匹配检测未通过、或方法匹配检测未通过、或至少两个数据连接报文中任一数据连接报文与至少一条白名单连接端口信息均不一致的情况下，确定至少两个数据连接报文为风险报文。

需要说明的是，在客户端与服务器之间的多网卡并行交互过程中，即使客户端的ip信息发生变化，利用上述方法，由于白名单的设置和匹配是与服务器端的连接端口信息对应的，因此并不会收到影响，进而达到一个白名单便能够完成对全部数据连接报文的检测，而无需单独的为每一个客户端ip分别分配相应的白名单，进而实现了提高流量检测的效率的技术效果。

作为一种可选的方案，在获取基于服务器的多个通信参数创建的缓存表之前，方法还包括：

S51，在客户端和服务器之间部署安全设备，其中，安全设备用于访问动态端口以获取控制连接报文，以及用于对由客户端流向服务器的数据连接报文进行安全检测；

S52，在检测到风险报文的异常事件的情况下，发出告警信息。

可选地，在本实施例中，在客户端和服务器之间部署安全设备，其中，安全设备通过访问动态端口(如OPC服务器下的135端口)获取控制连接报文，并对控制连接报文进行解析以得到上述多个通信参数，以及用于获取待检测的数据连接报文，其中，待检测的数据连接报文从客户端流向服务器进行数据通信。

可选地，在本实施例中，在检测到风险报文的异常(网络)事件时，发出告警信息，以告知相关管理人员。

通过本申请提供的实施例，通过部署的安全设备对客户端和服务器之间进行的多网卡并行交互下的多网卡流量进行实时检测，并在检测到异常情况时及时向相关关联人员进行告警，进而达到了提高流量检测的实时性和准确性的技术效果。

作为一种可选的方案，在获取待检测的第一数据连接报文对应的第一通信参数之后，方法还包括：

S61，在多个通信参数不包含第一通信参数时，将第一通信参数添加至多个通信参数中，以及将第一呼叫标识缓存至缓存表。

可选地，在本实施例中，在多个通信参数不包括第一通信参数的情况下，说明前述步骤中通过获取动态端口协商的响应报文并建立对应缓存表过程中遗漏了第一数据连接报文所对应的客户端源ip信息+服务器端口信息的组合情况(即第一通信参数)。因此，进一步将第一数据连接报文的第一通信参数补充至多个通信参数中，并将第一数据连接报文的第一呼叫标识缓存至缓存表。

通过本申请提供的实施例，不局限于客户端与服务器之间的单个协商信息的数据通信连接，在出现新的协商信息的情况下，及时创建对应的缓存集合，并按照上述方法进行相应的数据连接报文的获取、解析和防护，进而提高了流量检测的全面性，从而实现了提高流量检测准确性的技术效果。

作为一种可选的方案，将上述流量检测方法，应用在一种OPCDA协议流量检测和方法场景，以解决在该场景下，由于客户端和服务器通过多网卡进行并行交互，现有防火墙技术无法完全满足应用层数据解析需求的问题。

OPCDA协议主要是承载在DCE(Data Communication Equipment,数据通信设备)/RPC(Remote Procedure Cal l,远程过程调用)协议之上。通过识别DCERPC的响应报文，客户端可以获取服务器上提供的所有可用于数据连接通信的IP和端口列表(IPV4、IPV6、域名)，当网络拥堵时，客户端可以在IP和端口列表中随机选择一个网络连接，将拥堵的那部分报文继续发送到服务器上。网络恢复后，使用之前的端口继续交互数据流量。这也就表明当前工业防火墙通过单个会话的独立解析应用层内容的方式，不能达到多会话间关联解析应用层流量目的。并且也无法对于新建会话的报文做防护。

举例说明，DCERPC协议使用ISystemActivator接口下的RemoteCreateInstance方法进行用于OPCDA数据通信的动态端口协商机制，总体概括为3步骤：(1)OPC客户端向OPC服务器的135端口发起连接，(2)连接成功后OPC服务器提供用于OPCDA数据连接通信的IP+端口列表、通过应答报文返回给客户端，(3)OPC客户端会缓存服务器的ip/ipv6/域名+端口列表，并选择其一，用于向服务器发起连接用来后面数据的传输。OPC协议能够通过第(2)步返回的的通信列表通过随机选择的方式完成数据连接通信。

可选地，通过OPC服务器的135端***互连接追踪到opc交互ISystemActivatorRemoteCreat Instance response报文，就能拿到服务器和客户端用于数据交互的ip/ipv6/域名+端口列表。

具体地，本实施例在上述OPCDA协议流量检测和方法场景，提供了一种用于OPCDA协议流量检测的安全设备，如图2所示，安全设备包括流量解析处理模块和安全防御模块，部署在客户端(OPC客户端)和服务器(OPC服务器)之间，用于检测OPCDA的全流量交互过程，获取流量明文内容，匹配白名单，根据预设的处理动作，或日志告警通知管理员，或阻断对应的流量交互，其中，经过流量解析处理模块和安全防御模块处理后，正常流量完成从客户端至服务器的流向，对于非正常流量的异常情况则由安全防御模块上报通知管理员。

具体地，安全设备在部署完成后，首先通过控制连接报文来获取服务器返回的动态端口协商响应报文，缓存获取到的客户端ip、服务器ip+port(即服务器ipv4/ipv6/域名+端口)至缓存表的集合n中，用于后续判断同一个应用层会话。

通过数据连接获取opcda应用层cal l id信息，来确定一个连续的应用层会话流量。需要说明的是，数据连接的每对请求和响应都用相同的cal l id标识，不同的请求之间的cal l id递增。将cal l id值进行缓存，挂载到集合n下面，将cal l id报文内容上送到opcda进行解析。

可以理解的是，在发生网络拥堵时，opcda报文会进行多网卡交互，安全设备发现有新建会话是dcerpc报文时，需要判断会话信息是否命中缓存表中的集合，当缓存表的集合n中的多个服务器ip+port包括dcerpc报文的ip+port时确定命中，并进一步如果dcerpc报文的cal l id在已有id基础上递增时，则认为这是一条已知集合的多网卡流量，整合为一条应用层会话。若cal l id重复，判定中间人攻击/网络攻击。将该信息同步到安全防御模块，执行预设动作(如舍弃或放行)。

若cal l id不重复且大于当前缓存的cal l id，也进行缓存解析，开启2分钟定时器，如果计时器结束前没有中间cal l id补全，就跳过中间报文。继续在当前cal l id基础上等待新的请求响应。这样处理的原因是考虑到opcda报文交互频繁，可能对设备的解析性能有很高要求，所以尽力而为的进行解析。以此基础，安全设备就能够解析到多网卡产生的opcda报文，并进行防护。

进一步举例说明，图3为一种流量解析处理模块的操作流程示意图。如图3所示，具体步骤包括：

S301，获取OPC客户端和OPC服务器之间的连接报文；

S302，对连接报文的目的端口进行判断，是否为135端口；

S303，在连接报文的目的端口是135端口的情况下，判断连接报文是否为动态端口协商的响应报文；

S304，在连接报文是动态端口协商的响应报文的情况下，获取连接报文指示的OPC客户端源ip信息+OPC服务器的端口信息(即ipv4/ipv6/域名+端口)，并建立对应的缓存集合n；

S305，在连接报文不是动态端口协商的响应报文的情况下，退出解析；

S306，在连接报文的目的端口不是135端口的情况下，判断连接报文是否为DCERPC报文；

S307，在连接报文是DCERPC报文的情况下，对连接报文进行OPCDA解析，得到OPCDA协议内容；

S308，根据OPCDA协议内容指示的连接报文的OPC客户端源ip信息+OPC服务器的端口信息，在缓存表查询确认该连接报文是否为已知流量；

S309，在该连接报文为已知流量的情况下，将OPCDA协议内容指示的连接报文的cal l id标识缓存在对应集合内；

S310，判断连接报文的cal l id与集合内已有cal l id是否连续；

S311，在连接报文的cal l id与集合内已有cal l id不连续的情况下，对该集合内已缓存的cal l id的多个连接报文进行安全防护，并设置预设时间的定时器，其中，在预设时间内，接收并解析到上述不连续的cal l id之间的其他连接报文的情况下，进一步对该其他连接报文进行安全防护，在预设时间外，则不对该其他连接报文进行安全防护；

S312，在连接报文的cal l id与集合内已有cal l id连续的情况下，对该集合内已缓存的cal l id的多个连接报文进行安全防护；

S313,在该连接报文为未知流量的情况下，获取连接报文的OPC客户端源ip信息+OPC服务器的端口信息(即ipv4/ipv6/域名+端口)，并将连接报文的OPC客户端源ip信息+OPC服务器的端口信息补充至缓存集合n中(说明步骤S303、S304获取动态端口协商的响应报文并建立对应缓存集合n过程中遗漏了该连接报文所对应的客户端源ip信息+服务器端口信息的组合情况)；

S314，在连接报文不是DCERPC报文的情况下，退出解析。

进一步，上述安全防护基于安全防御模块实现，涉及到白名单匹配场景。需要说明的是，相关技术中，按照客户端ip(即上文客户端源ip，后文同，不再赘述)去产生白名单，就会出现比较多的白名单，进而导致白名单匹配的过程效率低下。

在本实施例中，将当前白名单与已有ip+port缓存表中的集合进行匹配。集合n中的单条s ip、ip+port(s ip：客户端的ip+port：服务器的ipv4/ipv6/域名+端口)与白名单的源目ip匹配命中时，则将集合n挂载到白名单下。以此达到减少白名单总数，多网卡场景交互产生的opc流量在匹配白名单过程中,源目的IP的匹配是通过集合n进行匹配的，当匹配到集合n中任意一条s ip、ip+port即为成功一个集合内的操作接口和方法的安全性一致，则继续匹配后续的接口和方法等内容。完全匹配后才认为命中白名单。

如果白名单命中失败，将网络异常事件及时告知管理员。

需要说明的是，上述策略有助于提高网络安全性和防护能力，降低潜在的网络威胁和攻击风险。通过黑、白名单的过滤和预设的响应措施，可以有效地监控和管理网络流量，保护关键信息资产的安全。

需要说明的是，本实施例提供了一种OPCDA协议全流量检测、防护方法，在有完整控制连接的场景下，安全设备通过上述动态端口获取报文，来获取服务器用于OPCDA数据连接的ip和接口列表，ip+port与客户端ip信息进行关联缓存，当新建会话符合缓存表关系且为decrpc流量，则认为当前多个会话其实是唯一的客户端和服务器在通信。而应用层报文因为存在不同网卡交互的情况，需要进行应用层会话合并后进行深层解析。应用层会话合并需要通过缓存cal l id值列表并关联到缓存表项。来获取唯一的完整的opcda应用层会话信息。再进行白名单过滤以及工业漏洞的检测。安全设备根据预设的处理动作可进行日志告警通知管理员，或直接阻断对应的流量交互。

通过本申请提供的实施例，对多网卡交互的OPCDA协议报文交互都能进行防护，防护更加全面，使用范围更广。根据CALLID+缓存集合表来判断是否是威胁报文，及时告知管理员。对获得的OPCDA全流量报文内容进行检查，并及时通知管理员。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例还提供了一种流量检测装置，需要说明的是，本申请实施例的流量检测装置可以用于执行本申请实施例所提供的用于流量检测方法。以下对本申请实施例提供的流量检测装置进行介绍。

图4是根据本申请实施例的流量检测装置的示意图。如图4所示，该装置包括：

第一获取单元401，用于获取基于服务器的多个通信参数创建的缓存表，其中，多个通信参数用于客户端通过多网卡与服务器交互，缓存表用于缓存至少一个呼叫标识，同一个呼叫标识关联属于同一个应用层会话的不同数据连接报文；

第二获取单元402，用于获取待检测的第一数据连接报文对应的第一通信参数；

确定单元403，用于在多个通信参数包含第一通信参数时，根据第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将第一呼叫标识缓存至缓存表中；

检测单元404，用于在缓存表中缓存有第一呼叫标识，且第一呼叫标识关联至少两个数据连接报文的情况下，对第一呼叫标识关联的至少两个数据连接报文进行检测。

可选地，在本申请实施例提供的流量检测装置中，确定单元403包括：

第一确定模块，用于在已缓存的呼叫标识不包括第一呼叫标识的情况下，从缓存表中确定出最新缓存的第二呼叫标识；

第二确定模块，用于在第一呼叫标识为第二呼叫标识以预设递增值递增得到的首个标识的情况下，确定将第一呼叫标识缓存至缓存表。

可选地，在本申请实施例提供的流量检测装置中，确定单元403包括：

第三确定模块，用于在已缓存的呼叫标识不包括第一呼叫标识的情况下，从缓存表中确定出最新缓存的第二呼叫标识；

第四确定模块，用于在第一呼叫标识为缓存表中最新缓存的第二呼叫标识以预设递增值递增得到的非首个标识的情况下，确定将第一呼叫标识缓存至缓存表，并开启定时器，其中，在定时器开启过程中，允许将接收到的、处于第二呼叫标识和第一呼叫标识之间的其他呼叫标识缓存至缓存表。

可选地，在本申请实施例提供的流量检测装置中，确定单元403包括：

第五确定模块，用于在已缓存的呼叫标识不包括第一呼叫标识的情况下，从缓存表中确定出最新缓存的第二呼叫标识；

判断模块，用于在所述缓存表中最新缓存的第二呼叫标识为所述第一呼叫标识以预设递增值递增得到的标识的情况下，判断定时器是否开启；

第六确定模块，用于在定时器开启的情况下，确定将第一呼叫标识缓存至缓存表；

第七确定模块，用于在定时器未开启的情况下，确定不将第一呼叫标识缓存至缓存表。

可选地，在本申请实施例提供的流量检测装置中，确定单元403包括：

第八确定模块，用于在已缓存的呼叫标识包括第一呼叫标识的情况下，确定不将第一呼叫标识缓存至缓存表，以及确定第一数据连接报文为风险报文。

可选地，在本申请实施例提供的流量检测装置中，装置还包括：

解析模块，用于在获取基于服务器的多个通信参数创建的缓存表之前，在获取到客户端和服务器之间的控制连接报文的情况下，对控制连接报文进行解析，得到客户端和服务器之间通过多网卡进行并行交互时的协商信息，其中，协商信息包括客户端的ip、服务器的ip和服务器提供的N个端口信息，N为大于1的正整数；

组合模块，用于在获取基于服务器的多个通信参数创建的缓存表之前，将服务器的ip和N个端口信息组合得到多个通信参数，其中，一个通信参数对应一个服务器的ip和一个端口信息。

可选地，在本申请实施例提供的流量检测装置中，检测单元404包括：

获取模块，用于获取用于对缓存集合进行检测的白名单，其中，白名单存储有至少一条白名单连接端口信息，每条白名单连接端口信息由服务器的ip和服务器的端口信息组成；

第九确定模块，用于在至少两个数据连接报文中存在通信参数与任一白名单连接端口信息一致的情况下，确定至少两个数据连接报文命中白名单；

匹配模块，用于对至少两个数据连接报文进行接口匹配检测和装置匹配检测；

第十确定模块，用于在接口匹配检测未通过、或装置匹配检测未通过、或至少两个数据连接报文中任一数据连接报文的通信参数与至少一条白名单连接端口信息均不一致的情况下，确定至少两个数据连接报文为风险报文。

可选地，在本申请实施例提供的流量检测装置中，装置还包括：

部署模块，用于在获取基于服务器的多个通信参数创建的缓存表之前，在客户端和服务器之间部署安全设备，其中，安全设备用于访问动态端口以获取控制连接报文，以及用于对由客户端流向服务器的数据连接报文进行安全检测；

告警模块，用于在获取基于服务器的多个通信参数创建的缓存表之前，在检测到风险报文的异常事件的情况下，发出告警信息。

可选地，在本申请实施例提供的流量检测装置中，装置还包括：

添加模块，用于在获取待检测的第一数据连接报文对应的第一通信参数之后，在多个通信参数不包含第一通信参数时，将第一通信参数添加至多个通信参数中，以及将第一呼叫标识缓存至第一缓存集合。

本发明实施例提供了一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现上述流量检测方法。

本发明实施例提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述流量检测方法。

如图5所示，本发明实施例提供了一种电子设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现上述流量检测方法。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来训练或优化目标模型，从而提高数据加载的效率。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(trans itory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种流量检测方法，其特征在于，包括：

获取基于服务器的多个通信参数创建的缓存表，其中，所述多个通信参数用于客户端通过多网卡与所述服务器交互，所述缓存表用于缓存至少一个呼叫标识，同一个所述呼叫标识关联属于同一个应用层会话的不同数据连接报文；

获取待检测的第一数据连接报文对应的第一通信参数；

在所述多个通信参数包含所述第一通信参数时，根据所述第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将所述第一呼叫标识缓存至所述缓存表中；

在所述缓存表中缓存有所述第一呼叫标识，且所述第一呼叫标识关联至少两个数据连接报文的情况下，对所述第一呼叫标识关联的至少两个数据连接报文进行检测。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将所述第一呼叫标识缓存至所述缓存表中包括：

在所述已缓存的呼叫标识不包括所述第一呼叫标识的情况下，从所述缓存表中确定出最新缓存的第二呼叫标识；

在所述第一呼叫标识为所述第二呼叫标识以预设递增值递增得到的首个标识的情况下，确定将所述第一呼叫标识缓存至所述缓存表。

3.根据权利要求1所述的方法，其特征在于，所述根据所述第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将所述第一呼叫标识缓存至所述缓存表中包括：

在所述已缓存的呼叫标识不包括所述第一呼叫标识的情况下，从所述缓存表中确定出最新缓存的第二呼叫标识；

在所述第一呼叫标识为所述第二呼叫标识以预设递增值递增得到的非首个标识的情况下，确定将所述第一呼叫标识缓存至所述缓存表，并开启定时器，其中，在所述定时器处于开启状态的情况下，允许将接收到的、处于所述第二呼叫标识和所述第一呼叫标识之间的其他呼叫标识缓存至所述缓存表。

4.根据权利要求1所述的方法，其特征在于，所述根据所述第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将所述第一呼叫标识缓存至所述缓存表中包括：

在所述已缓存的呼叫标识不包括所述第一呼叫标识的情况下，从所述缓存表中确定出最新缓存的第二呼叫标识；

在所述第二呼叫标识为所述第一呼叫标识以预设递增值递增得到的标识的情况下，判断定时器是否处于开启状态；

在所述定时器处于所述开启状态的情况下，确定将所述第一呼叫标识缓存至所述缓存表；

在所述定时器未处于所述开启状态的情况下，确定不将所述第一呼叫标识缓存至所述缓存表。

5.根据权利要求1所述的方法，其特征在于，所述根据所述第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将所述第一呼叫标识缓存至所述缓存表中包括：

在所述已缓存的呼叫标识包括所述第一呼叫标识的情况下，确定不将所述第一呼叫标识缓存至所述缓存表，以及确定所述第一数据连接报文为风险报文。

6.根据权利要求1所述的方法，其特征在于，在所述获取基于服务器的多个通信参数创建的缓存表之前，所述方法还包括：

在获取到所述客户端和所述服务器之间的控制连接报文的情况下，对所述控制连接报文进行解析，得到所述客户端和所述服务器之间通过多网卡进行并行交互时的协商信息，其中，所述协商信息包括所述客户端的ip、所述服务器的ip和所述服务器提供的N个端口信息，N为大于1的正整数；

将所述服务器的ip和所述N个端口信息组合得到所述多个通信参数，其中，一个通信参数对应一个所述服务器的ip和一个端口信息。

7.根据权利要求6所述的方法，其特征在于，所述对所述第一呼叫标识关联的至少两个数据连接报文进行检测包括：

获取用于对缓存集合进行检测的白名单，其中，所述白名单存储有至少一条白名单连接端口信息，每条白名单连接端口信息由所述服务器的ip和所述服务器的端口信息组成；

在所述至少两个数据连接报文中存在通信参数与任一所述白名单连接端口信息一致的情况下，确定所述至少两个数据连接报文命中所述白名单；

对所述至少两个数据连接报文进行接口匹配检测和方法匹配检测；

在所述接口匹配检测未通过、或所述方法匹配检测未通过、或所述至少两个数据连接报文中任一数据连接报文的通信参数与所述至少一条白名单连接端口信息均不一致的情况下，确定所述至少两个数据连接报文为风险报文。

8.根据权利要求1至7任一项所述的方法，其特征在于，在所述获取基于服务器的多个通信参数创建的缓存表之前，所述方法还包括：

在所述客户端和所述服务器之间部署安全设备，其中，所述安全设备用于访问动态端口以获取控制连接报文，以及用于对由所述客户端流向所述服务器的数据连接报文进行安全检测；

在检测到风险报文的异常事件的情况下，发出告警信息。

9.根据权利要求1所述的方法，其特征在于，在所述获取待检测的第一数据连接报文对应的第一通信参数之后，所述方法还包括：

在所述多个通信参数不包含所述第一通信参数时，将所述第一通信参数添加至所述多个通信参数中，以及将所述第一呼叫标识缓存至所述缓存表。

10.一种流量检测装置，其特征在于，包括：

第一获取单元，用于获取基于服务器的多个通信参数创建的缓存表，其中，所述多个通信参数用于客户端通过多网卡与所述服务器交互，所述缓存表用于缓存至少一个呼叫标识，同一个所述呼叫标识关联属于同一个应用层会话的不同数据连接报文；

第二获取单元，用于获取待检测的第一数据连接报文对应的第一通信参数；

确定单元，用于在所述多个通信参数包含所述第一通信参数时，根据所述第一数据连接报文的第一呼叫标识以及缓存表中已缓存的呼叫标识，确定是否将所述第一呼叫标识缓存至所述缓存表中；

检测单元，用于在所述缓存表中缓存有所述第一呼叫标识，且所述第一呼叫标识关联至少两个数据连接报文的情况下，对所述第一呼叫标识关联的至少两个数据连接报文进行检测。