鏈路聚合經常被當成“把兩根千兆變成兩千兆”的直覺工具，但局域網里的擁塞很多時候并不是聚合沒生效，而是管理員把聚合的分流粒度理解錯了。

鏈路聚合控制協(xié)議本身不負責按字節(jié)平均分流，它通常只按源目地址、網絡層地址或五元組做哈希，保證同一會話不亂序。于是當幾十臺電機端都訪問同一臺服務器，或者大量備份任務被網絡地址轉換壓縮成少數(shù)源地址時，熵不足會讓多數(shù)流量落在同一成員鏈路上，另一條鏈路幾乎空閑?？吹揭桓诖驖M、一根口半空，并不等于聚合失效，而是哈希輸入不足。前提是業(yè)務連接模式高度集中，或者設備默認只看二層或三層字段沒有納入傳輸層端口。服務器做主備綁定時如果發(fā)送和接收方向使用的哈希鍵不同，也會讓單向擁塞比雙向擁塞更難判斷。工程上應根據業(yè)務特征調整哈希鍵，并避免把不同速率、不同緩存深度的接口硬綁進同一聚合組，否則表面可用帶寬增加，實際排隊抖動反而更重。

單流大象流是另一種常被誤判的瓶頸。傳統(tǒng)以太網聚合為了避免亂序，同一傳輸控制流幾乎不會被拆到多條成員鏈路上，所以一次大文件傳輸、一個存儲會話或一個數(shù)據庫復制線程，吞吐上限通常仍受單成員口速率限制。很多人把這類現(xiàn)象歸咎于交換機“不會負載均衡”，實際上它滿足的是多流并發(fā)優(yōu)化，而不是單流加速。若場景確實存在少量大流，應從應用層增加并發(fā)連接，或在設計階段選擇更高速率的單鏈路、等價多路徑上聯(lián)、SMB多通道等方案，而不是指望聚合自動把一條流切碎。特別是在備份窗口和存儲同步窗口，真正決定效果的是會話并發(fā)度，而不是聚合成員數(shù)。聚合適合提升冗余和多會話承載能力，不適合掩蓋業(yè)務模型本身的集中性。

局域網里判斷聚合是否有效，先看流的分布，再看鏈路數(shù)量。能被分開的其實是并發(fā)會話，不是任何單條大流。