根据我的理解，LACP 总是要求特定网络“对话”（同一源端口和目标端口之间的 TCP 会话或 UDP 流）中的数据包遍历单个 LACP 路径，以保证交付顺序。LACP 根据散列算法选择路径。在 Linux 中，哈希算法是bonding驱动程序xmit_hash_policy设置中描述的那些：

• layer2 - 意味着散列由源和目标第 2 层 (MAC) 地址组成；
• layer2+3- 意味着散列由layer2信息以及源和目标第 3 层 (IP) 地址组成；
• layer3+4 - 意味着散列由第 3 层 (IP) 地址加上任何可用的第 4 层寻址信息（例如 TCP 或 UDP 源和目标端口号，如果数据包未分段）组成。

Cisco 有许多附加选项。

服务器和交换机不需要使用相同的哈希算法；所需要的只是特定对话的数据包选择相同的路径，只要该路径可用。

LACP 控制链路的聚合，而不控制交换。捆绑包的特定成员的选择是通过每个交换机供应商决定和实施的算法进行的。它必须是可以编程到硬件中的东西，以便以相对便宜的线速运行，并且以太网帧的各个字段的散列适合于此。为了执行循环，入口硬件需要知道所有关于捆绑成员的信息，并保持之前帧交换的状态。这个问题要复杂一个数量级。我不知道在 LAG 上执行循环的任何交换机。

Linux 和 ESX 等可以在软件中执行循环，相比之下，这相当简单，因为整个接口选择过程已经在软件中完成。另请注意，通常服务器的传输要求高于接收要求，因此对于许多应用程序，循环实现的带宽增加仅需要服务器到交换机。

我尝试使用循环法将两台 Linux 机器连接在一起，因为它们都支持这一点。虽然我确实获得了比单个链接更多的可用带宽，但结果并不出色。

我将两个 10G 链接绑定在一起，理论上允许主机之间的 20 Gbps。有时我确实会接近这个，但很多时候我只会得到 11-15 Gbps。

问题是无论出于何种原因，数据包并不总是按顺序到达。对于 TCP，这可能会导致它认为数据包已丢失并请求重新传输（降低整体带宽）并增加延迟，但是对于像文件服务器这样的批量传输，您最终仍会获得整体更高的传输速率，因此这不是结束世界。

然而，对于像 UDP 和实时视频流这样不保证交付的协议来说，这是一场灾难，因为它们倾向于处理最新的可用数据包并丢弃任何尚未到达的较早数据包，以获得尽可能低的延迟 - 他们不这样做不想等待所有数据包首先到达，因为这会引入很多延迟。虽然这里丢失的数据包没有问题，但使用循环法，您可能会得到大量无序到达的数据包，这可能会完全破坏数据流和视频，使其无法观看！

想象一下源机器正在按照 NIC1、NIC2、NIC3、NIC4、NIC1 等的顺序从四个绑定的 NIC 中发送一个流。现在想象一下接收机器正在以相反的顺序处理数据包，首先检查 NIC4，然后是 NIC3， NIC2、NIC1 然后是 NIC4。在这个例子中，它首先拾取的数据包将来自 NIC4，这将是最新的，接下来三个来自 NIC3、2 和 1 的数据包将更旧。那是 75% 的数据包乱序，这可能导致实时视频流丢失 75% 的数据包，很容易使其无法观看。

唯一可行的方法是，如果接收硬件设计为存储数据包，直到完整集到达，然后按顺序转发它们，这将增加延迟。这也意味着交换机必须决定等待多长时间才能确定数据包丢失并放弃等待，所以在你知道它之前，你正在实现一个精简的 TCP 风格的保证交付协议以太网。然后你必须考虑当有人试图绑定一个 10G 和四个 1G 链接时会发生什么，希望得到 14G。您的 10G 链路将发送如此多的数据包，看起来所有通过 1G 链路进入的数据包都丢失了，即使它们的传输时间增加了 10 倍。那么，您如何区分丢失的数据包或需要很长时间才能通过较慢的链接到达的数据包？

长话短说，让它工作很复杂。

40G QSFP 标准使用四个并行的 10G 链路来实现 40 Gbps 的带宽，但这只是因为它不是在数据包级别完成的。每个交换机拆分数据包并通过四个并行链路将其发送出去，接收交换机在远端合并它，从而保持每个数据包的有序和低延迟。这确实是正确执行此操作的唯一方法，但这意味着要提出一个新标准，就像他们对 QSFP 所做的那样，因为通过线路传输的数据不再是标准以太网并且不向后兼容。