PDFTCP 卸载技术解围
Andy Currid，iReady
初步了解 TCP 卸载引擎——以及我们为什么需要它们
近年来，TCP/IP 卸载引擎（TOE）引起了业界的广泛关注，并获得了大量的风险投资。TOE 是一种专门的网络设备，它在硬件中实现了 TCP/IP 协议的很大一部分，从而将 TCP/IP 处理从通用 CPU 上运行的软件中卸载出来。本文探讨了业界对 TOE 产生兴趣的原因，并研究了 TOE 在实施和部署方面所面临的挑战。
对 TCP/IP 卸载的需求
TCP 和 IP 都是独立于硬件的网络通信协议，由 IETF（互联网工程任务组）定义。1 TCP/IP 是互联网上信息交换的主要协议套件；因此，在 TCP/IP 上运行的网络应用程序的性能和效率备受关注。要理解 TCP/IP 卸载背后的动机，重要的是要认识到 TCP/IP 作为一个元素存在于由许多其他元素组成的网络基础设施中。例如：
• 网络互连，如铜缆、光纤和无线链路。
• 网络节点内的 CPU、内存和网络接口硬件。
• 在这些节点上运行的操作系统和应用程序软件。
所有这些元素都可能对应用程序在 TCP/IP 上的运行方式产生重大影响，而与 TCP/IP 本身无关。
网络容量：供需关系
让我们首先看看 TCP/IP 运行的网络容量。局域网主要使用以太网实现，以太网经历了稳步增长，从 1990 年的 10 Mbps（兆比特每秒），到 1990 年代中期的 100 Mbps，再到今天的 1 Gbps（千兆比特每秒）。10 Gbps 以太网的规范已于 2002 年获得批准，但该技术尚未实现广泛部署。
对于每次速度升级，广泛部署都滞后于最初的推出几年。千兆以太网于 1998 年推出，但在过去一两年才实现广泛部署。并非巧合的是，这段时期价格大幅下降；千兆以太网 NIC（网络接口卡）的典型价格已从推出时的约 500 美元降至今天的几十美元。
对网络带宽的需求也在增加。虽然办公室桌面机器尚不需要千兆带宽，但即使是中等规模的组织也发现，集中式文件、Web 和数据库服务器需要千兆连接才能为客户端提供及时的响应。中档和企业级服务器通常支持多个千兆接口。挑战在于如何在充分利用这些接口容量的同时，仍然提供足够的计算能力来运行服务器应用程序——而且价格不能过高。
CPU 功率的提升：收益递减？
运行 TCP/IP 协议软件的 CPU 处理能力也随着时间的推移而提高。自英特尔奔腾系列 CPU 推出以来，典型的 CPU 时钟速度已从 60 MHz（兆赫兹）提高到约 3 GHz（千兆赫兹），增长了约 5000%。
处理能力的增长似乎与网络容量的增长相匹配，但依赖 TCP/IP 网络的应用程序的需求增长速度同样快，甚至更快。此外，研究表明，随着 CPU 速度的提高，它们驱动 TCP/IP 流量的能力增长速度较慢。
图 1 说明了这种非线性关系。使用 800 MHz 和 2.4 GHz CPU 在其他硬件配置完全相同的情况下，测量了不同传输大小下的 TCP 吞吐量和主机 CPU 利用率。相对成本计算如下：
相对成本 = (CPU 利用率 % * CPU 速度，单位 MHz) / 吞吐量，单位 Mbps
目的是显示每兆比特网络吞吐量需要多少计算能力。（数字越大表示每兆比特的成本越高）。虽然 2.4 GHz CPU 在绝对吞吐量方面始终与 800 MHz CPU 持平或优于后者，但其性能并没有随着时钟速度的三倍提升而线性扩展。在所有情况下，速度更快的 CPU 每兆比特吞吐量的相对 CPU 成本都更高，在某些情况下甚至超过 800 MHz 时的两倍。
随着 CPU 速度的提高，收益递减的主要原因是 CPU 性能与内存和 I/O 子系统的性能之间的差距。2 随着 CPU 速度的提高，内存和 I/O 速度也随之提高，但速度要慢得多。结果，更多的 CPU 周期花费在等待内存访问完成上；这些停顿周期直接表现为 CPU 利用率。由于我们在后面将详细探讨的原因，传统的 TCP/IP 处理是内存密集型的，因此它对这种效应特别敏感。
在一定程度上，内存性能的不足可以通过使用更高性能的内存缓存层次结构来隐藏内存延迟，以及通过使用硬件多线程等技术来弥补，硬件多线程允许在停顿线程的内存访问完成时运行备用执行线程。然而，扩展缓存内存以满足性能要求的成本效益并不高，特别是对于网络应用程序而言，这些应用程序不断地处理数据，而不是迭代相同的数据集。
硬件多线程仅在多个执行线程准备好工作时才能提供性能提升，这在很大程度上取决于应用程序的性质。例如，硬件多线程可能为支持大量相对低带宽客户端的网络应用程序提供一些好处，这些应用程序使用线程池（Web 服务器、数据库服务器）。相反，它在通过相应少量线程支持少量高带宽客户端的应用程序（块存储和集群应用程序）中几乎没有好处。
新的应用
千兆以太网硬件的普遍性、高性能和低成本使其对传统上使用专用（且相应昂贵）非以太网硬件的应用具有吸引力。SAN（存储区域网络）在服务器和存储系统之间传输块存储流量，传统上是使用光纤通道结构上的 SCSI 协议实现的。iSCSI 规范定义了一种通过 TCP/IP 路由相同 SCSI 协议的方法。类似地，在 TCP/IP 上运行的 RDMA（远程直接内存访问）技术有望提供与当前使用专有消息传递协议和互连硬件实现的性能相当的基于集群的消息传递和 I/O 性能。
这些应用程序的一个共同因素是，现有技术（光纤通道、专有集群硬件）以极低的 CPU 开销实现了非常高的性能。性能较低的基于 TCP/IP 的替代方案可能足以满足某些 SAN 和集群应用程序的需求，但为了直接替代现有技术，基于 TCP/IP 的替代方案将需要 TCP 卸载。
万兆以太网
万兆以太网提供的 10 倍性能提升使其对存储网络和集群服务器互连等要求苛刻的应用具有吸引力。目前，万兆以太网尚未得到广泛采用，部分原因是万兆网卡和网络基础设施设备的价格昂贵。即使万兆设备更便宜，使用传统 CPU 和内存技术以万兆速率驱动 TCP 流量仍然非常昂贵。内存性能瓶颈在千兆速率下已经很麻烦，但在万兆速率下有可能成为瓶颈。TCP/IP 卸载为解决这个问题提供了一条可行的途径，尽管从长远来看，解决方案可能需要进行相当大的改变，而不仅仅是简单地卸载 TCP/IP 协议套件。
实施 TCP/IP 卸载的挑战
显然，在某些应用中，TCP/IP 卸载非常有意义，而在另一些应用中，它似乎是强制性的。为了将 TCP/IP 卸载技术推向市场，需要克服哪些关键挑战？
实施成本
虽然可以将实施成本视为营销问题（我们是工程师，对吧？），但这会忽略开发通用网络技术，特别是 TCP/IP 卸载技术的关键方面之一。毕竟，以太网技术的巨大成功主要归功于其硬件成本相对较低且易于部署。为了普及，TOE 必须提供传统 CPU 无法提供的解决方案，或者只能以更高的成本提供的解决方案。
那么，哪些因素决定了 TOE 的成本？设计的门数是设计整体复杂性的函数，它在总体成本中起着很大的作用，因为它决定了硅芯片的尺寸。芯片尺寸以及设计所需的 I/O 引脚数量决定了硅芯片所需的物理封装尺寸。封装尺寸以及任何必需的外部支持芯片，如内存或以太网物理接口组件，决定了容纳 TOE 需要多少电路板空间。
这些因素中的两个——设计复杂性和外部内存需求——使 TOE 与现有的以太网设备区分开来。为了更好地理解这些，让我们更详细地了解 TCP/IP 及其环境。
TCP 的性质
TCP 旨在在本质上不可靠的网络上提供可靠的数据传输。TCP 使用的功能在软件中实现起来比较复杂，在硬件中实现起来则更复杂——与光纤通道等协议相比尤其如此，光纤通道旨在在可靠的网络上运行，并考虑到硬件实现。对 TCP 功能的详尽论述超出了本文的范围；以下内容旨在说明 TCP 卸载的一些实现挑战。
TCP 中的数据流通过连接进行管理，这些连接在两个对等端点之间提供双向字节流通信。端点通过 32 位序列号来维护字节流中的同步，该序列号按每个传输的字节递增。每个端点通过在其发送给对等端点的每个数据包中包含最后成功接收的字节的序列号来肯定地确认接收到的数据。
接收端的流控制是通过滑动接收窗口实现的。这是一个字节计数，表示端点准备好从对等端点接收多少数据，它包含在对等端点之间传输的每个数据包中。接收窗口随着数据传输到对等端点而收缩（“关闭”），并随着对等端点消耗该数据而扩展（“打开”）。如果端点消耗数据的速度足够慢，接收窗口可能会缩小到零，在这种情况下，在对等端点消耗数据并重新打开窗口之前，其对等端点无法传输更多数据。具有要发送的数据但遇到零窗口的发送端会定期通过窗口探测数据包测试窗口是否再次打开。
除了对等端点可能发生的错误外，TCP 还必须应对中间网络因拥塞或错误条件而丢弃的数据包。为此，它结合了两种机制来检测数据包何时被丢弃并需要重新传输：未能在特定超时时间内收到确认，或收到同一数据的多个确认。当重新传输数据时，TCP 对连续的重新传输使用退避算法，最终在几分钟后放弃。
用于触发重新传输的确认超时基于 TCP 为每个活动连接维护的动态计算的 RTT（往返时间）估计。除了检测丢弃的数据包外，TCP 还包含流量控制机制——慢启动和拥塞窗口机制——当检测到数据包被丢弃时，这些机制动态地限制发送端向网络发送数据的速率。
随着网络数据速率的提高，TCP 的基本确认和重新传输机制已被证明效率有些低下；单个数据包的丢失可能会导致重新传输许多数据包。为了解决这个问题，引入了可选机制：时间戳选项允许更精确地估计 RTT，而 SACK（选择性确认）选项为数据重新传输提供了更精细的粒度。
所描述的 TCP 功能需要大量的门电路复杂性才能在硅芯片中实现。TOE 设计的一个关键挑战是确定在硬件中实现哪些 TCP 功能以实现高性能，以及哪些可以保留在软件中——以降低设计复杂性并确保安全，防止拒绝服务。（TOE 实现的安全性本身就是一个主题，超出了本文的范围。）
除了实现各种定时器、计数器和算法所需的逻辑复杂性外，TOE 还必须维护每个卸载连接的相关状态信息。此状态信息通常每个连接约 256 字节，因此旨在支持 64,000 个并发连接的 TOE 需要维护约 16 MB 的连接状态信息。
关键在于软件，笨蛋！
或者应该说是，关键在于笨拙的软件？软件虽然肯定不笨拙，但与硬件相比，变化速度相对较慢。这似乎有悖常理，因为更新软件通常比开发新硬件更容易。实际上，软件形成了一个复杂的层次结构，从 OS 内核和硬件设备接口的最低层，到内核服务（如 TCP/IP），再到用户空间应用程序（如 Web 和数据库服务器）。此层次结构中的每一层都通过 API（应用程序编程接口）将其自身抽象到上一层。这些 API 随着时间的推移保持相对稳定，尤其是在用户空间应用程序层，这使得软件开发更容易且更具成本效益。
图 2 显示了传统系统中发现的网络软件层次结构的简化视图。关键点包括应用程序用于访问操作系统网络设施的套接字 API，以及将特定硬件驱动程序链接到 OS 网络堆栈的网络硬件设备驱动程序接口。
套接字 API：没有免费的午餐
套接字 API（也称为套接字）起源于加州大学伯克利分校的 Unix 软件发行版；套接字 API 的衍生版本包含在今天销售的所有重要操作系统中，并且大多数网络应用程序都是使用此 API 编写的。套接字易于使用，从应用程序中隐藏了底层网络堆栈的许多方面，但这种易用性是有代价的。
当接收数据时，基于套接字的应用程序无需考虑从网络到达的数据包附带的 TCP 和 IP 标头。在传统堆栈中，这是通过在内核缓冲区中暂存接收到的数据，并将仅数据有效负载复制到应用程序缓冲区来实现的。内核接收缓冲区还支持套接字的另一个方便功能：应用程序无需在从网络接收数据之前提供接收缓冲区来保存入站数据。如果数据在应用程序提供接收缓冲区之前到达，则会在内核中缓冲，并在应用程序最终提供接收缓冲区时复制到应用程序缓冲区。
类似地，当传输数据时，应用程序无需等待远程对等端确认数据，即可丢弃其自己的本地副本。当从应用程序接受用于传输的数据时，内核会立即将数据复制到内核缓冲区中，数据保留在内核缓冲区中以供重新传输，直到对等端确认。
这些功能通常会导致数据在应用程序和网络接口硬件之间移动时，三次跨越主机内存接口。应用程序和内核内存缓冲区之间的数据复制需要一次读取，然后是一次写入（两次内存接口跨越），而网络硬件对内核内存的直接读取或写入访问会导致另一次内存接口跨越。
可以使用新颖的内存管理技术来减少传输数据路径上的缓冲区复制，但这些技术在接收数据路径上效果不佳。因此，传统系统仅支持单个千兆接口上的数据接收就需要约 375 Mbps 的内存带宽。对于万兆以太网，此数字跃升至 3.75 Gbps。
避免复制：TOE 缓冲区内存
TOE 设备通常能够解析和删除入站数据中的 TCP 和 IP 标头，然后再将数据传递给主机，这消除了在内核内存中暂存接收到的数据的原因之一。如果 TOE 具有足够的自身缓冲区内存，则可以在应用程序尚未提供接收缓冲区的情况下缓冲入站数据，并在接收缓冲区可用时将数据直接传输到应用程序缓冲区。类似地，应用程序传输的数据可以直接复制到 TOE 上的传输缓冲区，而不是暂存在内核缓冲区中。然后，任何数据重新传输都将从 TOE 的缓冲区中提供服务。（在这两种情况下，都假设应用程序的缓冲区可以锁定在内存中，以防止在 TOE 访问它们时被修改。）
值得注意的是，此技术不会从网络数据流中删除内存复制——它只是将它们重新定位到 TOE 的内存子系统。这仍然是一个胜利；为 TCP/IP 流量专门实施小型、高性能内存子系统通常比提高整个计算平台的内存性能更便宜。但是，TOE 缓冲区内存的性能和大小要求是什么？
数据从网络或主机移动到 TOE 中时，会跨越 TOE 的内存接口一次，而当数据从 TOE 中移出，目的地是网络或主机时，会再次跨越 TOE 的内存接口一次。与没有 TOE 的主机内存上看到的 3 倍要求相比，这导致了 2 倍的带宽要求。为了支持刚才描述的避免复制技术，所需的 TOE 内存大小与要支持的活动套接字数量以及每个套接字可能需要缓冲的数据量成正比。如果我们假设每个套接字的最大接收窗口大小为 64 KB，那么每支持 16 个卸载套接字的入站数据就需要 1 MB 的 TOE 缓冲区内存。可以使用各种技术来降低此内存需求，例如在 TOE 耗尽缓冲区内存时丢弃数据包，或将这些数据包转发到软件 TCP/IP 堆栈进行传统处理。同样，没有免费的午餐——这两种技术都会导致在高负载条件下的性能下降，而这恰恰是最需要 TOE 支持的地方。
避免复制：直接数据放置
虽然很明显，使用 TOE 缓冲区内存可以提高千兆速率下的 TCP 性能，但内存大小要求在万兆速率下可能会变得过高。这是由于 TCP 流控制机制的性质造成的。为了保持稳定的数据流，接收端必须通告足够大的接收窗口，以允许发送端在仍在等待先前发送数据的确认时不断传输数据。实现最大吞吐量所需的窗口大小是网络本身可以缓冲多少数据的函数——这反过来又是网络带宽和网络往返时间（网络的带宽-延迟乘积）的乘积的函数。在不赘述细节的情况下，很明显，对于万兆链路，此乘积是千兆链路的 10 倍。由于带宽-延迟乘积较高，如果 TOE 要支持最大吞吐量，则在万兆链路上的 TOE 设计将需要千兆链路上的相同 TOE 设计的 10 倍内存。
如果我们能够确保 TOE 始终可以将数据直接放置到应用程序缓冲区中，则可以大大减少对 TOE 缓冲区内存的需求。此功能通常称为 DDP（直接数据放置）。DDP 的好处已通过其在现有技术（如光纤通道和 SCSI 存储硬件）中的使用而得到充分理解；SCSI 适配器通常以接近 3 Gbps 的吞吐量实现，CPU 利用率极低，适配器上的缓冲区内存也极少。
使用 TCP/IP 的网络应用程序更难实现 DDP（例如，数据可能会乱序到达），因为应用程序使用的套接字 API 的性质。一种确实在 TCP/IP 上实现 DDP 的协议是 iSCSI，它通过 TCP/IP 传输 SCSI 存储协议。iSCSI 受益于存储应用程序通常不使用套接字 API，并且需要为从网络接收到的所有数据提前提供缓冲区这一事实。iSCSI 协议使用标签来指示应将接收到的数据放置在何处；iSCSI 还具有限制处理乱序 TCP/IP 数据的开销的机制。3
这对 iSCSI 和基于 TCP/IP 的存储来说很棒，但对于其他应用程序呢？目前，业界正在付出大量努力来定义广泛适用、标准化的机制，以实现基于 TCP/IP 的 DDP，特别是 RDMA 联盟4 和 IETF 的 RDDP 工作组5 的努力。这两项努力都在定义在 TCP/IP 之上运行的附加协议层，以提供指示应将数据放置在何处的标签，并协助处理乱序 TCP 数据。SDP（套接字直接协议）是一项并行工作，它定义了允许套接字应用程序利用网络传输中新的 DDP 功能的机制。
许多 TOE 硬件设计已经集成了对 iSCSI 的支持。虽然它增加了设计的门电路复杂性，但性能优势显而易见，并且市场对 iSCSI 的需求似乎良好。当通用 DDP 机制（如 RDMA）被接受时，在 TOE 中支持它们可能是从支持 iSCSI 协议所需的工作量中递增的工作量。
与现有 TCP/IP 软件的集成
TOE 设备在不久的将来不太可能完全取代软件 TCP/IP 实现——这样做不具成本效益。相反，TOE 设备将通过卸载软件无法有效处理的特定网络任务和数据流来补充软件实现。这就给 TOE 部署带来了一个关键挑战：如何将 TOE 操作与现有软件实现的操作集成，以为用户提供持续的体验，并继续支持诸如链路聚合、VLAN（虚拟 LAN）、负载平衡和故障转移以及网络接口之间流量转发等网络功能。
OS 设计通常在网络驱动程序接口的 TCP/IP 下方和套接字接口的 TCP/IP 上方提供稳定、文档化的接口，但在 TCP/IP 实现的核心内则不提供。在开源平台上，TCP/IP 内部结构可以自由访问，但对于应如何集成 TOE 设备尚未达成共识。因此，TOE 供应商遵循临时方法来支持其设备，结果是目前两家不同供应商的 TOE 设备在同一开源平台内互操作的可能性很小。在专有平台上，如果没有 OS 供应商的明确支持，提供功能齐全的 TCP/IP 卸载极其困难。有迹象表明，这种支持正在开始出现。例如，微软已提出扩展以支持 Windows 平台上的 TOE 设备。6
确保 TCP/IP 的主导地位
TCP 卸载技术的实施涉及重大挑战，从硅芯片设计问题到协议实施和软件集成。TCP 卸载的成功实现可能会通过为现有应用程序提供更高的性能并为 TCP/IP 和以太网硬件启用新应用程序来确保 TCP/IP 在网络世界中的持续主导地位。
参考文献
1. 互联网工程任务组 RFC（征求意见稿）：请参阅 http://www.ietf.org/rfc.html。该站点定义了 TCP/IP 和相关协议。如果您不喜欢阅读标准文档，以下书籍是一本极好的参考书：Stevens, W. R. TCP/IP Illustrated, Volume 1. Addison-Wesley, Boston: MA, 1994。
2. Foong, A. P., Huff, T. R., Hum, H. H., Patwardhan, J. P., and Regnier, G. J. TCP Performance Re-Visited; http://www.cs.duke.edu/~jaidev/papers/ispass03.pdf。（提供了对 TCP 性能瓶颈的定量分析，包括 CPU 和内存子系统因素。）
3. IETF IPS（IP 存储）工作组：请参阅 http://www.ietf.org/html.charters/ips-charter.html。IPS 工作组的任务是定义协议，以将现有存储协议（如 SCSI 和光纤通道）封装在基于 IP 的传输之上。工作组的显著成果包括 iSCSI、iFCP（互联网光纤通道协议）和相关的互联网草案，以及 FCIP（基于 IP 的光纤通道），RFC 3643。
4. RDMA（远程直接内存访问）联盟：请参阅 http://www.rdmaconsortium.org。该行业合作组织已发布了基于 TCP/IP 的 RDMA (DDP) 规范；SDP（套接字直接协议），它使套接字应用程序能够利用 DDP 传输；以及用于 RDMA 的 iSCSI 扩展 (iSER)。
5. RDDP（远程直接数据放置）工作组：请参阅 http://www.ietf.org/html.charters/rddp-charter.html。该小组的任务是定义一套协议，使远程直接数据放置能够在任意网络传输上进行，其中 SCTP 和 TCP 是主要关注点。
6. 有关微软提出的用于 TCP 卸载的 Chimney 架构的详细信息，大部分是在保密协议下发布的，但在 Google 搜索 (http://www.google.com/) “Microsoft Chimney” 将会找到大量关于该架构的二手信息。
喜欢它，讨厌它？请告诉我们
[email protected] 或 www.acmqueue.com/forums
ANDY CURRID 是 iReady 公司的首席软件架构师，他在该公司专注于 iReady 的 TCP/IP 和 iSCSI 卸载设备的软件支持。他在软件行业拥有超过 12 年的经验，包括在 Wind River、Tadpole Techology 和 Fujitsu-ICL 担任工程、管理和技术专家职位。Andy 在华威大学获得了计算机科学学士学位。
© 2004 1542-7730/04/0500 $5.00
最初发表于 Queue vol. 2, no. 3—
在 数字图书馆 中评论本文
更多相关文章
David Collier-Brown - 你根本不懂带宽
当您的员工或客户说他们的互联网性能很糟糕时，带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 的带宽，问题就变成了延迟，即 ISP 的路由器处理他们的流量需要多长时间。如果您是 ISP 并且所有客户都讨厌您，请鼓起勇气。这现在是一个可以解决的问题，这要归功于一群执着的人，他们找到了这个问题，解决了它，然后在家庭路由器中验证了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和非信任安装程序模型的设备载入
设备的自动载入是处理越来越多的正在安装的“边缘”和 IoT 设备的重要技术。设备的载入与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动载入加快流程，必须在设备中正式确定供应链中的信任关系，以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪进行分布式延迟分析
低延迟是许多 Google 应用程序（如搜索）的重要特性，延迟分析工具在维持大规模低延迟方面起着至关重要的作用。对于不断发展功能和数据的复杂分布式系统，将总体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实世界的分布式系统中，现有的工具（如 RPC 遥测、CPU 性能分析和分布式跟踪）对于理解整个系统的子组件非常有价值，但在实践中不足以执行端到端延迟分析。
David Crawshaw - 一切 VPN 焕然一新
VPN（虚拟专用网络）已有 24 年的历史。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也在不断变化。VPN 在 2000 年代的互联网中经历了一个尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，而这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。
© 保留所有权利。