CN108833301A - 一种报文处理方法和装置 - Google Patents
一种报文处理方法和装置 Download PDFInfo
- Publication number
- CN108833301A CN108833301A CN201810542890.7A CN201810542890A CN108833301A CN 108833301 A CN108833301 A CN 108833301A CN 201810542890 A CN201810542890 A CN 201810542890A CN 108833301 A CN108833301 A CN 108833301A
- Authority
- CN
- China
- Prior art keywords
- message
- buffering queue
- value
- vpn
- variable
- 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.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供一种报文处理方法和装置,该方法用于主机的虚拟专用网络VPN客户端,该方法为按照预定的移转策略将网卡内第一缓冲队列中的报文移转到预先为VPN客户端创建的VPN客户端的一个或多个第二缓冲队列,其中第二缓冲队列的总容量大于第一缓冲队列;从第二缓冲队列中读取报文,并对该报文进行VPN处理;按照预定的情况策略,将该报文从第二缓冲队列中清空。本方法通过在VPN客户端增加一个缓冲队列,一旦网卡中有报文存入该网卡的第一缓冲队列时,VPN客户端便及时将该报文从网卡中读取出来存入VPN客户端的缓冲队列,并进行处理,有效地解决VPN客户端进行VPN处理耗时过长导致网卡的缓冲队列无法缓存所有报文时出现丢包的问题。
Description
技术领域
本申请涉及网络通信技术领域,特别涉及一种报文处理方法和装置。
背景技术
VPN(Virtual Private Network,虚拟专用网络)终端可以包括应用程序、VPN虚拟网卡、VPN客户端和物理网卡。VPN终端的工作流程如下:
(1)发送报文:当应用程序发送一个报文之后,这个报文会被传送到VPN虚拟网卡,VPN客户端将该报文从VPN虚拟网卡的缓冲队列中读取出来,加密后发送给物理网卡,最后由物理网卡将加密后的报文通过VPN虚拟专用隧道发送出去;
(2)接收报文:当物理网卡从VPN虚拟专用隧道收到报文后,VPN客户端将该报文从物理网卡的缓冲队列中读取出来,解密后发送给VPN虚拟网卡,最后由VPN虚拟网卡根据自身的回调函数将该报文传递给对应的应用程序。
主机安装了VPN客户端和VNP虚拟网卡后,在收发报文的过程中容易出现丢包现象,并且丢包的位置并不固定,问题难以定位和解决。
发明内容
本申请提供一种报文处理方法和装置,以解决VPN客户端进行VPN处理耗时过长导致VPN虚拟网卡或物理网卡的缓冲队列无法缓存所有报文时出现丢包的问题。
本申请提供的技术方案包括:
本申请第一方面,提供了一种报文处理方法,该方法用于主机的VPN客户端,该方法包括:
按照预定的移转策略将网卡内第一缓冲队列中的报文转移到预先为VPN客户端创建的VPN客户端的一个或多个第二缓冲队列,其中第二缓冲队列的总容量大于第一缓冲队列;
从第二缓冲队列中读取报文,并对该报文进行VPN处理;
按照预定的清空策略,将该报文从第二缓冲队列中清空。
本申请第二方面,提供了一种报文处理装置,所述装置可以应用于主机的虚拟专用网络VPN客户端,具有实现上述方法的功能。所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块或单元。
一种可能的实现方式中,所述装置包括:
移转单元,用于按照预定的移转策略将网卡内第一缓冲队列中的报文转移到预先为VPN客户端创建的VPN客户端的一个或多个第二缓冲队列;
处理单元,用于从第二缓冲队列中读取报文,并对该报文进行VPN处理;
清空单元,用于将该报文从第二缓冲队列中清空。
另一种可能的实现方式中,所述装置包括通信接口、处理器、存储器和总线,所述通信接口、所述处理器和所述存储器之间通过总线相互连接;所述处理器通过读取所述存储器中存储的逻辑指令,执行本申请第一方面提供的方法。
由以上所述可以看出,本申请中,通过在VPN客户端增加一个缓冲队列,一旦VPN虚拟网卡或物理网卡中有报文存入该网卡的第一缓冲队列时,VPN客户端便及时将该报文从VPN虚拟网卡或物理网卡中读取出来存入VPN客户端的缓冲队列,并进行处理,有效地解决VPN客户端进行VPN处理耗时过长导致VPN虚拟网卡或物理网卡的缓冲队列无法缓存所有报文时出现丢包的问题。
附图说明
图1是本申请的系统架构图;
图2是本申请的方法流程图;
图3是本申请实施例提供的方法交互图;
图4是第二缓冲队列的队列格式图;
图5是本申请实施例提供的装置功能模块框图;
图6是图5所示装置的硬件结构图。
具体实施方式
参见图1,图1为目前通用的VPN环境的系统架构图,该系统包括VPN终端、VPN服务器、资源服务器等设备,其中:
VPN终端,为用户实际操作的终端设备,通常称为主机,该设备中包含应用程序、VPN客户端和VPN虚拟网卡以及物理网卡;VPN终端访问外部资源时,其内部的处理流程如下:应用程序生成请求资源报文,并将请求资源报文发送到VPN虚拟网卡,VPN客户端主动读取VPN虚拟网卡中的请求资源报文,对该报文进行加密后再通过物理网卡发送给VPN服务器。
VPN服务器,为同时对接VPN终端和资源服务器的服务器,可实现VPN终端对资源服务器的安全远程访问。
资源服务器,为一种存储文档、图片、视频等各种资源的应用服务器,提供资源访问等应用服务。
以上三个角色之间的交互过程如下:
当VPN终端需要访问资源服务器的某资源(比如文档、图片、视频等)时,VPN终端通过应用程序生成请求资源报文,将请求资源报文发送到该VPN终端的VPN虚拟网卡缓存,该VPN终端的VPN客户端会主动检测到VPN虚拟网卡中的请求资源报文,将上述报文获取至VPN客户端中并对其加密然后通过物理网卡发送给VPN服务器。VPN服务器收到VPN客户端发送的加密报文后对其进行解密然后转发给资源服务器。资源服务器收到上述请求资源报文后进行相应处理。
在上述过程中,VPN客户端每次只从VPN虚拟网卡读取一个报文,并且在完成对该报文的加密处理并发送给物理网卡后,才会对VPN虚拟网卡进行下一次读取报文操作。由于VPN虚拟网卡是一种软件形态非硬件设备,往往一个VPN终端会有多个VPN虚拟网卡存在,每个VPN虚拟网卡都需要VPN终端为其分配固定且有限的应用资源,所以VPN虚拟网卡的缓冲队列一般较小。如果请求资源报文较多或发送速度较快,VPN客户端对请求资源报文的加密过程耗时较长,便可能导致VPN客户端无法及时获取VPN虚拟网卡中的报文,进而导致VPN虚拟网卡的缓冲队列无法缓存所有的报文时而出现丢包的问题。
类似的,不仅VPN终端向资源服务器发送请求资源报文可能会出现丢包问题,VPN终端从资源服务器接收响应资源报文、或者VPN终端与网络中的其它设备通信时都有可能出现丢包问题。
一种容易想到的办法是如前所述,增加VNP虚拟网卡的缓存容量,然而对于VPN终端而言,其上可能运行N个VPN虚拟网卡实例,所以这种缓存的增加往往是N倍的增幅。对于没有报文收发的虚拟网卡而言,增加的缓存其实是浪费,因此这种方式固然可以缓解丢包问题,但引入了资源浪费的新问题。另一种容易想到的办法是增强VPN客户端处理报文的能力,使得加密/解密耗时较少时,看似理论上可以解决上述问题,但效果依然不好。如果通过增加硬件的方式提升处理能力则会造成成本上升。如果通过改进算法来提升处理能力,则需要投入开发升本,且提升空间有限;即便获得了提升,考虑到VPN终端设备上可能运行很多应用程序,资源消耗是不确定的,在计算资源消耗过大,设备出现瓶颈时,或多或少还会出现卡顿或阻塞等现象,此时丢包问题依然未得到有效的缓解。
为此,本申请提供一种新的报文处理方法,本方法通过在VPN客户端增加一个缓冲队列,一旦VPN虚拟网卡或物理网卡中有报文存入该网卡的第一缓冲队列时,VPN客户端便及时将该报文从VPN虚拟网卡或物理网卡中读取出来存入VPN客户端的缓冲队列,并进行处理。
在一个实施方案中,本申请提供的方法可以参照图2所示,包括如下步骤:
步骤201:VPN客户端按照预定的移转策略将网卡内第一缓冲队列中的报文转移到预先创建的隶属于VPN客户端的第二缓冲队列,其中第二缓冲队列的容量大于第一缓冲队列;
在一个典型的例子中,所谓的移转可以形象的理解为计算机操作中的剪切操作;在其他的例子中,移转可以变化为异步的读取和删除,总而言之成功读取第一缓冲队列的报文并写入第二缓冲队列后,将该报文删除即可。本领域普通技术人员可以根据实际来设计移转的具体实现,而第一缓冲队列报文的删除在最佳的场景中应该是立即删除,当然这并不是唯一的选择。
所谓的预定的移转策略可以是当VPN客户端监控到网卡的第一缓冲队列存入新报文时,从所述第一缓冲队列读取所述新报文,也可以是其他预定的移转策略,比如等待一个预定周期读取一次,如果新报文则继续执行移转,否则等待下一个周期的到来。在其他例子中,还可以等待新报文到达一定数量后再执行一次移转。
值得注意的是,这里的网卡可以为VPN虚拟网卡,也可以为物理网卡。关于这一点将在后续段落中进行详细解释。
步骤202:VPN客户端从第二缓冲队列中读取报文,并对该报文进行VPN处理;
在一个例子中,当步骤201中的网卡为VPN虚拟网卡时,步骤202中VPN客户端对第二缓冲队列中的报文进行VPN处理可包括:对第二缓冲队列中的报文进行加密,并将加密后的报文发送给物理网卡。此时该第二缓冲队列应用于发报文功能。
在另一个例子中,当步骤201中的网卡为物理网卡时,步骤202中VPN客户端对第二缓冲队列中的报文进行VPN处理可包括:对第二缓冲队列中的报文进行解密,并将解密后的报文发送给VPN虚拟网卡。此时该第二缓冲队列应用于收报文功能。
当上述例子中的第二缓冲队列都存在时,应用于收报文功能的第二缓冲队列容量大于应用于发报文功能的第二缓冲队列容量。
步骤203:VPN客户端按照预定的清空策略,将该报文从第二缓冲队列中清空。
在一个典型的例子中,所谓预定的清空策略可以是VPN客户端在所述第二缓冲队列中将所述报文进行VPN处理后,再从所述第二缓冲队列中将所述报文删除;也可以是VPN客户端在所述第二缓冲队列中将所述报文读取至VPN终端的内存中,立即将所述报文删除,然后再对所述读取至内存的报文进行VPN处理。
至此,完成图2所示流程。
通过图2所示的流程可以看出,在VPN虚拟网卡或物理网卡中有新报文存入时,VPN客户端可以主动读取网卡的第一缓冲队列中的新报文,将该新报文存入VPN客户端的第二缓冲队列中,对该新报文进行处理。这样,即使VPN客户端处理报文所消耗时间较过长,和/或网卡的第一缓冲队列中的报文较多,网卡的第一缓冲队列中的报文也不会被丢弃而是可以被及时读取保存到VPN客户端的第二缓冲队列中,解决了网卡的缓冲队列无法缓存所有的报文时而出现丢包的问题。相较于现有技术而言,本申请有效缓解了丢包的问题,相较于容易想到的方案而言,在VPN客户端处引入缓存配合报文移转机制,并不会增加太多的计算资源,并且不需要引入硬件或者改进VPN客户端的加密解密算法。
为了更加清楚地阐述本申请的具体实现以及其独特的技术优势,以下结合图3对本申请技术方案的一个典型的具体实施过程做进一步的详细说明。
步骤301:VPN客户端创建第二缓冲队列、第一变量和第一信号量。
第二缓冲队列、第一变量和第一信号量均是作用于VPN客户端的,并且在VPN客户端启动时进行初始化。
举例来说,可以通过以下代码创建并初始化第二缓冲队列:
可以通过以下代码创建并初始化第一信号量:
HANDEL hProduceSem=NILL;
其中hProduceSem是第一信号量。
可以通过以下代码创建并初始化第一变量:
struct packetQueue g_readTapPacketQuenu[512];
INT nNextProduces=0;
其中nNextProduces是第一变量。
在本申请中,第二缓冲队列,可以用于缓存VPN客户端从网卡第一缓冲队列中读取到的报文;该第二缓冲队列的默认长度为N,即第二缓冲队列支持存储的最大报文数量为N(为便于描述,本例第二缓冲队列的默认长度N为512)。且第二缓冲队列的容量大于第一缓冲队列。
上述第二缓冲队列可以应用于收报文操作,也可以应用于发报文操作,其中由于实际场景中发报文的数量和大小远远小于收报文的数量和大小,所以应用于收报文的第二缓冲队列比应用于发报文的第二缓冲队列容量要大,当然也可以为容量相等或容量要小。
第一变量,可以用于标识从网卡第一缓冲队列中读取的报文在第二缓冲队列中存储的位置;第一变量的初始值可以为小于N的任一非负整数(为便于描述,本例第一变量的初始值为0)。
第一信号量,可以用于控制VPN客户端从网卡第一缓冲队列中读取报文并将读取的报文保存在第二缓冲队列中;第一信号量表示第二缓冲队列当前能够存储的报文数量;第一信号量的初始值可以为第二缓冲队列的默认长度N(为便于描述,本例第二缓冲队列的默认长度N为512)。
步骤302:当监控到网卡的第一缓冲队列存入新报文时,VPN客户端判断所述第一信号量的值是否大于0。
如果第一信号量的值为0时,表示第二缓冲队列中所有位置均已存储了从网卡第一缓冲队列中读取的报文,此时VPN客户端不做读取报文的动作,等待第一信号量的值增加。
如果第一信号量的值大于0时,执行步骤303。
步骤303:第一信号量的值大于0时,VPN客户端从网卡的第一缓冲队列读取新报文。
在VPN客户端初始化后,VPN客户端在监控到网卡的第一缓冲队列存入新报文时,此时第一信号量的值为初始值512,由于第一信号量的值大于0,所以VPN客户端可以进行移转操作。从网卡的第一缓冲队列读取该新报文,将该新报文保存到第一变量标识的第二缓冲队列的位置处。
第二缓冲队列如图4所示,此时第一变量的值为初始值0,则该新报文可以存储在图4中“0”标识的位置,并将所述第一变量的值加1(此时第一变量的值为1);将所述第一信号量的值减1(此时第一信号量的值为511)。
当监控到网卡的第一缓冲队列存入第二个报文时,判断所述第一信号量的值为511,由于第一信号量的值大于0,VPN客户端可以进行移转操作。从网卡的第一缓冲队列读取所述报文,将所述报文保存到所述第一变量标识的第二缓冲队列的位置处。本例中此时第一变量的值为1,如图4所示的第二缓冲队列,所述报文存储在图4中“1”标识的位置,并将所述第一变量的值加1(此时第一变量的值为2),将所述第一信号量的值减1(此时第一信号量的值为510)。
以此类推,当加1后的第一变量的值等于512时,表示上一次读取网卡第一缓冲队列中的报文时第一变量已标识到第二缓冲队列的末尾。如图4所示的第二缓冲队列,所述报文存储在图4中“511”标识的位置,本次需存储的位置无法继续在第二缓冲队列标识,此时需要将第一变量的值重置为0,重新在“0”标识的位置进行存储。
当上述报文从网卡的第一缓冲队列中被VPN客户端读取后会从第一缓冲队列中删除,在最佳的场景中应该是立即删除,当然这并不是唯一的选择。
步骤304:VPN客户端创建第二信号量和第二变量;
第二变量和第二信号量均是作用于VPN客户端的,并且在VPN客户端启动时进行初始化。
举例来说,可以通过以下代码创建并初始化第二信号量:
HANDEL hConsumeSem=NILL;
其中hConsumeSem是第二信号量。
可以通过以下代码创建并初始化第二变量:
struct packetQueue g_readTapPacketQuenu[512];
INT nNextConsume=0;
其中nNextConsume是第二变量。
第二信号量,可以用于控制VPN客户端对第二缓冲队列中的报文进行处理;第二信号量表示第二缓冲队列中等待处理的报文数量;第二信号量的初始值可以为0。
第二变量,可以用于标识将要处理发送的报文在第二缓冲队列中的位置;第二变量的初始值可以为小于N的任一非负整数(为便于描述,本例第二变量的初始值为0)。
作为一个实施例,在步骤303中VPN客户端初始化后,VPN客户端在监控到网卡的第一缓冲队列存入新报文时,此时第一信号量的值为初始值512,由于第一信号量的值大于0,所以VPN客户端可以从网卡的第一缓冲队列读取该新报文,将该新报文保存到第一变量标识的第二缓冲队列的位置处。
第二缓冲队列如图4所示,此时第一变量的值为初始值0,则该新报文可以存储在图4中“0”标识的位置,并将所述第一变量的值加1(此时第一变量的值为1);将所述第一信号量的值减1(此时第一信号量的值为511)。此时还可以将第二信号量的值加1,因为第二信号量的初始值为0,所以此时第二信号量的值为1。
当监控到网卡的第一缓冲队列存入第二个报文时,判断所述第一信号量的值为511,大于0,VPN客户端从网卡的第一缓冲队列读取所述报文,将所述报文保存到所述第一变量标识的第二缓冲队列的位置处。本例中此时第一变量的值为1,如图4所示的第二缓冲队列,所述报文存储在图4中“1”标识的位置,并将所述第一变量的值加1(此时第一变量的值为2),将所述第一信号量的值减1(此时第一信号量的值为510)。
还可以将第二信号量的值加1(此时第二信号量的值为2)。
步骤305:VPN客户端判断第二信号量的值是否大于0
如果第二信号量的值等于0时,表示第二缓冲队列中没有等待处理的报文,VPN客户端处理报文的动作,等待第二信号量的值增加。
如果第二信号量的值大于0时,执行步骤306。
步骤306:第二信号量的值大于0时,VPN客户端从第二缓冲队列读取报文并进行VPN处理
当监控到所述第二信号量的值为1,第二信号量的值大于0时,从所述第二变量标识的第二缓冲队列的位置处读取报文并进行VPN处理,本例第二变量的初始值为0。如图4所示的第二缓冲队列,所述报文从图4中“0”标识的位置处读取并进行处理,并将所述第二变量的值加1(此时第二变量的值为1),将所述第二信号量的值减1(此时第二信号量的值为0),并将所述第一信号量的值加1(使第一信号量的值大于1),VPN客户端可以继续读取网卡第一缓冲队列中的报文。
以此类推,当加1后的第二变量的值等于512时,表示上一次VPN处理的报文已经在第二缓冲队列的末尾。如图4所示的第二缓冲队列,所述报文在图4中“511”标识的位置处进行VPN处理,本次需查找的报文的位置无法继续在第二缓冲队列标识,此时需要将第二变量的值重置为0,重新在“0”标识的位置进行VPN处理。
VPN客户端在所述第二缓冲队列中将所述报文进行VPN处理后,再从所述第二缓冲队列中将所述报文删除;也可以是VPN客户端在所述第二缓冲队列中将所述报文读取至内存中(该内存可以是VPN客户端也可以是该设备的内存),立即将所述报文删除,然后再对所述读取至内存的报文进行VPN处理。
作为另一个实施例,VPN客户端退出后,VPN终端回收第一信号量、第二信号量,同时回收第一变量和第二变量资源。
至此,完成图3所示的流程。
通过图3所示的流程可以看出,VPN客户端创建第二缓冲队列,并使用第一信号量和第一变量来操作VPN客户端读取网卡中第一缓冲队列的报文,以及第二信号量和第二变量来操作VPN客户端处理第二缓冲队列中的报文。因为VPN客户端读取网卡第一缓冲队列中的报文的速度远远大于VPN客户端处理VPN客户端第二缓冲队列中的报文的速度,便可能导致VPN客户端无法及时获取网卡第一缓冲队列中的报文,进而导致网卡的第一缓冲队列无法缓存所有的报文时而出现丢包的问题。
本申请中VPN客户端的第二缓冲队列设置足够大能满足处理报文时读取所有的网卡第一缓冲队列中的报文,即网卡第一缓冲队列的报文都可以即时被VPN客户端读取到第二缓冲队列,所以不会出现在网卡第一缓冲队列的丢包问题。
且本申请的VPN客户端创建的第二缓冲队列可满足VPN环境中的收发包双向功能,具有极强的可拓展性和应用性,可满足VPN环境中的任一收发报文场景。
以上对本申请提供的方法进行了描述。下面对本申请提供的装置进行描述。
参见图5,该图为本申请实施例提供的一种报文处理装置的功能模块框图,该装置可以应用于主机的虚拟专用网络VPN客户端。所述装置包括:
移转单元501,用于按照预定的移转策略将网卡内第一缓冲队列中的报文转移到预先为VPN客户端创建的VPN客户端的一个或多个第二缓冲队列;
处理单元502,用于从第二缓冲队列中读取报文,并对该报文进行VPN处理;
清空单元503,用于将该报文从第二缓冲队列中清空。
在其中一种实施方式中,所述装置还可以包括:
创建单元,用于创建第一变量和第一信号量;所述第一信号量的初始值为所述第二缓冲队列支持存储的最大报文数量N,第一变量的初始值为小于N的任一非负整数;
所述移转单元,还用于当监控到网卡的第一缓冲队列存入新报文时,在确定所述第一信号量的值大于0时,从所述第一缓冲队列读取所述新报文,将所述新报文保存到所述第一变量标识的第二缓冲队列的位置处,并将所述第一变量的值加1,以及将所述第一信号量的值减1;当第一变量的值等于N时,将第一变量的值重置为0。
在其中一种实施方式中,所述创建单元还用于创建第二信号量;所述第二信号量用于表示所述第二缓冲队列中等待处理的报文数量,第二信号量的初始值等于0;将所述新报文保存到所述第一变量标识的第二缓冲队列的位置处后,将所述第二信号量的值加1;还用于创建第二变量,所述第二变量的初始值与所述第一变量的初始值相同;
所述处理单元,还用于当监控到所述第二信号量的值大于0时,从所述第二变量标识的第二缓冲队列的位置处读取报文并进行处理,以及将所述第二变量的值加1,将所述第二信号量的值减1,将所述第一信号量的值加1;当第二变量的值等于N时,将第二变量的值重置为0。
在其中一种实施方式中,所述创建单元还用于创建的第二缓冲队列其中至少一个用于收报文的第二缓冲队列和至少一个用于发报文的第二缓冲队列,其中收报文的第二缓冲队列的容量大于发报文的第二缓冲队列。
在其中一种实施方式中,所述处理单元502,还用于当所述网卡为VPN虚拟网卡时,对所述第二缓冲队列中的报文进行加密,并将加密后的报文发送给物理网卡,当所述网卡为物理网卡时,对所述第二缓冲队列中的报文进行解密,并将解密后的报文发送给VPN虚拟网卡。
需要说明的是,本申请实施例中对单元的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。在本申请的实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
如图6所示,本申请实施例还提供一种报文处理装置,所述装置包括通信接口601、处理器602、存储器603和总线604;其中,通信接口601、处理器602、存储器603通过总线604完成相互间的通信。
其中,通信接口601,用于发送和接收报文。处理器602可以是一个中央处理器(CPU),存储器603可以是非易失性存储器(non-volatile memory),并且存储器603中存储有报文处理逻辑指令,处理器602可以执行存储器603中存储的报文处理逻辑指令,以实现上述的报文处理方法,参见图3所示流程中VPN客户端的功能。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。
Claims (10)
1.一种报文处理方法,其特征在于,该方法用于主机的虚拟专用网络VPN客户端,该方法包括:
按照预定的移转策略将网卡内第一缓冲队列中的报文转移到预先为VPN客户端创建的VPN客户端的一个或多个第二缓冲队列,其中第二缓冲队列的总容量大于第一缓冲队列;
从第二缓冲队列中读取报文,并对该报文进行VPN处理;
按照预定的清空策略,将该报文从第二缓冲队列中清空。
2.如权利要求1所述的方法,其特征在于,所述方法还包括:
创建第一变量和第一信号量;所述第一信号量的初始值为所述第二缓冲队列支持存储的最大报文数量N,第一变量的初始值为小于N的任一非负整数;
所述按照预定的移转策略将网卡内第一缓存队列中的报文转移到预先为VPN客户端创建的的VPN客户端的一个或多个第二缓冲队列,包括:
当监控到网卡的第一缓冲队列存入新报文时,在确定所述第一信号量的值大于0时,从所述第一缓冲队列读取所述新报文,将所述新报文保存到所述第一变量标识的第二缓冲队列的位置处,并将所述第一变量的值加1,以及将所述第一信号量的值减1;
当第一变量的值等于N时,将第一变量的值重置为0。
3.如权利要求2所述的方法,其特征在于,所述方法还包括:
创建第二信号量;所述第二信号量用于表示所述第二缓冲队列中等待处理的报文数量,第二信号量的初始值等于0;将所述新报文保存到所述第一变量标识的第二缓冲队列的位置处后,将所述第二信号量的值加1;
创建第二变量,所述第二变量的初始值与所述第一变量的初始值相同;
所述对所述第二缓冲队列中的报文进行VPN处理,包括:
当监控到所述第二信号量的值大于0时,从所述第二变量标识的第二缓冲队列的位置处读取报文并进行处理,以及将所述第二变量的值加1,将所述第二信号量的值减1,将所述第一信号量的值加1;
当第二变量的值等于N时,将第二变量的值重置为0。
4.如权利要求1所述的方法,其特征在于,当所述网卡为VPN虚拟网卡时,所述对所述第二缓冲队列中的报文进行处理,包括:
对所述第二缓冲队列中的报文进行加密,并将加密后的报文发送给物理网卡;
当所述网卡为物理网卡时,所述对所述第二缓冲队列中的报文进行处理,包括:
对所述第二缓冲队列中的报文进行解密,并将解密后的报文发送给VPN虚拟网卡。
5.如权利要求1所述的方法,其特征在于,预先创建的第二缓冲队列,包括;
其中至少一个用于收报文的第二缓冲队列和至少一个用于发报文的第二缓冲队列,其中收报文的第二缓冲队列的容量大于发报文的第二缓冲队列。
6.一种报文处理装置,其特征在于,该装置用于主机的虚拟专用网络VPN客户端,该装置包括:
移转单元,用于按照预定的移转策略将网卡内第一缓冲队列中的报文转移到预先为VPN客户端创建的VPN客户端的一个或多个第二缓冲队列,其中第二缓冲队列的总容量大于第一缓冲队列;
处理单元,用于从第二缓冲队列中读取报文,并对该报文进行VPN处理;
清空单元,用于将该报文从第二缓冲队列中清空。
7.如权利要求6所述的装置,其特征在于,所述装置还包括创建单元;
所述创建单元,用于创建第一变量和第一信号量;所述第一信号量的初始值为所述第二缓冲队列支持存储的最大报文数量N,第一变量的初始值为小于N的任一非负整数;
所述移转单元,还用于当监控到网卡的第一缓冲队列存入新报文时,在确定所述第一信号量的值大于0时,从所述第一缓冲队列读取所述新报文,将所述新报文保存到所述第一变量标识的第二缓冲队列的位置处,并将所述第一变量的值加1,以及将所述第一信号量的值减1;当第一变量的值等于N时,将第一变量的值重置为0。
8.如权利要求7所述的装置,其特征在于,
所述创建单元,还用于创建第二信号量;所述第二信号量用于表示所述第二缓冲队列中等待处理的报文数量,第二信号量的初始值等于0;将所述新报文保存到所述第一变量标识的第二缓冲队列的位置处后,将所述第二信号量的值加1;以及创建第二变量,所述第二变量的初始值与所述第一变量的初始值相同;
所述处理单元,还用于当监控到所述第二信号量的值大于0时,从所述第二变量标识的第二缓冲队列的位置处读取报文并进行处理,以及将所述第二变量的值加1,将所述第二信号量的值减1,将所述第一信号量的值加1;当第二变量的值等于N时,将第二变量的值重置为0。
9.如权利要求6所述的装置,其特征在于,
处理单元,用于当所述网卡为VPN虚拟网卡时,对所述第二缓冲队列中的报文进行加密,并将加密后的报文发送给物理网卡;当所述网卡为物理网卡时,对所述第二缓冲队列中的报文进行解密,并将解密后的报文发送给VPN虚拟网卡。
10.如权利要求6所述的装置,其特征在于,所述装置还包括:
创建单元,用于创建第二缓冲队列,创建的第二缓冲队列包括至少一个用于收报文的第二缓冲队列和至少一个用于发报文的第二缓冲队列,其中收报文的第二缓冲队列的容量大于发报文的第二缓冲队列。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810542890.7A CN108833301A (zh) | 2018-05-30 | 2018-05-30 | 一种报文处理方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810542890.7A CN108833301A (zh) | 2018-05-30 | 2018-05-30 | 一种报文处理方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN108833301A true CN108833301A (zh) | 2018-11-16 |
Family
ID=64147086
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810542890.7A Pending CN108833301A (zh) | 2018-05-30 | 2018-05-30 | 一种报文处理方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108833301A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111107019A (zh) * | 2019-12-29 | 2020-05-05 | 浪潮电子信息产业股份有限公司 | 一种数据传输方法、装置、设备及计算机可读存储介质 |
CN117112044A (zh) * | 2023-10-23 | 2023-11-24 | 腾讯科技(深圳)有限公司 | 基于网卡的指令处理方法、装置、设备和介质 |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101414973A (zh) * | 2008-11-25 | 2009-04-22 | 中国人民解放军信息工程大学 | 一种传输数据包的方法及装置 |
CN103347075A (zh) * | 2013-07-02 | 2013-10-09 | 北京金和软件股份有限公司 | 一种数据多级缓存处理方法 |
CN104509047A (zh) * | 2012-07-31 | 2015-04-08 | 华为技术有限公司 | 报文传输系统中分配报文缓冲区的方法 |
CN105991567A (zh) * | 2015-02-06 | 2016-10-05 | 中兴通讯股份有限公司 | 发送处理方法及装置 |
CN106254924A (zh) * | 2016-10-08 | 2016-12-21 | 广东欧珀移动通信有限公司 | 一种多媒体数据的播放方法、系统及相关设备 |
CN106385379A (zh) * | 2016-09-14 | 2017-02-08 | 杭州迪普科技有限公司 | 报文缓存方法及装置 |
US20170208010A1 (en) * | 2015-01-30 | 2017-07-20 | Vmware, Inc. | Data transmission using modified weighted fair queue algorithm |
CN107005494A (zh) * | 2014-12-24 | 2017-08-01 | 英特尔公司 | 用于在交换机中缓冲数据的装置和方法 |
CN107347039A (zh) * | 2016-05-05 | 2017-11-14 | 深圳市中兴微电子技术有限公司 | 一种共享缓存空间的管理方法及装置 |
CN107426117A (zh) * | 2016-05-23 | 2017-12-01 | 迈络思科技Tlv有限公司 | 网络交换机中的缓冲区空间的有效使用 |
CN107689923A (zh) * | 2016-08-04 | 2018-02-13 | 华为技术有限公司 | 报文处理方法及路由器 |
CN107733813A (zh) * | 2016-08-12 | 2018-02-23 | 中兴通讯股份有限公司 | 报文转发方法及装置 |
-
2018
- 2018-05-30 CN CN201810542890.7A patent/CN108833301A/zh active Pending
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101414973A (zh) * | 2008-11-25 | 2009-04-22 | 中国人民解放军信息工程大学 | 一种传输数据包的方法及装置 |
CN104509047A (zh) * | 2012-07-31 | 2015-04-08 | 华为技术有限公司 | 报文传输系统中分配报文缓冲区的方法 |
CN103347075A (zh) * | 2013-07-02 | 2013-10-09 | 北京金和软件股份有限公司 | 一种数据多级缓存处理方法 |
CN107005494A (zh) * | 2014-12-24 | 2017-08-01 | 英特尔公司 | 用于在交换机中缓冲数据的装置和方法 |
US20170208010A1 (en) * | 2015-01-30 | 2017-07-20 | Vmware, Inc. | Data transmission using modified weighted fair queue algorithm |
CN105991567A (zh) * | 2015-02-06 | 2016-10-05 | 中兴通讯股份有限公司 | 发送处理方法及装置 |
CN107347039A (zh) * | 2016-05-05 | 2017-11-14 | 深圳市中兴微电子技术有限公司 | 一种共享缓存空间的管理方法及装置 |
CN107426117A (zh) * | 2016-05-23 | 2017-12-01 | 迈络思科技Tlv有限公司 | 网络交换机中的缓冲区空间的有效使用 |
CN107689923A (zh) * | 2016-08-04 | 2018-02-13 | 华为技术有限公司 | 报文处理方法及路由器 |
CN107733813A (zh) * | 2016-08-12 | 2018-02-23 | 中兴通讯股份有限公司 | 报文转发方法及装置 |
CN106385379A (zh) * | 2016-09-14 | 2017-02-08 | 杭州迪普科技有限公司 | 报文缓存方法及装置 |
CN106254924A (zh) * | 2016-10-08 | 2016-12-21 | 广东欧珀移动通信有限公司 | 一种多媒体数据的播放方法、系统及相关设备 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111107019A (zh) * | 2019-12-29 | 2020-05-05 | 浪潮电子信息产业股份有限公司 | 一种数据传输方法、装置、设备及计算机可读存储介质 |
CN117112044A (zh) * | 2023-10-23 | 2023-11-24 | 腾讯科技(深圳)有限公司 | 基于网卡的指令处理方法、装置、设备和介质 |
CN117112044B (zh) * | 2023-10-23 | 2024-02-06 | 腾讯科技(深圳)有限公司 | 基于网卡的指令处理方法、装置、设备和介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3606541B2 (ja) | 複数ノードの非同期データ通信システム内で早期到達メッセージを処理する方法 | |
US6904040B2 (en) | Packet preprocessing interface for multiprocessor network handler | |
US6747949B1 (en) | Register based remote data flow control | |
US7631106B2 (en) | Prefetching of receive queue descriptors | |
CN100438403C (zh) | 用于管理通过网络的数据传输的方法和系统 | |
KR101006114B1 (ko) | 콘텐츠 푸시 서비스 | |
CN107257329B (zh) | 一种数据分段卸载发送方法 | |
CN104796337A (zh) | 一种转发报文的方法及装置 | |
TW200814672A (en) | Method and system for a user space TCP offload engine (TOE) | |
US20050187979A1 (en) | System and method for message-level connection management | |
US20130132960A1 (en) | Usb redirection for read transactions | |
US8700873B2 (en) | Direct memory access memory management | |
JP2017513096A (ja) | コンピュータ、制御デバイス及びデータ処理方法 | |
US7577956B2 (en) | Method, system and program storage device for accessing memory to perform messaging using a channel coupled to a sender and a receiver | |
CN104754012A (zh) | 一种数据传输方法和数据传输系统 | |
CN114490499A (zh) | 用于流送输入/输出数据的系统、装置和方法 | |
CN105141603A (zh) | 通信数据传输方法及系统 | |
CN111290979B (zh) | 数据传输方法、装置及系统 | |
CN108833301A (zh) | 一种报文处理方法和装置 | |
CN112052483A (zh) | 一种密码卡的数据通信系统及方法 | |
US8819305B2 (en) | Directly providing data messages to a protocol layer | |
US20060167922A1 (en) | Method and apparatus for managing data object size in a multi-user environment | |
JP5479710B2 (ja) | データを処理するためのプロセッサ‐サーバ・ハイブリッド・システムおよび方法 | |
US10719376B2 (en) | Methods and apparatus for multiplexing data flows via a single data structure | |
US9288163B2 (en) | Low-latency packet receive method for networking devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20181116 |