将双1 Gbit/s NIC连接起来，将吞吐量提高到2.5Gbit/s端口

Question

Linux能够将NIC连接在一起。这方面的有趣策略是循环，它在每个网卡之间交替发送数据包。

然而，性能的好处通常仅限于多个客户端。一个单一的1000BASE-T客户，尽管是从双1000 client，当然仍然是限制在1 Gbit/s。

2.5GBASE-T客户端呢？假设如下：

服务器(2x1G) <===> 开关编号:2.5G <-> 客户端:1x2.5G

服务器上的双NIC“条”将带宽加倍，交换机使用两个端口接收全部带宽，并切换到一个2.5G端口。

客户端能从服务器上下载~2 Gbit/s吗？如果是这样的话，这种情况需要比非托管交换机更“聪明”的东西吗？

谢谢!

Answer 1

对于单个流，从交换机到客户端的方向上的任何带宽增益都是极不可能的。

托管交换机通常根据802.3ad协议或静态连接支持端口绑定，哑(非托管)交换机根本不支持它。该信道支持冗余和更高的带宽，但有一个扭曲。通常使用所谓的散列策略选择特定端口，并且策略使用各种L2和L3 (有时还包括L4)字段计算哈希。在大多数情况下，对于特定的流，散列将保持不变--这意味着它的带宽受限于所选端口的带宽(BTW，对于802.3ad，所有端口都应该具有相同的速度)。对于更便宜的交换机(TP链接)，我见过基于L2或L3数据的哈希，更昂贵的(比如戴尔PowerConnect)也支持L4数据的哈希。

此外，这种通道是由对等点之间的某些数据交换动态形成的，这意味着这种信道与您提到的balance-rr模式不兼容。

因此，对于单个流来说，任何带宽增益都是极不可能的。通过使用多个流，您可能会看到一些增益，这取决于交换机使用的散列策略和配置的服务器(请参阅xmit_hash_policy获得可用的内容，您将需要包含L4信息的策略策略才能在两个特定主机之间获取任何信息)。

Answer 2

必须使用多个流.

除了Linux的键合驱动程序的循环模式和广播模式的特定例外，这两种模式都不会在您指定的场景中正确工作(下面将详细介绍)，所有的绑定模式都会将每个连接/流分配给特定的绑定设备。

这意味着对于单流用例，它们不能提供负载平衡，只提供故障转移。

这样做有以下几个原因：

• 它显着地减少了与运行绑定接口相关的开销。如果必须对每个单独的数据包做出决定，那么这将侵蚀绑定接口的峰值性能。通过只对每个流进行决策，这种开销只存在于流的第一个数据包。
• 许多较高级的网络协议依赖于按顺序传送数据包才能正常工作。一些第4层协议可以保证这一点，即使较低层没有，但仍然有许多应用程序不使用这样的协议，不做自己的排序。
• 第4层或更低层的许多东西实际上需要按顺序传送数据包才能有效地工作。例如，持续的无序传递会导致TCP出现各种问题，并严重限制了有效带宽。
• 大多数智能交换机和路由器也是按流操作的，这意味着它们在处理不按流操作的分组调度时可能会遇到问题。

因为它们是按流操作的，所以您最终会遇到这样一种情况，即任何一个流都不能得到比最低带宽绑定设备所能提供的更多带宽。您可以通过使用多个流来解决这个问题。

假设您的交换机运行良好，您可能需要balance-alb模式，因为它将为您提供在各个链接之间传播的最佳总体链路利用率。但是，一些网络硬件不喜欢该模式处理负载平衡的方式，在这种情况下，您几乎肯定希望802.3ad模式(如果您的交换机支持它，并且所有绑定的接口都连接到同一个交换机)或balance-xor (做同样的事情，但是交换机必须推断正在发生什么，所以在所有情况下都不能工作)。

为什么balance-rr或broadcast不能工作？

这两种键合方式都是特殊的。

broadcast模式的存在很大程度上只是为了提供一种绑定模式，它可以处理绑定接口的丢失而不受任何干扰(active-backup模式提供类似的容错功能，如果活动绑定接口由于必须重新路由流量并强制更新外部ARP缓存，则会显示出较小的延迟峰值)。实际上，它只适用于使用键连接驱动程序(甚至可能是相同模式)的系统之间的第二层点对点链接，并且没有给您带来性能上的好处。

相反，balance-rr模式被设计成具有最小的开销，而不管存在什么其他约束，它实际上进行了遍历，以平衡所有绑定接口的负载。问题是如果在第三层以下有一个以上的跳，这种模式不能提供分组排序保证，从而导致拥塞控制算法的各种问题，在功能上限制有效带宽。实际上，它也只适用于两种使用键合驱动程序的系统之间的第二层点对点链接。