1.序言

在近年来，TCP/IP减负引擎（TOEs）已经引起了工业领域极大的关注，同时占据了相当大的风险投资份额。TCP减负引擎是种专业化的网络设备，它在硬件上可以实现TCP/IP协议中重要的一个部分，从而可以减轻CPU在处理TCP/IP协议时在软件方面所承担的负担。这篇文章探讨人们对TOEs兴趣背后的原因，同时前瞻TOEs在实现和部署方面可能遇到的挑战。

2.TCP/IP减负引擎的必备条件

TCP和IP都是IETF（互联网工程任务组）定义的独立于硬件的网络传输协议。TCP/IP协议的信息交换主要是通过Internet协议套件。因此，那些基于TCP/IP协议运行的网络应用所具备的性能和效率与TCP/IP协议有着极大的联系。为了理解TCP/IP减负背后的动机，很重要的一点是意识到TCP/IP在包含很多其他元素的网络基础设施中以一体运行。例如以下几个方面：

l 网络互联，比如使用铜，光或者无线进行连接

l CPU，内存和那些在网络节点上的网络接口硬件

l 在这些节点上运行的操作系统和应用程序

所有这些因素可以对基于TCP/IP的应用程序的运行情况有显著的影响，而这些都独立于TCP/IP自身。

2.1网络能力：供应和需求

让我们先来看看TCP/IP为其工作的网络的能力情况。局域网主要是利用以太网来实现，而以太网的发展，从1990年的10Mbps（兆比特每秒）到1990年中期的100Mbps再到今天的1Gbps（千兆比特每秒）经历了一个平稳的过程。10-Gbps以太网的规格是在2002年批准的，但该技术尚未得到广泛的部署。

对于每一次速度提升，广泛的部署都比首次提出要落后很多年。千兆以太网在1998就已经被提出，但直到过去的一两年之间才得到广泛的部署。无独有偶，这一时期部署的成本大幅下降，千兆位以太网NIC(网络接口卡)的价格已经从最初引进时的500美元左右降到今日的几十美元。

对于网络带宽的需求也在增加，尽管办公室台式电脑目前不需要千兆带宽，但中等规模的企业在集中式文件，web及数据库服务器这些方面需要千兆字节的带宽，以便能及时地响应客户。中端和企业级服务器通常支持多个千兆接口。目前的挑战是对于这些接口的能力进行控制，同时在代价不高的情况下仍然能够提供足够的计算能力来运行服务器应用程序。

2.2提高CPU功率：收益递减？

CPU运行TCP/IP协议软件的能力也在随着时代的发展逐步提升。自从英特尔公司的奔腾系列CPU推出以来，典型的CPU时钟速度已经增加了百分之五千，从60MHz(兆赫)到今天的3GHz(千兆赫)。

处理能力的提升和网络能力的发展看起来很匹配，但对基于TCP/IP网络的应用程序的需求的增加却是快的不能再快。此外，研究表明，随着CPU的速度增加，它们对于驱动TCP/IP流量的能力却提升很慢。

图2-1：随着CPU速度变化相关的性能的成本

图2-1说明了这种变化的非线性。TCP吞吐量和主机CPU利用率通过一系列的传输数据的大小进行衡量，并且使用800MHz和2.4GHz主频的CPU在相同的硬件配置条件下进行测试。推导出一个相对成本的表达式：

相对成本=（CPU利用率*CPU主频）/CPU吞吐量（2-1）

我们想计算出每兆比特的网络吞吐量需要多大计算能力（数量越大意味着每兆字节花费多的成本越高）。尽管2.4GHz主频的CPU在绝对吞吐量总是接近甚至超过800MHz主频的CPU，但它的性能并不和时钟频率的三倍成线性关系。在任何情况下，运行速度越快的CPU在每兆比特的吞吐量方面的相关成本也越高，在有些情况下，2.4GHz的CPU的成本开销甚至超过800MHz的CPU的两倍。

CPU性能和内存以及I/O子系统之间的不同步性是导致CPU速度提升但效果反而减少的主要原因。随着CPU速度的增加，尽管内存和I/O的速度也得到提升，但提升却非常缓慢。结果导致比例上需要花费更多的CPU停顿周期来完成存储器访问，这些停顿的周期在CPU利用率上能直观的显示出来。至于原因我们将在后面详细探讨，传统的TCP/IP处理是和内存紧密相关的，所以对于这种周期停顿的情况特别敏感。

内存性能的不佳可以在一定程度上进行抵消，例如通过使用高速缓存层次结构来隐藏内存延迟，也可以通过使用诸如硬件多线程的技术来提升内存性能，这种技术允许线程交替执行此时内存可以等待一个停顿的线程完成访存。扩大高速缓存来满足性能的要求并不是一个有效的做法，尤其是网络应用程序的数据时不断流动的，而不是遍历相同的数据集的数据。

硬件多线程性能的提升只有在多个执行线程准备工作时才得到体现，并且这也高度依赖于应用程序的性质。例如，硬件多线程可能会对那些支持大量相对低带宽客户端的网络应用程序有所帮助，可以通过使用进程池（web服务器，数据库服务器）达到这一效果。相反，它对于那些支持少数高带宽客户端的应用程序帮助不大，仅仅提供相对少量的线程（块存储和集群应用程序）。

2.3新应用

千兆以太网的广泛普及，高性能以及其硬件低成本使得它对那些没有使用以太网的应用程序更具吸引力，这些应用程序传统上使用的都是专业但却昂贵的硬件。在服务器和存储系统之间传输块存储的存储区域网络传统上是使用基于光纤通道的SCSI协议，在iSCSI规范中定义了一种方法来在TCP/IP协议的基础上路由相同的SCSI协议。与此相同的是，基于TCP/IP运行的远程直接内存访问技术提供基于集群的通讯和I/O性能，这已经做到了能够和目前专有消息协议和互连硬件相媲美的程度。

这些应用程序之间的共同点是目前在光纤通道，专用集群硬件方面的技术，这技术实现了在极低的CPU开销下达到非常高的性能。低性能的基于TCP/IP的替代品对一些存储区域网络和集群应用程序而言可能已经足够，但是提供一个直接替代现任技术，以TCP/IP为基础的替代品就需要TCP减负。

2.4 10千兆比特以太网

10千兆比特以太网提供的10倍的性能使其对那些诸如存储网络和集群服务器互联等高要求的应用程序具有极大的吸引力。目前还没有10千兆以太网的广泛应用，一部分是因为10千兆比特网卡和网络基础设备的价格昂贵。即使10千兆比特的设备很便宜，使用传统CPU和内存技术传输10千兆比特速率的TCP数据依然十分昂贵。内存由于其性能瓶颈在以千兆位比特速率传输时已经相当吃力，更不用说传输10千兆比特数据了。TCP/IP减负为解决该问题提供了一个可行的途径，虽然长期的解决方案可能涉及到不断的变化甚至会与单纯的为TCP/IP协议套件减负有很大区别。

3.实现TCP/IP减负的挑战

很显然对于应用程序而言TCP/IP减负具有重要意义，对于一些应用程序而言甚至是强制性的。对于把TCP/IP减负技术投入市场有待克服的关键挑战是什么？

3.1 实现成本

虽然作为工程师地我们可以把实现成本看作是市场营销所关心的问题对此置之不理，但这将错过发展网络技术的一个关键环节，尤其是TCP/IP减负技术。毕竟以太网技术的巨大成功在很大程度上是其相对较低的硬件成本和易于部署的结果。为了实现网络的发展，TCP减负引擎必须提供要么传统CPU无法提供要么虽然提供但成本过高的解决方案。

那么哪些因素决定了TCP减负引擎的成本？网关的设计是整体复杂性设计中非常重要的一个部分，由于它决定了硅晶片的尺寸，故它在整体设计成本占据很大份额。芯片尺寸以及I/O引脚数量的设计要求决定了硅晶片所需要的物理封装包的大小。该包的大小以及需要例如内存和以太网物理接口芯片组件的外部支持的需求决定了电路板空间的大小，为的是更好的适应TCP减负引擎。

设计的负责性以及外部存储器的需求这两个因素使得TCP减负引擎不同于现有的以太网设备。为了更好的理解这些知识，让我们更详细的了解下TCP/IP协议及其运行环境。

3.2 TCP的本质

TCP的任务是在原本不可靠地网络中提供相对可靠的数据传递。TCP的特点是在软件和硬件方面实现起来复杂度中等，尤其是和那些诸如光纤通道的协议相比更是如此，那些协议都是设计运行在可靠的网络之中，考虑硬件的实现不是很多。一个针对TCP特点的详细说明已经超出了本文的范围，接下来就是为了说明TCP减负实施过程中的一些挑战。

在TCP中数据的流动建立在在两个对等端点之间，这两个端点提供双向字节流的移动。这些端点通过使用随着传输每字节增加的32位序列号实现字节流同步。每一个端点都通过包含传送到对端端点收到的最后一个字节的序列号的数据包序号，从而告知自己收到的数据。

数据流的接收控制是通过采用一个滑动窗口来加以实现，对于来自另一端的数据窗口可以设定准备接收多少数据，这些数据包含在对等端传输的每个数据包中。接收窗口在数据传输到本端时会缩小，在本端处理数据时会扩大。如果本端处理数据足够慢，接收窗口会收缩至零，在这种情况它的对等端就无法传输任何数据直到本端处理完数据重新把窗口打开为止。一个有数据要发送的传输器在遇到接收窗口为零的情况下会通过使用窗口探测报文定时检查接收窗口是否打开。

除了在对等端可能存在的潜在错误外，TCP必须处理那些被丢弃的数据包，这些数据包是在网络拥塞或错误时因干预网络而被丢弃。要做到这一点，TCP采用了两种机制来检测，当数据包被丢弃时它会要求发送端重发数据，当在一定时间内未收到数据包正确接收的消息或者同一数据收到多个确认收到的消息时也会进行处理。在重传数据时，TCP使用的是联系重传回退算法，在几分钟后会最终放弃传输。

在确认超时重传的方法中是以动态计算的往返时间为参考，该往返时间是用来估计TCP保持对等端可行连接的时间。除了检测数据包丢失外，当检测到数据包被丢弃时，在慢启动和拥塞窗口机制下利用TCP的流量控制机制可以动态限制数据发送器发送到网络中的数据。

随着网络数据传输速率的提升，基础的TCP数据确认和重传机制已经显得不是那么高效，丢失一个数据包可能导致重传很多数据包。为了解决这个问题，可选机制已经被提出，时间戳选项可以让往返时间的估计值更加精确，选择性确认选项也为重传提供了更精确的数据传递。

TCP可以描述的特点就像在硅晶体上实现大量门电路那样复杂。对于TCP减负引擎，最关键的挑战是决定把TCP的哪些特点放在硬件上加以实现从而达到高性能，把TCP的哪些特点保留在软件层面从而减少设计的复杂性。

除了为实现各种定时器、计数器和算法所要求的逻辑复杂性外，TCP减负引擎还必须保持每一个减负连接的相关状态信息。而此类状态信息通常为每个连接256个字节，故TCP减负引擎目的是要确保64000个并发连接的状态信息得到保持，而这些信息要占到16兆字节。

3.3 如果你认为它是软件？你就错了

还是应该这样认为：它是愚蠢的软件？软件与硬件相比变化相对缓慢，故其绝对不是愚蠢的。这看似有悖常理，因为更新软件比开发新的硬件通常更容易。实际上，软件有一个复杂的层次结构，从操作系统的内核和硬件接口的最底层，通过诸如TCP/IP的内核服务，到达诸如web界面和数据库服务器这些用户级应用程序。在这个层次中每一层都通过使用API应用程序接口把自己进行抽象以便和上层联系起来。随着时间的推移，这些相对稳定的应用程序接口使软件的研发更加容易，经济效益更高，用户应用层的接口更是如此。

图3-1：今日网络软件的层次结构

图3-1中显示了在传统系统中网络软件层次的简化视图。其中关键点是套接字应用程序接口，它们可以让应用程序访问网络设备和操作系统，同时网络硬件设备的驱动程序接口也把一个特定的硬件驱动程序链接到操作系统的网络堆栈中。

3.4 套接字API：没有免费的午餐

套接字应用程序接口（也被称为套接字）率先在美国加州的伯克利软件Unix发行时被提出，应用程序接口的衍生品在当今几乎所有的操作系统中都得到了体现，大多数网络应用程序都是在使用应用程序的接口上编写的。套接字是可以直接使用的，它隐藏了底层的网络协议栈使应用程序免受这些困扰，但这种易用性往往要付出代价。

当接收数据时，基于套接字的应用程序接收的数据包不需要包含任何TCP、IP协议头部。在传统的堆栈中，这是通过分解内核缓冲区中接收到的数据，然后把数据复制到应用程序的缓冲区中加以实现。接收缓冲区的内核也支持另一个套接字方便的功能特点：应用程序在数据从网络接收前不需要提供缓冲区去保存超出的数据。如果数据在应用程序提供接收缓冲区之前到达，这些数据会缓存在内核中，并且在应用程序最终使用它们时被复制到应用程序的缓冲区。

同样，在发送数据时，应用程序不必等待接收到对等端收到数据的消息后才删除本地的数据备份。当从应用程序接收或传输数据时，内核会立即把数据复制到内核缓冲区，在内核缓冲区中，数据仍然可以被重新传送直到收到对等端正确接收数据的消息。

这些功能通常会导致数据在主机内存接口流动次数为在应用程序和网络接口硬件之间流动次数的三倍。数据在应用程序和内核主存缓冲区之间的拷贝需要每次数据写入后进行读取，这就需要通过两次内存接口，在网络硬件对内核主存直接读或写时又需要通过一次内存接口。

在传送数据的过程中可以通过使用新的存储管理技术来减少缓存数据的副本的次数，但这在接收数据的过程中并不十分有效。传统的系统内存大约需要375Mbps的带宽从而能够在一个单一的千兆比特接口进行数据接收。对于10千兆比特的以太网来说，带宽的数量跃迁至3.75Gbps。

3.5 复制回避，TCP减负引擎的缓冲处理器

TCP减负引擎的设备一般都能够解析和删除接收到的数据的TCP、IP报头信息，然后再把处理过的数据传递给主机，这样一来就免去了把接收到的数据分期存储在内核主存之中。如果TCP减负引擎有自己足够的缓冲，它可以在应用程序未提供接收缓冲区之前先把接收到的数据缓冲到自己的缓冲区中，当应用程序的缓冲区可用时再把数据传递过去。同样，由应用程序传输的数据可以被直接复制到TCP减负引擎的发送缓冲区之中，而不是在内核缓冲区之中进行处理。任何数据重传以后都将由TCP减负引擎的缓冲区提供服务。

值得一提的是，这一技术并没有从网络数据流中移除内存拷贝，仅仅是把它们迁移到TCP减负引擎的内存子系统之中，但这仍然是一个胜利。我们知道实现一个小而高效的专为TCP/IP通信使用的内存子系统是简单易行的，因为这并不需要提高整个计算平台的内存性能。但是TCP减负引擎缓冲区内存的性能和尺寸有什么要求呢？

数据在从网络或主机移动到TCP减负引擎的过程中会通过TCP减负引擎内存接口一次，当从TCP减负引擎移出传向网络或主机时又会通过内存接口一次。这就需要达到两倍的带宽，而没有TCP减负引擎就需要达到三倍的带宽。为了支持刚才所描述的复制避免技术，TCP减负引擎所需要的内存大小应该和其支持的套接字的数量以及每一个套接字需要缓冲的数据量的多少成正比。如果我们假设一个最大接收窗口大小为每套接字64KB，那么就需要1MB大小的TCP减负引擎缓冲区用来接收每16个减负的套接字的流入数据。在这里可以使用各种技术来降低对内存的要求，例如可以在TCP减负引擎缓冲区内存用尽时丢弃数据包，或者把这些数据传递给用传统TCP/IP协议栈处理数据的软件。同样，天下没有免费的午餐，这两种技术都会导致在高负载情况下性能的降低，而这正是TCP减负引擎最需要的支持。

3.6 复制回避：直接数据替换

虽然使用TCP减负引擎缓冲区能明显提高TCP在千兆比特速率下的性能，但内存大小的要求可能会成为实现10千兆比特速率的限制条件。这是由于TCP流量控制机制的特征所造成的。为了维持一个稳定的数据流，接收器必须不断调整接收窗口的大小使得发送方能够持续不断的传送数据并且在等待确认之前所发送的数据。为实现吞吐量最大化，窗口大小的设计要求取决于多少数据可以在网络自身中被缓存，也间接取决于网络带宽和网络往返时间。如果不打算深入理解，很显然对于10千兆比特的链路而言它10倍于千兆比特的链路。由于高速带宽的延迟，如果TCP减负引擎能够支持最大吞吐量，运行在10千兆比特链路上的TCP减负引擎需要10倍于运行在千兆比特链路上的TCP减负引擎。

如果我们确信TCP减负引擎能够始终把数据直接放置到应用程序缓存之中的话，TCP减负引擎缓存的大小可以大大减少。这种能力通常称为直接数据放置。直接数据放置的好处在诸如光纤通信和SCSI存储硬件方面得到了很好的体现，SCSI适配器在最小的CPU利用率和最小缓存条件下一般吞吐量能接近3Gbps。

由于应用程序使用的套接字应用程序接口的特点，直接数据放置在TCP/IP之上的网络应用程序中实现比较困难。一个在TCP/IP之上实现了直接数据放置的协议是iSCSI，该协议在TCP/IP之上传输SCSI存储协议。iSCSI的好处在于存储应用程序一般不需要使用套接字应用程序接口，也不需要在从网络接收数据之前提供缓存。iSCSI协议使用标记来显示收到的数据的精确存放位置，同时也可以限制使用TCP/IP协议之外数据的机制。

这对于iSCSI和基于TCP/IP的存储有很大好处，但对于其他应用程序呢？行业正在努力制定广泛、可行的标准机制来实现TCP/IP之上的直接数据放置，其中RDMA联盟和IETF的RDDP工作组做出了重要的贡献。这些成果都是定义在TCP/IP之上运作的额外的协议层中，同时提供标记来表明数据应该存放在何处以及协助TCP乱序数据的处理。套接字直接协议就是一个不错的成果，它定义了一种机制使得套接字应用程序能够在网络传输中利用新的直接数据放置的特征。

许多TCP减负引擎的硬件设计已经加入了iSCSI的支持。尽管其中增加了门电路设计的复杂性，性能方面的好处却是显而易见，市场的需求也对iSCSI极其有利。当一般的直接数据放置机制例如RDMA被接受时，使用一个TCP减负引擎支持该协议很可能是一个长期渐进的过程，也需要iSCSI协议的支持。

3.7 积分与现有TCP/IP软件

TCP减负引擎设备在不久的将来不可能完全取代TCP/IP在软件方面的实现，这不符合成本效益。相反，通过把一些软件无法高效解决的特定的网络任务和数据流减负，TCP减负引擎能够对软件方面的实现进行补充。这对于TCP减负引擎的部署是一个关键的挑战，如何把TCP减负引擎和现有的软件实现整合起来为用户提供连续的服务，同时也继续为诸如链路聚合，虚拟局域网，负载平衡和故障转移，网络接口的转发流量这些网络特点提供服务。

操作系统的设计一般提供稳定的在网络驱动接口中TCP/IP之下的记录接口，在TCP/IP上层提供套接字接口，但这些都不属于TCP/IP实现的核心。在开源平台上，TCP/IP的内部是可以自由进出的，但在TCP减负引擎设备该如何集成还没有达成共识。正因为如此，TCP减负引擎的厂商仅仅提供支持他们自己设备的方法，导致来自两个不同厂商的设备在同一个开源平台上无法进行交互运行。对专有平台，提供全功能的TCP/IP减负很难得到操作系统厂商的明确支持。但有迹象表明，越来越多的支持开始出现，例如微软就提议在windows平台上支持TCP减负引擎。

4.确保TCP/IP的优势

TCP减负技术的实施涉及到重大挑战，从芯片设计，协议的实施和软件集成方面都存在挑战。成功的实现TCP减负有可能确保TCP/IP在网络世界中为已存在的应用程序和新应用程序和以太网硬件提供更好的性能。

TCP offload to the resuce 让TCP减负来挽救我们相关推荐

tcp报文格式_面试必备TCP(一)：三次握手
TCP大家都知道是什么东西,这个协议的具体报文格式如下: 标志位 URG:指示报文中有紧急数据,应尽快传送(相当于高优先级的数据). PSH:为1表示是带有push标志的数据,指示接收方在接收到该报文 ...
linux tcp窗口大小设置,高性能Linux：TCP/IP内核参数调优之TCP窗口扩大因子(TCP Window Scaling)选项(理论篇)...
TCP报文窗口字段介绍在TCP报文头部,有一个16比特的窗口字段,用来表示接受方的缓冲区大小,发送方可以根据这个值的大小来调节发送的数据量,从而起到流控的目的. TCP的流量控制由连接的每一端通过声 ...
5.3 计算机网络传输层之TCP协议（tcp协议特点、tcp报文段首部格式、tcp连接---三次握手、tcp连接释放---四次握手）
文章目录 1.TCP协议特点 2.TCP报文段的首部格式 3.TCP连接管理 (1)连接的建立 - - - 三次握手 (2)SYN泛洪攻击 4.TCP连接释放----四次握手 5.TCP连接建立和释放 ...
TCP/IP协议（二）tcp/ip基础知识
转载:http://www.cnblogs.com/imyalost/p/6139191.html 一.TCP/IP的标准化 1.TCP/IP的含义一般来说,TCP/IP是利用IP进行通信时所必须用 ...
TCP/IP（四）：TCP 与 UDP 协议简介
从本章开始,我们开始介绍最重要的传输层.传输层位于 OSI 七层模型的第四层(由下往上).顾名思义,传输层的主要作用是实现应用程序之间的通信.网络层主要是保证不同数据链路下数据的可达性,至于如何传输数 ...
TCP/IP网络编程之基于TCP的服务端/客户端（二）
回声客户端问题上一章TCP/IP网络编程之基于TCP的服务端/客户端(一)中,我们解释了回声客户端所存在的问题,那么单单是客户端的问题,服务端没有任何问题?是的,服务端没有问题,现在先让我们回顾下服 ...
tcp网络通信教程 java_基于java TCP网络通信的实例详解
JAVA中设计网络编程模式的主要有TCP和UDP两种,TCP是属于即时通信,UDP是通过数据包来进行通信,UDP当中就会牵扯到数据的解析和传送.在安全性能方面,TCP要略胜一筹,通信过程中不容易出现数 ...
TCP/IP文档阅读笔记-TCP Receive Window
TCP Receive Window TCP接收窗口,TCP接收数据到缓冲,应用程序还未处理的那块数据. TCP Receive Window大小,在TCP三次握手时就已经商量好了.并且还确定了数据包 ...
TCP/IP的初步理解，TCP和UDP的区别
1.什么是TCP/IP协议 TCP/IP协议是一个协议簇.里面包括很多协议的.UDP只是其中的一个.之所以命名为TCP/IP协议,因为TCP,IP协议是两个很重要的协议,就用他俩命名了. TCP/IP ...
java tcp demo_详解Java使用TCP实现数据传输实例
这篇文章主要介绍了Java使用TCP实现数据传输实例详解的相关资料,需要的朋友可以参考下 Java使用TCP实现数据传输实例详解 TCP所提供服务的主要特点: 1．面向连接的传输: 2．端到端的通信: ...

TCP offload to the resuce 让TCP减负来挽救我们