技术领域
[0001] 本
发明涉及协议栈技术领域，本发明公开了一种基于三层交换机设备的用户态协议栈实现方法及系统。
背景技术
[0002] Linux作为开源的
操作系统，因其良好的
稳定性、灵活性和可扩展性，广泛用于多种设备。在linux协议栈内做相关的协议开发，一般分两个部分：数据转
发面和协议控制面。数据转发面用于处理数据包的选路、转发等，采用linux
内核协议栈来实现，工作在内核态。
协议控制面用于控制报文转发或者实现数据服务，比如mstp，telnet，ssh等协议，通常在用户态实现。二者直接通过socket来通信，开发模式如
附图1所示。
[0003] 协议控制的开发基于用户态，相较于需要在内核态下开发的数据转发面，其开发难度相对较低。一般而言，二层交换设备对
软件的需求为：较多的控制协议和少量的数据转发，数据转发通常是
硬件完成，对数据转发面的需求不高。三层设备的形态从接入层向汇聚及以上层转变，数据面的功能变得强大，因此对协议栈的数据面需求也随之增高。因此在三层交换设备上，必须对协议栈数据转发面进行较大的改造、优化、开发。
[0004] 按照现有的协议栈开发模式如附图2所示，在linux内核态下做开发，其难度至少包括以下几个方面： 1）内核复杂的工作机制，由于协议栈工作在内核态，会使用内核提供的各种机制：如中断，软中断，内核调度，内存管理等。在内核下做开发，需要熟悉这些机制。而这些机制的熟悉和掌握，非朝夕之功，难度相对较大。2）编程的限制，在内核态下开发有一些编程限制，内核栈，线性的内核地址空间，各种
锁等。3）调试困难，在内核模式下开发，常规的用户态调试器将无法工作，程序发生异常时，可用的调试手段很少；更为极端的情况下，控制台都无法工作。显然，在内核态下实现大规模的协议栈开发是不太可能的。
发明内容
[0005] 针对
现有技术中在三层交换机设备的内核态下实现协议栈开发存在的上述问题，本发明公开了一种基于三层交换机设备的用户态协议栈实现方法及系统。
[0006] 本发明的技术方案如下：
[0007] 本发明公开了一种基于三层交换机设备的用户态协议栈实现方法，其具体包括以下的步骤：步骤一、在用户态构建用户态协议栈，把L2层和L3层移植到用户态协议栈，L4层以及内核驱动则保留在内核态；L2层主要是对网络设备
接口进行管理以及和网络设备驱动的交互；L3层是协议栈的核心，主要实现各种网络协议；步骤二、通过内存映射实现L2层和保留在内核态的内核驱动的通信建立；L3层与L4层之间的通信采用内核提供的套接口I/O来实现。
[0008] 更进一步地，上述方法还包括在L3层与L4层之间通信时，区分数据通道和控制通道，数据通道采用地址映射来实现，控制通道采用套接口I/O来实现。
[0009] 更进一步地，上述步骤二具体为：在内核中开辟一
块新的内存用于报文所需的内存，并将这块内存映射到用户空间中。
[0010] 更进一步地，上述用户态协议栈用于实现：1、邻居系统的实现；2、ROUTE路由功能；3、ICMP协议；4、IPV4协议。
[0011] 本发明还公开了一种基于三层交换机设备的用户态协议栈实现系统，其具体包括用户态协议栈构建单元和通信单元；所述用户态协议栈构建单元用于把L2层和L3层移植到用户态协议栈；L2层主要是对网络设备接口进行管理以及和网络设备驱动的交互；L3层是协议栈的核心，主要实现各种网络协议；所述通信单元用于通过内存映射实现L2层和保留在内核态的内核驱动的通信建立，以及采用内核提供的套接口I/O来实现L3层与L4层之间的通信。
[0012] 本发明还公开了上述用户态协议栈接收报文的方法，其具体包括以下的步骤：对端主机发送ICMP（Internet Control Message Protocol）
请求报文；用户态协议栈接收ICMP请求报文，ICMP请求报文封装在IP报文中； IPV4把报文投递给ICMP模块；ICMP模块收到ICMP请求报文后，发送ICMP响应报文；经输出选路后，通过邻居系统将响应报文发送至驱动；驱动将报文发送给对端主机。
[0013] 本发明还公开了上述用户态协议栈发送报文的方法，其具体包括以下的步骤：应用程序在发送IP报文时，用户态要进行系统调用进入内核态，在传输层中对报文进行组织，通过选路后发送到用户态的IPV4，再发送给对端主机。
[0014] 本发明还公开了上述用户态协议栈转发报文的方法，其具体包括以下的步骤：主机A发送IP报文给用户态协议栈，用户态协议栈接收IP报文至IPV4，根据选路的结果发现是转发的报文，则在IPV4中直接将报文投递到对应的端口上，向主机B转发出来自主机A的报文，主机B的响应报文则通过交换芯片直接发送到主机A端。
[0015] 通过采用以上的技术方案，本发明的有益效果包括：协议栈的部分实现，从内核中剥离出来，放在用户态中实现，后续的大规模开发都只在用户态下进行，从而降低开发难度，提高数据转发面的性能。剥离出来的协议栈简称用户态协议栈（user netstack），一部分存在于内核态，其他的部分则移出到用户态。本发明依然保留socket的健壮性、稳定性；移出到用户态的协议栈以独立
进程的方式存在，与其他模块基本没有耦合。需要
修改的部分仅有：1、解耦，主要是进程与进程之间的接口（报文收发、路由查询等）；2、进程与进程之间的通信，可以使用进程与内核通信以及标准的套接口I/O。
附图说明
[0016] 图1为现有技术中的linux协议栈开发模式1。
[0017] 图2为现有技术中的linux协议栈开发模式2。
[0018] 图3为linux 协议栈层次结构。
[0019] 图4为用户态协议栈方案。
[0020] 图5为用户态协议栈中的数据流。
[0021] 图6为用户态协议栈接收报文。
[0022] 图7为用户态协议栈发送报文。
具体实施方式
[0023] 为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及
实施例，对本发明进行进一步详细的说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0024] 以下是结合附图3、附图4和附图5对本发明进一步说明。如附图3所示，linux协议栈主要包括7个层次，一般在实际的开发过程中为叙述和使用方便，将其归纳为三个层次即L2层，L3层和L4层。L2层主要是对网络设备接口进行管理以及和网络设备驱动的交互；L3层是协议栈的核心，主要实现各种网络协议，最主要的就是IP/ICMP/ARP等协议；L4层包括了传输层和系统调用层，传输层主要用的协议是TCP/UDP/RAW等，而与应用层关系紧密的SOCKET系统调用层往往与传输层中的各种协议关系紧密，因此将二者归为L4层。
[0025] 附图4是用户态协议栈的结构，对比附图3内核协议栈的结构，用户态协议栈把L2和L3层移植到用户态，L4层保留在内核态。原内核协议栈驱动和L4均在内核空间中，但将L2/L3层移植到用户空间后，由于内核空间和用户空间的区分，就存在L2层和内核驱动的通信建立，以及L3层与L4层之间的通道问题。
[0026] 针对以上两个通信问题，用户态协议栈L2层即链路层，采用的办法通过内存映射实现读取和发送报文。具体方法是在内核中开辟一块新的内存用于报文所需的SKB等内存的分配，并将这块内存映射到用户空间中，使得用户空间可以
访问该块内存，这样L2层就可以读取内核驱动的报文，并发送相应的报文。L2层更改到用户态后其作用包括了接收驱动报文并根据报文类型上传至L3层或者在L2层本层协议中处理（如桥转发，QOS等），还包括对所有的接口进行管理，如驱动对应的物理接口以及L3层所需要的虚拟接口，对这些接口状态和统计的管理，决定了是否将报文投递到对应的接口上。
[0027] 另外一个问题是L3层和L4层之间的通信，因L3层现处于用户态，L4层处于内核态，那么L3层与L4层之间的通信就可以采用内核提供的套接口I/O来实现，但L3层与L4层之间的通信还存在一个问题就是，通道要区分数据通道和控制通道。控制通道主要是用于同步一些L3层的配置信息到内核L4层中，比如路由的刷新和一些系统的参数，另一个数据通道主要是指L3层的报文进入L4层和L4层的报文下发到L3层。数据通道相较与控制通道要求的内存要大的多，可以采用类似L2层和内核驱动的通信方式做地址映射，而控制通道需要的实时性高，可以采用套接口I/O来实现。
[0028] 用户态协议栈最基本的功能是提供以下四个：1、邻居系统的实现，用于ARP协议的实现；2、ROUTE路由功能的实现，包括路由缓存和路由表的查找、添加和删除；3、ICMP协议的实现，用于对IP报文出错的处理反馈；4、IPV4协议的实现，报文IP报文的接收，转发和向本地L4层的投递。总体上这四个模块的功能和处理报文的流程与内核相似，不同处在与报文从用户态L2层接收进来，需要建立对应的三层虚拟接口，投递到内核L4层时要区分是控制信息还是数据信息采用不同的通道。
[0029] 此外这四个模块按照内核的架构，模块之间的耦合程度很高，具体的模块联系可参考内核网络层的内容（这部分内容不属于本发明的重点改进，不在本发明讨论范围内）。此外整体的L3层数据流的改变也会影响一些L3内部模块的系统参数配置，因此在实际调试时需要对原内核协议栈的模块要有一定程度的熟悉，才能使用户态的协议栈发挥作用。当然在用户态协议栈开发过程中可以根据实际的需要，添加或摒弃一些原来内核的一些处理逻辑。
[0030] IP是用户态协议栈中最核心的协议，所有TCP/UPD/ICMP的数据都是以IP数据报的形式传输的。IPV4是一种不可靠的协议，不能保证每个数据报都能成功的到达目的地（无论是到本地的数据报还是转发的数据报）如果发生错误就丢弃，然后发送ICMP消息给发送方。可靠性由传输层的协议负责，如TCP。IPV4的每个数据包的处理是相互独立的，可以不按照发送顺序接收。
[0031] IPV4处于传输层和链路层之间，同时还关联到路由表和邻居系统。在接收数据时，提供输入接口给链路层调用，并调用传输层的输入接口将数据传递到传输层。在发送数据时，根据不同的传输层协议提供不同的输出接口给传输层，并调用链路层的输出接口将数据发送到链路层。
[0032] 以实际应用中的ping应用程序为例说明接收，发送和转发数据流在用户态协议栈中的过程。
[0033] 一、协议栈接收报文
[0034] 附图6是用户态协议栈接收来自对端主机的ping 命令的ICMP报文的简易过程，当协议栈收到来自对端主机的IP报文时如果解析是ICMP报文，则转给ICMP模块处理。ICMP处理完成会发送响应报文给对端主机，整个过程是在用户态协议栈实现，不经过内核，虽然会投递一份SKB给内核，但由于内核中无ICMP模块，最终会被释放。过程如下：
[0035] 对端主机发送ICMP请求报文；
[0036] 协议栈接收ICMP请求报文，ICMP请求报文封装在IP报文中；
[0037] IPV4把报文投递给ICMP模块；
[0038] ICMP模块收到ICMP请求报文后，发送ICMP响应报文；
[0039] 经输出选路后，通过邻居系统将响应报文发送至驱动；
[0040] 驱动将报文发送给对端主机。
[0041] 二、协议栈发送报文
[0042] 附图7是用户态ping程序经过用户态协议栈下发报文的简易过程图，应用程序在发送IP报文时，用户态要进行系统调用进入内核态，在传输层中对报文进行组织，通过选路后发送到用户态的IPV4，再发送给对端主机。对于此时对端回应的报文处理区别于附图6，不仅要在ICMP中进行判断是否出错，还要投递到传输层中，使应用程序可以接收到响应报文。同样在对端的协议栈中也止步于L3层的ICMP模块，不会传递到传输层，这是ping程序的特点。过程如下：
[0043] ping程序通过系统调用sendmsg()发送ICMP请求报文；
[0044] 传输层raw_sendmsg()继续发送ICMP消息，ip_append_data()用于将报文预分片，ip_output()通过用户态与内核的通道将报文发送至用户态协议栈IPV4中；
[0045] IPV4经输出选路通过邻居系统将报文发送至驱动；
[0046] 驱动将报文发送到对端主机的L3层，ICMP模块接收到来自协议栈的ICMP请求报文；
[0047] 对端主机L3层发送ICMP响应报文给协议栈；
[0048] 协议栈接收到IP报文，经过入口选路发现是本地的报文，将报文上传至内核的传输层，并发送至ICMP模块。如果是出错的报文则通过过程将ICMP报文发送到对端主机；
[0049] 进入内核的ICMP报文，通过协议号找到对应的RAW协议；
[0050] 经过系统调用recvmsg()，用户态的ping程序收到对端的ICMP响应报文并作相应的统计计数。
[0051] 三、协议栈转发报文
[0052] 报文的转发过程从主机A发送的目的地址为主机B的报文会经过协议栈进行转发。同前述的输入报文的处理一样，根据选路的结果发现是转发的报文，则在IPV4中直接将报文投递到对应的端口上，向主机B转发出来自主机A的报文，主机B的响应报文则通过交换芯片直接发送到主机A端，不再进入用户态协议栈，这是交换设备的一个特性。过程如下：
[0053] 主机A发送IP报文给协议栈；
[0054] 协议栈接收IP报文至IPV4；
[0055] IPV4模块经过选路，决定报文转发，通过邻居将报文发送至驱动；
[0056] 驱动将报文发送至目的主机B；
[0057] 目的主机B接收到ICMP请求报文后，发送ICMP响应报文至协议栈；
[0058] 交换芯片直接将报文转发至源主机A，一次路由，多次转发。
[0059] 上述的实施例中所给出的系数和参数，是提供给本领域的技术人员来实现或使用发明的，发明并不限定仅取前述公开的数值，在不脱离发明的思想的情况下，本领域的技术人员可以对上述实施例作出种种修改或调整，因而发明的保护范围并不被上述实施例所限，而应该是符合
权利要求书提到的创新性特征的最大范围。
