Linux 可以将 NIC 绑定在一起。其中有趣的策略是 Round-robin，它在每个 NIC 之间交替发送数据包。
然而，性能优势通常仅限于多个客户端。单个 1000BASE-T 客户端，尽管由双 1000BASE-T 供电，当然仍然限制为 1 Gbit/s。
那么 2.5GBASE-T 客户端呢？假设如下：
[服务器|2x1G] <===> [交换机|2.5G] <---> [客户端|1x2.5G]
服务器上的双网卡“条带化”使带宽加倍，交换机使用两个端口接收全部带宽并切换到单个2.5G端口。
客户端能否以 ~2 Gbit/s 的速度从服务器下载？如果可以，这种情况是否需要比非托管交换机更“智能”的设备？
谢谢！
答案1
对于单个流，从交换机到客户端方向上的任何带宽增益都极不可能。
托管交换机通常支持根据 802.3ad 协议或静态绑定进行端口绑定，哑（非托管）交换机根本不支持它。通道支持冗余和更高的带宽，但有一个问题。通常使用所谓的哈希策略选择特定端口，该策略使用各种 L2 和 L3（有时也包括 L4）字段计算哈希值。在大多数情况下，哈希值对于特定流将保持不变 - 这意味着其带宽仅限于所选端口的带宽（顺便说一句，对于 802.3ad，所有端口都应具有相同的速度）。对于较便宜的交换机（TP-link），我看到过基于 L2 或 L3 数据的哈希，更昂贵的（如 Dell PowerConnect）也支持基于 L4 数据的哈希。
此外，此类通道是通过对等方之间的一些数据交换动态形成的，这意味着此类通道与您提到的 balance-rr 模式不兼容。
因此，单流的任何带宽增益都极不可能实现。使用多流可能会看到一些增益，具体取决于交换机使用的哈希策略和配置的服务器（请参阅 xmit_hash_policy 了解可用的内容，您需要包含 L4 信息的策略才能在两个特定主机之间获得任何增益）。
答案2
不使用多个流程就不行。
除了 Linux 绑定驱动程序的循环和广播模式这两个特殊例外，这两种模式实际上都无法在您所述的场景中正常工作（更多内容见下文），所有绑定模式都会将每个连接/流分配给特定的绑定设备。
这意味着对于单流用例，它们无法提供负载平衡，只能提供故障转移。
这样做有以下几个原因：
- 它显著降低了通过绑定接口运行的开销。如果必须针对每个数据包做出决策，那么这将影响绑定接口的峰值性能。通过仅针对每个流做出决策，该开销仅存在于流的第一个数据包中。
- A很多更高级别的网络协议依赖于数据包的按序交付才能正常运行。即使较低层不能保证这一点，某些第 4 层协议也可以保证这一点，但仍有相当多的应用程序不使用此类协议和不进行自己的排序。
- A很多第 4 层或更低层上的事物实际上需要按顺序传送数据包才能有效运行。持续无序传送会导致各种问题，例如 TCP，并严重限制有效带宽。
- 大多数智能交换机和路由器也是按照流量来运行的，这意味着它们在处理不按照流量运行的数据包调度时可能会遇到问题。
但是，由于它们是按照流来运作的，因此最终会出现这样的情况：任何一个流都不能保证比最低带宽限制设备所能提供的带宽更多。您可以使用多个流来解决这个问题。
假设您的交换机可以很好地配合使用，您可能需要balance-alb模式，因为它将为您提供最佳的整体链路利用率。但是，某些网络硬件不喜欢该模式处理接收负载平衡的方式，在这种情况下，您几乎肯定会想要802.3ad模式（如果您的交换机支持它，并且所有绑定接口都连接到同一个交换机）或balance-xor（做同样的事情，但交换机必须推断发生了什么，因此并非在所有情况下都能很好地工作）。
为何balance-rr不起作用broadcast？
这两种粘合模式比较特殊。
broadcast模式的存在主要是为了提供一种绑定模式，可以处理绑定接口的丢失，而无需任何任何中断（active-backup模式提供了类似的容错能力，如果活动绑定接口发生故障，它将显示一个小的延迟峰值，因为它必须重新路由流量并强制更新外部 ARP 缓存）。它实际上仅适用于使用绑定驱动程序（甚至可能是相同模式）的系统之间的第 2 层点对点链接，并且不会为您带来任何性能优势。
balance-rr相反，该模式的设计目标是将开销降到最低，而不管存在其他什么限制，它实际上确实意味着在所有绑定接口之间均衡负载。问题是，如果第 3 层以下有多个跳数，则此模式无法提供数据包排序保证，这反过来会导致拥塞控制算法出现各种问题，从而限制有效带宽。实际上，它还仅适用于使用绑定驱动程序的系统之间的第 2 层点对点链接。