ECMP 親和性與持續性

等價多路徑 (ECMP) 路由只是分配數據流；它不理解使用者、Cookie、登入工作階段或應用程式交易。請在能夠感知應用程式的應用層設計應用程式持續性，而不要將穩定的 ECMP 雜湊當成一種工作階段持續性功能。

雜湊標識的是數據流，而不是使用者

許多路由器根據網際網路協定 (IP) 和傳輸層首部中的欄位來選擇等價路徑。常見的輸入是五元組：來源位址、目的位址、協定、來源連接埠和目的連接埠。確切的欄位、雜湊種子和行為方式取決於具體平台。

在 ECMP 下一跳群組保持穩定時，具有相同選中欄位的封包通常會沿相同路徑轉發。新連線可能會使用不同的來源連接埠，從而選擇另一個 CE。HTTP/1.0、HTTP/1.1、HTTP/2、瀏覽器連線重複使用、代理以及網路位址轉換 (NAT) 都會改變用多少個傳輸層連線來代表一個表面上的使用者工作階段。

這種行為僅是「流親和性」 (flow affinity)。它不是來源位址持續性、Cookie 持續性或工作階段狀態複製。

省略來源連接埠會改變權衡

某些路由器可以從 ECMP 雜湊中省略來源連接埠。這樣做可以更頻繁地將具有相同來源和目的位址的連線保持在同一條路徑上，但它減少了可用於分流的取值空間。這樣，位於同一個 NAT 位址後面的大量使用者可能會集中到單個 CE 上。

這種配置依然無法保證應用層持續性：

路徑集的改變可能會重新對應雜湊值；
CE 故障會將新流量遷移到其他 CE；
用戶端位址可能會發生改變；
路由器不會在 CE 之間複製應用程式狀態。

將嚴格的持續性置於正確的層級

當應用程式需要將使用者帶回同一個處理上下文時，請使用支援的應用層持續性機制或將工作階段狀態外部化。範例包括 Cookie 持續性、由應用程式感知的負載平衡器實作的來源位址持續性，以及共享的工作階段儲存。

準確闡述需求：

需求	適用機制
將同一個傳輸流中的封包保持在一個路徑上	ECMP 流雜湊
將來自同一位址的新連線保持在同一個目標上	來源位址親和性，需理解 NAT 集中
將同一已認證使用者保持在同一個應用程式執行個體上	應用層持續性
容忍所選 CE 或應用程式執行個體丟失並正常存活	複製的或外部的工作階段狀態，加上健康感知的故障轉移

用實際流量驗證，而不要憑空假設

生成多個獨立的連線，並對比逐路徑或逐 CE 計數器。測試應包括 NAT 後的用戶端、範圍內的每個 HTTP 版本、長連線以及路徑集變化。請求成功僅證明了可達性；它並不代表分流均勻或實作了工作階段持續性。

有關路徑集變化的路由側行為，請參閱路由和故障轉移。

標準參考

RFC 2992 描述了一種將流分配到等價下一跳的模型，以及下一跳集改變時造成的業務中斷。