国家数字交换系统工程技术研究中心
摘 要：分布式体系结构已成为高性能路由器普遍采用的实现结构，然而迫切需要解决的问题是如何实现独立于上层软件及底层硬件的通用性支撑软件体系结构。硬件抽象层的设计方案成功解决了该问题，本文对其在高性能路由器实现中的关键技术进行了详细研究。
关键词：网络；路由器；硬件抽象层；实时；分布式结构
1 引 言
随着Internet的飞速发展和宽带技术的不断出现，骨干网络核心路由器的体系结构也发生了一些变化。近年来，高性能路由器体系结构的研究和国内外主流厂商生产的大部分商用高端路由器的实现方案中，普遍采用了集中式交换、分布式报文处理和转发的体系结构［1，2］。
文献［3］提出了硬件抽象层(Hardware AbstractionLayer，HAL)的设计思想，成功地解决了分布式路由器面临的通用性支撑软件系统结构设计问题，为构建开放通用的路由器软件基础平台提供了保证。硬件抽象层包括虚拟驱动、系统管理和内部通信3大模块，在整个路由器系统中的位置如图1所示。
结合国家863重大课题“高性能IPv6路由器基础平台及实验系统”，将文献［3］中提出的硬件抽象层在嵌入式实时操作系统Hard HatLinux中进行了实现。本文针对高性能路由器体系结构的特点，研究了硬件抽象层在实现过程中的关键技术。主要包括虚拟驱动的动态加载模式、基于分隔符的TCP实时传输方法、基于地址映射的内核态与用户态间的阻塞式数据交换机制几个内容。
2 支撑软件在高性能IPv6路由器中实现的关键技术
2．1 虚拟驱动的动态加载模式
虚拟驱动模块是模拟线路接口单元动作的重要部分，他的灵活性和可扩展性直接影响硬件抽象层的可用性。
在Linux操作系统下，该模块是作为一个内核模块来实现的。他可以实现实时动态加载，与静态加载相比具有很大的灵活性。编译时，内核模块可单独进行模块的编译调试，缩短了调试时间；使用时，将该模块链接到内核，便可发挥模拟线路接口单元的作用；扩展或升级时，可以将其卸载后进行修改。除此之外，动态加载还可以缩减Linux内核的大小，使编译后的内核小巧，占用内存较少，提高了运转速度。
2．2 基于地址映射的内核态与用户态间的阻塞式数据交换机
Linux操作系统中的进程分为用户态进程和内核态进程2类，用户态进程不能直接执行运行在内核态的内核代码或者存取操作系统内核的数据结构。在内存管理方面，Linux系统采用虚拟内存管理机制，设置了两级页表结构，通过页面地址和在该页中的偏移量就可以惟一确定虚拟地址所对应的物理地址。
在硬件抽象层的实现中，内部通信处于用户态，虚拟驱动处于内核态。而他们之间不可避免地需要进行一些数据的传递，即处于Linux不同空间的2个进程要进行通信。但是，这2个模块分处于Linux系统的用户空间和内核空间，数据指针如何传递是一个问题，指针传递后如何映射又是一个问题。因此用户态与内核态之间内存地址的传递和转换成为了提高硬件抽象层工作效率的关键。
2．2．1 内核态与用户态的指针传递
先来解决内存地址的传递问题，根据Linux驱动程序的特点，选择ioctl()函数来传递指针。该函数属于系统调用，调用后将一个类型为ifreq的结构指针变量ral＿ifr从用户态传入内核态，该结构的定义在/include/Linux/if．h中。
使用了其中的ifrn＿name和ifru＿data两个域，其中ifrn＿name代表设备的名称，即虚拟网络接口设备名，ifru＿data为所要传递的数据指针。使用系统调用ioctl()之后，用户空间到内核空间的指针传递就完成了。内核空间到用户空间的指针传递过程与其相反。因此，下一步要进行的是内核空间与用户空间数据指针的映射。
2．2．2 内核态与用户态的内存映射
由2．2．1可知，用户空间的指针通过ioctl传入内核空间后，他本身并没有发生改变，需要进行虚拟地址到物理地址的映射才可以对其进行读写操作。
由文献［4］分析可知，可以使用内核kiobuf机制，他能提供从内核空间对用户内存的直接访问。内核kiobuf机制的设计初衷就是为了便于将用户空间的缓冲区映射到内核。使用他能够获得数据的页面起始位置、页数和偏移量等具体参数，因此可在内核空间对用户态申请的内存进行操作。
首先分配一个内核I/O向量(kiovec)来产生kiobuf，使用函数如图2所示。
然后再对其进行初始化，如图3所示。
最后，将通过ioctl传入的用户空间指针ifru＿data映射 到内核态，使用函数map＿user＿kiobuf，如图4所示。
这样就完成了将指针由用户空间映射到内核空间的过程，实现了从虚拟地址向物理地址的转换。
至此，内核空间与用户空间的内存映射问题得到了很好的解决。通过解决内存地址映射的问题，内部通信和虚拟驱动之间就可以只传递数据指针，大大提高了模块的运行效率。
2．3 基于分隔符的TCP实时传输方法
2．3．1 Nagle算法的弊端
糊涂窗口综合症(Silly WindowSyndrome)的出现使网络开销过大，从而造成TCP性能变坏。根据文献［5］所述，糊涂窗口综合症的解决方法就是采用文献［6］中所建议的Nagle算法。但是在实际应用时发现，Nagle算法的不足之处主要有2点：
(1)在限制数据报头部信息消耗的带宽总量的同时，是以牺牲网络延迟为代价的。
(2)在发送方的缓冲区中，应用程序发送的数据包发生了粘滞的现象，即发送的若干数据包到接收方接收时变成一包，分不出各个包的界线。
前者因为数据被排队而不是立即发送的，因此不适用于需要快速响应时间的系统。后者则会影响到接收方的数据处理的准确性。第一种不足可以通过使用PUSH标记来实现，发送方如果使用了该标志，会立即将缓冲区中的数据发送出去。对于第二个问题，解决起来就比较复杂，因为出现数据包粘滞现象的原因既可能由发送方造成，也可能由接收方造成。
2．3．2 基于分隔符的TCP实时传输方法
采用了基于分隔符的TCP实时传输方法来解决包粘滞问题。该方法在应用层数据包的起始部分附加上有特定格式的分隔符和数据长度域，其中分隔符用于界定数据包之间的界限，长度域则用于表示该数据包的实际长度。
首先，所有经内部通信模块传输的数据，都需要进行一次内部固定格式的封装。封装后数据包的包头，是由内部通信模块自定义的，起始位置是分隔符和长度域。其次，接收方按照内部通信模块的自定义的包结构，接收后对数据流进行预处理，还原成为应用程序可正确识别的数据包。预处理的原理如下：先查找包头中的分隔符，他标识着一个数据包的开始；接下来的域表示的是实际数据包的长度len，取出紧跟在包头后的长度为len的那段数据，这就是需要应用程序处理的数据包。
包粘滞的情况具体可细分为3大类，这里均以2个应用程序数据包粘滞成一段的情况为例，如图5～图9所示，当应用程序数据包个数为n时，可采用类似的方法进行处理。
第1类，粘滞数据是由完整的数据包组成的，如图5所示。这种情况的处理非常简单，按分隔符找到数据包的起始位置，再根据数据长度取出应用程序数据即可。
第2类，粘滞数据是由完整数据包和应用程序数据残缺的数据包组成，如图6和图7所示。处理时，需要对残缺数据包2的应用程序数据部分进行保存，内部通信包头的数据长度域也要记录下来，以便下次接收时知道应用程序数据剩余部分的长度。再次收到数据时，就根据剩余长度取出一段数据，与上次保存的应用程序数据合为一个完整的数据包。
第3类，粘滞数据是由完整数据包和内部通信包头残缺的数据包组成，如图8和图9所示。首先，要将如图8所示数据段中收到的残缺的这部分包头保存起来，然后收取下一次数据如图9所示。再从收取的数据中，截取可以与上次残缺包头组成完整的内部通信包头的一段报文，形成所需要的内部通信包头。当然，该段数据有可能并不是内部通信包头，这可以从分隔符是否正确等内部通信封装格式来判断。如果发生这种情况，就要将指针以字节为单位，顺次向后滑动，直到找到真正的内部通信包头为止。然后根据包头中的信息，取出相应长度的应用程序数据交送给应用程序接收者。
解决了上述分析的2大不足之后，内部通信模块中实现的TCP传输，在保证数据传输的良好的可靠性和流控性之外，还具备了一定的实时性能和防止数据包粘滞的功能。
3 结 语
本文研究了硬件抽象层在高性能IPv6路由器实现中的关键技术，主要分析了虚拟驱动的动态加载模式、基于分隔符的TCP实时传输方法、基于地址映射的内核态与用户态间的阻塞式数据交换机制。通过上述关键技术的研究，使硬件抽象层得以实时、高效地运行，并且已稳定运行于高性能IPv6路由器中。
摘自 现代电子技术
文章整理：站长天空 网址：http://www.z6688.com/
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
