CN105871725A - 一种报文分流方法及装置 - Google Patents
一种报文分流方法及装置 Download PDFInfo
- Publication number
- CN105871725A CN105871725A CN201510036029.XA CN201510036029A CN105871725A CN 105871725 A CN105871725 A CN 105871725A CN 201510036029 A CN201510036029 A CN 201510036029A CN 105871725 A CN105871725 A CN 105871725A
- Authority
- CN
- China
- Prior art keywords
- bit
- address
- rss
- source
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Abstract
一种报文分流方法及装置,该方法包括:将RSS随机秘钥中与RSS分流数据的待屏蔽比特在位置上相对应的比特及其后续的连续31个比特设置为0;使用上述RSS随机秘钥对接收到的报文的RSS分流数据进行哈希运算,根据哈希运算得到的哈希值对该报文进行分流处理;其中,上述RSS分流数据由一个或多个报文头字段组成。本申请可以充分利用网卡硬件已有的RSS报文分流技术,通过对网卡寄存器中的RSS随机秘钥进行设置实现报文分流,在现有的分流方式的基础上派生出多种新的分流方式以满足更多更灵活的系统需求,同时避免了管道模式对系统性能造成的不利影响。
Description
技术领域
本申请涉及网络通信领域,尤其涉及一种报文分流方法及装置。
背景技术
多核处理器是指在一块处理器中集成两个或多个完整的计算引擎(内核)。在多核、多处理器环境中,当访问多个处理器核心共享的资源时需要进行加锁处理,而加锁对系统整体性能的负面影响很大。为了避免加锁带来的开销及对系统性能的负面影响,在系统设计时通常会设法避免资源共享,具体到网络设备(例如,路由器,交换机,网络服务器等)中,就是使属于同一报文流的报文都由同一个处理器核心来处理,以避免报文跨处理器核心处理所带来的处理器核心之间的资源共享。
目前,主流网卡大多数都支持RSS(Receive-Side Scaling,接收端调节)报文分流技术,使用该分流技术可以使同一报文流的报文都由一个处理器核心来处理。但是目前网卡提供的接口都只允许在几种预先设定的配置方式中选择分流方式,包括:
配置方式一:将具有相同的源IP(Internet Protocol,互联网协议)地址、目的IP地址的报文作为同一报文流的报文对IP报文进行分流;
配置方式二:将具有相同的源IP地址、目的IP地址、源端口号和目的端口号的报文作为同一报文流的报文对TCP(Transfer Control Protocol,传输控制协议)或UDP(User Datagram Protocol,用户数据报协议)报文进行分流。
除了上述网卡预先设定配置方式外,系统开发和管理人员无法选择其它的方式进行分流。例如,如果需要在分流时屏蔽目的地址对分流的影响,即仅依据源IP地址、源端口号和目的端口号进行报文分流,由于现有的网卡并未提供相应的配置接口,上述报文分流方式在现有技术中无法实现。
由上可知,现有的RSS报文分流技术中可选的分流方式较少,灵活性差,无法满足用户的需求。
公开号为“103269317A”,名称为“基于对称多处理SMP系统的无锁化通信方法和系统”的中国专利中披露了一种RSS报文分流方法,该方法的主要思路是不对目前网卡的RSS报文分流功能进行修改,而是将整个系统运行于管道(pipeline)模式,并且将一个处理器核心(例如,记作CoreA)用于处理报文分流,报文都由网卡送到CoreA,由CoreA执行一次哈希(HASH)运算后再根据哈希运算的结果将报文发送给对应的处理器核心。
上述分流方法需要使用一个处理器核心专用于报文分流,不进行其它业务的处理,浪费了处理器资源,而且该处理器核心容易成为整个系统的性能瓶颈。此外,由于使用上述分流方法时整个系统运行于管道模式,一次报文处理需要由多个处理器核心共同完成,因此一次报文处理所需的数据需要存储在多个处理器核心所对应的高速缓冲存储器(Cache)中,这会降低处理器的Cache命中率,进一步降低了系统性能。
发明内容
本申请的目的在于提供一种报文分流方法及装置。
为了达到上述目的,本申请公开了一种报文分流方法,该方法包括:
将RSS随机秘钥中与RSS分流数据的待屏蔽比特在位置上相对应的比特及其后续的连续31个比特设置为0;
使用上述RSS随机秘钥对接收到的报文的RSS分流数据进行哈希运算,根据哈希运算得到的哈希值对该报文进行分流处理;
其中,上述RSS分流数据由一个或多个报文头字段组成。
此外,所述RSS分流数据依序包含4个报文头字段:源IP地址,目的IP地址,源端口号,目的端口号;
所述待屏蔽比特为所述4个报文头字段中的:
任意1个报文头字段的全部或部分比特;或
任意连续的2个报文头字段的全部或部分比特;或
任意连续的3个报文头字段的全部或部分比特;或
源IP地址中的全部或部分比特,和源端口号中的全部或部分比特;或
源IP地址中的全部或部分比特,和目的端口号中的全部或部分比特。
此外,所述RSS分流数据依序包含2个报文头字段:源IP地址,目的IP地址;
所述待屏蔽比特为所述2个报文头字段中的任意1个报文头字段的全部或部分比特。
此外,所述待屏蔽比特包括:
源IP地址中的子网号和主机号所对应的比特,或源IP地址中的主机号所对应的比特;和/或
目的IP地址中的子网号和主机号所对应的比特,或目的IP地址中的主机号所对应的比特。
此外,所述待屏蔽比特为:
源IP地址中的子网号和主机号所对应的比特;或
源IP地址中的主机号所对应的比特;或
目的IP地址中的子网号和主机号所对应的比特;或
目的IP地址中的主机号所对应的比特。
此外,所述哈希运算采用基于异或运算的哈希函数。
此外,所述哈希运算采用Toeplitz哈希函数。
为了达到上述目的,本申请还公开了一种报文分流装置,包括:
随机秘钥设置模块,用于将RSS随机秘钥中与RSS分流数据的待屏蔽比特在位置上相对应的比特及其后续的连续31个比特设置为0;
哈希运算模块,用于使用上述RSS随机秘钥对接收到的报文的RSS分流数据进行哈希运算;
分流模块,用于根据哈希运算得到的哈希值对该报文进行分流处理;
其中,上述RSS分流数据由一个或多个报文头字段组成。
此外,所述RSS分流数据依序包含4个报文头字段:源IP地址,目的IP地址,源端口号,目的端口号;
所述随机秘钥设置模块将所述4个报文头字段中的:
任意1个报文头字段的全部或部分比特;或
任意连续的2个报文头字段的全部或部分比特;或
任意连续的3个报文头字段的全部或部分比特;或
源IP地址中的全部或部分比特,和源端口号中的全部或部分比特;或
源IP地址中的全部或部分比特,和目的端口号中的全部或部分比特作为所述待屏蔽比特。
此外,所述RSS分流数据依序包含2个报文头字段:源IP地址,目的IP地址;
所述随机秘钥设置模块将所述2个报文头字段中的任意1个报文头字段的全部或部分比特作为所述待屏蔽比特。
此外,所述待屏蔽比特包括:
源IP地址中的子网号和主机号所对应的比特,或源IP地址中的主机号所对应的比特;和/或
目的IP地址中的子网号和主机号所对应的比特,或目的IP地址中的主机号所对应的比特。
此外,所述待屏蔽比特为:
源IP地址中的子网号和主机号所对应的比特;或
源IP地址中的主机号所对应的比特;或
目的IP地址中的子网号和主机号所对应的比特;或
目的IP地址中的主机号所对应的比特。
此外,所述哈希运算模块采用基于异或运算的哈希函数进行所述哈希运算。
此外,所述哈希运算模块采用Toeplitz哈希函数进行所述哈希运算。
与现有技术相比,本申请可以获得包括以下技术效果:
充分利用网卡硬件已有的RSS报文分流技术,通过对网卡寄存器中的RSS随机秘钥进行设置实现报文分流,在现有的分流方式的基础上派生出多种新的分流方式以满足更多更灵活的系统需求,同时避免了管道模式对系统性能造成的不利影响。
当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有技术效果。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是本申请实施例的一种报文分流方法的方法流程图;
图2是本申请实施例的另一种报文分流方法的方法流程图;
图3是本申请实施例的RSS随机秘钥中与各报文头字段所对应的比特的位置示意图;
图4是本申请实施例的另一种报文分流方法的方法流程图;
图5是本申请实施例的另一种RSS随机秘钥中与各报文头字段所对应的比特的位置示意图;
图6是本申请实施例的另一种报文分流方法的方法流程图;
图7是本申请实施例的另一种RSS随机秘钥中与各报文头字段所对应的比特的位置示意图;
图8是本申请实施例的另一种报文分流方法的方法流程图;
图9是本申请实施例的另一种RSS随机秘钥中与各报文头字段所对应的比特的位置示意图;
图10是本申请实施例的另一种报文分流方法的方法流程图;
图11是本申请实施例的另一种RSS随机秘钥中与各报文头字段所对应的比特的位置示意图;
图12是本申请实施例的报文分流装置的装置结构图。
具体实施方式
以下将配合附图及实施例来详细说明本申请的实施方式,藉此对本申请如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
实施例描述
下面以一实施例对本申请方法的实现作进一步说明。如图1所示,为本申请实施例的一种报文分流方法的方法流程图,该方法包括:
步骤S100:将RSS随机秘钥(RSS Random Secret Key)中与RSS分流数据的待屏蔽比特在位置上相对应的比特及其后续的连续31个比特设置为0;
RSS随机秘钥为网卡进行哈希(HASH)运算时所需的参数,RSS随机秘钥存放在网卡的硬件寄存器中,操作系统及上层应用软件可以在网卡初始化等过程中对RSS随机秘钥进行设置和修改。
其中,上述RSS分流数据由一个或多个报文头字段组成。
步骤S102:使用上述RSS随机秘钥对接收到的报文的RSS分流数据进行哈希运算,根据哈希运算得到的哈希值对该报文进行分流处理;
上述RSS分流数据中包含的多个报文头字段由网卡从接收到的报文中提取。
RSS分流数据分为两种类型:
类型1(四元组类型):由4个报文头字段组成,依次包含:源IP地址、目的IP地址、源端口号和目的端口号;
类型2(二元组类型):由2个报文头字段组成,依次包含:源IP地址、目的IP地址。
上述根据哈希值对报文进行的分流处理包括:将报文放入与计算得到的哈希值相对应的RSS队列中,并交由与该RSS队列对应的处理器核心进行处理。
下面以第二实施例对本申请方法的实现作进一步说明。如图2所示,为本申请实施例的另一种报文分流方法的方法流程图;本实施例中,采用IPv4协议,并且当前配置的RSS分流数据类型为四元组类型;该方法包括:
步骤S200:将RSS随机秘钥中与RSS分流数据中的待屏蔽比特在位置上相对应的比特以及该比特之后的31个比特设置为0;
RSS随机秘钥RSSRK为40个字节(320比特)长,其默认值为:
{0x6D,0x5A,0x56,0xDA,0x25,0x5B,0x0E,0xC2,
0x41,0x67,0x25,0x3D,0x43,0xA3,0x8F,0xB0,
0xD0,0xCA,0x2B,0xCB,0xAE,0x7B,0x30,0xB4,
0x77,0xCB,0x2D,0xA3,0x80,0x30,0xF2,0x0C,
0x6A,0x42,0xB7,0x3B,0xBE,0xAC,0x01,0xFA}。
本实施例中,采用IPv4协议,且RSS分流数据类型为四元组类型,因此RSS分流数据={SourceIP+DestIP+SourcePort+DestPort};其中:
SourceIP为源IP地址,长度L1=32比特;DestIP为目的IP地址,长度L2=32比特;SourcePort为源端口号,长度L3=16比特;DestPort为目的端口号,长度L4=16比特;RSS分流数据的总长度L=96比特。
本实施例中,上述待屏蔽比特可以是:4个报文头字段中的任意1个报文头字段的全部比特,或任意连续的2个报文头字段的全部比特,或任意连续的3个报文头字段的全部比特,或第1和第3个报文头字段的全部比特,或第1和第4个报文头字段的全部比特。
图3为第二实施例中RSS随机秘钥中与各报文头字段所对应的比特的位置示意图。图3中,KEY1为第1个报文头字段(即源IP地址)在RSS随机秘钥中所对应的比特;KEY2为第2个报文头字段(即目的IP地址)在RSS随机秘钥中所对应的比特;KEY3为第3个报文头字段(即源端口号)在RSS随机秘钥中所对应的比特;KEY4为第4个报文头字段(即目的端口号)在RSS随机秘钥中所对应的比特。其中:
KEY1的长度K1=L1+31=63比特,KEY1在RSS随机秘钥中的对应位置为:第1~63比特(第1~L1+31比特);
KEY2的长度K2=L2+31=63比特,KEY2在RSS随机秘钥中的对应位置为:第33~95比特(第L1+1~L1+L2+31比特);
KEY3的长度K3=L3+31=47比特;KEY3在RSS随机秘钥中的对应位置为:第65~111比特(第L1+L2+1~L1+L2+L3+31比特);
KEY4的长度K4=L4+31=47比特;KEY4在RSS随机秘钥中的对应位置为:第81~127比特(第L1+L2+L3+1~L1+L2+L3+L4+31比特)。
本实施例中,RSS随机秘钥的有效字节为L+31=127比特。
以待屏蔽比特为目的IP地址字段的全部比特为例,将目的IP地址字段在RSS随机秘钥中所对应的比特及各比特之后的31个比特(即KEY2)设置为0后,上述RSS随机秘钥的值RSSRK将变为:
{0x6D,0x5A,0x56,0xDA,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x01,0x43,0xA3,0x8F,0xB0,
0xD0,0xCA,0x2B,0xCB,0xAE,0x7B,0x30,0xB4,
0x77,0xCB,0x2D,0xA3,0x80,0x30,0xF2,0x0C,
0x6A,0x42,0xB7,0x3B,0xBE,0xAC,0x01,0xFA}。
步骤S202:网卡接收到报文后,根据当前的配置从接收到的报文中提取RSS分流数据;
如上所述,本实施例中,
RSS分流数据={SourceIP+DestIP+SourcePort+DestPort}。
步骤S204:网卡使用其硬件寄存器中存储的上述RSS随机秘钥对RSS分流数据进行哈希运算得到哈希值;
本实施例中,哈希运算可以采用基于异或运算的哈希函数,如Toeplitz(托布里兹)哈希函数,Toeplitz哈希函数的伪代码如下:
ComputeHash(input[],N)
For hash-input input[]of length N bytes(8N bits)and a random secret key
K of 320bits
Result=0;
For each bit b in input[]{
if(b==1)then Result^=(left-most 32bits of K);
shift K left 1bit position;
}
return Result;
其中,ComputeHash为Toeplitz哈希函数的函数名;
input[]和N为Toeplitz哈希函数的两个输入参数,input[]为长度为N字节(8×N比特)RSS分流数据,本实施例中,N=12;
K为40字节(320比特)长的RSS随机秘钥;
Result为Toeplitz哈希函数输出的哈希值,其初值为0。
Toeplitz哈希函数中,从输入的RSS分流数据的最左侧的比特开始,对于RSS分流数据中的每一比特b依次进行如下处理:
判断b是否为1:
如果b=1,则令Result=Result^(K[32]),并将K左移1比特;
如果b≠1,则将K左移1比特。
完成上述处理后,将Result值作为Toeplitz哈希函数的哈希值输出。
其中,上述K[32]表示当前K值的最左侧(最高位)的32比特。
步骤S206:网卡根据计算得到的哈希值对接收到的报文进行分流处理,即将该报文放入与哈希值相对应的RSS队列中,并交由与该RSS队列对应的处理器核心进行处理。
由上可知,本实施例基于四元组类型的RSS分流数据,通过对RSS随机秘钥进行设置,派生出多种新的分流方式,例如:
将KEY1设置为0,可依据目的IP地址、源端口号和目的端口号进行分流;或
将KEY2设置为0,可依据源IP地址、源端口号和目的端口号进行分流;或
将KEY3设置为0,可依据源IP地址、目的IP地址和目的端口号进行分流;或
将KEY4设置为0,可依据源IP地址、目的IP地址和源端口号进行分流。
除以上分流方式外,还可以通过:将KEY1和KEY2设置为0,或将KEY2和KEY3设置为0,或将KEY3和KEY4设置为0,或将KEY1、KEY2和KEY3设置为0,或将KEY2、KEY3和KEY4设置为0,或将KEY1和KEY3设置为0,或将KEY1和KEY4设置为0等方式派生出更多的分流方式。
下面以第三实施例对本申请方法的实现作进一步说明。如图4所示,为本申请实施例的另一种报文分流方法的方法流程图;本实施例中,采用IPv4协议,并且当前配置的RSS分流数据类型为二元组类型;该方法包括:
步骤S400:将RSS随机秘钥中与RSS分流数据中的待屏蔽比特在位置上相对应的比特以及该比特之后的31个比特设置为0;
本实施例中,采用IPv4协议,且RSS分流数据类型为二元组类型,因此RSS分流数据={SourceIP+DestIP};其中:
SourceIP为源IP地址,长度L1=32比特;DestIP为目的IP地址,长度L2=32比特;RSS分流数据的总长度L=64比特。
本实施例中,上述待屏蔽比特可以是2个报文头字段中的任意1个报文头字段的全部比特。
图5为第三实施例中RSS随机秘钥中与各报文头字段所对应的比特的位置示意图。图5中,KEY1为第1个报文头字段(即源IP地址)在RSS随机秘钥中所对应的比特;KEY2为第2个报文头字段(即目的IP地址字段)在RSS随机秘钥中所对应的比特。其中:
KEY1的长度K1=L1+31=63比特,KEY1在RSS随机秘钥中的对应位置为:第1~63比特(第1~L1+31比特);
KEY2的长度K2=L2+31=63比特,KEY2在RSS随机秘钥中的对应位置为:第33~95比特(第L1+1~L1+L2+31比特);
本实施例中,RSS随机秘钥的有效字节为L+31=95比特。
步骤S402:网卡接收到报文后,根据当前的配置从接收到的报文中提取RSS分流数据;
如上所述,本实施例中,
RSS分流数据={SourceIP+DestIP}。
步骤S404:网卡使用其硬件寄存器中存储的上述RSS随机秘钥对RSS分流数据进行哈希运算得到哈希值;
本实施例中,哈希运算可以采用基于异或运算的哈希函数,如Toeplitz(托布里兹)哈希函数。
步骤S406:网卡根据计算得到的哈希值对接收到的报文进行分流处理,即将该报文放入与哈希值相对应的RSS队列中,并交由与该RSS队列对应的处理器核心进行处理。
由上可知,本实施例基于二元组类型的RSS分流数据,通过对RSS随机秘钥进行设置,派生出多种新的分流方式,例如:
将KEY1设置为0,可依据目的IP地址进行分流;或
将KEY2设置为0,可依据源IP地址进行分流。
下面以第四实施例对本申请方法的实现作进一步说明。如图6所示,为本申请实施例的另一种报文分流方法的方法流程图;本实施例中,采用IPv6协议,并且当前配置的RSS分流数据类型为四元组类型;该方法包括:
步骤S600:将RSS随机秘钥中与RSS分流数据中的待屏蔽比特在位置上相对应的比特以及该比特之后的31个比特设置为0;
本实施例中,采用IPv6协议,且RSS分流数据类型为四元组类型,因此RSS分流数据={SourceIP+DestIP+SourcePort+DestPort};其中:
SourceIP为源IP地址,长度L1=128比特;DestIP为目的IP地址,长度L2=128比特;SourcePort为源端口号,长度L3=16比特;DestPort为目的端口号,长度L4=16比特;RSS分流数据的总长度L=288比特。
本实施例中,上述待屏蔽比特可以是:4个报文头字段中的任意1个报文头字段的全部比特,或任意连续的2个报文头字段的全部比特,或任意连续的3个报文头字段的全部比特,或第1和第3个报文头字段的全部比特,或第1和第4个报文头字段的全部比特。
图7为第四实施例中RSS随机秘钥中与各报文头字段所对应的比特的位置示意图。图7中,KEY1为第1个报文头字段(即源IP地址)在RSS随机秘钥中所对应的比特;KEY2为第2个报文头字段(即目的IP地址)在RSS随机秘钥中所对应的比特;KEY3为第3个报文头字段(即源端口号)在RSS随机秘钥中所对应的比特;KEY4为第4个报文头字段(即目的端口号)在RSS随机秘钥中所对应的比特。其中:
KEY1的长度K1=L1+31=159比特,KEY1在RSS随机秘钥中的对应位置为:第1~159比特(第1~L1+31比特);
KEY2的长度K2=L2+31=159比特,KEY2在RSS随机秘钥中的对应位置为:第129~287比特(第L1+1~L1+L2+31比特);
KEY3的长度K3=L3+31=47比特;KEY3在RSS随机秘钥中的对应位置为:第257~303比特(第L1+L2+1~L1+L2+L3+31比特);
KEY4的长度K4=L4+31=47比特;KEY4在RSS随机秘钥中的对应位置为:第273~319比特(第L1+L2+L3+1~L1+L2+L3+L4+31比特)。
本实施例中,RSS随机秘钥的有效字节为L+31=319比特。
步骤S602:网卡接收到报文后,根据当前的配置从接收到的报文中提取RSS分流数据;
如上所述,本实施例中,
RSS分流数据={SourceIP+DestIP+SourcePort+DestPort}。
步骤S604:网卡使用其硬件寄存器中存储的上述RSS随机秘钥对RSS分流数据进行哈希运算得到哈希值;
本实施例中,哈希运算可以采用基于异或运算的哈希函数,如Toeplitz(托布里兹)哈希函数。
步骤S606:网卡根据计算得到的哈希值对接收到的报文进行分流处理,即将该报文放入与哈希值相对应的RSS队列中,并交由与该RSS队列对应的处理器核心进行处理。
由上可知,本实施例基于四元组类型的RSS分流数据,通过对RSS随机秘钥进行设置,派生出了多种新的分流方式,例如:
将KEY1设置为0,可依据目的IP地址、源端口号和目的端口号进行分流;或
将KEY2设置为0,可依据源IP地址、源端口号和目的端口号进行分流;或
将KEY3设置为0,可依据源IP地址、目的IP地址和目的端口号进行分流;或
将KEY4设置为0,可依据源IP地址、目的IP地址和源端口号进行分流。
除以上分流方式外,还可以通过:将KEY1和KEY2设置为0,或将KEY2和KEY3设置为0,或将KEY3和KEY4设置为0,或将KEY1、KEY2和KEY3设置为0,或将KEY2、KEY3和KEY4设置为0,或将KEY1和KEY3设置为0,或将KEY1和KEY4设置为0等方式派生出更多的分流方式。
下面以第五实施例对本申请方法的实现作进一步说明。如图8所示,为本申请实施例的另一种报文分流方法的方法流程图;本实施例中,采用IPv6协议,并且当前配置的RSS分流数据类型为二元组类型;该方法包括:
步骤S800:将RSS随机秘钥中与RSS分流数据中的待屏蔽比特在位置上相对应的比特以及该比特之后的31个比特设置为0;
本实施例中,采用IPv6协议,且RSS分流数据类型为二元组类型,因此RSS分流数据={SourceIP+DestIP};其中:
SourceIP为源IP地址,长度L1=128比特;DestIP为目的IP地址,长度L2=128比特;RSS分流数据的总长度L=256比特。
本实施例中,上述待屏蔽比特可以是2个报文头字段中的任意1个报文头字段的全部比特。
图9为第五实施例中RSS随机秘钥中与各报文头字段所对应的比特的位置示意图。图9中,KEY1为第1个报文头字段(即源IP地址字段)在RSS随机秘钥中所对应的比特;KEY2为第2个报文头字段(即目的IP地址字段)在RSS随机秘钥中所对应的比特。其中:
KEY1的长度K1=L1+31=159比特,KEY1在RSS随机秘钥中的对应位置为:第1~159比特(第1~L1+31比特);
KEY2的长度K2=L2+31=159比特,KEY2在RSS随机秘钥中的对应位置为:第129~287比特(第L1+1~L1+L2+31比特)。
本实施例中,RSS随机秘钥的有效字节为L+31=287比特。
步骤S802:网卡接收到报文后,根据当前的配置从接收到的报文中提取RSS分流数据;
如上所述,本实施例中,
RSS分流数据={SourceIP+DestIP}。
步骤S804:网卡使用其硬件寄存器中存储的上述RSS随机秘钥对RSS分流数据进行哈希运算得到哈希值;
本实施例中,哈希运算可以采用基于异或运算的哈希函数,如Toeplitz(托布里兹)哈希函数。
步骤S806:网卡根据计算得到的哈希值对接收到的报文进行分流处理,即将该报文放入与哈希值相对应的RSS队列中,并交由与该RSS队列对应的处理器核心进行处理。
由上可知,本实施例基于二元组类型的RSS分流数据,通过对RSS随机秘钥进行设置,派生出了多种新的分流方式,例如:
将KEY1设置为0,可依据目的IP地址进行分流;或
将KEY2设置为0,可依据源IP地址进行分流。
下面以第六实施例对本申请方法的实现作进一步说明。如图10所示,为本申请实施例的另一种报文分流方法的方法流程图;本实施例中,采用IPv4协议,并且当前配置的RSS分流数据类型为二元组类型;该方法包括:
步骤S1000:将RSS随机秘钥中与RSS分流数据中的待屏蔽比特在位置上相对应的比特以及该比特之后的31个比特设置为0;
本实施例中,采用IPv4协议,且RSS分流数据类型为二元组类型,因此RSS分流数据={SourceIP+DestIP}。
本实施例中,上述待屏蔽比特为2个报文头字段中的任意1个或2报文头字段的部分比特。具体地说,本实施例中待屏蔽比特可以为:
源IP地址中的子网号和主机号所对应的比特,或主机号所对应的比特;和/或
目的IP地址中的子网号和主机号所对应的比特,或主机号所对应的比特。
IP地址以两级划分可以表示为:网络号+主机号,如果以三级划分,主机号又可以表示为:子网号+主机号;此外,IP地址可分为A、B、C等多类,不同类别的IP地址的网络号、子网号和主机号所占比特数不同。
本实施例中,以Nn表示网络号所占比特数,Ns表示子网号所占比特数,Nh表示主机号所占比特数,则:
如果待屏蔽比特为源IP地址的主机号所对应的比特,则将RSS随机秘钥的第Nn+Ns+1~L1+31个比特设置为0,即将图5所示的KEY1的后Nh+31个比特设置为0;
如果待屏蔽比特为源IP地址的子网号和主机号所对应的比特,则将RSS随机秘钥的第Nn+1~L1+31个比特设置为0,即将图5所示的KEY1的后Ns+Nh+31个比特设置为0;
如果待屏蔽比特为目的IP地址的主机号所对应的比特,则将RSS随机秘钥的第L1+Nn+Ns+1~L1+L2+31比特设置为0,即将图5所示的KEY2的后Nh+31个比特设置为0;
如果待屏蔽字节为目的IP地址的子网号和主机号所对应的比特,则将RSS随机秘钥的第L1+Nn+1~L1+L2+31比特设置为0,即将图5所示的KEY2的后Ns+Nh+31个比特设置为0。
步骤S1002:网卡接收到报文后,根据当前的配置从接收到的报文中提取RSS分流数据;
如上所述,本实施例中,
RSS分流数据={SourceIP+DestIP}。
步骤S1004:网卡使用其硬件寄存器中存储的上述RSS随机秘钥对RSS分流数据进行哈希运算得到哈希值;
本实施例中,哈希运算可以采用基于异或运算的哈希函数,如Toeplitz(托布里兹)哈希函数。
步骤S1006:网卡根据输出的哈希值对接收到的报文进行分流处理,即将该报文放入与哈希值相对应的RSS队列中,并交由与该RSS队列对应的处理器核心进行处理。
由上可知,本实施例基于二元组类型的RSS分流数据,通过对RSS随机秘钥进行设置,派生出多种新的分流方式,例如:
将KEY1的后Nh+31或后Ns+Nh+31个比特设置为0,可依据源IP地址的网络号或依据源IP地址的网络号和子网号进行分流;和/或
将KEY2的后Nh+31或后Ns+Nh+31个比特设置为0,可依据目的IP地址的网络号或依据目的IP地址的网络号和子网号进行分流。
本实施例可以应用于IPv6协议,所不同的是,IPv6协议的IP地址没有包含子网号,其IP地址的构成为网络号+主机号(或称为:网络前缀+主机号),即上述Ns=0。
本发明的第六实施例可以与本发明的第二至第五实施例中的任何一个结合使用。
应用实例描述
下面以一应用实例对本申请方法的实现作进一步说明。
设接收到的报文为TCP报文,源IP地址={1.1.1.1},源端口号=0x1234,目的IP地址={2.2.2.2},目的端口号=0x50;RSS分流数据类型为四元组类型,则:RSS分流数据={SourceIP+DestIP+SourcePort+DestPort}。
本应用实例中以待屏蔽比特为目的IP地址字段(DestIP)的全部比特为例进行说明。
图11为本申请应用实例中RSS随机秘钥中与各报文头字段所对应的比特的位置示意图。如图11所示,为了屏蔽目的IP地址字段的对应比特,应当将RSS随机秘钥中的KEY2的全部比特设置为0。
为了更清晰地说明本申请的原理,本应用实例中对Toeplitz哈希函数进行改写,伪代码如下:
ComputeHash_S(input[],N,K,Result)
For each bit b in input[]{
if(b==1)then Result^=(left-most 32bits of K);
shift K left 1bit position;
}
return Result;
如以上伪代码所示,ComputeHash_S函数与Toeplitz哈希函数ComputeHash的区别在于ComputeHash_S函数增加了一个输入参数Result,即Result作为哈希值的初始值输入,也作为哈希运算的结果值输出。
经过上述改写后,我们可以将哈希运算分解为以下子步骤:
Rss1=ComputeHash_S(SourceIP,4,KEY1,0);
Rss2=ComputeHash_S(DestIP,4,KEY2,Rss1);
Rss3=ComputeHash_S(SourcePort,2,KEY3,Rss2);
Rss4=ComputeHash_S(DestPort,2,KEY4,Rss3)。
在Rss2=ComputeHash_S(DestIP,4,KEY2,Rss1)中,由于KEY2的全部比特为0,因此无论DestIP为何值,Rss2=Rss1,即在哈希函数的计算过程中,哈希值没有变化,即输出的哈希值与DestIP的值无关,通过将KEY2设置为0实现了对目的IP地址字段的屏蔽,以源IP地址、源端口号和目的端口号进行RSS分流。
下面以另一实施例对本申请装置的实现作进一步说明。如图12所示,为本申请实施例的报文分流装置的装置结构图,报文分流装置包括:随机秘钥设置模块1200、哈希运算模块1202、分流模块1204;其中:
随机秘钥设置模块,用于将RSS随机秘钥中与RSS分流数据的待屏蔽比特在位置上相对应的比特及其后续的连续31个比特设置为0;
哈希运算模块,用于使用上述RSS随机秘钥对接收到的报文的RSS分流数据进行哈希运算;
分流模块,用于根据哈希运算得到的哈希值对该报文进行分流处理;
其中,上述RSS分流数据由一个或多个报文头字段组成。
RSS分流数据依序包含4个报文头字段:源IP地址,目的IP地址,源端口号,目的端口号;
随机秘钥设置模块将所述4个报文头字段中的:
任意1个报文头字段的全部或部分比特;或
任意连续的2个报文头字段的全部或部分比特;或
任意连续的3个报文头字段的全部或部分比特;或
源IP地址中的全部或部分比特,和源端口号中的全部或部分比特;或
源IP地址中的全部或部分比特,和目的端口号中的全部或部分比特作为待屏蔽比特。
待屏蔽比特包括:
源IP地址中的子网号和主机号所对应的比特,或源IP地址中的主机号所对应的比特;和/或
目的IP地址中的子网号和主机号所对应的比特,或目的IP地址中的主机号所对应的比特。
此外,RSS分流数据还可以依序包含2个报文头字段:源IP地址,目的IP地址;
所述随机秘钥设置模块将所述2个报文头字段中的任意1个报文头字段的全部或部分比特作为所述待屏蔽比特。
所述待屏蔽比特为:
源IP地址中的子网号和主机号所对应的比特;或
源IP地址中的主机号所对应的比特;或
目的IP地址中的子网号和主机号所对应的比特;或
目的IP地址中的主机号所对应的比特。
所述哈希运算模块采用基于异或运算的哈希函数进行所述哈希运算。
优选地,所述哈希运算模块采用Toeplitz哈希函数进行所述哈希运算。
所述装置与前述的方法流程描述对应,更具体的描述请参考上述方法流程的叙述,不再一一赘述。
上述说明示出并描述了本申请的若干优选实施例,但如前所述,应当理解本申请并非局限于本文所披露的形式,不应看作是对其他实施例的排除,而可用于各种其他组合、修改和环境,并能够在本文所述发明构想范围内,通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围,则都应在本申请所附权利要求的保护范围内。
Claims (14)
1.一种报文分流方法,其特征在于,该方法包括:
将RSS随机秘钥中与RSS分流数据的待屏蔽比特在位置上相对应的比特及其后续的连续31个比特设置为0;
使用上述RSS随机秘钥对接收到的报文的RSS分流数据进行哈希运算,根据哈希运算得到的哈希值对该报文进行分流处理;
其中,上述RSS分流数据由一个或多个报文头字段组成。
2.根据权利要求1所述的方法,其特征在于,
所述RSS分流数据依序包含4个报文头字段:源IP地址,目的IP地址,源端口号,目的端口号;
所述待屏蔽比特为所述4个报文头字段中的:
任意1个报文头字段的全部或部分比特;或
任意连续的2个报文头字段的全部或部分比特;或
任意连续的3个报文头字段的全部或部分比特;或
源IP地址中的全部或部分比特,和源端口号中的全部或部分比特;或
源IP地址中的全部或部分比特,和目的端口号中的全部或部分比特。
3.根据权利要求1所述的方法,其特征在于,
所述RSS分流数据依序包含2个报文头字段:源IP地址,目的IP地址;
所述待屏蔽比特为所述2个报文头字段中的任意1个报文头字段的全部或部分比特。
4.根据权利要求2所述的方法,其特征在于,
所述待屏蔽比特包括:
源IP地址中的子网号和主机号所对应的比特,或源IP地址中的主机号所对应的比特;和/或
目的IP地址中的子网号和主机号所对应的比特,或目的IP地址中的主机号所对应的比特。
5.根据权利要求3所述的方法,其特征在于,
所述待屏蔽比特为:
源IP地址中的子网号和主机号所对应的比特;或
源IP地址中的主机号所对应的比特;或
目的IP地址中的子网号和主机号所对应的比特;或
目的IP地址中的主机号所对应的比特。
6.根据权利要求1所述的方法,其特征在于,
所述哈希运算采用基于异或运算的哈希函数。
7.根据权利要求6所述的方法,其特征在于,
所述哈希运算采用Toeplitz哈希函数。
8.一种报文分流装置,其特征在于,包括:
随机秘钥设置模块,用于将RSS随机秘钥中与RSS分流数据的待屏蔽比特在位置上相对应的比特及其后续的连续31个比特设置为0;
哈希运算模块,用于使用上述RSS随机秘钥对接收到的报文的RSS分流数据进行哈希运算;
分流模块,用于根据哈希运算得到的哈希值对该报文进行分流处理;
其中,上述RSS分流数据由一个或多个报文头字段组成。
9.根据权利要求6所述的装置,其特征在于,
所述RSS分流数据依序包含4个报文头字段:源IP地址,目的IP地址,源端口号,目的端口号;
所述随机秘钥设置模块将所述4个报文头字段中的:
任意1个报文头字段的全部或部分比特;或
任意连续的2个报文头字段的全部或部分比特;或
任意连续的3个报文头字段的全部或部分比特;或
源IP地址中的全部或部分比特,和源端口号中的全部或部分比特;或
源IP地址中的全部或部分比特,和目的端口号中的全部或部分比特作为所述待屏蔽比特。
10.根据权利要求6所述的装置,其特征在于,
所述RSS分流数据依序包含2个报文头字段:源IP地址,目的IP地址;
所述随机秘钥设置模块将所述2个报文头字段中的任意1个报文头字段的全部或部分比特作为所述待屏蔽比特。
11.根据权利要求9所述的装置,其特征在于,
所述待屏蔽比特包括:
源IP地址中的子网号和主机号所对应的比特,或源IP地址中的主机号所对应的比特;和/或
目的IP地址中的子网号和主机号所对应的比特,或目的IP地址中的主机号所对应的比特。
12.根据权利要求10所述的装置,其特征在于,
所述待屏蔽比特为:
源IP地址中的子网号和主机号所对应的比特;或
源IP地址中的主机号所对应的比特;或
目的IP地址中的子网号和主机号所对应的比特;或
目的IP地址中的主机号所对应的比特。
13.根据权利要求8所述的装置,其特征在于,
所述哈希运算模块采用基于异或运算的哈希函数进行所述哈希运算。
14.根据权利要求9所述的装置,其特征在于,
所述哈希运算模块采用Toeplitz哈希函数进行所述哈希运算。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510036029.XA CN105871725B (zh) | 2015-01-23 | 2015-01-23 | 一种报文分流方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510036029.XA CN105871725B (zh) | 2015-01-23 | 2015-01-23 | 一种报文分流方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105871725A true CN105871725A (zh) | 2016-08-17 |
CN105871725B CN105871725B (zh) | 2019-02-05 |
Family
ID=56624050
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510036029.XA Active CN105871725B (zh) | 2015-01-23 | 2015-01-23 | 一种报文分流方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105871725B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106375237A (zh) * | 2016-09-28 | 2017-02-01 | 郑州云海信息技术有限公司 | 一种基于Intel 82599万兆网卡的Hash函数Key值筛选方法 |
CN108111530A (zh) * | 2017-12-30 | 2018-06-01 | 世纪网通成都科技有限公司 | 用于侦测voip通话状态的计算机可读存储介质和应用该介质的侦测系统 |
CN109451045A (zh) * | 2018-12-12 | 2019-03-08 | 成都九洲电子信息系统股份有限公司 | 一种可配置自定义以太头的高速报文采集网卡控制方法 |
CN113098794A (zh) * | 2021-03-30 | 2021-07-09 | 郑州信大捷安信息技术股份有限公司 | 利用二次分流实现隧道报文对称rss处理的方法及系统 |
CN113157445A (zh) * | 2021-03-30 | 2021-07-23 | 郑州信大捷安信息技术股份有限公司 | 基于哈希运算和索引值比对的双向报文对称rss处理方法及系统 |
CN113839772A (zh) * | 2021-09-18 | 2021-12-24 | 哲库科技(北京)有限公司 | 托普利茨哈希算法的处理电路、芯片和终端 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040125799A1 (en) * | 2002-12-31 | 2004-07-01 | Buer Mark L. | Data processing hash algorithm and policy management |
CN101286936A (zh) * | 2008-05-16 | 2008-10-15 | 华为技术有限公司 | 数据报文的处理方法及装置 |
CN102916905A (zh) * | 2012-10-18 | 2013-02-06 | 曙光信息产业(北京)有限公司 | 一种基于hash算法的万兆网卡多路分流方法及其系统 |
CN103269317A (zh) * | 2013-04-22 | 2013-08-28 | 北京百度网讯科技有限公司 | 基于对称多处理smp系统的无锁化通信方法和系统 |
CN103503424A (zh) * | 2010-12-20 | 2014-01-08 | 思杰系统有限公司 | 用于实现多核系统中的连接镜像的系统和方法 |
-
2015
- 2015-01-23 CN CN201510036029.XA patent/CN105871725B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040125799A1 (en) * | 2002-12-31 | 2004-07-01 | Buer Mark L. | Data processing hash algorithm and policy management |
CN101286936A (zh) * | 2008-05-16 | 2008-10-15 | 华为技术有限公司 | 数据报文的处理方法及装置 |
CN103503424A (zh) * | 2010-12-20 | 2014-01-08 | 思杰系统有限公司 | 用于实现多核系统中的连接镜像的系统和方法 |
CN102916905A (zh) * | 2012-10-18 | 2013-02-06 | 曙光信息产业(北京)有限公司 | 一种基于hash算法的万兆网卡多路分流方法及其系统 |
CN103269317A (zh) * | 2013-04-22 | 2013-08-28 | 北京百度网讯科技有限公司 | 基于对称多处理smp系统的无锁化通信方法和系统 |
Non-Patent Citations (2)
Title |
---|
SHU LI TEC.: "THE IMPLEMENTATION AND APPLICATION", 《IEEE》 * |
秦步捷: "基于多核平台的协议重组与还原系统", 《中国优秀硕士学位论文全文数据库 信息科技辑 (月刊 )2013年5月》 * |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106375237A (zh) * | 2016-09-28 | 2017-02-01 | 郑州云海信息技术有限公司 | 一种基于Intel 82599万兆网卡的Hash函数Key值筛选方法 |
CN106375237B (zh) * | 2016-09-28 | 2019-11-01 | 郑州云海信息技术有限公司 | 一种基于Intel 82599万兆网卡的Hash函数Key值筛选方法 |
CN108111530A (zh) * | 2017-12-30 | 2018-06-01 | 世纪网通成都科技有限公司 | 用于侦测voip通话状态的计算机可读存储介质和应用该介质的侦测系统 |
CN108111530B (zh) * | 2017-12-30 | 2020-11-13 | 世纪网通成都科技有限公司 | 用于侦测voip通话状态的计算机可读存储介质和应用该介质的侦测系统 |
CN109451045A (zh) * | 2018-12-12 | 2019-03-08 | 成都九洲电子信息系统股份有限公司 | 一种可配置自定义以太头的高速报文采集网卡控制方法 |
CN113098794A (zh) * | 2021-03-30 | 2021-07-09 | 郑州信大捷安信息技术股份有限公司 | 利用二次分流实现隧道报文对称rss处理的方法及系统 |
CN113157445A (zh) * | 2021-03-30 | 2021-07-23 | 郑州信大捷安信息技术股份有限公司 | 基于哈希运算和索引值比对的双向报文对称rss处理方法及系统 |
CN113098794B (zh) * | 2021-03-30 | 2022-04-05 | 郑州信大捷安信息技术股份有限公司 | 利用二次分流实现隧道报文对称rss处理的方法及系统 |
CN113157445B (zh) * | 2021-03-30 | 2022-04-08 | 郑州信大捷安信息技术股份有限公司 | 基于哈希运算和索引值比对的双向报文对称rss处理方法及系统 |
CN113839772A (zh) * | 2021-09-18 | 2021-12-24 | 哲库科技(北京)有限公司 | 托普利茨哈希算法的处理电路、芯片和终端 |
Also Published As
Publication number | Publication date |
---|---|
CN105871725B (zh) | 2019-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105871725A (zh) | 一种报文分流方法及装置 | |
US10708178B2 (en) | Method, medium, and apparatus for inserting a placeholder service function | |
CN103428094B (zh) | 开放流OpenFlow系统中的报文转发方法及装置 | |
US10284390B2 (en) | Techniques for efficient service chain analytics | |
CN107872392A (zh) | 在网络中分配服务功能链数据和服务功能实例数据 | |
CN109861924A (zh) | 报文的发送、处理方法及装置,pe节点,节点 | |
US20040177139A1 (en) | Method and apparatus for computing priorities between conflicting rules for network services | |
US20170163531A1 (en) | Infrastructure-exclusive service forwarding | |
US10819573B2 (en) | Hierarchical coherency for network function virtualization | |
CN110352586B (zh) | 用于保留网络中的数据分组的相对定时和排序的方法和装置 | |
TW201351191A (zh) | 用於使用影子網路技術以識別、阻斷及/或延遲對一網路之攻擊的系統及方法 | |
US11637702B2 (en) | Verifiable computation for cross-domain information sharing | |
CN105871741B (zh) | 一种报文分流方法及装置 | |
EP3821589B1 (en) | Session management in a forwarding plane | |
US9444736B2 (en) | Selecting an interface for packet routing based on application-layer data | |
Davoli et al. | Implementation of service function chaining control plane through OpenFlow | |
CN112787913B (zh) | 智能网卡组件、物理机、云服务系统以及报文发送方法 | |
TW201408023A (zh) | 於原有硬體中實施活動目標技術之系統及方法 | |
CN110290072A (zh) | 流量控制方法、装置、网络设备及存储介质 | |
US20230097734A1 (en) | Wire-speed routing and policy enforcement without dpi or decryption | |
CN103346950A (zh) | 一种机架式无线控制器用户业务板间负载均摊方法及装置 | |
US11765146B2 (en) | Partial packet encryption for encrypted tunnels | |
CN104219160A (zh) | 生成输入参数的方法及设备 | |
Bays et al. | A toolset for efficient privacy-oriented virtual network embedding and its instantiation on SDN/OpenFlow-based substrates | |
Musa | Network Security and Cryptography |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |