CN108718279A - 一种基于Linux系统实现路由器的portal认证报文转发方法和装置 - Google Patents

Abstract

本发明涉及计算机路由技术领域，提供了一种基于Linux系统实现路由器的portal认证报文转发方法和装置。物理网卡收到portal认证报文，并解析出portal认证报文的目的IP；确认portal认证报文的目的IP与虚拟网卡的环回口IP相同，将portal认证报文写入到对应的虚拟网卡的缓存区中；虚拟网卡获取到portal认证报文后，查询Linux系统上的第一路由表，生成回应报文；用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文，根据查找到的第二路由表项选取回应报文的出口物理网卡，通过出口物理网卡将所述回应报文发出去。本发明实现了基于Linux系统的路由器对外呈现的环回口功能，提高了portal认证报文转发的稳定性。

Description

一种基于Linux系统实现路由器的portal认证报文转发方法 和装置

【技术领域】

本发明涉及计算机路由技术领域，特别是涉及一种基于Linux系统实现路由器的portal认证报文转发方法和装置。

【背景技术】

在传统路由器上，存在着一种虚拟接口，称之为环回口或loopback接口，环回口是一种逻辑上的接口，与物理网口无关，它的状态永远是UP的。

环回口的特点是稳定，不存在故障的可能性，比如路由器有多个接口连接到网络，为了安全起见只允许一个接口的IP地址可以被telnet，而正好该接口出现了故障，这时就无法登录到该路由器了，而如果用了环回口作为telnet的管理地址，只要还有一个物理接口正常连接到网络，那么都能登录到该路由器，当然前提是把环回口的路由宣告到了网络。又比如边界网关协议(Border Gateway Protocol，简写为：BGP)会话如果使用物理接口进行连接，那么这个物理接口一旦down了，BGP邻居也就down了，再up时又要重新初始化BGP并进行路由收敛，这是相当耗路由器性能的，而且耗时间，如果使用了环回口作为BGP会话的接口，那么即使当前使用的链路中断了，但只要网络中还存在其它可以到达对方的链路时，BGP会话就不会被重置，保证了网络的稳定性。当然，环回口还可以做很多用处，但它的特点主要体现在稳定性上。

在x86架构Linux系统上实现路由器的功能，就必须实现环回口，但是通用Linux系统上并没有实现这样一个虚拟的接口，所以需要设计一种方案来实现。

【发明内容】

本发明要解决的技术问题是在x86架构Linux系统上实现路由器的功能，就必须实现环回口，但是通用Linux系统上并没有实现这样一个虚拟的接口，所以需要设计一种方案来实现，并且，如何将所具有环回口功能的路由器应用到portal认证报文转发中去。

本发明进一步要解决的技术问题是如果通过Linux系统自身具有的处理能力，将其介入到常规的路由功能中去，从而提出常规路由器无法解决或者改善的功能，包括对报文的深度解析等等。

本发明采用如下技术方案：

第一方面，本发明提供了一种基于Linux系统实现路由器的portal认证报文转发方法，在Linux系统上创建虚拟网卡，为虚拟网卡配置环回口IP地址，配置portal进程监听环回口的TCP协议预设端口，并启动portal进程，方法包括：

物理网卡收到portal认证报文，用户空间应用程序获取所述portal认证报文，并解析出所述portal认证报文的目的IP；

用户空间应用程序确认所述portal认证报文的目的IP与虚拟网卡的环回口IP相同，将所述portal认证报文写入到对应的虚拟网卡的缓存区中；

虚拟网卡通过对应缓存区获取到所述portal认证报文后，确认portal认证报文的目的端口与portal进程监听的预设端口相同，则将所述portal认证报文交给portal进程进行处理，portal进程按照portal协议生成回应报文；

查询Linux系统上的第一路由表，并根据找到的第一路由表项，选择所述虚拟网卡发送portal进程的回应报文；其中，所述回应报文被存储在相应虚拟网卡的缓存区上；

用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文，查询用户空间应用程序中的第二路由表，根据查找到的第二路由表项选取回应报文的出口物理网卡，通过所述出口物理网卡将所述回应报文发出去。

优选的，所述第一路由表中存储有所述虚拟网卡的环回口IP地址以及相应虚拟网卡的端口号的策略路由，所述策略路由基于环回口IP作为源地址进行选路，虚拟网卡生成回应报文时查询该策略路由选取虚拟网卡；所述第二路由表存储有路由网络环境，由各路由器的IP地址以及相应各路由器的端口号构成，用于用户空间应用程序查询该路由选取出物理网卡，基于源IP网段，目的IP网段,目的端口范围和协议类型进行选路。

优选的，用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文后，查询用户空间应用程序中的第二路由表，根据查找到的第二路由表项选取回应报文的出口物理网卡，还包括：

应用程序对于所述回应报文进行深度包分析，获取所述回应报文的应用类型、网速配置、带宽要求中的一项或者多项分析结果；并根据所述分析结果和所述第二路由表项，选配适合上述应用类型、网速配置和/或带宽要求的物理网卡和相应端口，用于传输所述回应报文。

优选的，所述方法还包括：

接收针对第二路由表的更新报文，其中，所述针对第二路由表的更新报文由服务器侧根据当前网络类型状态生成的用于深度报文解析后，识别出的对应不同应用类型、网速配置和/或带宽要求的路由策略；

用户空间应用程序更新本地存储的第二路由表中的相应路由策略。

优选的，在出现本地设备中的第一物理网卡故障时，用户空间应用程序检测到网卡故障，通过动态路由协议通告给相邻路由器，并更新本地的第二路由表，将原本基于深度包分析分配给所述第一物理网卡发送的报文的路由表项更新为与所述第一物理网卡性能最相近的第二物理网卡。

优选的，在所述用户空间应用程序对从物理网卡收到的portal认证报文中，获取portal认证报文的目的IP之前，所述方法还包括：

在Linux内核中，建立预设数量的缓存，然后用环形缓冲区队列描述符连接起来构成网络缓冲区列表；

Linux内核建立物理网卡与所述网络缓冲区列表之间的映射关系；其中，所述缓冲区控制权根据数据的写入和读取需求，分别在物理网卡和用户空间应用程序之间进行切换。

优选的，所述将所述portal认证报文写入到对应的虚拟网卡的缓存区上，具体包括：

用户空间应用程序使用write()系统函数调用向虚拟网卡的字符设备文件写入portal认证报文时，tun_chr_write()函数将被调用，所述tun_chr_write()函数使用tun_get_user()从用户区接受数据，其中将数据存入虚拟网卡的缓存区中；以便虚拟网卡调用函数netif_rx()将虚拟网卡的缓存区发送给TCP/IP协议栈处理，确认portal认证报文的目的端口与portal进程监听的预设端口相同时，转交给portal进程完成回应报文的生成。

优选的，所述用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文，具体包括：

所述TCP/IP协议栈把生成的回应报文存储在虚拟网卡的缓存区中；唤醒被阻塞的使用虚拟网卡的字符设备读数据的进程，虚拟网卡的字符设备读取虚拟网卡的缓存区，并将每一个读到的缓存发给用户空间应用程序。

优选的，所述方法还包括用户空间应用程序主动向外发起报文，具体包括：

用户空间应用程序调用socket函数接口，指定目标设备IP地址，并从虚拟网卡主动发出报文；其中，所述主动发出报文包括：主动与路由器建立BGP邻居的报文、更新网络拓扑中其它路由器中路由表的报文、向服务器发送本地物理网卡发生故障的消息报文和向服务器发送DPI分析报文中的一种或者多种。

第二方面，本发明还提供了一种基于Linux系统实现路由器的portal认证报文转发装置，用于实现第一方面所述的基于Linux系统实现路由器的portal认证报文转发方法，所述装置包括：

至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被程序设置为执行第一方面所述的基于Linux系统实现路由器的portal认证报文转发方法。

第三方面，本发明还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，用于完成第一方面所述的基于Linux系统实现路由器的portal认证报文转发方法。

本发明通过设计一虚拟网卡，实现了基于Linux系统的路由器对外呈现的环回口功能，提高了路由器自身的稳定性，并且，通过创建虚拟网卡，实现了用户空间应用程序对数据报文的读取、解析和发送过程的介入，并且实现了本发明所提出的路由器与portal认证报文转发功能的融合，为本发明后续扩展实现方案中解决常规路由器所无法实现的复杂解析过程提供了设计接口。

【附图说明】

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种基于Linux系统实现路由器的portal认证报文转发方法的流程示意图；

图2是本发明实施例提供的一种基于Linux系统实现路由器的portal认证报文转发的配置参数示意图；

图3是本发明实施例提供的一种基于Linux系统实现路由器的portal认证报文转发的配置参数示意图；

图4是本发明实施例提供的一种具体应用场景的架构示意图；

图5是本发明实施例提供的一种用户空间应用程序对从物理网卡收到的portal认证报文中的流程扩展开后实现流程示意图；

图6是本发明实施例提供的一种基于Linux系统实现路由器的portal认证报文转发改进方法的流程示意图；

图7是本发明实施例提供的一种创建网络缓冲区列表的架构信令示意图；

图8是本发明实施例提供的一种基于Linux系统实现路由器的portal认证报文转发方法的流程示意图；

图9是本发明实施例提供的一种基于Linux系统实现的路由器发生网卡故障的信令架构图；

图10是本发明实施例提供的一种基于Linux系统实现路由器的portal认证报文转发装置的结构示意图。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在本发明的描述中，术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不应当理解为对本发明的限制。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

在现有的网络架构中，若想在x86架构Linux系统上实现路由器的功能，就必须实现环回口功能。这是因为随着网络拓扑复杂度的提升，以及数据量的爆炸式增长，普通的固定物理IP的方式已经无法适应上述环境下的设备鲁棒性要求。但是通用Linux系统上并没有实现这样一个虚拟的接口，因此，无法在x86架构Linux系统实现具有环回口功能的路由器。

实施例1:

本发明实施例1提供了一种基于Linux系统实现路由器的portal认证报文转发方法，首先在Linux系统上创建虚拟网卡，为虚拟网卡配置环回口IP地址，配置portal进程监听环回口的TCP协议预设端口，并启动portal进程；所述环回口IP地址，即Linux系统被表征为一路由器后，其在网络中表征的一个可被寻址的地址，所述环回口IP地址与Linux系统上配置的多个物理网卡建立映射关系，从而能够实现其被作为目标寻址功能和作为发送源地址到物理网络的衔接。如图1所示，方法包括：

在步骤201中，物理网卡收到portal认证报文，用户空间应用程序获取所述portal认证报文，并解析出所述portal认证报文的目的IP。

其中，物理网卡是数据报文的直接接收设备，所述物理网卡通常是指插在主板上的或者集成在主板上的网卡硬件设备，所述物理网卡具备同外部网络连接的网口或者无线宽带收发模块。而所述虚拟网卡提供了用户空间应用程序访问内核数据的接口。

在步骤202中，用户空间应用程序确认所述portal认证报文的目的IP与虚拟网卡的环回口IP相同，将所述portal认证报文写入到对应的虚拟网卡的缓存区中。

其中，通常是利用Linux系统的write()系统函数将所述portal认证报文写入到对应的虚拟网卡的缓存区中。

在步骤203中，虚拟网卡通过对应缓存区获取到所述portal认证报文后，确认portal认证报文的目的端口与portal进程监听的预设端口相同，则将所述portal认证报文交给portal进程进行处理，portal进程按照portal协议生成回应报文。

在步骤204中，查询Linux系统上的第一路由表，并根据找到的相应路由表项，选择所述虚拟网卡发送portal进程的回应报文。其中，所述回应报文被存储在相应虚拟网卡的缓存区上。

在具体实现方法中，所述回应报文通常都是由协议栈来完成的，即虚拟网卡在找到相应路由表项后，便会将portal认证报文和所述相关路由表项发送给协议栈，并由协议栈完成所述回应报文的生成。

其中，所述第一路由表中存储有所述虚拟网卡的环回口IP地址以及相应虚拟网卡的端口号的策略路由，所述策略路由基于环回口IP作为源地址进行选路，虚拟网卡生成回应报文时查询该策略路由选取出虚拟网卡。所述第一路由表是Linux系统的TCP/IP协议栈上的，为了减小对Linux系统内核的资源的占用和损耗，在本发明实施例中，所述第一路由表中并不存储对外的路由信息，而仅仅用于存储虚拟网卡的环回口IP地址以及相应的虚拟网卡的端口号，以便用户空间应用程序调取相应回应报文的时候，知道该回应报文的实现意图，即需要通过环回口IP地址制定某一具体物理网卡完成报文的发送。而在所述第一路由表中是不存储实质性路由信息的，相应涉及实质路由信息的内容，将被存储在位于用户空间的第二路由表中，从而达到上述减小对Linux系统内核的资源的占用和损耗的目的。

以图2所示的配置参数为例，通过本发明实施例所提出的方法，通过生成虚拟网卡创建了一个环回口loopback0,loopback0的IP为10.0.2.2,在第一路由表中添加了一条策略路由：报文的源IP地址为10.0.2.2的从环回口loopback0发出去，即源IP为10.0.2.2--->loopback0。

在步骤205中，用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文，查询用户空间应用程序中的第二路由表，根据查找到的第二路由表项选取回应报文的出口物理网卡，通过所述出口物理网卡将所述回应报文发出去。

其中，所述第二路由表存储有路由网络环境中，各路由器的IP地址以及相应各路由器的端口号(例如：源IP、目的IP、目的端口等等)，该路由基于源IP网段，目的IP网段,目的端口范围和协议类型(TCP/UDP)进行选路，用户空间应用程序查询该路由选取出物理网卡。在本发明实施例中，将总量可能达到数以千计的路由表项存储在位于用户空间层的所述第二路由表中，从而简化了步骤204中的存储在内核中的第一路由表，节省了资源更为稀缺的内核中的资源占用。

以图3所示的配置参数为例，应用程序路由表项：基于源IP网段，目的IP网段，目的端口范围，协议类型进行选路。即目的IP为1.1.1.1/32-->eth2，其中，eth2为物理网卡的身份标识(在本发明实施例后续例子展示中将会继续使用该标识号来进行说明)。

本发明实施例通过设计一虚拟网卡，实现了基于Linux系统的路由器对外呈现的环回口功能，提高了路由器自身的稳定性，并且，通过创建虚拟网卡，实现了用户空间应用程序对数据报文的读取、解析和发送过程的介入，并且实现了本发明所提出的路由器与portal认证报文转发功能的融合，为本发明后续扩展实现方案中解决常规路由器所无法实现的复杂解析过程提供了设计接口。

对本发明实施例所提出的方法，给予了一具体应用场景进行阐述，以图4为例，路由器R1要与应用程序建立通讯，指定使用1.1.1.1与应用程序的环回口loopback0的IP为10.0.2.2建立连接。路由器R1发起的portal认证报文的源IP为1.1.1.1,目的IP为10.0.2.2，该报文到达物理网卡eth2后,被应用程序收到，应用程序判断目的IP为10.0.2.2为虚拟网卡(在本实例中以TUN虚拟网卡为例)的环回口loopback0的IP,故去掉二层mac头部,只将包含IP头部的报文通过write函数给虚拟网卡的环回口loopback0,虚拟网卡调用协议栈生成回应报文的源IP为10.0.2.2,目的IP为1.1.1.1,查询上述的第一路由中的策略路由(该处为第一路由，协议栈的处理过程无法查询应用程序中的第二路由)，选择从loopback0将回应报文发出来。应用程序通过read函数捕获此回应报文，查询应用程序中的第二路由，选择回应报文的出物理网卡为eth2，根据物理网卡eth2的mac和vlan信息将回应报文封装二层头部后从eth2发送给R1。

在本发明实施例1中，为了提高用户空间应用程序和物理网卡对于接收到的portal认证报文的数据处理统一性和高效性，存在一种优选的实现方案，即在Linux内核中，建立预设数量的缓存，然后用环形缓冲区队列描述符连接起来构成网络缓冲区列表。

Linux内核建立物理网卡与所述网络缓冲区列表之间的映射关系；其中，所述缓冲区控制权根据数据的写入和读取需求，分别在物理网卡和用户空间应用程序之间进行切换。实际实现过程中所述缓冲区还可以接收用户空间应用程序的写入和读取操作，当然用户空间应用程序对所述缓冲区的相关操作也可以经由虚拟网卡来实现，上述两种实现用户空间应用程序访问缓冲区方式均可在本发明实施例中实现。所述用户空间应用程序则通过所述虚拟网卡实现对所述网络缓冲区列表中数据的读取和写入操作。Linux

因此，在步骤201中，用户空间应用程序对从物理网卡收到的portal认证报文中的流程扩展开，如图5所示，会表现为以下子步骤：

在步骤2011中，物理网卡获取到portal认证报文，将所述portal认证报文内容write到网络缓冲区列表中。

其中，所述物理网卡通过其自身与所述网络缓冲区列表之间的映射关系，从而可以通过调用Linux内核函数write完成上述portal认证报文内容写入操作。

在步骤2012中，用户空间应用程序从所述网络缓冲区列表中读取相应的portal认证报文内容，并获取portal认证报文的目的IP。

其中，用户空间应用程序在物理网卡将portal认证报文写入到所述网络缓冲区列表中后，便会收到一个通知消息(也被成为唤醒指令)，从而激活用户空间应用程序对所述网络缓冲区列表，发起read函数操作，从而得到相应的portal认证报文内容。

通过上述步骤2011和步骤2012的优化处理，Linux内核将无需直接接入到portal认证报文的处理过程中，而仅需要提供所述网络缓冲区列表存储区间，便能提升用户空间应用程序获取所述portal认证报文内容的效率，否则，按照现有技术的处理过程，用户空间应用程序与物理网卡之间还会夹杂进Linux内容对portal认证报文的反应内容，从而降低了整个基于Linux系统实现的路由功能效率。

结合本发明实施例，除了主体方案所涉及的接收到来自其它路由器或者终端发送的报文(例如：上述portal认证报文)，并进行回应报文生成和发送以外，还可以通过本发明实施例所提出的基于Linux系统实现的路由器主动发起报文，具体的，所述方法还包括用户空间应用程序主动向外发起报文，具体描述如下：

用户空间应用程序调用socket函数接口，指定目标设备IP地址，并从虚拟网卡主动发出报文；其中，所述主动发出报文包括：主动与路由器建立BGP邻居的报文、更新网络拓扑中其它路由器中路由表的报文、向服务器发送本地物理网卡发生故障的消息报文和向服务器发送DPI分析报文中的一种或者多种。

其中，主动与路由器建立BGP邻居的报文是一种基于BGP协议的业务类型报文，其用于建立完成BGP网络拓扑架构；而更新网络拓扑中其它路由器中路由表的报文，则是现有动态路由表建立功能移植到本发明实施例中的表现；所述向服务器发送本地物理网卡发生故障的消息报文，则是紧扣本发明实施例所提出的拥有环回口功能路由器中，继续解决的问题情况，即发生了部分硬件网卡故障后，如何第一时间通知服务器，而相应的问题则可以通过本发明的用户空间应用程序实现及时的上报功能；而向服务器发送DPI分析报文则是进一步在本发明实施例中提出了深度包分析功能以后，衍伸出来的附加功能，即向服务器上报一段时间内转发的报文类型、报文总量、指定应用类型报文总量、指定目的地址访问报文数量等等，均属于所述DPI分析报文所能携带的数据范畴内。

结合本发明实施例，还存在一种扩展方案，在所述扩展方案中，相应的portal认证报文可以表现为服务器针对所述第二路由表的更新报文，则所述方法还包括：

接收第二路由表的更新报文，其中，所述第二路由表的更新报文由服务器侧根据当前网络类型状态生成的针对深度报文解析后，识别出的对应不同应用类型、网速配置和/或带宽要求的路由策略；更新本地存储的第二路由表中的相应路由策略。需要强调的是，所述第二路由表的更新报文是在本发明实施例所提出的基于Linux系统实现路由器的portal认证报文转发方法中，在具备了上述扩展方案中所描述的深度包分析功能后，才能实现的。而上述更新本地存储的第二路由表中的相应路由策略，最直观的表现便是对于深度包分析得出是应用A的报文，则按照路由策略配置给物理网卡A发送。

对上上述的深度报文解析的应用路由举例如下：

1)、对用户空间应用程序配置应用路由规则，例如：迅雷下载的报文从网卡eth1发出。

2)、用户空间应用程序对收到的业务报文进行协议识别，例如识别到：目的IP是dip1，目的端口是port1，协议类型是proto1的报文是迅雷下载。

3)、用户空间应用程序更新第二路由表，生成新的路由表项：目的IP是dip1，目的端口是port1，协议类型是proto1的报文从网卡eth1发出。

4)、用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文后，查询用户空间应用程序中的第二路由表，根据查找到的第二路由表项选取回应报文的出口物理网卡。

由于在本发明实施例所提出的基于Linux系统的路由器中，引入了深度包分析功能和对应的路由策略，那么在出现本地设备中的第一物理网卡故障时，也需要做不同于以往的路由策略的调整。因此，结合本发明实施例，还存在一种优选的实现方案，具体的，用户空间应用程序检测到网卡故障，通过动态路由协议通告给相邻路由器，并更新本地的第二路由表，将原本基于深度包分析分配给所述第一物理网卡发送的报文的路由表项更新为与所述第一物理网卡性能最相近的第二物理网卡。

实施例2：

本发明实施例相比较实施例1所述的基于Linux系统实现路由器的portal认证报文转发方法，对于步骤202中写入对应的虚拟网卡的缓存区中的portal认证报文做了进一步精细化的处理，使得后续解析所述portal认证报文所需读取的数据量和执行速度得到了进一步的提高，如图6所示，具体包括：

在步骤301中，物理网卡收到portal认证报文，用户空间应用程序获取所述portal认证报文，并解析出所述portal认证报文的目的IP。

其中，物理网卡是数据报文的直接接收设备，所述物理网卡通常是指插在主板上的或者集成在主板上的网卡设备，所述物理网卡具备同外部网络连接的网口或者无线宽带收发模块。而所述虚拟网卡提供了用户空间应用程序访问内核数据的接口。

在步骤302中，用户空间应用程序确认所述portal认证报文的目的IP与虚拟网卡的环回口IP相同，则去掉所述portal认证报文的以太网二层头部后得到第二报文，将所述第二报文写入到对应的虚拟网卡的缓存区中。

其中，通常是利用Linux系统的write()系统函数将所述第二报文写入到对应的虚拟网卡的缓存区中。

其中，上面的报文是从外部收到的，二层头部取决于外部发送时是何网络状态，但是，生成回应报文无需关注所述二层头部，因此剔除掉二层头部(例如：虚拟网卡TUN是三层设备，只关注IP，不关注二层mac头部，所以回应报文不关注二层头部)；而在下面步骤303中的回应报文是程序发出去时，需要先查找Linux系统上的路由表，根据路由表查找的结果决定出网口，根据网口的配置(比如是否有vlan)来封装特定的二层头部。

在步骤303中，虚拟网卡通过对应缓存区获取到所述第二报文后，确认portal认证报文的目的端口与portal进程监听的预设端口相同，则将所述portal认证报文交给portal进程进行处理，portal进程按照portal协议生成回应报文。

在步骤304中，查询Linux系统上的第一路由表，并根据找到的相应路由表项，选择所述虚拟网卡发送portal进程的回应报文。其中，所述回应报文被存储在相应虚拟网卡的缓存区上。

其中，所述第一路由表中存储有所述虚拟网卡的环回口IP地址以及相应虚拟网卡的端口号的策略路由，该策略路由基于环回口IP作为源地址进行选路，虚拟网卡生成回应报文时查询该策略路由选取出虚拟网卡。所述第一路由表是Linux系统的TCP/IP协议栈上的，为了减小对Linux系统内核的资源的占用和损耗，在本发明实施例中，所述第一路由表中并不存储对外的路由信息，而仅仅用于存储虚拟网卡的环回口IP地址以及相应的虚拟网卡的端口号，以便用户空间应用程序调取相应回应报文的时候，知道该回应报文的实现意图，即需要通过环回口IP地址制定某一具体物理网卡完成报文的发送。

在步骤305中，用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文，查询用户空间应用程序中的第二路由表，根据查找到的第二路由表项选取回应报文的出口物理网卡，将所述回应报文封装以太网二层头部后通过所述出口物理网卡发出去。

其中，所述第二路由表存储有路由网络环境中，各路由器的IP地址以及相应各路由器的端口号(例如：源IP、目的IP、目的端口等等)，该路由基于源IP网段，目的IP网段,目的端口范围和协议类型(TCP/UDP)进行选路，用户空间应用程序查询该路由选取出物理网卡。在本发明实施例中，将总量可能达到数以千计的路由表项存储在位于用户空间层的所述第二路由表中。

本发明实施例通过设计一虚拟网卡，实现了基于Linux系统的路由器对外呈现的环回口功能，提高了路由器自身的稳定性，并且，通过创建虚拟网卡，实现了用户空间应用程序对数据报文的读取、解析和发送过程的介入，为本发明后续扩展实现方案中解决常规路由器所无法实现的复杂解析过程提供了设计接口。

本发明实施例同样可以沿用实施例1中各扩展的实现方式(尤其是实施例1中的深度包分析的相关内容)，在此不再赘述。

实施例3：

本发明实施例对于实施例1中创建网络缓冲区列表的过程，以引入Linux内核代码的方式进行详尽的阐述。如图7所示，具体包括：

在Linux内核中，建立一定数量的skb，然后用e1000_rx_ring环形缓冲区队列描述符连接起来构成网络缓冲区列表；其中，所述skb标示一个缓存；

Linux内核建立物理网卡与所述网络缓冲区列表之间的映射关系；其中，所述缓冲区控制权根据数据的写入和读取需求，分别在物理网卡和虚拟网卡之间进行切换。

其中，内核通过调用dma_map_single(struct device*dev,void *buffer,size_tsize,enum dma_data_direction direction)建立物理网卡与所述网络缓冲区列表之间的映射关系。在上述函数中，struct device*dev描述一个物理网卡设备；buffer表示映射给物理网卡设备的地址，也就是某一个skb，若要映射全部，在本发明实施例中做一个双向链表的循环即可；size表示缓存大小；direction表示映射方向，即由谁传给谁，一般来说，是“双向”映射，数据在设备和内存之间双向流动；对于物理网卡(上面也被描述为PCI设备)，通过另一个包裹函数pci_map_single，把buffer(即本发明实施例中所提出的网络缓冲区列表)交给物理网卡设备了，物理网卡设备可以直接从里边读/取数据。

另外一方面，内核通过调用函数dma_unmap_single来取消映射，对物理网卡设备而言，通常调用它的包裹函数pci_unmap_single，不取消的话，缓存控制权还在物理网卡设备手里；因此，要调用dma_unmap_single函数，把主动权转交给CPU(或者理解为本发明中所提出的用户空间应用程序)，因为我们已经接收到数据了，应该由CPU把数据交给用户空间应用程序。

因此，结合本发明实施例，在所述虚拟网卡具体为TUN网卡，则所述用户空间应用程序使用write()系统函数调用向虚拟网卡的字符设备文件写入portal认证报文如图7所示，具体包括：

用户空间应用程序使用write()系统函数调用向TUN网卡的字符设备文件写portal认证报文时，tun_chr_write()函数将被调用，它使用tun_get_user()从用户区接受数据，其中将数据存入虚拟网卡的缓存区中，然后虚拟网卡调用函数netif_rx()将虚拟网卡的缓存区送给TCP/IP协议栈处理，确认portal认证报文的目的端口与portal进程监听的预设端口相同时，转交给portal进程完成回应报文的生成。

其中，结合本发明实施例，所述虚拟网卡具体为TUN网卡，所述调用read()系统函数从对应的虚拟网卡上读取回应报文，具体包括：

TCP/IP协议栈把生成的回应报文传送给TUN网卡，TUN网卡调用注册好的hard_start_xmit函数发送，hard_start_xmit函数又会调用tun_net_xmit函数，然后唤醒用户空间应用程序中被阻塞的使用TUN字符设备读数据的进程，该进程通过read函数向字符设备读取回应报文，具体为TUN设备的字符设备部分调用其tun_chr_read()过程读取虚拟网卡的缓存区发往用户区；以便用户空间应用程序获取虚拟网卡的回应报文。

实施例4：

本发明实施例通过一种涉及Linux内核态和用户区间的架构层结构的方式，并配以相对更为具体的流程图阐述本发明实施例1的具体实现过程，需要强调的是，在开始执行本发明实施例所述方法流程时，已经完成了如实施例2中所述的虚拟网卡的建立，以及相应网络缓冲区列表的生成；配置portal进程监听环回口的TCP协议80端口，并启动portal进程。如图7和图8所示，具体包括：

在步骤401中，物理网卡收到portal认证报文后，通过与网络缓冲区列表的映射关系，将portal认证报文写入到网络缓冲区列表中。相应的网络缓冲区链表位于内核态，相应的逻辑位置关系如图7所示。

在步骤402中，当物理网卡完成数据写入后，触发中断，以便用户空间应用程序通过函数dma_unmap_single取消映射，从而获取所述网络缓冲区列表的读取和写入权限。

在步骤403中，用户空间应用程序到相应网络缓冲区列表中获取所述portal认证报文。

在步骤404中，用户空间应用程序确认所述portal认证报文的目的IP与虚拟网卡的环回口IP相同，则执行步骤405；否则执行步骤406。

在步骤405中，用户空间应用程序去掉所述portal认证报文的以太网二层头部后得到第二报文，通过tun_chr_write()函数将所述第二报文发送给虚拟网卡的缓冲区，并进入步骤407。

在步骤406中，若用户空间应用程序确认所述portal认证报文的目的IP与虚拟网卡的环回口IP不相同，则会查询应用程序中的路由(第二路由)，按匹配的第二路由进行转发。

在步骤407中，虚拟网卡获取到所述第二报文并存储到对应缓存区后，调用函数netif_rx()将虚拟网卡缓存区的第二报文送给TCP/IP协议栈处理，TCP/IP协议栈确认第二报文的目的端口与portal进程监听的端口一样，都是TCP协议179端口，便将此报文交给portal进程进行处理，portal进程按照portal协议生成回应报文，并将回应报文交给TCP/IP协议栈。

TCP/IP协议栈查询Linux系统上的第一路由表，并根据找到的第一路由表项选择一个虚拟网卡来发送portal进程的回应报文。

其中，所述回应报文由TCP/IP协议栈返回给虚拟网卡，并存储在相应虚拟网卡的缓存区上。

在步骤408中，虚拟网卡唤醒用户空间应用程序中被阻塞的使用TUN字符设备读数据的进程，该进程通过read函数向字符设备读取回应报文，具体为TUN设备的字符设备部分调用其tun_chr_read()过程读取虚拟网卡的缓存区得到回应报文，然后查询用户空间应用程序中的第二路由表，根据查找到的第二路由表项选取回应报文的出口物理网卡。

在步骤409中，将所述回应报文封装以太网二层头部后通过所述出口物理网卡发出去。

实施例5：

在本发明实施例所设定的架构中各物理网卡的端口IP在发生故障时，如何通过本发明提出的虚拟网卡、及其配套的架构完成环回口功能。如图9所示，具体包括：

Linux系统的应用程序拥有对应虚拟网卡的环回口loopback0的访问权限,相应的loopback0的IP地址为IP1,路由器R2指定通过IP地址IP2与IP地址IP1建立BGP邻居，根据动态路由协议协商，R2选取线路①，通过应用程序当前关联的物理网卡eth2与虚拟网卡的环回口loopback0的IP地址IP1进行通信。

此时，当eth2出现故障，各路由器(R1-R4)通过动态路由协议感知这一变化，重新生成各自的路由表项，此时，R2选取线路②，通过eth3与虚拟网卡的环回口loopback0进行通信，在这一变化中，因为R2是与虚拟网卡的环回口loopback0进行通信，即使eth2网卡出现故障，也只是路由表项发生变化，原有的通信并不会因此而中断，但是假使R2是与网卡eth2的IP进行通信，如果eth2故障，那么两者的通信就中断了。

实施例6:

如图10所示，是本发明实施例的基于Linux系统实现路由器的portal认证报文转发装置的架构示意图。本实施例的基于Linux系统实现路由器的portal认证报文转发装置包括一个或多个处理器21以及存储器22。其中，图10中以一个处理器21为例。

处理器21和存储器22可以通过总线或者其他方式连接，图10中以通过总线连接为例。

存储器22作为一种基于Linux系统实现路由器的portal认证报文转发方法和装置非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1中的基于Linux系统实现路由器的portal认证报文转发方法以及对应的程序指令。处理器21通过运行存储在存储器22中的非易失性软件程序、指令以及模块，从而执行基于Linux系统实现路由器的portal认证报文转发装置的各种功能应用以及数据处理，即实现实施例1-实施例6中涉及的基于Linux系统实现路由器的portal认证报文转发方法。

存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述程序指令/模块存储在所述存储器22中，当被所述一个或者多个处理器21执行时，执行上述实施例1中的基于Linux系统实现路由器的portal认证报文转发方法，例如，执行以上描述的图1-实施例6所示的各个步骤。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，在Linux系统上创建虚拟网卡，为虚拟网卡配置环回口IP地址，配置portal进程监听环回口的TCP协议预设端口，并启动portal进程，方法包括：

物理网卡收到portal认证报文，用户空间应用程序获取所述portal认证报文，并解析出所述portal认证报文的目的IP；

用户空间应用程序确认所述portal认证报文的目的IP与虚拟网卡的环回口IP相同，将所述portal认证报文写入到对应的虚拟网卡的缓存区中；

虚拟网卡通过对应缓存区获取到所述portal认证报文后，确认portal认证报文的目的端口与portal进程监听的预设端口相同，则将所述portal认证报文交给portal进程进行处理，portal进程按照portal协议生成回应报文；

查询Linux系统上的第一路由表，并根据找到的第一路由表项，选择所述虚拟网卡发送portal进程的回应报文；其中，所述回应报文被存储在相应虚拟网卡的缓存区上；

用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文，查询用户空间应用程序中的第二路由表，根据查找到的第二路由表项选取回应报文的出口物理网卡，通过所述出口物理网卡将所述回应报文发出去。

2.根据权利要求1所述的基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，所述第一路由表中存储有所述虚拟网卡的环回口IP地址以及相应虚拟网卡的端口号的策略路由，所述策略路由基于环回口IP作为源地址进行选路，虚拟网卡生成回应报文时查询该策略路由选取虚拟网卡；所述第二路由表存储有路由网络环境，由各路由器的IP地址以及相应各路由器的端口号构成，用于用户空间应用程序查询该路由选取出物理网卡，基于源IP网段，目的IP网段,目的端口范围和协议类型进行选路。

3.根据权利要求1所述的基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文后，查询用户空间应用程序中的第二路由表，根据查找到的第二路由表项选取回应报文的出口物理网卡，还包括：

应用程序对于所述回应报文进行深度包分析，获取所述回应报文的应用类型、网速配置、带宽要求中的一项或者多项分析结果；并根据所述分析结果和所述第二路由表项，选配适合上述应用类型、网速配置和/或带宽要求的物理网卡和相应端口，用于传输所述回应报文。

4.根据权利要求3所述的基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，所述方法还包括：

接收针对第二路由表的更新报文，其中，所述针对第二路由表的更新报文由服务器侧根据当前网络类型状态生成的用于深度报文解析后，识别出的对应不同应用类型、网速配置和/或带宽要求的路由策略；

用户空间应用程序更新本地存储的第二路由表中的相应路由策略。

5.根据权利要求3所述的基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，在出现本地设备中的第一物理网卡故障时，用户空间应用程序检测到网卡故障，通过动态路由协议通告给相邻路由器，并更新本地的第二路由表，将原本基于深度包分析分配给所述第一物理网卡发送的报文的路由表项更新为与所述第一物理网卡性能最相近的第二物理网卡。

6.根据权利要求1-5任一所述的基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，在所述用户空间应用程序对从物理网卡收到的portal认证报文中，获取portal认证报文的目的IP之前，所述方法还包括：

在Linux内核中，建立预设数量的缓存，然后用环形缓冲区队列描述符连接起来构成网络缓冲区列表；

Linux内核建立物理网卡与所述网络缓冲区列表之间的映射关系；其中，所述缓冲区控制权根据数据的写入和读取需求，分别在物理网卡和用户空间应用程序之间进行切换。

7.根据权利要求1-6任一所述的基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，所述将所述portal认证报文写入到对应的虚拟网卡的缓存区上，具体包括：

用户空间应用程序使用write()系统函数调用向虚拟网卡的字符设备文件写入portal认证报文时，tun_chr_write()函数将被调用，所述tun_chr_write()函数使用tun_get_user()从用户区接受数据，其中将数据存入虚拟网卡的缓存区中；以便虚拟网卡调用函数netif_rx()将虚拟网卡的缓存区发送给TCP/IP协议栈处理，确认portal认证报文的目的端口与portal进程监听的预设端口相同时，转交给portal进程完成回应报文的生成。

8.根据权利要求7所述的基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，所述用户空间应用程序从对应的虚拟网卡的缓存区上读取回应报文，具体包括：

所述TCP/IP协议栈把生成的回应报文存储在虚拟网卡的缓存区中；唤醒被阻塞的使用虚拟网卡的字符设备读数据的进程，虚拟网卡的字符设备读取虚拟网卡的缓存区，并将每一个读到的缓存发给用户空间应用程序。

9.根据权利要求1所述的基于Linux系统实现路由器的portal认证报文转发方法，其特征在于，所述方法还包括用户空间应用程序主动向外发起报文，具体包括：

用户空间应用程序调用socket函数接口，指定目标设备IP地址，并从虚拟网卡主动发出报文；其中，所述主动发出报文包括：主动与路由器建立BGP邻居的报文、更新网络拓扑中其它路由器中路由表的报文、向服务器发送本地物理网卡发生故障的消息报文和向服务器发送DPI分析报文中的一种或者多种。

10.一种基于Linux系统实现路由器的portal认证报文转发装置，其特征在于，所述装置包括：

至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被程序设置为执行权利要求1-9任一所述的基于Linux系统实现路由器的portal认证报文转发方法。