tcp减压引擎，第一次听说这个名词，但是并不是一个新的概念了，若干年前听说过设备厂商在研究在fpga之中实现tcp stack，但是后来没有听到任何的产品出来，应该是路由设备to host的traffic不多，而对于fw设备，中间的tcp proxy实现过于复杂，工程上不可能实现。
现在的所谓toe实现我理解主要用于host的interface之中，用于为gbits以及10gbits接口场景中为cpu减压，例如部署在数据中心内部的服务器，cpu虽然越来越快，但是对于汹涌澎湃的traffic来说，还是有些力不从心。
上面是toe应用前后协议栈的差别，我觉得画的有点绝对，tcp stack不太可能完全实现在interface之中，其实toe主要实现如下的offload：
1.tcp/ip checksum offload
cpu可以不用计算checksum而由网卡计算
2.cpu不用考虑数据的分段了，估计是直接将socket送过来的buf交给网卡。
如果是仅仅实现上述功能toe是很可能工程化实现的。
在另一篇文档中提到了toe的一些优势，但是我的分析，这个可能是要实现top替代整个tcp之后的优势。
1.减少中断：不用每个报文都产生中断，如果10g接口这个对于cpu是很大的开销。
2.减少memory拷贝次数，很多时候网卡的buffer和app的可以直接共享。
3.协议处理的节约，这个是当然的了。
显而易见toe有一些问题。
1.没有标准，导致协议栈实现困难，无法标准化的进行剪裁
2.硬件中实现，有bug怎么办？
我们知道，用tcp/ip协议处理网络流量，要占用大量服务器资源。为了减轻服务器的压力，一种称为tcp减负引擎（tcp offload engine ：toe）的技术应运而生。tcp减负引擎一般由软硬两部分组件构成，将传统的tip/ip协议栈的功能进行延伸，把网络数据流量的处理工作全部转到网卡上的集成硬件中进行，服务器只承担tcp/ip控制信息的处理任务。这种为服务器减轻负担的技术，得到了大多数厂商的肯定。
普通网卡用软件方式进行一系列tcp/ip相关操作，因此，会在三个方面增加服务器的负担，这三个方面是：数据复制、协议处理和中断处理。
网络上每个应用程序在收发大量数据包时，要引发大量的网络i/o中断，对这些i/o中断信号进行响应，成了服务器的沉重负担。比如，一个典型的 64kbps的应用程序在向网络发送数据时，为了将这些数据装配成以太网的数据包，并对网络接收确认信号进行响应，要在服务器和网卡间触发60多个中断事件，这么高的中断率和协议分析工作量已经是相当可观的了。虽然某些网络操作系统具有中断捆绑功能，能够有效减少中断信号的产生，但却无法减少服务器和网卡间响应事件的处理总量。
tcp减负引擎网卡的工作原理与普通网卡不同。普通网卡处理每个数据包都要触发一次中断，tcp 减负引擎网卡则让每个应用程序完成一次完整的数据处理进程后才触发一次中断，显著减轻服务器对中断的响应负担。还是以64kbps的应用程序为例，应用程序向网络发送数据全部完成后，才向服务器发送一个数据通道减负事件中断，数据包的处理工作由tcp减负引擎网卡来做，而不是由服务器来做，从而消除了过于频繁的中断事件对服务器的过度干扰。网络应用程序在收发数据时，经常是同一数据要复制多份，在这种情形下，tcp减负引擎网卡发挥的效益最明显。
普通网卡通过采用支持校验功能的硬件和某些软件，能够在一定程度上减少发送数据的复制量，但却无法减少接收数据的复制量。对大量接收数据进行复制通常要占用大量的机器工作周期。普通网卡先将接收到的数据在服务器的缓冲区中复制一份，经系统处理后分配给其中一个tcp连接，然后，系统再将这些数据与使用它的应用程序相关联，并将这些数据由系统缓冲区复制到应用程序的缓冲区。tcp减负引擎网卡在接收数据时，在网卡内进行协议处理，因此，它不必将数据复制到服务器缓冲区，而是直接复制到应用程序的缓冲区，这种“零拷贝”方式避免了网卡和服务器间的不必要的数据往复拷贝。
tcp减负引擎网卡能显著减轻由数据大量移动造成的服务器过载负担。实测证明，对于文件服务器和以内容服务为主的服务器应用环境来说，如果用tcp减负引擎网卡代替普通网卡，相当于为服务器增加了一个cpu