（计算机软件与理论专业论文）一种基于实时环境的零拷贝通信技术的研究.pdf

i 摘摘 要要 为了提高网络通信性能，需要减小通信中的开销。零拷贝技术能够减小通信过 程中数据拷贝带来的开销，是高性能通信的重要研究领域。国内外在这个领域做了 大量的研究和技术开发。现有的零拷贝通信协议不能满足实时通信的要求。因此， 研究和开发基于实时环境的零拷贝协议具有理论意义和实用价值。 实时环境下的零拷贝 rtzcp 是基于集群环境的实时通信技术，适用于 linux 环 境，支持 rtai 进行硬实时任务调度。 rtzcp 通过如下方式实现网络通信的零拷贝，其工作方式是：在发送端采用直 接映射方式发送数据；在接收端采用直接映射方式接收单片包数据；采用单拷贝的 方式接收分片包数据。rtzcp 提供了网络通信编程和通信实时调度的接口。rtzcp 主要采用了如下技术：新的基于 rtskb 网络缓冲结构的网络缓冲管理机制、新定义的 rtsokcet 接口、发送分片数据包的重映射方式、在 rtmac 层增加的对于非实时通信 进行流量控制的平滑传输层、新的接收端分片包收集方式。 测试结果说明 rtzcp 保证了通信的实时性，很大的提高单片数据包的发送效率， 对于分片包的通信效率也有一定的提高。测试还说明，rtzcp 在非实时通信和实时 通信同时存在时，能够保证实时通信的性能稳定。 关键字关键字：零拷贝，硬实时通信，软实时通信，远端内存访问，平滑层处理技术 ii abstract to improve the efficiency of network commucations, the cost of communications must be reduced. the zero-copy technology can reduce the cost of data copying in communicate process. it is an important researching area of high performance communications. there is a lot of research and technology development about the area in the world. the presented zero-copy communications protocols can not satisfy the need of real time communications. so, it has academic meaning and applied value to research and develope zero-copy communications protocol in real time environment. the zero-copy communications in real time environment-rtzcp is a lightweight protocol technology for cluster system. it is fit for the linux environment; sustain the hard real time control scheduling provided by rtai. rtzcp turns the zero-copy communications into reality by this way: using direct mapping way to send data in the sending end; using direct mapping way to receive the non- fragmentated data or single-copy way to receive the fragmentated data in the receiving end. rtzcp provides the interface for network communications and communications real time scheduling. rtzcp has these technologies: a new network cache manage system base on the rtskb data structure, new rtsocket interface, repeated mapping way used to send the fragmentated data, the traffic smoother layer added on the rtmac layer to control the flux, new fragmentated data collecting way in the receiving end. the test result has shown that rtzcp can protect the real time quality of communications, has greatly improved the efficiency of transferring the non-fragmentated data packet, has some improved the efficiency of transferring the fragmentated data. the test result also shows that rtzcp can assure the steady real time communications efficiency when there is non-real time communications. key words: zero-copy, hard real time communications, soft real time communications, rma (remote memory access), traffic smoothing technique 独创性声明独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其他个人或 集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集体，均已在 文中以明确方式标明。本人完全意识到本声明的法律结果由本人承担。 学位论文作者签名： 日期： 年 月 日 学位论文版权使用授权书学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即：学校有权 保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。 本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据库进行检 索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。 保密 ，在_年解密后适用本授权书。 本论文属于 不保密。 (请在以上方框内打“”) 学位论文作者签名： 指导教师签名： 日期： 年 月 日 日期： 年 月 日 1 1 绪论绪论 本章首先简述零拷贝技术的研究现状和存在的问题，接着从轻量级通信协议， 实时通信协议，零拷贝通信协议三个方面介绍本文研究内容的国内外现状，然后介 绍项目对系统的要求，最后说明本文的整体结构。 1.1 问题提出 现在很多与网络有关的应用，比如多媒体协作、视频点播、实时数字信号传输 处理和一些科学应用，需要进行大量的基于高速网络的消息传递。现在以太网能够 提供千兆以及千兆以上的网络传输速度，其它硬件设备如 cpu 处理器、内存总线带 宽都已经达到了千兆以上的处理速度，目前的常用的 pci 总线（或者 i/o 总线）都 可以达到千兆以上的处理速度（如 32 位 33mhz 的 pci 总线可以提供 133mb 的处理 带宽） 。传统的网络通信协议，如 tcp/ip 协议，逐渐成为了网络通信的主要瓶颈之 一。它的软件开销包括消息发送接收过程中的系统调用、中断处理、上下文交换、 用户空间与内核空间、内核空间与网络设备之间以及不同网络协议层之间的数据复 制等，极大的影响了通信性能。 提高通信性能的方法之一是减小数据在用户空间与内核空间、内核空间与网络 设备以及不同网络协议层之间复制所消耗的时间。很多研究希望能够减少或者甚至 消除通信过程中的数据拷贝，实现在应用层与网卡设备之间传递过程中没有拷贝或 则拷贝过程不需要 cpu 参与的“零拷贝”通信。这就需要消除用户空间与内核空间 的数据拷贝操作，对于没有 dma（直接内存存取，direct memory access）功能的 网络适配器，还要考虑消除内核空间与网卡设备之间的传输拷贝。事实上完全的“零 拷贝”是不可能的，即使是拷贝次数最少的 rdma1方式也没有消除应用空间与网 卡缓冲之间的数据拷贝，只是拷贝由网卡上的 dma 完成，不需要主机 cpu 参与， 但是 cpu 还是要参与一些相关的初始化，内存管理等工作。因此，在具备 dma 功 能的网卡中，零拷贝通信的实现主要是如何消除用户空间与内核空间的数据拷贝。 在没有 dma 功能的网卡上实现零拷贝通信更加困难，因为内核空间与网卡之间的 数据拷贝只能通过 cpu 才能实现。 如通过可编程 i/o 的方式 （pio， programmable i/o） 实现的零拷贝通信虽然消除了用户空间与内核空间的数据拷贝，但内核空间与网络 2 设备缓冲之间的数据拷贝还是需要 cpu 的参与。 综上所述，零拷贝技术的基本思想是通过减少数据传输过程中的内存拷贝次数， 在应用程序和外设接口间提供更快的数据通路，从而提高数据吞吐率，降低通信和 减轻 cpu 负载2。 目前，国内外在这个领域做了大量的研究和技术开发，但是现有的零拷贝通信 协议都是针对某个具体应用而设计开发的，通用性较差，并且都不适合运用于实时 环境。 1.2 国内外研究现状国内外研究现状 1.2.1 轻量级通信协议 轻量级通信协议是集群环境下通信的重要技术之一。轻量级通信协议的实现方 式主要分为以下两种：优化传统的网络协议；设计一种新的网络协议来替代传统的 网络协议。 优化传统的网络协议的主要方式有：采用零拷贝通信技术，例如 gamma 3， speculative defragmentation 4，emp 5，solaris 6，afterburner 7 等；提高网卡中断 处理的效率或减小中断处理的开销，如设计低消耗的中断处理机制，或者在某些环 境中使用其他的方案如轮询技术（polling）等代替中断处理机制；简化通信流程以 及优化通信过程中的操作，如减少数据传输过程中的校验和计算、使用更合理的通 信层次结构以避免过多的消息缓存、简化或者设计更高效率的流量控制与容错机制 算法、优化路由算法等等。 设计全新的通信协议来替代或者兼容传统通信协议是近年来研究领域的重点之 一。这种方案又分化为以下两个方向： (1) 设计需要操作系统支持的通信协议，也就是说这种通信协议与传统的通信协 议一样，需要 cpu 和操作系统的参与才能进行通信。其代表是 clic8，emp5， gamma3等。这些协议通常自行开发一整套自定义的应用编程接口（api） ，通信流 程同普通的通信协议一样，只不过层次结构更加简单，数据处理过程更加简化。一 般情况下，这些协议能够充分地利用网络硬件提供的物理带宽，但明显的缺点是应 用编程变得困难，由于没有标准，各个系统自成体系，同时也很难使用基于传统通 信协议如基于 socket 的通信资源。 (2) 设计基于专门网络硬件的用户级通信协议。用户级通信的主要目的是让用户 3 可以直接与网络设备之间实现数据传递而不需要操作系统的参与，目前比较具有代 表性的产品是 via9，u-net10，am11，fm 12，vmmc13，pm14，bip15等等。国 内也有一些基于用户级通信协议的研究，如清华大学基于 via 的 myvia16协议以 及半用户级通信方式17（semi-user level communication）等等。这些协议的缺点是它 们一般需要依靠具有特殊功能的网卡设备，如 myrinet 公司生产的网络适配器设备， 要求网卡带有处理能力很强的处理器和较大的网卡内存空间并且能够支持对网卡设 备的固件部分（firmware）进行编程控制。而普通的商业用途千兆以太网卡设备基 本上没有设备自用的处理器，而且其可用的网卡内存空间十分有限，而多数千兆网 络适配器设备的固件部分不具有可重新根据用户需求编程的能力。因此，尽管用户 级通信协议项目能够提供优秀的通信性能，但对硬件的要求太高，其过高的价格限 制了应用级通信协议的发展。 另外，由于千兆以太网络（gigabit ethernet）18具有良好的向下兼容性能，而相 关设备价格适中，目前基于千兆或者千兆以上的网络互连集群系统互连网络越来越 多。考虑千兆以太网络优秀的性价比，千兆以太网络上的轻量级通信有着广泛的应 用前景。 1.2.2 零拷贝技术 现有的零拷贝通信协议分为以下几种：内核级零拷贝通信协议，用户级零拷贝 通信协议，其它零拷贝通信协议。 内核级零拷贝通信协议由对操作系统的网络部分进行修改而得来，这是零拷贝 技术的最初实现形式之一。在发送端，该协议将收集数据信息、对数据进行校检、 形成数据报头部等操作在内核区完成，取消用户区到内核区的数据拷贝，将在数据 上添加数据报头部的工作推迟到内核区到网卡的硬件缓冲的拷贝完成后才进行。只 有在网卡的发送缓冲上数据包才被完整的拼接起来。在接收端，协议在数据包还在 网卡的接收缓冲上时就对数据包执行取数据头部，校检等操作，相当于将内核区的 除了拷贝以外的其它操作统统移到网卡的硬件缓冲上完成，然后找到对应的用户程 序，在数据处理完后将数据直接从网卡的硬件缓冲拷贝到对应的用户缓冲区。 用户级零拷贝通信协议是在一般网络通信体系的结构上进行了较大的改动得 来，其改动影响到了用户编程。用户在进行网络相关的编程时一定要使用该通信协 议提供的网络接口。用户级零拷贝通信协议主要有 via9，u-net10，am11，fm12 等。这类协议主要采用 rdma 方式1 实现零拷贝通信。rdma 协议对内存总线带 4 宽和 cpu 处理能力的要求比较低，而且不需要进行数据拷贝，能极大的缩短网络延 迟。rdma 方式允许网卡在应用程序的控制下直接在应用程序缓冲区中读写数据， 操作完成后再通知 cpu，相当于网卡从发送端缓冲区中取出数据，直接传送到接收 端的缓冲区中。rdma 读写操作要求源端的读方或写方知道目的缓冲区的位置和大 小。如果从一个主机的内存通过 rdma 方式向另一主机内存写一块数据，则必须提 供目的缓冲区的虚拟地址，并确保这个缓冲区足够大，可以接收所有数据。同样， 当从一个远端主机读取数据时，必须知道要读取的数据的存放地址，并要求本地主 机上具有一个相应大小的本地缓冲区。实现时，它允许发送方和接收方在接收端对 目的缓冲区的位置进行协商：发送方在一个 tcp 头部选项中包含缓冲区地址，网卡 可以将目的地址提取出来，通过直接内存访问将它存放到合适的位置。因此，要对 tcp 头部数据结构进行一些改动以支持 rdma 协议，主要是增加一个表示目的地址 的字段。 另外还有其它一些零拷贝通信协议，如基于主机的路由器的零拷贝通信协议2。 在传统的基于主机的数据包转发处理过程中，报文必须拷贝两次：一次进入主机存 储器，一次从主机存储器中拷贝出来。采用零拷贝技术，将报文从其到达的 nic 直 接传送到其发出的 nic 上，使 i/o 端口上的报文拷贝次数降为零次，可以有效地降 低数据通过路由器的传输延迟。这种技术通过网络接口之间的对等 dma 转发实现： 报文的大部分内容留在接收报文的 nic 中，等待其目的地址的确定，然后通过 dma 直接将报文从源 nic 传送到目的 nic。对等 dma 转发的实现技术有两种：定位转 发和报文头部拷贝转发。采用定位转发技术时，整个报文留在 nic 中，主机通过 pci 总线直接读取报文头部的相关字段进行处理，然后通过对等 dma 转发方式将报文传 送到发送端 nic。该协议对驱动程序只作很小的修改例程中的报文缓冲区指针 指向 nic 存储器而非内核 ram。采用报文头部拷贝转发时，主机将报文头部拷贝到 主机内存中，使用本地 ram 对其进行操作后，拷贝新的报文头部覆盖原来的报文头 部，然后将整个报文通过对等 dma 转发传送到目的 nic，减少了主机上总线访问的 开销。 在上述零拷贝通信协议中，主要采用了以下技术实现零拷贝通信： (1) 用户/内核地址重映射（page remapping）以及写时拷贝（copy-on-write）技 术。该技术的主要思想是：通过重新编辑系统的 mmu 表让内核缓冲区与用户缓冲 区都指向相同的连续的物理地址空间。地址重映射技术要求被映射的物理地址空间 5 必须是页面大小的整数倍，这样用户和内核都可以对被映射的物理地址空间进行操 作，还需要对被映射的页面需要进行加锁保护，以防止被该物理页面被置换出去。 用户缓冲区在发送完成之前不允许重新对用户数据缓冲区进行改写操作，一旦检测 到了改写的发生，就将执行用户缓冲到内核缓冲的拷贝操作。文献19是这种方案的 典型代表之一。 (2) 用户/内核共享内存。该技术通过共享内存语义方式实现。它让内核缓冲区 和用户缓冲区都可以共享相同的物理地址空间，通过网卡设备的 dma 操作，可以直 接将用户缓冲区的数据通过 dma 方式传到网卡设备缓冲区去，从而实现零拷贝通 信。这种方式要求定义一整套具有共享语义的应用编程接口 api 来实现用户缓冲区 与内核缓冲区的共享的目的。fbufs 20是使用共享内存来实现零拷贝通信的方案之 一，fbufs 中每个进程都拥有一个缓冲池，这些缓冲池预先映射好了一些用户和内核 的地址空间，通过这些共享的地址空间达到消除用户空间到内核空间的数据拷贝的 目的。fbufs 方式的问题在于因为所有的程序都需要使用自定义的 api 和编程模式， 所以兼容性很差。文献 io-lite21是采用共享内存方式实现零拷贝通信的另一种方案。 io-lite 项目尽量统一管理系统所有的内存缓冲与高速缓冲，它允许应用程序、进程 间通信、文件系统、文件高速缓存以及网络子系统安全而并行地使用单一物理数据 拷贝，同时结合存取控制以及设置只读限制来保证数据的安全。 (3) 内核/网卡共享内存。这种方案要求操作系统来管理网卡接口的内存，可以 使用 dma 或者 pio 方式实现用户缓冲区与网络内存之间的数据移动。该方案要求 操作系统更改网络缓冲区管理机制以支持网络接口的内存管理。这样，应用程序就 不能直接使用网络接口内存，而 tcp 的重传等操作的相关缓冲区都设置在网络接口 内存中。afterburner7是使用这种方式的方案之一。 (4) 大数据块传输方式（blasting transmission） 。blast 协议通过延迟或者聚集通 知消息（acknowledge messages） ，传输大块数据来提高系统的吞吐量。网卡驱动器 的缓冲链被修改以使得网卡设备能够直接分离抵达数据包的头部与有效数据部分。 在接收数据时，数据部分被直接写到了用户空间22，或者采用重映射方式从内核空 间传输到用户空间23。这种方案要求 nic 设备能够分离抵达的数据帧的有效数据与 头部，并在分析数据帧的头部信息后将数据帧的数据部分放置到相应的位置。 (5) 用户直接访问网络接口内存。这种方案主要应用于用户级通信协议中。该方 案允许用户直接对网络接口内存进行操作，通过预先将网络接口内存映射到用户缓 6 冲区和将网络协议栈直接放置到网络接口对应的内存空间中去， 达到不需要主机 cpu 的参与达到就能传输数据的目的。但是这种方案需要复杂特殊的网络硬件支持。同 时，这种方案要求用户程序使用专门的内存管理调用机制来使用与操纵网络接口内 存，这样就也带来了软件的复杂性与难于移植性的问题。 上面提及的零拷贝通信的主要目的之一是消除数据拷贝带来的通信开销，但最 主要的目的不仅仅是消除通信开销，毕竟现在的内存总线与 i/o 总线都可以提供千兆 以上的带宽，但因为数据拷贝需要占有系统资源（如内存，总线，io，cpu 等） ，同 时存在用户与内核空间的交互，所以过多的数据拷贝操作会影响系统的整体性能。 因此，严格意义上来说，零拷贝的另外一个主要目的是减少系统开销，如内存、cpu 等关键资源的开销，来达到提高系统的整体性能的目的。 1.2.3 实时通信协议 近年来，实时通信，特别是基于以太网（ethernet，802.3）的实时通信技术很多。 实时通信分为软实时通信 （soft real time communications） 和硬实时通信 （hard real time communications） 。软实时通信一般用于多媒体应用以及其他实时性能要求不高的场 合，它的特征是允许消息通信超时，而且部分消息的通信超时对于系统整体的实时 性能影响不大；硬实时通信不允许任何通信超过对应的时限（deadline） ，否则就会 造成系统的整体失效，如航天控制系统等应用与通信行业，就要求任何的通信都必 须具有确定的端到端时延，消息抵达的时限必须在确定的最大时延之内。基于以太 网的实时通信方案大致分为以下三类：基于总线结构、基于交换式以太网和其他形 式的实时通信方案。 基于总线结构的实时通信方案主要分为基于令牌的媒体访问控制方法，基于时 间片的实时通信方案以及基于统计的实时通信方案。基于令牌的媒体访问控制协议 的主要代表是 rether24项目，该项目使用一个循环的令牌来作为允许在共享式信 道中通信的通行证，哪个节点拥有令牌，该节点就拥有了发送数据包的权限。基于 令牌的实时通信方案的优点是其实现的灵活性，因为它可以用于几乎所有的网络体 系结构，缺点是系统的整体性能在受令牌的传递与管理开销的影响很大。基于时间 片的实时通信的典型代表是 mars25系统， 它使用了时分多路复用技术 （tdma， time division multiple access）26来提供基于共享式以太网络的实时通信保证，具体的做 法是每个节点拥有预先分配的一定数量的时间片，这些时间片采用全局时间为标准， 只有在属于自己的时间片内节点才能进行数据包的发送，但节点可以在任何时候接 7 收抵达该节点的数据包。使用时间片的实时通信方案要求系统必须有一个全局的系 统时间，并且每个节点都必须与这个全局时间同步，因此要求必须要有相应的基于 全局时间的相对高精度时钟同步方案的支持。基于统计的实时通信方案主要代表是 实时平滑层处理技术（traffic smoothing technique） 27与模糊通信平滑控制技术（fuzzy traffic smoothing technique）28。统计实时通信的主要方式是使用统计的方式，保持 整个系统的网络通信数量低于某个具体的确定的限制之内，也就是通过自适应的调 节来控制各个节点内部的抵达网络的通信速率以保证数据包不会丢失。这样，从统 计的角度来说保证了网络冲突的概率不会太高。当然，要求的网络冲突的概率越低， 网络的利用率就下降越多。 随着以太网交换机技术不断发展，交换式以太网络取代传统的总线式共享网络 成为了一种趋势与必然。基于传统的共享式以太网使用带冲突检测的载波监听的多 路复用（csma/cd，carrier sense multiple access with collision detect）技术来控制 共享信道，这种技术的问题在于信道占有延时不可预计。而在交换式以太网中，被 交换机连接的各个节点都成为了独立的冲突域，因此不存在任何的信道冲突。当前 的交换机设备大多采用了存储转发方式转发数据帧，并且使用基于输出端口的缓冲 方式，这样唯一的可能发生冲突的情况是多个节点同时向同一个节点发送大量的数 据包，这些数据包的总抵达速率高于交换机输出端口的输出速率从而导致了发向同 一节点的数据包的丢失。因为交换机的缓冲空间有限，抵达交换机的数据包如果速 率过快而又没有位置缓存，那么这些数据包就会被交换机丢弃。当前的交换机在拥 塞的情况下并没有任何的针对某种类别的数据包的服务质量保证，如哪个包先发送 或者哪个包该被丢弃等。目前大多数基于交换式以太网络的实时通信方案都是用提 高交换机的服务质量的方法来避免这一冲突的发生。ethereal29项目通过在交换机里 面添加带宽预留机制来达到保护针对特殊用户的通信，通过带宽预留的方式来增强 这些特殊的应用的实时通信保障，该项目的另外一个目的就是希望不改动节点本身 的标准操作系统。文献30同样在交换机里面添加了带宽预留机制，同时在节点机内 部以太网媒体访问控制层mac（media access control）上面添加了实时软件层，另 外，交换机上还运用了最早时限优先edf（earliest deadline first）调度算法，从而 提供了通信速率和实时性的保证。文献31把网络微积分（network calculus）32-34理 论应用到交换式以太网络中，并且分析了基于线性拓扑的多个交换机系统的实时通 信模式，还采用了基于漏斗的平滑流方案。交换式以太网系统的性能测试表明在50 8 个节点的100m同时发送15k字节数据包使网络利用率高于90的情况下，消息传输 的通信延迟仍可以保持在400ms左右。文献35也使用网络微积分理论对基于交换式以 太网的有界延迟（bounded delay）进行了分析。文献36介绍了一种基于交换式以太网 络的实时通信协议，方式是在交换机里面增加了自然优先级排队功能的支持，交换 机对具有不同优先级的消息进行相应的处理优先级别，如定义周期性实时消息的优 先级最高等等。 文献37提出了位于共享式以太网之上的硬实时通信协议 rtcc（real-time communication control） ，该协议使用了一个节点作为系统的总线控制器，其他节点 都被称为远端终端，各远端终端只有得到总线控制器的允许以后方能发送数据，这 种集中式的实时通信方案存在明显的缺点就是总线控制器成为系统的单一失效点， 如果没有配套的恢复协议来保证总线控制器失效情况下系统的恢复，系统就很容易 崩溃。文献38同样提出了类似 rtcc 的基于仲裁控制的以太网实时通信方案。文献39 讨论了几种基于多个交换式集线器（switching hub）的交换式以太网并对其进行了性 能分析，结果表明拥有多个交换式集线器是实时工业网络的非常不错的替代品。 1.3 研究内容 “十五”项目“实时信息处理平台”rtgrid 要求实现具有异构、实时、高可靠 等特性的实时信息处理平台。它的要求之一是实现集群系统内部的零拷贝实时网络 通信。这种网络通信应该具有以下特点： (1) 实时性 要求保证通信的实时性。 (2) 高效性 要求提高通信效率。提高通信效率的途径是减少通信过程中数据拷贝的次数， 减少通信开销。 (3) 兼容性 能够和一般的非实时通信同时运行。 根据课题研究目标和要求，针对现有实时通信协议和零拷贝技术现状，在研究 相关的理论的基础上，课题组研制开发了实时环境下的零拷贝通信设计 rtzcp（real time zero-copy plan） 。rtzcp 基于 linux 环境，受实时内核 rtai 调度控制，能够 实现集群环境下的实时零拷贝通信。rtzcp 能够满足实时性、高效性和兼容性的要 9 求。 rtzcp 的研究包括零拷贝技术、通信实时性、网络缓冲管理、通信稳定性等方 面。 1.4 论文结构 本文各章节的内容组织如下： 第一章首先简述零拷贝技术的研究现状和存在的问题，接着从轻量级通信协议， 零拷贝技术，实时通信协议三个方面说明本文研究内容的相关现状。最后说明本文 的全文结构。 第二章分析了 linux 环境下 udp 协议的通信流程，测试了通信过程中的几个主 要操作的开销，设想了几种可以实施的零拷贝通信方案，并对这几种方案进行了模 拟测试和分析。 第三章介绍了 rtzcp 的实时通信环境和实现实时通信的要求，说明了 rtzcp 的主要结构、通信流程和主要模块。 第四章介绍了 rtzcp 的实现技术，主要包括 rtzcp 提供的主要接口函数及其 作用，还介绍了 rtzcp 中采用的内存管理机制，发送数据包的重映射方式，网络平 滑传输层技术和分片包重组机制等技术。 第五章对于 rtzcp 进行了测试，测试了实时通信和非实时通信同时进行时相互 间的性能影响，还测试了实时通信的网络延迟性能。 第六章对全文进行总结并展望了未来工作；最后是致谢和参考文献。 10 2 零拷贝技术分析零拷贝技术分析 本章将先分析 linux 环境下 udp 协议的通信流程及主要开销，再讨论了几种设 想的基于 udp 协议的零拷贝方案，最后对这些零拷贝方案进行了模拟测试和分析。 2.1 udp 通信流程分析 由于项目的主要运行环境是 linux 操作系统，并且要求进行实时通信，在此分 析 linux 环境下 udp 协议的通信流程。 发送端的数据处理流程如图 2.1 所示。 用户区 udp_sendmsg udp_getfrag copy_from_user ip_build_xmitip_build_xmit_slow udp层 dev_queue_xmit start_xmit ip层 数据链路层 网络设备 socket_sendmsg 图 2.1 linux 下 udp 协议发送流程 (1) 用户数据发送程序首先通过 socket 接口提供的 socket_sendmsg 函数对数据进 行处理，然后将数据交给内核通信模块； 11 (2) 数据经过 inet 层进行处理后被交由 udp 层，udp 层的 udp_sendmsg 函数 中首先检查数据包兼容性，调用 ip_route_output 函数收集 ip 路径相关参数，确定发 送路径，再在数据上增加 udp 头部，然后调用 udp_getfrag 函数分析数据包是否需要 进行分片操作，接着调用 copy_from_user 函数将待发送数据从 socket 相关的用户区 发送缓冲拷贝到内核区的网络发送缓冲，如果需要分片操作，则在这次拷贝中将数 据包按系统要求拷贝为规定大小的若干个分片包，最后通过 ip_build_xmit 函数将数 据转 ip 层进行处理； (3) ip 层的 ip_build_xmit 函数将可以慢速发送的大数据包转 ip_build_xmit_slow 函数处理，ip_build_xmit 函数和 ip_build_xmit_slow 函数在完成增加 ip 头部、进行 相关查错等操作后将数据转送数据链路层； (4) 数据链路层的 net_xmit 函数激活相应的网卡发送程序 start_xmit； (5) 如果网卡不具有 dma 功能，则该函数在进行硬件相关查错的同时将要发送 的数据拷贝到网卡的硬件发送缓冲；如果网卡具有 dma 功能，则该函数首先进行数 据查错，再通过映射方式将内核区的发送缓冲作为网卡的发送缓冲。网卡的硬件中 断产生时网卡会将网卡发送缓冲的数据发送出去。 接收端的数据处理流程如图 2.2 所示。 (1) 数据到达网卡的接收缓冲后，产生中断，网卡驱动的 clean_irq 函数断开数据 包和网卡接受缓冲的连接；如果网卡不具有 dma 功能则先对数据进行硬件查错，然 后在内核区分配相应的内核缓冲，将数据拷贝过去。如果网卡的芯片不具有 dma 功 能，则在网卡执行 clean_rx_irq 函数操作时需要进行一次拷贝，否则该拷贝由硬件完 成，不需要 cpu 参与。如果网卡具有 dma 功能，则先由网卡直接将数据拷贝到内 核区中对应的网络缓冲，再进行硬件查错； (2) 数据链路层的 eth_type_trans 函数对数据进行分析，判断协议类型，再将数 据入对应的接收队列，然后调用 netif_rx 函数将数据转 ip 层进行处理； (3) ip 层的 ip_rcv 函数将数据的 ip 头部取出，并进行 ip 查错，如没有错误则调 用 ip_local_deliver 函数，ip_local_deliver 函数在检查收到的分片包顺序是否正确后调 用 ip_defrag 函数，ip_defrag 函数将分片包数据交由 ip_frag_queue 函数进行处理， ip_frag_queue 函数将同一数据的分片包通过镜像方式建立连接，然后通过 udp_rcv 函 数转 udp 层； (4) udp 层的 udp_rcv 函数收到数据后用 udp_v4_lookup 函数寻找数据包对应的 12 socket 接口，找到后采用发送信号或回调函数的方式通知数据包对应的 socket 接口； (5) socket 接口调用相应的 udp_recvmsg 函数，该函数会在内核缓冲区中搜寻有 无对应的 socket 内核缓冲队列，如果找到相关队列，则将对应的 udp 头部取出，然 后将数据从内核缓冲拷贝到用户区的 socket 缓冲中去，如果是分片包则在这次拷贝 中将分片包的数据拼接起来，然后将数据交给用户处理。 ip_rcv eth_type_trans clear_irq ip层 数据链路层 网络设备 netif_rx ip_local_deliver ip_defragip_frag_queue udp_recv udp_v4_lookup udp_recvmsg udp层 用户区 socket_recvmsg skb镜像 图 2.2 linux 下 udp 协议接收流程 总的说来， 发送端和接收端都要对数据进行两次拷贝。 如果网卡具有 dma 功能， 则网卡和主存上的内核空间通过 dma 方式建立连接，网卡上的 dma 芯片能够直接 处理主存上对应的内核网络缓冲：发送端将数据拷贝到内核区后经过处理后与网卡 13 建立映射连接，网卡将映射的内存空间的数据用 dma 方式发送出去；接收端则先将 内核管理的一部分内存空间作为网卡的 dma 缓冲区，收到的数据直接用 dma 方式 放到缓冲区中，然后交由操作系统处理，处理完后再拷贝给用户程序。收发的过程 中都与网卡自带缓冲区相关的拷贝都由网卡的 dma 芯片完成，不需要 cpu 参与。 2.2 通信开销分析 接下来测试各通信步骤的时间消耗，硬件测试环境为：intel2.0gcpu，256m 内 存，interl pro e1000 网卡，千兆网线，节点机之间采用直接网线连接的方式。软件测 试环境为：linux9.0 操作系统。测试方案为：从客户端向服务器端发送数据，服务 器端接收到数据后向客户端回发数据，在收发数据的过程中取数据到达各层激活对 应函数的时间，从这些时间计算出 linux 环境下的主要通信开销，测试结果如表 2.1 所示。表 2.1 udp 协议的通信开销 数据包大小 (byte) 发送端查错等操 作所需时间(us) 发送端拷贝所 需时间(us) 接收端拷贝所 需时间(us) 接收端查错等操作所需 时间(us) 3238192241 6439202049 12831171942 25630181844 51231172542 102438172245 204849273757 409654354166 819257566272 1228865738575 16384809511591 204807911014092 245768513515189 2867290175192100 3276895201233112 测试结果表明：随着数据包大小的增长，数据包拷贝所消耗的时间逐渐增加， 尤其是在数据包需要进行分片操作后，通信时所消耗的时间增长迅速。而数据包查 14 错等为了保持通信可靠性进行的操作所消耗的时间随着数据包增长变化不大，但是 这些操作所消耗的时间并不小，在集群等可靠网络条件下可以减少一部分相关操作， 从而提高通信效率。 2.3 零拷贝测试方案设计 下面结合现有的零拷贝技术和以 udp 协议为主的 rtnet 通信协议的特点，考虑 实现零拷贝技术的可行性方案： (1) 发送端 cpu 完全不需要参与拷贝，接收端 cpu 参与一次拷贝。本方案要求 网卡具有 dma 功能（如 intel pro e1000） 。在发送端用重映射方式取代用户区到内核 区的一次拷贝。在用户区的数据包上采用分片加上数据头部dma 发送 再分片的方式将大数据包依次分片发送。在接收端采用和 linux 环境下的 udp 协议 类似的接收方式处理数据。本文中称这种方案为零拷贝方法 1。 (2) 对发送方发送数据的大小进行限制， 使发送数据小于 mtu （maximal transfer unit） ，在数据传输过程中不需要进行分片操作。发送端通过重映射方式将数据传送 到内核区，再由网卡用 dma 方式将数据发送出去。接收端先通过 dma 方式将数据 放到网卡在内存中的缓冲区中，然后找到对应的用户程序，调用内存管理机制，通 过映射机制使用户程序能够访问该内存区域，再断开网卡缓冲对该内存空间的映射， 同时为网卡分配新的缓冲空间，用户就能够直接对收到的数据进行处理。不过由于 数据包大小不能大于 mtu(maximum transmission unit，一般为 1500bytes） ，这种通 信方式只能处理小数据包。本文中称这种方案为零拷贝方法 2。 (3) 内核级零拷贝通信协议。主要针对 realtek8139 等不具有 dma 功能的网络设 备。在发送端，协议按照 linux 环境下的 udp 协议的方式在各层进行数据的校检， 形成数据报头部等操作，取消在 udp 层的用户区到内核区的数据拷贝，在数据包从 用户区拷贝到网卡的硬件缓冲后再将形成的数据包头部拷贝到网卡硬件缓冲上对应 数据包的相应位置，形成完整的待发送数据包后进行发送。在接收端，当数据被接 收到网卡上的硬件缓冲后，就执行 ip 层和 udp 层的取数据包头部，校验等操作， 然后找到对应的用户程序，相当于将内核区的除了拷贝以外的其它操作统统移到网 卡的硬件缓冲上完成，在数据处理完后直接拷贝到对应的用户区缓冲去。 (4) rma40（remote memory access,远端内存访问）方式。这种方式的实现方式 一般为 rdma 方式。它的实现要求网卡为具有编程功能的 scsi 网络设备。将通信 15 方式进行修改，按照图 2.3 所示流程进行发送： 用户程序用户程序 网卡网卡 dma缓冲区 图 2.3 rma 通信方式 发送端首先将数据交给通信系统进行处理，系统对待发送数据进行写保护操 作，然后收集数据包的信息，形成被称为“消息”的小数据包； 将“消息”数据包发送至接收端； 接收端收到这些“消息”数据包后找到对应的用户程序，判断这些程序的处 理优先级； 将优先级最高的用户程序的网络缓冲作为网络设备的接收缓冲； 向对应的发送端发送“可以发送”的信号； 发送端的信号后发送数据，接收端通过 dma 方式将数据接收到 dma 缓冲 区，也就是由网卡直接将数据放到对应的用户存储空间。 2.4 零拷贝测试方案性能分析 接下来对 2.3 节所述的四个零拷贝通信方案进行性能测试，硬件测试环境为： intel2.0g cpu，256m 内存，节点机之间采用直接网线连接的方式。软件测试环境为： linux9.0 操作系统，rtai3.0r4 实时内核模块和 rtnet-0.7.1 实时网络通信模块。测 试方案为：从客户端向服务器端发送数据，服务器端接收到数据后向客户端回发数 据，即 ping-pong 测试，客户端取发送和接收两次时间之差即一次循环往返之差 （round-trip time） ，将 round-trip time 作为测试数据。测试结果如下： 在测试内核级零拷贝通信协议时，网络设备采用 realtek8139 网卡和百兆网线， 测试结果如表 2.2 所示。 16 表 2.2 内核级零拷贝通信协议通信延迟测试 数据包大小(bytes)rtnet(us)内核级零拷贝通信协议性能测试(us) 64527236 128526241 256511235 512555260 1024573286 2048602323 4096579369 8192640493 16384738712 20000779821 内核级零拷贝通信协议实现简单，对于硬件要求低。但是通信性能提高不大（小 数据包时性能明显提高主要是因为在实现内核级零拷贝通信协议时我们简化了数据 包查错等保持通信可靠性的操作）。 在测试零拷贝方法 1 和 rma 方式时，网络设备采用 intel pro e1000 网卡和千兆 网线，零拷贝方法 1 和 rma 的测试结果如表 2.3 所示。 表 2.3 零拷贝方法 1 和 rma 方式通信延迟测试 数据包大小(bytes)rtnet(us)零拷贝方法 1(us)rma(us) 32512.7173 318.3 64508.8177 317 128512176.4 327.7 256530.7180.5 322.6 512520.7186.6 322.5 1024533.8190.6 354 2048536.3231.1 394.9 4096544.8253.5 425.2 8192569.6255.4 532.7 12288600.2366.5 544 16384620.5387.9 563 20480648.6472 607.8 24576680.2452.5 630.4 28672701.1553.2 657.5 32768736.1632.9 683.7 零拷贝方法 1 的优点在于对于中等大小的数据包的通信性能提高较大，但是在 17 传输小数据包和很大的数据包时通信性能变化不大。rma 方式在处理大数据包时大 幅缩减了通信延迟，在处理小数据包时反而比一般通信协议要慢（测试结果中性能 较好主要是因为在实现上述两种协议时我们简化了数据包查错等保持通信可靠性的 操作），有一种改进方案为将小数据包拼接为大数据包再进行发送，但是不符合实 时通信的要求。 零拷贝方法 2 的测试结果如表 2.4 所示。它极大的提高了通信性能，但是由于数 据包大小限制在 mtu 之内，实际应用限制太大。 总的说来，内核级零拷贝通信协议实现简单，对于通信性能有一定的提高，但 是由于没有采用 dma 设备和只能采用百兆网卡实现等原因，能够提供的通