局域网聚合为何不分流？哈希怎么选准？

链路聚合经常被当成“把两根千兆变成两千兆”的直觉工具，但局域网里的拥塞很多时候并不是聚合没生效，而是管理员把聚合的分流粒度理解错了。

链路聚合控制协议本身不负责按字节平均分流，它通常只按源目地址、网络层地址或五元组做哈希，保证同一会话不乱序。于是当几十台电机端都访问同一台服务器，或者大量备份任务被网络地址转换压缩成少数源地址时，熵不足会让多数流量落在同一成员链路上，另一条链路几乎空闲。看到一根口打满、一根口半空，并不等于聚合失效，而是哈希输入不足。前提是业务连接模式高度集中，或者设备默认只看二层或三层字段没有纳入传输层端口。服务器做主备绑定时如果发送和接收方向使用的哈希键不同，也会让单向拥塞比双向拥塞更难判断。工程上应根据业务特征调整哈希键，并避免把不同速率、不同缓存深度的接口硬绑进同一聚合组，否则表面可用带宽增加，实际排队抖动反而更重。

单流大象流是另一种常被误判的瓶颈。传统以太网聚合为了避免乱序，同一传输控制流几乎不会被拆到多条成员链路上，所以一次大文件传输、一个存储会话或一个数据库复制线程，吞吐上限通常仍受单成员口速率限制。很多人把这类现象归咎于交换机“不会负载均衡”，实际上它满足的是多流并发优化，而不是单流加速。若场景确实存在少量大流，应从应用层增加并发连接，或在设计阶段选择更高速率的单链路、等价多路径上联、SMB多通道等方案，而不是指望聚合自动把一条流切碎。特别是在备份窗口和存储同步窗口，真正决定效果的是会话并发度，而不是聚合成员数。聚合适合提升冗余和多会话承载能力，不适合掩盖业务模型本身的集中性。

局域网里判断聚合是否有效，先看流的分布，再看链路数量。能被分开的其实是并发会话，不是任何单条大流。