TCP - LRO/TSO 技术
为什么所有涉及的接口（路由器和网桥）都必须支持LRO/TSO技术？
Why is it must that all interfaces (routers and bridges) involved support LRO/TSO technique ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
路由器没有。桥梁可以。
外部路由器、集线器、交换机或任何其他外部连接到网络的设备都不会受到 TSO 的影响，只有具有 TSO 的设备内部的接口才会受到任何影响 - 这是一个软件问题。
路由器是一种通过以太网电缆、光纤电缆、无线通信等连接到网络的外部设备。这些通信介质遵循国际标准，例如以太网 803.2 或无线 803.11 - 它们是硬件设备，也是硬件设备对他们的沟通方式有非常严格的规定。
桥是一种内部软件构造，特定于您的操作系统。
让我们以 803.2（以太网）和 Linux 主机为例。
应用程序调用创建套接字，然后将大数据块推送到套接字中。 Linux 内核决定该数据应在哪个接口上传输。接下来，内核将询问该接口的驱动程序以确定其功能，如果该接口支持 TSO，则内核会将带有单个“模板”标头和大量数据（超过 1 个数据包）的 sk_buff 传递给该接口司机。
让我们首先考虑直接连接到硬件 NIC 的标准接口：
有些接口具有假 TSO（它们在驱动程序中对数据包进行分段），有些具有真正的 TSO（模板标头和数据通过以下方式传递到硬件）：最小的改动）。此时，驱动程序或 NIC 硬件会将这一大段数据转换为多个符合标准的 803.2 以太网帧，外部设备（例如路由器、集线器、交换机、调制解调器或其他主机）正是这些符合标准的帧将在电线上看到。
现在让我们考虑软件桥后面的多个 NIC：
尽管内核在较低级别上了解每个 NIC，但网络堆栈仅了解新娘，因此仅了解所有底层 NIC 都具有的功能应该传到桥上。如果将 sk_buff 传递到网桥，则网桥中的所有接口都将收到相同的 sk_buff。我们假设内核再次将我们的大 TSO sk_buff 传递到桥接器，如果任何底层接口不支持 TSO，则数据包很可能会被相关硬件 NIC 丢弃。
总结：
最坏的情况是桥接器将在损坏的接口上重复重试发送相同的数据块，并且整个桥接器将锁定，直到应用程序决定放弃。最好的情况是，非 TSO NIC 看起来就像已失效。
也就是说，如果 NIC 的驱动程序中存在不安全代码，则可能会导致分段错误，从而导致整个系统瘫痪。
Routers don't. Bridges do.
External routers, hubs, switches or anything else that is externally connected to the network will not see the effects of TSO, only interfaces inside the device with TSO will experience any effects - it's a software thing.
A router is an external device which is connected to the network by ethernet cables, fibre optic cables, wireless comms etc. These communication mediums adhere to internation standards such as 803.2 for ethernet or 803.11 for wireless - they're hardware devices, and hardware devices have very strict rules on how they communicate.
A bridge is an internal software construct and is specific to your OS.
Let's use 803.2 (ethernet) and a linux host for an example.
An application calls for a socket to be created and then pushes a large data chunk into the socket. The linux kernel determines which interface this data should be transitted on. The kernel will next interrogate the driver for this interface to determine its capabilities, if the interface is TSO capable the kernel will pass an sk_buff with a single "template" header and a huge chunk of data (more than 1 packets worth) to the interface driver.
Let's consider a standard interface straight to a hardware NIC first:
Some interfaces have fake TSO (they segment the packet in the driver) and some have true TSO (the template header and data are passed to the hardware with minimal alterations). At this point ether the driver or the NIC hardware will convert this large segment of data into multiple, standard compliant, 803.2 ethernet frames, it is these compliant frames that an external device, such as a router, hub, switch, modem or other host will see on the wire.
Now let's consider several NICs behind a software bridge:
Although the kernel is aware of each NIC at a low level, the network stack is only aware of the bride, thus only capabilities that ALL of the underlying NICs have should be passed up to the bridge. If an sk_buff is passed to a bridge, then ALL the interfaces in the bridge will receive the same sk_buff. We'll assume that the kernal has once again passed our large TSO sk_buff to a bridge, if any of the underlying interfaces does not support TSO then the packet will most likely be dropped by the hardware NIC in question.
In summary:
Worst case scenario is the bridge will repeatedly retry to send the same data chunk on the broken interface and the whole bridge will lock up until the application decides to give up. Best case scenario, the non TSO NIC will simply appear to be dead.
That said, if the NIC has unsafe code in its driver then this could cause a segmentation fault that could bring the whole system down.