CN116055586B - 分片报文的匹配方法、路由器及存储介质 - Google Patents

Abstract

本申请提供了一种分片报文的匹配方法、路由器及存储介质。该方法通过构建分片报文中具有唯一性的识别号与端口号信息之间的映射关系，进而在接收到分片报文时根据识别号从映射关系中确定对应的端口号信息，优化了内核原生代码match注册机制不支持针对分片报文的端口号匹配缺陷，使得用户在防火墙配置时，不用再担心基于端口号的端口号匹配规则无法实现对分片报文的匹配，从而提高了基于端口匹配而开发的功能的易用性和可靠性。

Description

分片报文的匹配方法、路由器及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种分片报文的匹配方法、路由器及存储介质。

背景技术

Netfilter是Linux 2.4版本后支持的内核防火墙框架，它作为一个通用的、抽象的框架提供了match(用于注册匹配规则)，target(用于确定目标)等注册机制，通过实例化match，target对象及其对应算法，就可以通过iptables(Linux上常用的防火墙软件)进行参数命令组合达到用户精准配置效果。

目前，在Netfilter的原生代码中，基于match注册机制配置的用户数据报协议(User Datagram Protocol，UDP)的端口匹配规则，只能针对不分片报文，即携带UDP报文头的报文，对于不携带UDP报文头的分片报文，无法进行匹配。然后在实际应用中，受设备支持的最大传输单元的限制，需要传输的数据往往会被拆分为多个数据包，即进行分片。而对于分片报文，只有第一个分片报文携带UDP报文头，后续的分片报文不携带UDP报文头，这就导致不携带UDP报文头的分片报文，无法进行匹配。

因此，亟需提供一种能够解决分片报文在Linux内核UDP端口匹配失效的方法。

发明内容

为了解决上述技术问题，本申请提供一种分片报文的匹配方法、路由器及存储介质，旨在解决目前分片报文在Linux内核UDP端口匹配失效的问题。

第一方面，本申请提供一种分片报文的匹配方法。该方法包括：在接收到的数据包为用户数据报协议UDP数据包时，确定UDP数据包是否是分片报文，分片报文中包括识别号，识别号用于标识UDP数据包对应的未分片的数据包，未分片的数据包进行分片后，包括分片报文；在UDP数据包是分片报文时，确定UDP数据包是否是第一个分片报文，第一个分片报文包括端口号信息；在UDP数据包是第一个分片报文时，对端口号信息进行端口号匹配，并根据识别号和端口号信息，构建映射关系表；在UDP数据包不是第一个分片报文时，根据识别号从映射关系表中查找端口号信息，并对查找到的端口号信息进行端口号匹配。

其中，识别号例如为下文所说的“Identification”字段对应的信息。

其中，未分片的数据包例如为下问所说的整包。

由此，通过构建分片报文中具有唯一性的识别号与端口号信息之间的映射关系，进而在接收到分片报文时根据识别号从映射关系中确定对应的端口号信息，优化了内核原生代码match注册机制不支持针对分片报文的端口号匹配缺陷，使得用户在防火墙配置时，不用再担心基于端口号的端口号匹配规则无法实现对分片报文的匹配，从而提高了基于端口匹配而开发的功能的易用性和可靠性。

根据第一方面，端口号信息位于第一分片报文的数据体的前8位。例如下文所说的Data部分的前8位。

根据第一方面，或者以上第一方面的任意一种实现方式，端口号信息包括源端口号和目的端口号；第一分片报文的数据体的前8位中前4位上的字符对应源端口号，第一分片报文的数据体的前8位中后4位上的字符对应目的端口号。

由于Data部分的信息是16进制的，每2位16进制的符号表示一个字节，根据现有协议可知，第一个分片报文中携带的UDP报文头占前4个字节，其中前两个字节，即前8位中前4位上的字符对应的是源端口号，后两个字节，即前8位中后4位上的字符应的是目的端口号。

根据第一方面，或者以上第一方面的任意一种实现方式，UDP数据包包括互联网协议第6版本IPv6报文头；确定UDP数据包是否是第一个分片报文，包括：确定IPv6报文头中第一字段对应的信息是否是第一信息；在第一字段对应的信息是第一信息时，确定IPv6报文头中第二字段对应的信息确是否为第二信息；在第二字段对应的信息是第二信息时，确定UDP数据包是第一个分片报文；在第二字段对应的信息不是第二信息时，确定UDP数据包不是第一个分片报文。

其中，第一字段例如为下文所说的“Next Heade”字段。

相应地，第一信息例如为下文所说的“44”。

其中，第二字段例如为下文所说的“Offset”字段。

相应地，第二信息例如为下文所说的“0”。

这样，根据“Next Heade”字段对应的不同信息，就可以快速、准确的确定当前的UDP数据包是否为分片报文或非分片报文(一个包含端口号信息的UDP数据包)；根据“Offset”字段字段对应的不同信息，就可以快速、准确的确定是分片报文的UDP数据包是否为同一个数据包(即下文所说的整包)进行分片后的第一个分片报文。

根据第一方面，或者以上第一方面的任意一种实现方式，在UDP数据包不是第一个分片报文时，方法还包括：确定UDP数据包是否是最后一个分片报文；在UDP数据包是最后一个分片报文时，在对查找到的端口号信息进行端口号匹配之后，删除映射关系表。

这样，可以有效减少对路由器资源存储空间、资源的占用。

根据第一方面，或者以上第一方面的任意一种实现方式，UDP数据包包括IPv6报文头；确定UDP数据包是否是最后一个分片报文，包括：获取IPv6报文头中第三字段对应的信息；在第三字段对应的信息是第三信息时，确定UDP数据包是最后一个分片报文；在第三字段对应的信息是第四信息时，确定UDP数据包不是最后一个分片报文。

其中，第三字段例如为下文所说的“More Fragment”字段。

相应地，第三信息例如为下文所说的“More Fragment”字段前的内容“1”，或者“More Fragment”字段后对应的信息“Yes”。

相应地，第四信息例如为下文所说的“More Fragment”字段前的内容“0”，或者“More Fragment”字段后对应的信息“No”。

这样，根据“More Fragment”字段对应的不同信息，就可以快速、准确的确定当前是分片报文的UDP数据包是否为同一个数据包(即下文所说的整包)进行分片后的最后一个分片报文。

根据第一方面，或者以上第一方面的任意一种实现方式，根据识别号和端口号信息，构建映射关系表，包括：以识别号为键，以端口号信息为键对应的值，构建映射关系表。

这样，在保证match注册机制能够支持对分片报文的端口号匹配的情况下，仅根据第一个分片报文中提取的端口号信息和分片报文中具有唯一性的识别号构建映射关系表，大大减少了映射关系表的整体大小，降低了对路由器存储空间、资源的占用。

根据第一方面，或者以上第一方面的任意一种实现方式，根据识别号和端口号信息，构建映射关系表，还包括：以识别号为键，以端口号信息对应的端口号匹配结果为键对应的值，构建映射关系表。

这样，后续接收到识别号相同的其他分片报文时，直接根据识别号从映射关系表中查找对应的匹配结果即可，无需再次执行端口号的匹配操作，大大简化了处理流程，提升了路由器内端口号匹配流程的执行效率。

根据第一方面，或者以上第一方面的任意一种实现方式，UDP数据包包括应用层面向的应用数据、传输层添加的UDP报文头、网络层添加的报文头和数据链路层添加的报文头。

也就是说，本申请中涉及的UDP数据包是四层结构，发送端在生成UDP数据包时，最先产生的是应用层面向的应用数据，应用数据从应用层向下传输经传输层时会添加对应的TCP报文头会UDP报文头。具体到本申请中，由于是为了解决IPv6的分片报文在Linux内核上实现UDP的端口号匹配，故而本申请中添加的是UDP报文头。

接着，添加UDP报文头的数据继续向下传输，经网络层，会添加IPv6报文头。

相应地，添加IPv6报文头的数据继续向下传输，经数据链路层会根据当前的网络架构，添加具体的网络报文头，如下文所说的以太网报文头。

关于UDP数据包的形成过程，可以参见下文，此处不再赘述。

这样，路由器在对接收到的数据包进行处理时，根据传输层添加的报文头就可以确定当前数据包是否为UDP数据包，进而确定是否需要对该数据包进行端口号匹配。

根据第一方面，或者以上第一方面的任意一种实现方式，根据识别号和端口号信息，构建映射关系表，还包括：从网络层添加的报文头中获取源互联网协议IP地址、目的IP地址和网络层添加的报文头对应的协议信息；根据源IP地址、目的IP地址、协议信息和端口号信息中的源端口号、目的端口号，生成五元组信息；以识别号为键，以五元组信息为键对应的值，构建映射关系表。

可理解的，本申请是为了解决IPv6的分片报文在Linux内核上实现UDP的端口号匹配，故而本申请以网络层添加的报文头为IPv6报文头为例。

相应地，获取到的协议信息，具体为IPv6。

可理解的，IPv6报文头除了携带上述所说的第一字段对应的信息、第二字段对应的信息、第三字段对应的信息，还会携带源IP地址和目的IP地址，如下文中所说的“SourceAddress”和“Destination Address”，故而直接从这两个字段对应的位置获取源IP地址和目的IP地址即可。

这样，后续同一个数据包(即下文所说的整包)分片出的其他分片报文就可以根据识别号从映射关系表中查找到对应的五元组信息，进而根据业务需求进行匹配，如根据端口号信息进行端口号匹配，或者根据IP地址信息进行IP地址匹配，根据协议进行协议匹配等，具体的应用场景可以根据实际需求进行设置，此不作限制。

根据第一方面，或者以上第一方面的任意一种实现方式，在UDP数据包不是分片报文时，方法还包括：对UDP数据包中的端口号信息进行端口号匹配。

这样，根据本申请提供的分片报文的匹配方法，在接收到的UDP数据包不是分片报文时，可以直接从UDP报文中提取端口号信息进行端口号匹配，从而既可以针对分片报文进行端口号匹配，又可以保证现有针对非分片报文的UDP数据包的端口号匹配能够正常执行。

第二方面，本申请提供了一种路由器。该路由器包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得所述路由器执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第四方面，本申请提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第五方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1为示例性示出的一种应用场景的示意图；

图2a为示例性示出的内核中对UDP报文进行端口号匹配规则的部分原生代码的示意图；

图2b为示例性示出的一种非分片报文的示意图；

图2c为示例性示出的第一个分片报文的示意图；

图2d为示例性示出的非第一个分片报文的示意图；

图2e为示例性示出的基于原生代码配置的端口号匹配规则进行的匹配示意图；

图3为示例性示出的基于本申请实施例提供的分片报文的匹配方法进行的匹配示意图；

图4为示例性示出的路由器的硬件结构示意图；

图5为示例性示出的路由器的软件结构示意图；

图6为示例性示出的协议栈的示意图；

图7为示例性示出的UDP报文涉及的网络分层示意图；

图8为示例性示出的UDP报文的形成与还原示意图；

图9为示例性示出的分片报文的示意图；

图10为示例性示出的本申请实施例提供的分片报文的匹配方法的流程示意图；

图11为示例性示出的第一个分片报文的示意图；

图12为示例性示出的第一个分片报文的示意图；

图13为示例性示出的中间的分片报文的示意图；

图14为示例性示出的最后一个分片报文的示意图；

图15为示例性示出的本申请实施例提供的又一分片报文的匹配方法的流程示意图；

图16为示例性示出的本申请实施例提供的又一分片报文的匹配方法的流程示意图。

具体实施方式

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

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

路由器是互联网的主要节点设备，目前常见的类型可以分为有线路由器和无线路由器。本申请以无线路由器为例进行说明，然在实际应用中也可以应用于有线路由器，本申请对此不作限制。

示例性性的，在一些实现方式中，无线路由器可以将家中墙上接出的宽带网络信号通过天线转发给附近的支持无线保真(wireless fidelity，Wi-Fi)的无线网络设备，例如，笔记本电脑、手机、平板电脑等电子设备。由此，如图1所示，例如笔记本电脑101、手机102、平板电脑103等电子设备可以基于路由器200来访问因特网(Internet)。

随着通信技术的发展，为了更好的维护网络安全，Linux2.4.x引入了Netfilter这一内核防火墙框架。该框架作为一个通用的、抽象的框架，提供了一整套的检测点(hook点)函数的管理机制，使得诸如数据包过滤、数据包处理、地址伪装、透明代理、动态网络地址转换(Network Address Translation，NAT)，以及基于用户及媒体访问控制(Media AccessControl，MAC)地址的过滤和基于状态的过滤、包速率限制等功能成为可能。即，采用引入了Netfilter的Linux内核的路由器进行数据传输时，可以基于Netfilter提供的管理机制，根据业务需求实现上述功能，从而更好的保障网络安全，避免恶意第三方的访问、病毒的入侵。

与此同时，Netfilter框架的扩展也十分便利，其提供了match(用于注册匹配规则)，target(用于确定目标)等注册机制，通过实例化match，target对象及其对应算法，就可以通过iptables(Linux上常用的防火墙软件)进行参数命令组合达到用户精准配置效果。

然而，在Netfilter的原生代码中，基于match注册机制在Linux内核态配置的UDP的端口匹配规则，只能针对不分片报文，如图2a示出的原生代码片段，明确规定了“Mustnot be a fragment”(必须不是分片报文)。

参见图2b，示例性示出一种不是分片报文的报文片段。如图2b所示，对于不是分片报文的报文，其携带了UDP报文头，而在UDP报文头中携带了具体的端口号信息，如源端口号(Src Port)和目的端口号(Dst Port)。

参见图2c，示例性示出一种分片报文的报文片段。如图2c所示，该分片报文为第一个分片报文，因此在其数据体Data中携带了端口号信息(具体是前8位)。

参见图2d，示例性示出又一种分片报文的报文片段。如图2d所示，该分片报文不是第一个分类报文，在其数据体Data中没有携带端口号信息，直接是需要传输的数据内容。

通过上述描述可知，对于不是分片报文的报文，其携带了UDP报文头，因此根据UDP报文头可以直接获取到端口号信息，而对分片报文，除了第一个分片报文的数据体中会携带端口号信息，其余分片报文是不携带端口号信息的。基于此，在已有的一些实现方式中，基于match注册机制在Linux内核态配置的UDP的端口匹配规则，路由器在接收到数据包时进行的UDP端口匹配可以如图2e所示。

参见图2e，当发送端，可以是网络侧设备，也可以是用户侧设备提供的数据包(报文)到达路由器时，路由器会根据基于Netfilter的原生代码配置的端口号匹配规则进行匹配。

继续参见图2e，示例性的，路由器会确定接收到的数据包是否为UDP数据包，当确定是UDP数据包时进一步确定当前数据包是否是一个分片报文，如果不是分片报文，则根据端口号匹配规则进行匹配，并返回匹配结果，例如ture或false。相应地，如果是分片报文，则直接不进行端口号匹配操作。

然后在实际应用中，受设备支持的最大传输单元(Maximum transimission unit，MTU)的限制，需要传输的数据往往会被拆分为多个数据包，即进行分片。而对于分片报文，通过上述描述可知，只有第一个分片报文携带UDP报文头，后续的分片报文不携带UDP报文头，这就导致不携带UDP报文头的分片报文，无法进行匹配，如图2e所示，在数据包为UDP报文，且时分片报文时，直接不执行匹配操作。

有鉴于此，为了解决上述问题，本申请实施例提供了一种分片报文的匹配方案。在该方案中，通过构建分片报文中具有唯一性的识别号与端口号信息之间的映射关系，进而在接收到分片报文时根据识别号从映射关系中确定对应的端口号信息，优化了内核原生代码match注册机制不支持针对分片报文的端口号匹配缺陷，使得用户在防火墙配置时，不用再担心基于端口号的端口号匹配规则无法实现对分片报文的匹配，从而提高了基于端口匹配而开发的功能的易用性和可靠性。

也就是说，基于本申请实施例提供的分片报文的匹配方案，当发送端提供的数据包到达路由器后，路由器会根据基于本申请提供的方案优化后的原生代码配置的端口号匹配规则进行匹配。

参见图3，示例性的示出一种路由器根据基于本申请提供的方案优化后的原生代码配置的端口号匹配规则进行匹配的示意图。如图3所示，当路由器接收到发送端提供的数据包后，会确定接收到的数据包是否为UDP数据包，当确定是UDP数据包时进一步确定当前数据包是否是一个分片报文，如果不是分片报文，则直接从UDP报文头中获取端口号信息，进而根据端口号匹配规则进行匹配，并返回匹配结果，例如ture或false。

继续参见图3，如果是UDP报文，且为分片报文，则根据本申请提供的分片报文的匹配方案确定当前分片报文的端口号信息，进而根据端口号匹配规则进行匹配，并返回匹配结果，例如ture或false。

为了更好的理解本申请实施例提供的技术方案，下面结合图4和图5对路由器的硬件结构和软件结构进行介绍。

参见图4，路由器200可以包括：一个或多个中央处理器(Central ProcessingUnits，CPU)201和存储器205，该存储器205中存储有一个或多个应用程序或数据。

其中，中央处理器201可以是路由器200的神经中枢和指挥中心。中央处理器201可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。中央处理器201中还可以设置存储器，用于存储指令和数据。在一些实施例中，中央处理器201中的存储器为高速缓冲存储器。

其中，存储器205可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。存储器205可以是易失性存储器或持久存储器。存储在存储器205中的计算机可执行程序代码可以包括一个或多个模块，每个模块可以包括对无线路由器中的一系列指令操作。存储器205可以包括存储程序区和存储数据区。

更进一步地，中央处理器201可以设置为与存储器205通信，在路由器200上执行存储器205中的一系列指令操作。其中，中央处理器201通过运行存储在存储器205中的计算机程序指令，从而执行路由器200的各种功能以及数据处理，例如使得路由器200实现本申请实施例提供的分片报文的匹配方法。

路由器200还可以包括一个或多个电源202，一个或多个有线或无线网络接口203，一个或多个输入输出接口204，和/或，一个或多个操作系统，例如Windows ServerTM，MacOS XTM，UnixTM，LinuxTM，FreeBSDTM等。具体到本实施例中，以Linux2.4版本后的操作系统为例，即引入了Netfilter的Linux系统为例。

该路由器200可以执行下述实施例中路由器所执行的操作，具体此处不再赘述。

关于路由器200的硬件结构就介绍到此，应当理解的是，图4所示路由器200仅是一个范例，在具体实现中，路由器200可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图4中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

为了更好的理解图4所示路由器200的软件结构，以下对路由器200的软件结构进行说明。在对路由器2000的软件结构进行说明之前，首先对路由器200的软件系统可以采用的架构进行说明。

具体的，在实际应用中，路由器200的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的系统为例，示例性说明路由器200的软件结构。

参见图5，为本申请实施例的路由器200的软件结构框图。

如图5所示，路由器200的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将路由器200的系统分为三层，从上至下分别为应用程序层，内核层及驱动层。

应用程序层可以包括一系列应用程序包。如图5所示，应用程序包可以包括设置应用。具体的说，在实际应用中，用户可以通过访问设置应用对路由器进行Wi-Fi设置、上网设置、安全设置等。

示例性的，在一些实现方式中，用户可以通过上网设置入口和/或安全设置入口进行端口号匹配规则的设置。

继续参见图5，示例性的，内核层包括协议栈，其中，协议栈例如为TCP(Transmission Control Protocol，传输控制协议)/IP(Internet Protocol，互联网协议)协议栈。在本实施例中，内核层至少还包括分片报文匹配处理模块。其中，分片报文匹配处理模块可以设置于IP协议栈(或TCP/IP协议栈)中，具体可以根据业务需要设置在协议栈的任意一个hook点中。在本实施例中，分片报文匹配处理模块可以用于根据接收到的数据包(报文)进行报文类型识别，在确定是UDP报文，且为分片报文时，确定每一个分片报文的端口号信息，进而根据端口号匹配规则进行端口号匹配。其中，报文类型可以包括TCP报文、UDP报文等。

需要说明的是，在内核IP协议栈(或TCP/IP协议栈)中，Netfilter框架是通过5个关键的hook点对数据包(报文)进行处理的，即上述所说的分片报文匹配处理模块可以设置于这5个hook点的任意一个中。

参见图6，示例性的，上述提及的5个关键的hook点分别是PRE_ROUTING节点、LOCAL_IN节点、LOCAL_OUT节点、FORWARD节点以及POST_ROUTING节点。其中，PRE_ROUTING节点是报文路由前处理节点，主要用于处理目的地址转换(DNAT)及给报文添加特定标志等；FORWARD节点是转发报文关键节点；POST_ROUTING节点是报文路由后处理节点，主要用于处理源地址转换(SNAT)；LOCAL_IN节点和LOCAL_OUT节点分别是路由本地业务处理节点的入口和出口。

继续参见图6，路由决策节点用于决策报文是转发处理还是给路由器本身业务(例如Web等业务)使用；四层及以上的协议栈用于对路由器本身业务数据进行处理。

其中，路由器的下挂设备(例如手机等)需要无线路由器进行转发处理的数据会经过PRE_ROUTING节点、FORWARD节点、POST_ROUTING节点这三个关键hook点。参照图6所示，来自手机的数据流经过PRE_ROUTING节点的处理后，由路由决策节点进行决策，若确定当前流入的数据流需要转发至无线网络(即访问外网的)，则数据流会流入FORWARD节点进行处理，并在经过POST_ROUTING节点的处理后被转发至无线网络中。由此，根据业务需要，可以将分片报文匹配处理模块设置于上述5个hook点中的任意一个当中。即保证最终发出去的数据包是满足匹配规则的即可。

此外，需要指出的是，本实施例中所说的报文是经应用层、传输层、网络层和数据链路层封装获得的。

关于上述所说的应用层、传输层、网络层和数据链路层，具体到开放式系统互联通信参考模型(OSI网络分层模型)这个7层协议模型中，具体涉及的是位于第2层的数据链路层、位于第3层的网络层、位于第4层的传输层和位于第7层的应用层。

参见图7，OSI网络分层模型这个7层协议模型，从下至上分别是：物理层—>数据链路层—>网络层—>传输层—>会话层—>表示层—>应用层。其中，位于第1层的物理层，具体是指网络的物理形式，如电缆、光纤、网卡、集线器等；位于第2层的数据链路层相当于TCP/IP五层协议栈的链路层；位于第3层的网络层相当于TCP/IP五层协议栈的网际层(IP层)；位于第4层的传输层相当于TCP/IP五层协议栈的传输层；位于第5层的会话层，具体用于维护网络中的连接状态，即保持回话和同步；位于第6层的表示层，具体用于把数据转换成合适的、可理解的语法和语义；位于第7层的应用层，面向具体的应用传输数据。

对应到TCP/IP五层协议栈的体系结构中，OSI网络分层模型中的第5～7层统一对应应用层，其他的层分别与OSI网络分层模型相对应。

对应到TCP/IP四层协议栈的体系结构中，OSI网络分层模型中的第5～7层统一对应应用层，第1、第2层统一为网络接口层，其他的层分别与OSI网络分层模型相对应。

继续参见图7，示例性的，本申请各实施例所说的数据包/报文对应于每一层的所做的操作例如为：

在应用层面向具体的应用传输数据例如可以遵循应用层传输协议，如超文本传输协议(Hyper Text Transfer Protocol，HTTP)，得到实际要传输的HTTP数据体，或者UDP协议，得到实际要传输的UDP数据体，具体到本实施例中以UDP数据体为例。

在传输层对应的传输协议例如为可以包括TCP协议，或UDP协议，即经过传输层，根据对应的协议添加报文头，如第HTTP数据体添加TCP报文头，或对UDP数据体添加UDP报文头后，报文类型可以被确定为TCP报文或UDP报文，具体到本实施例中以UDP报文为例。

在网络层对应的传输协议，例如可以为IP协议和ICMP(Internet ControlMessage Protocol，互联网控制报文协议)。

继续参见图7，进一步地，IP协议又可以分为IPv4(Internet Protocol Version4，互联网协议第4版本)和IPv6(Internet Protocol Version 6，互联网协议第6版本)，具体到本实施例中以IPv6为例。即经过网络层后，还会添加IPv6报文头。

在数据链路层，则会根据具体的网络架构添加对应的报文头，如对于以太网架构，添加的是以太网报文头。

为了更好的理解发送端经过应用层、传输层、网络层和数据链路层得到的数据包经路由器传输给接收端的过程，以下结合图8以非分片报文(即包括携带了端口号信息的UDP报文头的报文)的在发送端的形成，以及在接收端的还原过程进行说明。

参见图8，示例性的，以应用层面向的具体需要传输的应用数据为UDP数据为例，当该数据经过传输层时，会为UDP数据添加UDP报文头。

继续参见图8，示例性的，经传输层添加UDP报文头的数据继续向下传输，经网络层，基于图7所示的IPv4协议可以添加IPv4报文头，也可以基于IPv6协议添加IPv6报文头，还可以根据ICMP协议添加ICMP报文头。本实施例以基于IPv6协议添加IPv6报文头。

继续参见图8，示例性的，经网络层添加IPv6报文头的数据继续向下传输，经数据链路层，会根据当前的网络架构添加对应的报文头，如根据以太网架构，添加以太网报文头，即每通过一层，就增加对应的报文头，将上一层的数据作为数据体，这样就得到了最终发送给路由器的数据包/报文。

相应地，路由器在接收到发送端发送的上述结构的数据包后，在流经设置了上述所说的分片报文匹配处理模块所在的hook点时，就会由分片报文匹配处理模块确定接收到的数据包是否为UDP数据包，当确定是UDP数据包时进一步确定当前数据包是否是一个分片报文，如果不是分片报文，则直接从UDP报文头中获取端口号信息，进而根据端口号匹配规则进行匹配，并返回匹配结果，例如ture或false。反之，如果是UDP报文，且为分片报文，则确定当前分片报文的端口号信息，进而根据端口号匹配规则进行匹配，并返回匹配结果，例如ture或false。

继续参见图8，示例性的，路由器执行完上述操作后，最终会将满足配置要求的数据包发送给接收端。

继续参见图8，示例性的，对于接收端其处理过程与接收端相反，即每通过一层，就删除该层对应的报文头，这样当数据到达最上层的应用层时，就会还原出发送端发送的UDP数据。

参见图9，示例性的，发送端生成的数据包受设备支持的足大传输单元MTU限制，比如图9示出的MTU＝1500字节。对于这种情况，当应用层面向的需要传输的UDP数据大于1500字节时，UDP数据经传输层添加UDP报文头后，会将UDP报文头+UDP数据作为一个整体(为了便于说明后续称为整包)进行分片(也可以理解为拆包)，如图9所示，以1500字节为单位，将整包拆分为多个分片报文，其中第一个分片报文和中间的分为报文大小均为1500字节，最后一个分片报文可能因剩余的UDP数据不足1500字节，不满1500字节，也可以刚好1500字节。

需要说明的是，在一些实现方式中，整包的结构为UDP报文头+UDP数据，因此在对整包进行分片时，第一个分片报文中会包括UDP报文头，剩余的字节会填充UDP数据，而后续的分片报文则直接从前一个分片报文截止的UDP数据开始填充UDP数据。故而，经过传输层的分片处理后，只有第一个分片报文包括了UDP报文头，而后续的则没有，即从结构上第一个分片报文后的分片报文其结构为图9示出的应用层数据封装网络层的IPv6报文头，然后再封装数据链路层的以太网报文头。

此外，还需要说明的是，由于每一个整包对应的分片报文中的识别号字段(identification)是相同的，故而本实施例中通过将identification作为分片报文标识，建立identification与第一个分片报文中携带的UDP报文头中的端口号信息之间的映射关系，基于该映射关系和从每一个分片报文中提取出的identification，就可以确定当前报文对应的端口号信息，进而实现对分片报文的匹配。

此外，需要说明的是，在本实施例中，提供数据包的发送端，例如可以是网络侧设备或用户侧设备，接收数据包的接收端可以是用户侧设备或网络侧设备。

示例性的，对于发送端和接收端均为用户侧设备的应用场景，例如可以是通过路由器将均为用户侧设备的发送端和接收端接入到同一局域网，进而实现单机游戏之间的数据交互，或者企业内不同员工通过不同的用户侧设备进行文件交互的场景。

示例性的，对于发送端为网络侧设备，接收端为用户侧设备的应用场景，例如可以是作为网络侧设备的服务器向接入的用户侧设备推送系统升级包、游戏升级包等。

示例性的，对于发送端为用户侧设备，接收端为网络侧设备的应用场景，例如可以是用户侧设备通过网页访问外网的网络侧设备，进行数据获取。

示例性的，对于发送端为网络侧设备，接收端为网络侧设备的应用场景，例如为不通服务器之间的信息交互。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

关于确定当前分片报文的端口号信息的具体实现逻辑和细节，详见下文，此处不再赘述。

驱动层是硬件和软件之间的层。驱动层至少包含Wi-Fi驱动等。其中，硬件至少包括处理器、Wi-Fi模块等。

可以理解的是，图5示出的软件结构中的层以及各层中包含的部件，并不构成对路由器200的具体限定。在本申请另一些实施例中，路由器200可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

此外，还可以理解的是，路由器为了实现本申请实施例中的分片报文的匹配方法，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

基于上述硬件结构和软件结构，针对上文所描述的应用场景，本申请实施例提供的分片报文的匹配方法的实现流程如图10所示，具体包括：

S101，确定数据包为UDP数据包。

示例性的，通过上述描述可知，不论是UDP数据包还是TCP数据包，亦或其他类型的数据包，在经过上述网络结构对应的每一层后，都会添加对应的报文头，因此路由器接收到数据包后，通过获取传输层添加的报文头，根据该报文头所遵循的协议就可以知道当前数据包是否为UDP数据包。

相应地，在确定数据包为UDP数据包后，就可以调用内核提供的UDP匹配函数(udp_mt函数)进行端口号匹配。

需要说明的是，具体到本实施例中，为了使得udp_mt函数可以支持对分片报文进行端口号匹配，本实施例对udp_mt函数的执行逻辑进行了重构。具体是在确定数据包为UDP数据包时，不按照图2a示出的原生代码的处理流程进行匹配处理，而是经图10中示出的步骤S102至步骤S113的处理流程进行匹配处理。

S102，解析数据包的IPv6报文头。

具体的，在本实施例中，在确定数据包为UDP报文时，首先解析数据包的IPv6报文头，进而得到如图11中示出的信息，如“Payload Length”字段对应的信息、“Next Header”字段对应的信息等。其中，“Payload Length”字段指示该数据包的载荷长度，如图11示出的为1456字节；“Next Header”字段指示该数据包后是否还有其他数据包(报文)。

此外，需要说明的是，当“Next Header”字段对应的信息为“44”时，如图11中示出的“Fragment Header for IPv6(44)”，指示该数据包为分片报文。

可理解的，用“44”指示当前数据包为分片报文，具体是根据RFC(Request ForComments，是一些列以编号排定的文件)协议规定的，未在本实施例写明的地方可以参见RFC协议，此处不再赘述。

S103，根据IPv6报文头中Next Header字段对应的信息确定数据包是否为分片报文。

基于上述描述，可知“Next Header”字段对应的信息可以用于确定是否为分片报文，因此在对数据包的IPv6报文头进行解析后，可以提取“Next Header”字段对应的信息，进而确定“Next Header”字段对应的信息是否为上文所说的“44”。

相应地，若不是“44”，表面该数据包不是分片报文，是一个携带了端口号信息的UDP报文。故而，直接执行步骤S104；反之，如果是“44”，表面该数据包是UDP报文，且是一个分片报文，此时执行步骤S106，而非如图2a和图2e所示，直接不进行端口号匹配。

S104，解析数据包的UDP报文头，得到端口号信息。

示例性的，当数据包是UDP报文，但不是分片报文时，表面该数据包携带了UDP报文头，因此可以直接对UDP报文头进行进行，进而得到如图2b所示的“Src Port”字段对应的信息“57844”，以及“Dst Port”字段对应的信息“5201”。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

S105，对端口号信息进行匹配，得到匹配结果。

示例性的，在对UDP报文头进行解析获得源端口号和目的端口号的端口号信息后，就可以基于udp_mt函数，根据配置的端口号匹配规则对端口号信息进行匹配，如确定当前数据包对应的端口号信息是否在配置的端口号匹配规则表中。

示例性的，在一些实现方式中，可以约定获取的端口号信息与端口号匹配规则表中记录的匹配时，返回“true”作为匹配结果，即表明不匹配。

相应地，在获取的端口号信息与端口号匹配规则表中记录的不匹配时，返回“false”作为匹配结果，即表明不匹配。

示例性的，在另一些实现方式中，还可以约定匹配时返回“1”作为匹配结果，不匹配时返回“0”作为匹配结果。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，可以遵循udp_mt函数返回的匹配结果的标准协议，本实施例对此不作限制。

S106，根据IPv6报文头中Offset字段对应的信确定数据包是否为第一个分片报文。

需要说明的是，在数据包为UDP报文，且是一个分片报文时，其对应的IPv6报文头中还会包括“Offset”字段、“More Fragments”字段、“Identification”字段等。

其中，“Offset”字段指示该分片报文是否为第一个分片报文。示例性的，在本实施例中，当“Offset”字段对应的信息为“0”时，指示该分片报文是第一个分片报文，非0时，则指示该分片报文不是第一个分片报文，即可能是中间的分片报文，或者最后一个分片报文。

其中，“More Fragments”字段指示该分片报文后是否还有其他分片报文。示例性的，在本实施例中，当“More Fragments”字段对应的信息为“Yes”，或者“More Fragments”字段前的内容为“1”时，指示该分片报文后还有其他分片报文；当“More Fragments”字段对应的信息为“No”，或者“More Fragments”字段前的内容为“0”时，指示该分片报文后没有其他分片报文，这种情况下，表面当前分片报文为最后一个分片报文。

其中，“Identification”字段(也可以称为识别号字段)对应的信息用于标识当前分片报文。可理解的，同一个整包分片出的多个分片报文，“Identification”字段对应的信息是相同的。

可理解的，上述说明仅罗列了实现本案所需的字段，在实际应用中，IPv6报文头中还可以包括其他字段，此处不再赘述。

基于上述描述，继续参见图11，示例性的，在“Next Header”字段对应的信息为“Fragment Header for IPv6(44)”，即“44”，“Offset”字段对应的信息为“0”，“MoreFragments”字段对应的内容为“Yes”时，根据上述对这三个字段的描述可知，当前数据包是分片报文的头数据包，即第一个分片报文。

相应地，在确定当前接收到的数据包是第一个分片报文时，进入步骤S107至步骤S109的分支，进行匹配处理；反之，进入步骤S110至步骤S113的分支进行匹配处理。

可理解的，在数据包不是第一个分片报文时，存在两种情况，一种是该数据包为中间的分片报文，一种是该数据包为最后一个分片报文。对于数据包是中间的分片报文的情况，上述几个字段对应的信息，例如可以如图13所示；对于数据包是最后一个分片报文的情况，上述几个字段对应的信息，例如可以如图14所示。

参见图13，示例性的，在“Next Header”字段对应的信息为“Fragment Header forIPv6(44)”，即“44”，“Offset”字段对应的信息为非0，如图13中的“181”，“More Fragments”字段对应的内容为“Yes”时，根据上述对这三个字段的描述可知，当前数据包是分片报文，但不是第一个分片报文，也不是最后一个分片报文，即是中间的分区报文。

参见图14，示例性的，在“Next Header”字段对应的信息为“Fragment Header forIPv6(44)”，即“44”，“Offset”字段对应的信息为非0，如图14中的“905”，“More Fragments”字段对应的内容为“No”时，根据上述对这三个字段的描述可知，当前数据包是分片报文，且是最后一个分片报文。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

S107，提取数据包的五元组信息和数据包的识别号。

示例性的，在本实施例中，上述所说的五元组信息，例如包括源端口号、目的端口号、源IP地址、目的IP地址和协议。其中，源IP地址例如从图11示出的IPv6报文头中“SourceAddress”字段对应的信息提取，目的IP地址则从图11示出的IPv6报文头中“DestinationAddress”字段对应的信息提取，协议则为IPv6。

此外，通过上文描述可知，在第一个分片报文中，Data部分的前8位携带的是源端口号和目的端口号，基于此可以从如图12所示的“Data”字段对应的信息中截取前8位“d8bf1e61”。

此外，需要说明的是，由于Data部分的信息是16进制的，每2位16进制的符号表示一个字节，根据现有协议可知，第一个分片报文中携带的UDP报文头占前4个字节，其中前两个字节对应的是源端口号，即图12中“d8bf”对应的是源端口号，后两个字节对应的是目的端口号，即图12中“1e61”对应的是目的端口号。

相应地，识别号字段，即为上述所说的“Identification”字段，相应地识别号即“Identification”字段对应的信息，如图12中的“0x13999605”。

S108，建立识别号字段和五元组信息之间的映射关系表。

示例性的，在一些实现方式中，映射关系表例如可以是哈希hash映射关系表。由于“Identification”字段对应的识别号具有唯一性，即同一个整包分片出的分片报文的识别号均相同，故而本实施例以识别号为键(key)，以上述获得的五元组信息为值(value)，构建hash映射关系表。这样，后续同一个整包分片出的其他分片报文就可以根据识别号从hash映射关系表中查找到对应的五元组信息，进而根据业务需求进行匹配，如根据端口号信息进行端口号匹配，或者根据IP地址信息进行IP地址匹配，根据协议进行协议匹配等，具体的应用场景可以根据实际需求进行设置，本实施对此不作限制。

S109，对五元组信息中的端口号信息进行匹配，得到匹配结果。

关于匹配结果的形式，可以参见步骤S105，此处不再赘述。

此外，还需要说明的是，在实际应用中，步骤S108和步骤S109的执行顺序可以对调，本实施例对此不作限制。

S110，提取数据包的识别号，根据识别号在映射关系表中查找对应的端口号信息。

参见图11至图14可知，对于由一个整包分片出的分片报文，其携带的识别号均相同，如图11至图14所例举的示例，识别号均为“0x13999605”。而根据上述步骤S107和步骤S108的描述可知，本实施例中构建的hash映射关系表，是以识别号为key，value中包括了对应的端口号信息。故而根据当前数据包的识别号，就可以在映射关系表中查找到对应的端口号信息。

S111，根据IPv6报文头中More Fragments字段对应的信确定数据包是否为最后一个分片报文。

通过上文针对图14，以及关于“More Fragments”字段作用的描述可知，当“MoreFragments”字段对应的信息为“No”，或者“More Fragments”字段前的内容为0时，指示当前分片报文为最后一个报文，故而只需提取“More Fragments”字段对应的信息，确定其是否为“No”或者“0”就可以确定当前接收到的数据包是否为最后一个分片报文。

相应地，如果是，则执行步骤S112，对从映射关系表中查找到的端口号信息进行匹配，得到匹配结果，并删除该数据包的识别号对应的hash映射关系表，从而减少对路由器资源存储空间、资源的占用；反之，则执行步骤S113，即只执行端口号匹配操作，不删除对应的hash映射关系表。

S112，对从映射关系表中查找到的端口号信息进行匹配，得到匹配结果，并删除记录查找到的端口号信息的映射关系表。

S113，对从映射关系表中查找到的端口号信息进行匹配，得到匹配结果。

关于匹配结果的形式，可以参见步骤S105，此处不再赘述。

此外，需要说明的是，上述步骤S110至步骤S113的执行顺序，在实际应用中也可以根据需要进行调整，例如在步骤S106确定当前数据包不是第一个分片报文时，可以直接执行上述步骤S111。

相应地，在确是最后一个分片报文时，先执行上述步骤S110，再执行上述步骤S112；反之，在确定不是最后一个分片报文时，先执行上述步骤S110，再执行上述步骤S113。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，本实施例提供的分片报文的匹配方法，通过构建分片报文中具有唯一性的识别号与端口号信息之间的映射关系，进而在接收到分片报文时根据识别号从映射关系中确定对应的端口号信息，优化了内核原生代码match注册机制不支持针对分片报文的端口号匹配缺陷，使得用户在防火墙配置时，不用再担心基于端口号的端口号匹配规则无法实现对分片报文的匹配，从而提高了基于端口匹配而开发的功能的易用性和可靠性。

应当理解的是，上述实施例中构建的映射关系表仅为一种具体的实现形式，不作为唯一的限制。在实际应用中，构建的映射关系表可以是以识别号为key，以从第一个分片报文中提取出的端口号信息(源端口号和目的端口号)为value。对于这种形式的映射关系表，分片报文的匹配方法可以如图15所示，具体包括：

S201，确定数据包为UDP数据包。

S202，解析数据包的IPv6报文头。

S203，根据IPv6报文头中Next Header字段对应的信息确定数据包是否为分片报文。

S204，解析数据包的UDP报文头，得到端口号信息。

S205，对端口号信息进行匹配，得到匹配结果。

S206，根据IPv6报文头中Offset字段对应的信确定数据包是否为第一个分片报文。

不难发现，本实施例中的步骤S201至步骤S206，与上述实施例中的步骤S101至步骤S106大致相似，未在本实施例中详细说明的技术细节可以参见上述实施例，此处不再赘述。

S207，提取数据包的端口号信息和数据包的识别号。

即，从第一个分片报文的Data部分提取前8位字符，根据这8位字符的前4位，确定上文所说的源端口号号，根据这8位字符的后4位，确定上文所说的目的端口号和标识分片报文是来自同一个整包的识别号。

S208，建立识别号字段和端口号信息之间的映射关系表。

即，以识别号为key，以端口号信息为value。

S209，对端口号信息进行匹配，得到匹配结果。

关于匹配结果的形式，可以参见上述实施例中的步骤S105，此处不再赘述。

此外，还需要说明的是，在实际应用中，步骤S208和步骤S209的执行顺序可以对调，本实施例对此不作限制。

S210，提取数据包的识别号，根据识别号在映射关系表中查找对应的端口号信息。

S211，根据IPv6报文头中More Fragments字段对应的信确定数据包是否为最后一个分片报文。

S212，对从映射关系表中查找到的端口号信息进行匹配，得到匹配结果，并删除记录查找到的端口号信息的映射关系表。

S213，对从映射关系表中查找到的端口号信息进行匹配，得到匹配结果。

不难发现，本实施例中的步骤S210至步骤S213，与上述实施例中的步骤S110至步骤S113大致相似，未在本实施例中详细说明的技术细节可以参见上述实施例，此处不再赘述。

此外，还需要说明的是，上述步骤S210至步骤S213的执行顺序，在实际应用中也可以根据需要进行调整，例如在步骤S206确定当前数据包不是第一个分片报文时，可以直接执行上述步骤S211。

相应地，在确是最后一个分片报文时，先执行上述步骤S210，再执行上述步骤S212；反之，在确定不是最后一个分片报文时，先执行上述步骤S210，再执行上述步骤S213。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，本实施提供的分片报文的匹配方法，在保证match注册机制能够支持对分片报文的端口号匹配的情况下，仅根据第一个分片报文中提取的端口号信息和分片报文中具有唯一性的识别号构建映射关系表，大大减少了映射关系表的整体大小，降低了对路由器存储空间、资源的占用。

应当理解的是，上述实施例中构建的映射关系表仅为一种具体的实现形式，不作为唯一的限制。在实际应用中，构建的映射关系表还可以是以识别号为key，以第一个分片报文的匹配结果为value。对于这种形式的映射关系表，分片报文的匹配方法可以如图16所示，具体包括：

S301，确定数据包为UDP数据包。

S302，解析数据包的IPv6报文头。

S303，根据IPv6报文头中Next Header字段对应的信息确定数据包是否为分片报文。

S304，解析数据包的UDP报文头，得到端口号信息。

S305，对端口号信息进行匹配，得到匹配结果。

S306，根据IPv6报文头中Offset字段对应的信确定数据包是否为第一个分片报文。

不难发现，本实施例中的步骤S301至步骤S306，与上述实施例中的步骤S101至步骤S106大致相似，未在本实施例中详细说明的技术细节可以参见上述实施例，此处不再赘述。

S307，提取数据包的端口号信息和数据包的识别号。

即，从第一个分片报文的Data部分提取前8位字符，根据这8位字符的前4位，确定上文所说的源端口号号，根据这8位字符的后4位，确定上文所说的目的端口号和标识分片报文是来自同一个整包的识别号。

S308，对端口号信息进行匹配，得到匹配结果。

关于匹配结果的形式，可以参见上述实施例中的步骤S105，此处不再赘述。

S309，建立识别号字段和匹配结果之间的映射关系表。

即，以识别号为key，以第一个分片报文中端口号信息的匹配结果为value。这样，后续接收到识别号相同的其他分片报文时，直接根据识别号从映射关系表中查找对应的匹配结果即可，无需再次执行端口号的匹配操作，大大简化了处理流程，提升了路由器内端口号匹配流程的执行效率。

S310，根据IPv6报文头中More Fragments字段对应的信确定数据包是否为最后一个分片报文。

不难发现，本实施例中的步骤S310，与上述实施例中的步骤S111大致相似，未在本实施例中详细说明的技术细节可以参见上述实施例，此处不再赘述。

S311，提取数据包的识别号，根据识别号在映射关系表中查找对应的匹配结果，并删除记录查找到的匹配结果的映射关系表。

S312，提取数据包的识别号，根据识别号在映射关系表中查找对应的匹配结果。

由此，本实施例提供的分片报文的匹配方法，在保证match注册机制能够支持对分片报文的端口号匹配的情况下，直接将根据第一个分片报文中提取的端口号信息进行的端口号匹配结果作为映射关系表的value，进一步减少了映射关系表的整体大小，降低了对路由器存储空间、资源的占用。

并且，由于映射关系表是以识别号为key，以第一个分片报文中端口号信息的匹配结果为value。因此，后续接收到识别号相同的其他分片报文时，直接根据识别号从映射关系表中查找对应的匹配结果即可，无需再次执行端口号的匹配操作，大大简化了处理流程，提升了路由器内端口号匹配流程的执行效率。

应当理解的是，上述所例举的各实施例，仅是为了更好的理解本申请提供的分片报文的匹配方案而列举具体实现方式，不作为对本申请的唯一限制。

此外，还应当理解的是，本文中示出的各报文的附图是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，还可以理解的是，路由器为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

此外，需要说明的是，在实际的应用场景中由路由器实现的上述各实施例提供的分片报文的匹配方法，也可以由路由器中包括的一种芯片系统来执行，其中，该芯片系统可以包括处理器。该芯片系统可以与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述路由器执行的步骤。其中，该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。

另外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在路由器上运行时，使得路由器执行上述相关方法步骤实现上述实施例中的分片报文的匹配方法。

另外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在路由器上运行时，使得路由器执行上述相关步骤，以实现上述实施例中的分片报文的匹配方法。

另外，本申请的实施例还提供一种芯片(也可以是组件或模块)，该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的分片报文的匹配方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

此外，通过上述描述可知，本申请实施例提供的路由器、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (13)

1.一种分片报文的匹配方法，其特征在于，包括：

在接收到的数据包为用户数据报协议UDP数据包时，确定所述UDP数据包是否是分片报文，所述分片报文中包括识别号，所述识别号用于标识所述UDP数据包对应的未分片的数据包，所述未分片的数据包进行分片后，包括所述分片报文；

在所述UDP数据包是分片报文时，确定所述UDP数据包是否是第一个分片报文，所述第一个分片报文包括端口号信息；

在所述UDP数据包是第一个分片报文时，对所述端口号信息进行端口号匹配，并根据所述识别号和所述端口号信息，构建映射关系表；

在所述UDP数据包不是第一个分片报文时，根据所述识别号从所述映射关系表中查找所述端口号信息，并对查找到的所述端口号信息进行端口号匹配。

2.根据权利要求1所述的方法，其特征在于，所述端口号信息位于所述第一分片报文的数据体的前8位。

3.根据权利要求2所述的方法，其特征在于，所述端口号信息包括源端口号和目的端口号；

所述第一分片报文的数据体的前8位中前4位上的字符对应所述源端口号，所述第一分片报文的数据体的前8位中后4位上的字符对应所述目的端口号。

4.根据权利要求1所述的方法，其特征在于，所述UDP数据包包括互联网协议第6版本IPv6报文头；

所述确定所述UDP数据包是否是第一个分片报文，包括：

确定所述IPv6报文头中第一字段对应的信息是否是第一信息；

在所述第一字段对应的信息是第一信息时，确定所述IPv6报文头中第二字段对应的信息确是否为第二信息；

在所述第二字段对应的信息是第二信息时，确定所述UDP数据包是第一个分片报文；

在所述第二字段对应的信息不是所述第二信息时，确定所述UDP数据包不是第一个分片报文。

5.根据权利要求1所述的方法，其特征在于，在所述UDP数据包不是第一个分片报文时，所述方法还包括：

确定所述UDP数据包是否是最后一个分片报文；

在所述UDP数据包是最后一个分片报文时，在对查找到的所述端口号信息进行端口号匹配之后，删除所述映射关系表。

6.根据权利要求5所述的方法，其特征在于，所述UDP数据包包括IPv6报文头；所述确定所述UDP数据包是否是最后一个分片报文，包括：

获取所述IPv6报文头中第三字段对应的信息；

在所述第三字段对应的信息是第三信息时，确定所述UDP数据包是最后一个分片报文；

在所述第三字段对应的信息是第四信息时，确定所述UDP数据包不是最后一个分片报文。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述根据所述识别号和所述端口号信息，构建映射关系表，包括：

以所述识别号为键，以所述端口号信息为所述键对应的值，构建映射关系表。

8.根据权利要求1至6任一项所述的方法，其特征在于，所述根据所述识别号和所述端口号信息，构建映射关系表，还包括：

以所述识别号为键，以所述端口号信息对应的端口号匹配结果为所述键对应的值，构建映射关系表。

9.根据权利要求1至6任一项所述的方法，其特征在于，所述UDP数据包包括应用层面向的应用数据、传输层添加的UDP报文头、网络层添加的报文头和数据链路层添加的报文头。

10.根据权利要求9所述的方法，其特征在于，所述根据所述识别号和所述端口号信息，构建映射关系表，还包括：

从所述网络层添加的报文头中获取源互联网协议IP地址、目的IP地址和所述网络层添加的报文头对应的协议信息；

根据所述源IP地址、目的IP地址、协议信息和所述端口号信息中的源端口号、目的端口号，生成五元组信息；

以所述识别号为键，以所述五元组信息为所述键对应的值，构建映射关系表。

11.根据权利要求1至6任一项所述的方法，其特征在于，在所述UDP数据包不是分片报文时，所述方法还包括：

对所述UDP数据包中的端口号信息进行端口号匹配。

12.一种路由器，其特征在于，所述路由器包括：存储器和处理器，所述存储器和所述处理器耦合；所述存储器存储有程序指令，所述程序指令由所述处理器执行时，使得所述路由器执行如权利要求1至11任意一项所述的分片报文的匹配方法。

13.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在路由器上运行时，使得所述路由器执行如权利要求1至11任意一项所述的分片报文的匹配方法。