要理解負載平衡,先要理解一個反直覺的事實:在無線網絡中,最終決定連上哪一部接入點的,是用戶端的裝置,而不是網絡本身。手機、平板與手提電腦在選擇接入點時,一般只以自己的訊號強度作為判斷基準——哪一部 AP 訊號最強,就嘗試連到哪一部,裝置通常不會知道該 AP 已連接了多少其他裝置、正在承受多少流量。
這個行為在實際部署中的後果非常明顯:在人流密集的場地,最接近入口或座位區的 AP 會吸引大量裝置同時連線,訊號次強的其他 AP 卻閒置;當某一部 AP 同時服務太多裝置時,無線媒介是共享的,所有連接該 AP 的裝置都會感到頻寬下降、回應變慢,即使訊號「滿格」亦然。負載平衡要解決的,正是「訊號最強」與「體驗最好」之間的落差。
要做到負載平衡,網絡側需要兩項能力:第一是量度,即監察每部 AP 目前的負載狀況;第二是引導,即讓裝置改用另一部 AP。前者屬於控制器或接入點軟件的功能,後者則須依靠通訊標準或接入點對客戶端的引導機制——但引導是否被遵從,仍然取決於裝置的選擇。
負載平衡與無線漫遊(Roaming)常被混淆,兩者其實不同:漫遊處理的是裝置移動時在不同 AP 之間轉換連線的流暢度,例如由辦公室走到會議室;負載平衡處理的是多部 AP 之間的用戶分布是否平均,即使裝置完全靜止不動,仍可能需要被引導至另一部 AP。兩者機制有部分重疊,但目標不同。
需要留意的是,即使裝置支援 802.11k/v,廠商在相同標準下的實作細節仍有差異;而各廠商宣稱的引導能力,未必等於所有客戶端都會配合。工程上應以實際量度為準——在場地以真實裝置進行連接測試,量度各 AP 的連接分布,而非只看控制器的負載平衡設定頁面。
黏性客戶端:負載平衡的近親問題
負載平衡面對的另一個頑固問題是黏性客戶端(Sticky Client):裝置已連上某一部 AP 後,即使訊號變弱或該 AP 日益擁塞,仍然不願轉換,直至連線幾乎中斷才被迫換網。此現象在支援 802.11v 建議之前的系統尤為常見,也是負載平衡與漫遊設計要一併處理的問題。
黏性的成因,是裝置判斷「是否值得轉網」的標準過於保守:只有當現有連線的訊號跌到很低水平,裝置才肯重新搜尋。於是使用者可能在靠近另一部 AP 的位置,仍被「黏」在一部訊號弱或擁塞的 AP 上,體驗與網絡利用率同時受損。負載平衡的引導機制,正是針對這類「裝置不願自行轉換」的情況而設計——但如前所述,引導只是建議,最終仍要看裝置。
量度現狀——以無線勘察工具統計每部 AP 的連接數、流量與訊號分布,找出連接數明顯失衡或訊號與位置不相符的裝置群組。