正文共：6666 字 2 图，预估阅读时间：4 分钟
RFC4297：Remote Direct Memory Access (RDMA) over IP Problem Statement，December 2005这份备忘录为互联网社区提供信息。它没有指定任何类型的互联网标准。这份备忘录的分发是无限的。
版权所有（C）The Internet Society（2005）。
由于用户数据在终端系统网络I/O处理路径中以高速移动而产生的开销是显著的，并且限制了互联网协议在互连网络和互联网本身中的使用，尤其是在托管应用程序需要高带宽、低延迟和/或低开销的情况下。
本文档研究了这种开销，并通过启用远程直接内存访问（Remote Direct Memory Access，RDMA），提出了一种基于IP的体系结构“避免复制”解决方案，以消除这种开销。
本文档考虑了在高速条件下与用户数据往返于网络接口的移动相关联的高主机处理开销的问题。这个问题通常被称为“I/O瓶颈”[CT90]。更具体地说，这里感兴趣的高开销的来源是数据移动操作，即复制。因此，系统的吞吐量可能会受到这种复制的开销的限制。不要将此问题与TCP卸载混淆，此处未解决此问题。高速是指网络链路速度相对于主机CPU和存储器的带宽较高的情况。在当今的计算机系统中，每秒1吉比特（Gbits/s）及以上被认为是高速的。
与复制相关的高成本主要是大型系统的问题。尽管机架式PC和小型工作站等较小的系统将受益于复制开销的减少，但较小的机器将主要在未来几年受益，因为它们可以扩展处理的带宽。如今，具有高带宽馈送的大型系统机器（通常是多处理器和集群）会受到复制开销的不利影响。这类机器的例子包括各种各样的服务器：数据库服务器、存储服务器、用于交易处理、电子商务和网络服务、内容分发、视频分发、备份、数据挖掘和决策支持以及科学计算的应用服务器。
请注意，此类服务器几乎只为许多并发会话（传输连接）提供服务，这些会话总共负责>1 Gbits/s的通信。尽管如此，特定负载的复制开销的成本是相同的，无论是从几个会话还是多个会话。
在过去的大约14年里，I/O瓶颈和数据移动操作的作用在研究和工业中得到了广泛的研究，我们可以自由地利用这些结果。从历史上看，每当新的网络技术大幅提高线路速率时，I/O瓶颈就会受到关注：100兆比特每秒（Mbits/s）的快速以太网和光纤分布式数据接口（Fibre Distributed Data Interface，FDDI）、155 Mbits/s的异步传输模式（Asynchronous Transfer Mode，ATM）、1 Gbits/s的以太网。在早期的速度转换中，内存带宽的可用性使I/O瓶颈问题得以推迟。然而，现在情况已不再如此。虽然I/O问题在1 Gbits/s时非常严重，但10 Gbits/s以太网的引入正在推动工业和研究的热潮[IB，VI，CGY01，Ma02，MAF+02]。
由于在当前实现中终端主机处理的高开销，TCP/IP协议栈不用于高速传输。相反，使用通常被称为远程直接内存访问（RDMA）的技术的专用网络结构已经被开发并广泛使用。RDMA是一组机制，允许网络适配器在应用程序的控制下，将数据直接导入和导出应用程序缓冲区。这种互连结构的例子包括用于块存储传输的光纤通道[Fibre]、用于数据库集群的虚拟接口（Virtual Interface）体系结构[VI]，以及用于系统局域网的Infiniband[IB]、Compaq Servernet[SRVNET]和Quadrics[QUAD]。这些链路级技术限制了应用程序在距离和大小方面的扩展，这意味着节点的数量不能任意大。
这个问题陈述证实了这样一种说法，即在网络I/O处理中，数据移动操作（特别是复制）会导致高开销；并且该复制避免显著地减少了该处理开销。它描述了高处理开销出现的时间和原因，解释了开销出现问题的原因，并指出了哪些应用程序受到的影响最大。
该文件接着讨论了为什么这个问题与互联网和基于互联网的应用程序有关。存储、管理和分发Internet信息的应用程序非常适合应用避免复制解决方案。他们将受益于避免高处理开销，这消除了对分层终端系统可用扩展的限制。避免复制还消除了这些系统的延迟，这可以进一步有利于有效的分布式处理。
此外，本文档介绍了一种解决该问题的体系结构方法，该方法在[BT05]中进行了详细开发。它还讨论了拟议的技术如何引入安全问题，以及应该如何解决这些问题。
最后，本文档包括术语部分，作为RDMA引入的几个新术语的参考。
来自研究和行业的大量数据表明，复制造成了大量的处理开销。它进一步表明，即使在精心实现的系统中，消除拷贝也会显著降低开销，如下所述。
Clark等人在1989年的[CJRS89]表明，TCP[Po81]开销处理可归因于操作系统成本（如中断、上下文切换、进程管理、缓冲区管理、定时器管理）和与处理单个字节相关的成本（特别是计算校验和和和在内存中移动数据）。他们发现，在内存中移动数据是更重要的成本，他们的实验表明，内存带宽是最大的限制来源。在[CKRS89]提供的数据中，64%的测量微秒开销归因于数据触摸操作，48%归因于复制。该系统使用1460字节以太网数据包在Sun-3/60上测量Berkeley TCP。
在一个实现良好的系统中，复制可以发生在网络接口和内核之间，以及内核和应用程序缓冲区之间；有两个副本，每个副本是两个存储器总线交叉点，用于读取和写入。尽管在某些情况下可以做得更好，但通常收到时需要两份。
随后的工作一直显示出与早期克拉克研究相同的现象。许多研究报告的结果表明，数据触摸操作、校验和和和数据移动在128字节以上消息的处理成本中占主导地位[BS96、CGY01、Ch96、CJRS89、DAPP93、KP96]。对于较小尺寸的消息，每包开销占主导地位[KP96，CGY01]。
由于每字节操作所花费的时间与消息大小成线性关系，因此数据触摸操作导致的开销百分比随数据包大小而增加[KP96]。例如，Chu [Ch96] 报告了在 SPARCstation/20 上进行内存到内存 TCP 测试时，对于不同 MTU 大小网络上的 MTU 大小数据包，每字节的延迟成本占总网络软件成本的相当大的百分比。可归因于每字节操作的软件总成本的百分比为：
1500字节的以太网类型，占比为18-25%；
4352字节的FDDI类型，占比为35-50%；
9180字节的ARM类型，占比为55-65%。
尽管许多研究报告了数据触摸操作的结果，包括校验和和和数据移动，但许多工作仅集中在复制[BS96，Br99，Ch96，TK95]。例如，[KP96]报告将校验和的处理时间与数据移动操作分开的结果。对于1500字节以太网大小，总处理开销时间的20%可归因于复制。该研究使用了两台通过FDDI网络连接的DECstations 5000/200。（在本研究中，校验和占处理时间的30%。）
大量研究表明，消除拷贝大大减少了开销。例如，旨在提高web服务器性能的IO Lite系统[PDZ99]中避免复制的结果显示，与优化的web服务器相比，吞吐量提高了43%，与Apache服务器相比提高了137%。该系统在4.4BSD衍生的UNIX内核中实现，实验使用了一个基于333MHz Pentium II PC的服务器系统，该PC连接到交换的100 Mbits/s快速以太网。
在许多其他例子中，使用各种不同方法消除复制显示出系统性能的显著提高[CF+94、DP93、EBBV95、KSZ95、TK95、Wa97]。我们将详细讨论其中一项研究的结果，以阐明避免复制所产生的显著改善程度[Ch02]。
Chase等人最近的工作[CGY01]测量了CPU利用率，结果表明，对于使用AlphaStation XP1000和Myrinet适配器[BCF+95]的32 KB MTU，在370 Mbits/s的速度下，避免复制可以将用于数据访问的CPU时间从24%减少到15%。由于避免了复制，这绝对提高了9%。
总CPU利用率为35%，其中数据访问占24%。因此，减少拷贝的相对重要性为26%。在370 Mbits/s的速度下，该系统的负载不是很重。可实现带宽的相对提高是34%。如果在机器被网络I/O饱和时添加避免复制功能，我们会看到这种改进。
请注意，如果优化的目标开销在总成本中所占份额更大，那么优化的改进就变得更加重要。如果消除了诸如校验和之类的其他开销源，就会发生这种情况。在[CGY01]中，在消除校验和开销后，避免复制将CPU利用率从26%降低到10%。这是可实现带宽的16%绝对减少、61%相对减少和160%相对改善。
事实上，今天的网络接口硬件通常会卸载校验和，从而消除每字节开销的另一个来源。它们还合并中断以降低每个数据包的成本。因此，今天的复制成本在CPU利用率中所占的比例比以前相对更大，因此在减少它们方面可以获得相对更多的好处。（当然，如果间接费用数额微不足道，这种说法是似是而非的，但事实证明它是实质性的。[BS96，Br99，Ch96，KP96，TK95]）
数据移动操作是昂贵的，因为相对于网络带宽和CPU带宽[PAC+97]，内存带宽是稀缺的。这一趋势在过去就存在，预计将持续到未来[HP97，STREAM]，尤其是在大型多处理器系统中。
由于每个副本跨越总线两次，与CPU和内存带宽相比，每当网络带宽较大时，网络处理开销就会很高。一般来说，对于今天的终端系统，在超过1 Gbits/s的网络速度下可以观察到这种影响。事实上，对于多个总线交叉点，可以看出总线带宽是吞吐量的限制因素。这阻止了这样的终端系统同时实现全网络带宽和全应用性能。
一个常见的问题是CPU处理能力的增加是否缓解了网络I/O的高处理成本问题。答案是否定的，问题出在内存带宽上。如果CPU的大部分时间都在等待内存[CGY01]，那么再快的CPU也无济于事。
微处理器性能和存储器性能之间日益扩大的差距长期以来一直是一个被广泛认识和理解的问题[PAC+97]。Hennessy[HP97]显示，从1980年到1998年，微处理器性能以每年60%的速度增长，而DRAM的访问时间以每年10%的速度提高，这导致了“处理器内存性能差距”的增加。
另一个相关数据来源是STREAM基准参考信息网站，该网站提供有关STREAM标准[STREAM]的信息。该基准测试是一个简单的综合基准测试程序，用于测量可持续内存带宽（以MBytes/s为单位）和以MFLOPS为单位测量的简单矢量内核的相应计算速率。该网站跟踪数百台机器和所有主要供应商的可持续内存带宽信息。
结果显示测量的系统性能统计信息。在所有测量的系统中，1985-2001年的处理性能平均每年增长50%，1975年至2001年的可持续内存带宽平均每年增长35%。在另一项统计数据“机器平衡[Mc95]”中，处理器带宽每年比内存带宽领先15%，这是衡量CPU与内存带宽相对速率（FLOPS/周期）/（持续内存操作/周期）[STREAM]的指标。
网络带宽大约每8年增长10倍，即每年40%的增长率。
一个典型的例子说明存储器带宽与链路速度相比是不利的。STREAM基准测试表明，现代单处理器PC，例如2001年的1.2 GHz Athlon，在进行接收操作时会移动数据3次：一次用于网络接口将数据存储在内存中，两次用于CPU复制数据。使用1 Gbits/s的内存带宽，即一次读取或一次写入，该机器可以处理大约2.67 Gbits/s的网络带宽，即复制带宽的三分之一。但这是假设100%的利用率，这是不可能的，更重要的是，机器将被完全消耗掉！（数据库的经验法则是，应该要求20%的计算机为I/O提供服务，剩下80%用于数据库应用程序。而且，越少越好。）
2001年，1 Gbits/s的链路很常见。应用程序服务器通常可以有两个1 Gbits/s连接：一个连接后端到存储服务器，另一个连接前端，例如用于服务HTTP[FGM+99]。因此，通信可以使用2 Gbits/s。在我们的典型示例中，该机器可以在其理论最大值下处理2.7 Gbits/s，而不做任何其他事情。这意味着该机器基本上无法跟上2001年的通信需求；随着相对增长的趋势，情况只会变得更糟。
如果应用程序机器上的很大一部分资源被消耗在网络I/O中，而不是应用程序处理中，则应用程序很难扩展，即处理更多的客户端，提供更多的服务。
几年前，受影响最大的应用程序是流媒体多媒体、并行文件系统和集群上的超级计算[BS96]。此外，如今，遭受复制开销的应用程序在互联网计算中更为重要——它们存储、管理和分发互联网和企业的信息。它们包括执行事务处理、电子商务、web服务、决策支持、内容分发、视频分发和备份的数据库应用程序。集群通常用于这类应用程序，因为它们具有可用性和可扩展性的优势。
如今，这些提供和管理Internet和公司信息的应用程序通常在分为三个逻辑层的数据中心中运行。一层通常是连接到WAN的一组web服务器；第二层是一组应用程序服务器，通常在功能更强大的机器上运行特定的应用程序；第三层是后端数据库。在物理上，前两层——web服务器和应用程序服务器——通常是组合在一起的[Pi01]。例如，电子商务服务器与数据库服务器和客户站点通信，或者内容分发服务器连接到服务器场，或者OLTP服务器连接到数据库和客户站点。
当网络I/O使用过多内存带宽时，网络层级之间网络路径的性能可能会受到影响。（数据库层或应用程序层使用的存储区域网络路径也可能存在性能问题。）网络相关内存拷贝的高开销会将系统资源从其他应用程序处理中转移出去。它还可能造成限制整个系统性能的瓶颈。
最大化每个CPU的处理能力是有很大动机的，因为通过添加CPU来进行扩展，无论以何种方式，都有缺点。例如，在多处理器中添加CPU并不一定有帮助，因为只有当内存总线有额外的空闲带宽时，多处理器才能提高性能。集群可能会增加处理应用程序的复杂性。
为了扩展集群或多处理器系统，必须按比例扩展互连带宽。互连带宽决定了通信密集型并行应用程序的性能；如果这个值（通常用“平分带宽”表示）太低，则添加额外的处理器无法提高系统吞吐量。互连延迟也会限制经常在处理器之间共享数据的应用程序的性能。
因此，在“可扩展”系统中，网络路径上的过多开销既可能需要使用比最佳处理器更多的处理器，也可能降低这些额外处理器的边际效用。
通过从“非常好”的1拷贝（接收时）实现中消除至少三分之二的总线带宽负载，避免拷贝可以向上扩展机器，并从2拷贝实现中消除了至少80%的带宽开销。
总线带宽要求的消除反过来又消除了网络处理路径的瓶颈，并提高了机器的吞吐量。在总线带宽有限的机器上，消除这种负载的优势是显而易见的，因为主机可以获得完整的网络带宽。即使在总线带宽足以维持整个网络带宽的机器上，消除总线带宽负载也有助于提高机器处理用户应用程序的可用性，在某些情况下会显著提高可用性。
一个示例显示了使用拷贝时性能较差，而使用拷贝避免时可扩展性得到改善，这是一个示例。IO Lite工作[PDZ99]显示了更高的服务器吞吐量，使用零拷贝系统为更多的客户端提供服务。在一个旨在通过模拟TCP WAN连接对服务器的影响来模拟真实世界web条件的实验中，对3台服务器的性能进行了比较。一个服务器是Apache，另一个是一个名为Flash的优化服务器，第三个是运行IO Lite的Flash服务器，称为零拷贝的Flash-Lite。测量的是以请求/秒为单位的吞吐量，它是可以服务的慢速后台客户端数量的函数。如表所示，Flash-Lite具有更好的吞吐量，尤其是随着客户端数量的增加。
传统的Web服务器（主要发送数据，并可以将大部分内容保存在文件缓存中）并不是复制开销的最坏情况。基于系统局域网或多层系统的Web代理（通常接收与发送一样多的数据）和复杂的Web服务器将比上面的示例遭受更多的复制开销。
对于消除数据移动开销的两种主要替代方法，以及提高其他操作系统处理成本，已经进行了广泛的研究调查和行业经验。在一种方法中，单个主机内的硬件和/或软件改变降低了处理成本。在另一种方法，内存到内存网络[MAF+02]中，主机之间显式数据放置信息的交换允许它们降低处理成本。
单主机方法的范围从新的硬件和软件体系结构[KSZ95、Wa97、DWB+93]到新的或修改的软件系统[BS96、Ch96、TK95、DP93、PDZ99]。在基于使用网络协议交换信息的方法中，网络适配器在应用程序的控制下，将数据直接放入应用程序缓冲区和从应用程序缓冲区时取出，从而减少了数据移动的需要。这种方法通常被称为RDMA（Remote Direct Memory Access，远程直接内存访问）。
如下所述，研究和行业经验表明，仅在接收器处理路径内的复制避免技术已被证明是有问题的。研究的专用主机适配器系统具有良好的性能，可以被视为基于RDMA的商用适配器[KSZ95，DWB+93]的先驱。在软件方面，许多实现方式已经成功地实现了零拷贝传输，但很少有实现零拷贝接收。这样做的人对应用程序提出了严格的对齐和无接触要求，大大降低了实现的可移植性和实用性。
相反，经验证明，允许RDMA的内存到内存系统是令人满意的；性能一直很好，没有出现系统或网络问题。RDMA是一个单一的解决方案。一旦实现，它就可以与任何操作系统和机器体系结构一起使用，当这两种体系结构中的任何一种发生变化时，它都不需要修改。
在早期的工作中，软件方法的一个目标是表明TCP在适当的操作系统支持下可以更快地运行[CKRS89，CFF+94]。虽然实现了这一目标，但进一步的调查和经验表明，尽管可以制定软件解决方案，但特定的系统优化是复杂的、脆弱的，以复杂的方式与其他系统参数极为相互依赖，而且往往只有边际改进[CF+94，CGY01，Ch96，DAPP93，KSZ95，PDZ99]。网络I/O系统与操作系统的其他方面交互，例如机器体系结构和文件I/O以及磁盘I/O[Br99，Ch96，DP93]。
例如，依赖于页面重新映射的Solaris零拷贝TCP工作[Ch96]表明，结果与其他系统（如文件系统）高度依赖，并且特定的优化针对特定的体系结构，这意味着对于体系结构的每种变体，都必须重新编制优化[Ch96]。
使用RDMA，直接映射应用程序I/O缓冲区，授权的对等方可以访问它，而不会产生额外的处理开销。当RDMA在硬件中实现时，可以在根本不涉及主机CPU的情况下执行任意数据移动。
许多研究项目和行业产品都是基于内存到内存的方法来避免复制的。其中包括U-Net[EBV95]、SHRIMP[BLA+94]、Hamlyn[BPM+96]、Infiniband[IB]、Winsock Direct[Pi01]。几种存储器到存储器系统已经被广泛使用，并且通常被发现是鲁棒的、具有良好的性能并且实现起来相对简单。其中包括VI[VI]、Myrinet[BCF+95]、Quadrics[QUAD]、Compaq/Tandem Servernet[SRVNET]。基于这些存储器到存储器体系结构的网络已广泛用于科学应用和数据中心的块存储、文件系统访问和事务处理。
通过“有线传输”导出直接内存访问，应用程序可以指示网络堆栈直接从应用程序缓冲区管理所有数据。已经出现了一个利用应用程序的此类功能的大型且不断增长的类。它包括所有主要的数据库，以及Sockets Direct[SDP]等网络协议。
RDMA解决方案可以有效地视为由两个不同的组件组成：“直接数据放置（direct data placement，DDP）”和“远程直接内存访问（remote direct memory access，RDMA）语义”。它们在目的和实践上都是不同的——它们可以作为单独的协议来实现。
两者中更基本的是DDP直接数据放置功能。这是以适当的方式将内存暴露给远程对等体的方式，也是对等体可以访问内存的方式，例如读取和写入。
RDMA控制功能在语义上分层在直接数据放置之上。包括提供“控制”功能的操作，如连接和终止，以及操作的顺序和完成信号。提供了“发送”功能。
虽然功能（以及潜在的协议）是不同的，但从历史上看，这两个方面都被称为“RDMA”。直接数据放置的设施本身是有用的，并且可以被其他上层协议用来促进数据传输。因此，将DDP用于数据放置功能，将RDMA用于方面通常是有用的。
[BT05]在Internet协议套件的基础上开发了DDP和RDMA的体系结构，是该问题声明的配套文档。
本问题声明的结论是，需要一种基于IP的通用解决方案来减少终端主机的处理开销。
研究表明，网络数据处理的高开销会导致终端主机瓶颈。这些瓶颈在很大程度上归因于数据的复制。从历史上看，机器的总线带宽一直是有限的，高速互连的带宽给它带来了沉重的负担。
缓解这些瓶颈的体系结构解决方案最能满足这个问题。此外，当今互连的高速性和这些主机在基于互联网协议的网络上的部署导致了在互联网协议套件上分层这种解决方案的可取性。[BT05]中描述的体系结构就是这样一个建议。
在高带宽传输中减少复制开销的问题的解决方案可能会引入新的安全问题。任何拟议的解决方案都必须针对安全漏洞进行分析，并解决任何此类漏洞。潜在的安全弱点——由于可能导致拒绝服务攻击、覆写和其他并发操作的资源问题、RDMA协议要求的完成顺序、传输粒度和任何其他已识别的漏洞——需要进行检查、描述，并找到适当的解决方案。
RDMA协议位于互联网传输协议之上，将从互联网安全标准（如IPsec和TLS[IPSEC，TLS]）中获得优势，并且必须允许与之集成。然而，由于RDMA避免了复制，因此某些安全方法可能会产生实施后果。
IPsec在逐包的基础上操作以确保连接的安全，似乎很自然地适合于与传输一起操作的RDMA放置的安全。因为RDMA能够实现避免缓冲，所以最好在传输层和RDMA层处理每个段之前执行所有适用的安全保护。这样的分层实现了最高效的安全RDMA实现。
另一方面，TLS记录协议是在可靠传输之上分层的，在整个记录可用之前无法提供这种安全保证，这可能需要在TLS处理之前缓冲和/或组装几个不同的消息。这将推迟RDMA处理，并引入了RDMA旨在避免的开销。因此，TLS被视为保护RDMA协议的潜在不太自然的选择。
有必要保证RDMA通信信道上的机密性、完整性和身份验证等属性。然而，这些属性无法抵御来自经过正确身份验证的对等方的所有攻击，这些攻击可能是恶意的、被破坏的或有缺陷的。因此，RDMA设计必须解决针对此类攻击的保护问题。例如，未经事先同意，RDMA对等方不应能够读取或写入内存区域。
此外，一定不能逃避接收者的内存一致性检查。RDMA设计必须允许接收方通过在适当的时间显式地控制对存储器区域的对等访问来依赖其一致的存储器内容。
不能允许未通过上层身份验证和授权检查的对等连接以RDMA模式开始处理不合适的端点。一旦关联，在访问任何传输操作或数据之前，对存储器区域的对等访问必须经过身份验证，并在执行这些访问的关联和连接的上下文中进行授权检查。
RDMA协议必须确保这些区域保护处于严格的应用程序控制之下。网络对等方对本地存储器的远程访问在互联网环境中尤为重要，因为这种访问可以全局导出。
本节包含本文档和远程直接内存访问的一般术语定义。
远程直接内存访问（RDMA）：一种访问远程系统内存的方法，其中本地系统指定要传输的数据的位置。
RDMA协议：一种支持RDMA操作以在系统之间传输数据的协议。
网络架构：连接一组系统的链路、交换机和路由器的集合。
存储区域网络（Storage Area Network，SAN）：一种网络，其中磁盘、磁带和其他存储设备通过结构可供一个或多个终端系统使用。
System Area Network：系统局域网，集群系统通过结构共享服务（如存储和进程间通信）的网络。
光纤通道（Fibre Channel，FC）：具有相关协议的ANSI标准链路层，通常用于实现存储区域网络。[FIBRE]
虚拟接口体系结构（Virtual Interface Architecture，VI，VIA）：RDMA接口定义由一个行业团体开发，并使用各种不同的有线协议实现。[VI]
Infiniband（IB）：由行业贸易协会定义的RDMA接口、协议套件和链路层规范。[IB]
Jeff Chase慷慨地提供了许多有用的见解和信息。感谢Jim Pinkerton的许多有益讨论。
[ATM] The ATM Forum, "Asynchronous Transfer Mode Physical Layer Specification" af-phy-0015.000, etc. available from http://www.atmforum.com/standards/approved.html.[BCF+95] N. J. Boden, D. Cohen, R. E. Felderman, A. E. Kulawik, C. L. Seitz, J. N. Seizovic, and W. Su. "Myrinet - A gigabit-per-second local-area network", IEEE Micro, February 1995.[BJM+96] G. Buzzard, D. Jacobson, M. Mackey, S. Marovich, J. Wilkes, "An implementation of the Hamlyn send-managed interface architecture", in Proceedings of the Second Symposium on Operating Systems Design and Implementation, USENIX Assoc., October 1996.[BLA+94] M. A. Blumrich, K. Li, R. Alpert, C. Dubnicki, E.W.Felten, "A virtual memory mapped network interface for the SHRIMP multicomputer", in Proceedings of the 21st Annual Symposium on Computer Architecture, April 1994, pp. 142-153.[Br99] J. C. Brustoloni, "Interoperation of copy avoidance in network and file I/O", Proceedings of IEEE Infocom, 1999, pp. 534-542.[BS96] J. C. Brustoloni, P. Steenkiste, "Effects of buffering semantics on I/O performance", Proceedings OSDI'96, USENIX, Seattle, WA October 1996, pp. 277-291.[BT05] Bailey, S. and T. Talpey, "The Architecture of Direct Data Placement (DDP) And Remote Direct Memory Access (RDMA) On Internet Protocols", RFC 4296, December 2005.[CFF+94] C-H Chang, D. Flower, J. Forecast, H. Gray, B. Hawe, A. Nadkarni, K. K. Ramakrishnan, U. Shikarpur, K. Wilde, "High-performance TCP/IP and UDP/IP networking in DEC OSF/1 for Alpha AXP", Proceedings of the 3rd IEEE Symposium on High Performance Distributed Computing, August 1994, pp. 36-42.[CGY01] J. S. Chase, A. J. Gallatin, and K. G. Yocum, "End system optimizations for high-speed TCP", IEEE Communications Magazine, Volume: 39, Issue: 4 , April 2001, pp 68-74. http://www.cs.duke.edu/ari/publications/end-system.{ps,pdf}.[Ch96] H.K. Chu, "Zero-copy TCP in Solaris", Proc. of the USENIX 1996 Annual Technical Conference, San Diego, CA, January 1996.[Ch02] Jeffrey Chase, Personal communication.[CJRS89] D. D. Clark, V. Jacobson, J. Romkey, H. Salwen, "An analysis of TCP processing overhead", IEEE Communications Magazine, volume: 27, Issue: 6, June 1989, pp 23-29.[CT90] D. D. Clark, D. Tennenhouse, "Architectural considerations for a new generation of protocols", Proceedings of the ACM SIGCOMM Conference, 1990.[DAPP93] P. Druschel, M. B. Abbott, M. A. Pagels, L. L. Peterson, "Network subsystem design", IEEE Network, July 1993, pp.8-17.[DP93] P. Druschel, L. L. Peterson, "Fbufs: a high-bandwidth cross-domain transfer facility", Proceedings of the 14th ACM Symposium of Operating Systems Principles, December 1993.[DWB+93] C. Dalton, G. Watson, D. Banks, C. Calamvokis, A. Edwards, J. Lumley, "Afterburner: architectural support for high-performance protocols", Technical Report, HP Laboratories Bristol, HPL-93-46, July 1993.[EBBV95] T. von Eicken, A. Basu, V. Buch, and W. Vogels, "U-Net: A user-level network interface for parallel and distributed computing", Proc. of the 15th ACM Symposium on Operating Systems Principles, Copper Mountain, Colorado, December 3-6, 1995.[FDDI] International Standards Organization, "Fibre Distributed Data Interface", ISO/IEC 9314, committee drafts available from http://www.iso.org.[FGM+99] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.[FIBRE] ANSI Technical Committee T10, "Fibre Channel Protocol (FCP)" (and as revised and updated), ANSI X3.269:1996 [R2001], committee draft available from http://www.t10.org/drafts.htm#FibreChannel[HP97] J. L. Hennessy, D. A. Patterson, Computer Organization and Design, 2nd Edition, San Francisco: Morgan Kaufmann Publishers, 1997.[IB] InfiniBand Trade Association, "InfiniBand Architecture Specification, Volumes 1 and 2", Release 1.1, November 2002, available from http://www.infinibandta.org/specs.[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.[KP96] J. Kay, J. Pasquale, "Profiling and reducing processing overheads in TCP/IP", IEEE/ACM Transactions on Networking, Vol 4, No. 6, pp.817-828, December 1996.[KSZ95] K. Kleinpaste, P. Steenkiste, B. Zill, "Software support for outboard buffering and checksumming", SIGCOMM'95.[Ma02] K. Magoutis, "Design and Implementation of a Direct Access File System (DAFS) Kernel Server for FreeBSD", in Proceedings of USENIX BSDCon 2002 Conference, San Francisco, CA, February 11-14, 2002.[MAF+02] K. Magoutis, S. Addetia, A. Fedorova, M. I. Seltzer, J. S. Chase, D. Gallatin, R. Kisley, R. Wickremesinghe, E. Gabber, "Structure and Performance of the Direct Access File System (DAFS)", in Proceedings of the 2002 USENIX Annual Technical Conference, Monterey, CA, June 9-14, 2002.[Mc95] J. D. McCalpin, "A Survey of memory bandwidth and machine balance in current high performance computers", IEEE TCCA Newsletter, December 1995.[PAC+97] D. Patterson, T. Anderson, N. Cardwell, R. Fromm, K. Keeton, C. Kozyrakis, R. Thomas, K. Yelick , "A case for intelligient RAM: IRAM", IEEE Micro, April 1997.[PDZ99] V. S. Pai, P. Druschel, W. Zwaenepoel, "IO-Lite: a unified I/O buffering and caching system", Proc. of the 3rd Symposium on Operating Systems Design and Implementation, New Orleans, LA, February 1999.[Pi01] J. Pinkerton, "Winsock Direct: The Value of System Area Networks", May 2001, available from http://www.microsoft.com/windows2000/techinfo/howitworks/communications/winsock.asp.[Po81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.[QUAD] Quadrics Ltd., Quadrics QSNet product information, available from http://www.quadrics.com/website/pages/02qsn.html.[SDP] InfiniBand Trade Association, "Sockets Direct Protocol v1.0", Annex A of InfiniBand Architecture Specification Volume 1, Release 1.1, November 2002, available from http://www.infinibandta.org/specs.[SRVNET] R. Horst, "TNet: A reliable system area network", IEEE Micro, pp. 37-45, February 1995.[STREAM] J. D. McAlpin, The STREAM Benchmark Reference Information, http://www.cs.virginia.edu/stream/.[TK95] M. N. Thadani, Y. A. Khalidi, "An efficient zero-copy I/O framework for UNIX", Technical Report, SMLI TR-95-39, May 1995.[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.[VI] D. Cameron and G. Regnier, "The Virtual Interface Architecture", ISBN 0971288704, Intel Press, April 2002, more info at http://www.intel.com/intelpress/via/.[Wa97] J. R. Walsh, "DART: Fast application-level networking via data-copy avoidance", IEEE Network, July/August 1997, pp.28-38.
版权所有（C）The Internet Society（2005）。
本文件受BCP 78中包含的权利、许可和限制的约束，除非其中另有规定，否则作者保留其所有权利。
本文件和此处包含的信息是在“原样”的基础上提供的，贡献者、他/她代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利，或任何隐含的适销性或适用于特定目的的保证。
IETF对任何知识产权或可能声称与本文件中所述技术的实施或使用有关的其他权利的有效性或范围，或此类权利下的任何许可可能可用或不可用的程度，不持任何立场；它也不代表它已作出任何独立努力来确定任何此类权利。有关RFC文档中权限的过程的信息可以在BCP78和BCP79中找到。
向IETF秘书处披露的知识产权的副本和任何许可证的保证，或本规范的实施者或用户试图获得通用许可证或使用此类专有权利的许可的结果，可从IETF在线知识产权库获取，网址为http://www.ietf.org/ipr.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准所需技术的其他专有权利。请将信息发送至IETF，网址为ietf-ipr@ietf.org.
RFC编辑器功能的资金目前由互联网协会提供。
长按二维码
关注我们吧
