降低高密度 WiFi 網路上的延遲

播客腳本 — "Reducing Latency on High-Density WiFi Networks" 播送時間：約 10 分鐘 配音：英式英文，男性，資深顧問口吻 — 自信、對話式、具權威感。 --- [片頭 — 約 1 分鐘] 歡迎回來。我今天想直接切入正題，因為在這個主題上，大多數團隊的實際做法與正確做法之間存在著極大落差，而這正是造成損失的元凶。我們今天要探討的是高密度 WiFi 網路上的延遲問題 — 尤其是為什麼 DNS 是幾乎沒人注意到的隱藏幫兇。 如果您正在飯店、體育場、會議中心或大型零售商場營運 WiFi，您幾乎肯定聽過這種對話：「網路很慢。」而直覺反應通常是去檢查基地台密度、頻道使用率或回傳網路容量。這些確實很重要。但在這一切之下還有一個層級 — 也就是 DNS 層 — 在實際內容傳輸任何一個位元組之前，每個裝置的每一次網頁載入，都可能在此流失大量的延遲時間。 這就是我們今天要去解析的內容。我將帶您深入瞭解技術機制，提供兩個具體的建置情境，並為您提供一套明確的行動方案，讓您本週就能帶回給團隊執行。 --- [技術深究 — 約 5 分鐘] 讓我們從基本原理開始。當裝置連線到您的 WiFi 且使用者開啟瀏覽器或應用程式時，實際發生的第一件事是什麼？在獲取任何內容之前，裝置需要將網域名稱解析為 IP 位址。這就是 DNS。在現代智慧型手機上，單次網頁載入 — 例如新聞文章或飯店預訂頁面 — 就可以觸發 20 到 70 次 DNS 查詢。這不是因為頁面本身有 70 個網域，而是因為頁面載入了第三方追蹤像素、廣告腳本、分析信標和社群媒體小工具。其中每一個都會觸發一次 DNS 查詢。 現在，在只有少數裝置的正常家庭或辦公室環境中，這基本上是察覺不到的。DNS 解析器會處理它，TTL 快取會發揮作用，且開銷微乎其微。但是，如果將 500 個裝置放在會議中的同一個基地台叢集上，或者在入住高峰期有 3,000 名旅客待在飯店裡，您就會面臨 DNS 查詢風暴。您的本機解析器 — 如果您有的話 — 每分鐘要處理數萬次查詢，其中很大一部分正傳送到公共網際網路，以解析廣告網路和追蹤服務的網域，而這些服務根本不會載入使用者關心的內容。 這是一個關鍵的洞察：每一個不必要的 DNS 查詢都會增加使用者感受到的延遲。我們這裡討論的不是內容載入時間，而是載入前的解析時間。在擁擠的網絡中，向外部解析器發送單個 DNS 查詢可能需要 80 到 150 毫秒。如果一個頁面在開始載入實際內容之前觸發了 15 次追蹤網域查詢，那麼在使用者看到任何內容之前，您就已經增加了超過一秒的隱形延遲。這不是回程傳輸（backhaul）的問題，而是 DNS 的問題。 解決方案由兩個部分組成。第一，部署一個具有強力快取功能的本地 DNS 解析器，最好是在地端（on-premises）或網路邊緣。Unbound、企業模式下的 Pi-hole，或來自 Cisco Umbrella 或 Infoblox 等廠商的商業等效產品，在此處都非常適用。其目標是從快取中解析大多數查詢（小於 5 毫秒），而完全不需要存取公共網際網路。對於高密度的場域，在穩定運作狀態下，您的快取命中率目標應該要達到 70% 以上。 第二，這才是真正帶來效益的地方：實施 DNS 過濾，在解析器層級直接捨棄已知追蹤、廣告和遙測網域的查詢。當收到針對已知廣告網路網域的查詢時，解析器會立即在 1 毫秒內返回 NXDOMAIN（找不到網域）。裝置得到回覆後會停止等待，並繼續進行下一個查詢。您完全省去了往返公共網際網路的時間。將這個效果乘以每個頁面載入 15 個追蹤網域，再乘以 500 台同時線上的裝置，整個 DNS 查詢量的累計減少量（進而降低延遲）將會非常顯著。 這裡有一個關於 DNS over HTTPS（簡稱 DoH）的重要細節。現代瀏覽器和作業系統越來越傾向於透過加密的 HTTPS 直接將 DNS 查詢發送到 Cloudflare 或 Google 等 DoH 提供商，從而完全繞過您的本地解析器。這在消費級情境中對隱私保護非常棒，但在受管理的場域環境中，這會完全破壞您的本地快取和過濾策略。您需要在防火牆層級攔截或重導向 DoH 流量，或者部署您自己的 DoH 解析器，並透過 DHCP option 6 和網路原則引導裝置使用。這是一個日益複雜的領域 - 如果您想深入瞭解 DoH 帶來的具體影響，Purple 有一份專門針對大眾 WiFi 過濾的 DNS over HTTPS 專題指南，非常值得閱讀。 現在，讓我們將射頻（RF）端納入考量，因為 DNS 最佳化並不是獨立運作的。在高密度部署中，您通常會執行 802.11ax - WiFi 6 或 WiFi 6E - 並搭配 OFDMA 與 BSS 着色技術（BSS Colouring）來管理同頻道干擾。DNS 在這些環境中更加重要的原因在於，OFDMA 的效率提升是建立在「無線媒體是用於實際數據傳輸，而非用於解析數百個無用網域名稱的開銷」這一假設之上。傳送到網際網路的每個 DNS 查詢都是一個佔用傳輸機會的小封包。在大型架構下，這種開銷在吞吐量方面是清晰可測的。 將本機 DNS 快取、追蹤網域過濾與調校良好的 802.11ax 無線環境相結合，您就能開始看到顯著的改善。我們所說的是在實際部署中（而非在實驗室條件下），將感知到的網頁載入延遲縮短 60% 至 87%。 --- [實作建議與常見陷阱 - 約 2 分鐘] 好，讓我們切入實際操作。如果您正在為部署進行評估，以下是我的作法。 從 DNS 審計開始。在您進行任何調整之前，請先配置您現有的解析程式，或部署被動式 DNS 監聽程式，並收集 24 到 48 小時的查詢記錄。您幾乎肯定會發現，有 30% 到 50% 的查詢量是流向一組相對較小的追蹤與廣告網域。這就是您的首要下手目標。 接下來，部署一個帶有精選封鎖清單的本機解析程式。我建議從保守的清單開始（例如 Steven Black 整合主機清單或商業同等清單），而不是使用過於激進的清單。您必須避免封鎖合法應用程式所依賴的網域。在推播至正式環境之前，請先在暫存 VLAN 中進行測試。 至於 DoH 攔截，您需要在防火牆層級進行處理。封鎖至已知 DoH 供應商 IP 範圍（例如 Cloudflare 的 1.1.1.1、Google 的 8.8.8.8）的輸出 TCP 和 UDP 連接埠 443，並將這些查詢重導向至您的本機 DoH 解析程式。這需要與您的安全團隊協調，特別是當您處於對 PCI-DSS 或 GDPR 敏感的環境中，因為您實際上是在執行某種形式的 DNS 檢測。請記錄此流程、取得核准，並確保您的 Captive Portal 服務條款反映了過濾政策。 我最常看到的陷阱是團隊過於激進地部署過濾，隨後因為特定應用程式停止運作而收到客服電話。請針對網域白名單請求建立快速回應流程，並監控您的 NXDOMAIN 回應率。如果回應率突然激增，代表合法應用程式的 DNS 依賴關係發生了變化。 第二個陷阱是將其視為一次性的設定，而不是持續的維運工作。追蹤網域會不斷變化，新的廣告網絡也會隨之出現。您的封鎖清單需要定期更新，至少每月一次，最好是每週透過自動化摘要進行更新。 --- [快速問答 — 約 1 分鐘] 關於這個主題，我經常被問到幾個問題。 「DNS 過濾會影響 GDPR 合規性嗎？」 - 實際上它能提供幫助。透過阻止追蹤網域的解析，您可以減少第三方廣告網路可以收集的訪客數據。話雖如此，請記錄您的過濾政策並將其包含在您的隱私聲明中。 「內部資源的分割 DNS 呢？」 - 絕對必要。您的本地解析器應該為所有內部主機名稱配備授權區域，且這些主機名稱絕不應轉發到外部。這是標準做法，但值得一說。 「我可以在雲端管理的 WiFi 平台上執行此操作嗎？」 - 可以，大多數企業平台 - Cisco Meraki、Juniper Mist、Aruba Central - 都支援透過 DHCP 進行自訂 DNS 伺服器指派。您將裝置指向您的本地解析器，不論哪個雲端平台管理您的 AP，過濾都會在那裡進行。 「這件事的投資報酬率是什麼？」 - 訪客滿意度評分、因 WiFi 慢而產生的支援工單量減少，以及 Captive Portal 載入時間的顯著改善。對於飯店來說，這會直接轉化為評論分數。對於會議場地來說，這就是續訂與流失客戶之間的差別。 --- [總結與後續步驟 — 約 1 分鐘] 總結一下：在低延遲的高密度場地中，為了降低 WiFi 延遲，您可以採取影響最大、成本最低的干預措施，就是部署具有追蹤網域過濾功能的本地 DNS 解析器。它解決了很大一部分感知延遲的根本原因 - 不是射頻環境，不是回程傳輸，而是您網路上每部裝置為永遠不會載入的內容解析網域所產生的 DNS 查詢風暴。 您的行動清單：本週進行 DNS 稽核，規劃本地解析器部署範圍，並與您的安全性團隊達成封鎖清單策略的共識。如果您正在處理 DoH 繞過，那就是下一個要解決的層面。 Purple 的 [Guest WiFi] 平台與 [WiFi Analytics] 工具在建置時就考量到了這種網路智慧 - 如果您想了解 DNS 最佳化如何融入更廣泛的場地 WiFi 策略，非常值得與 Purple 的團隊聊聊。 感謝您的收聽。我們下次見。 --- 腳本結束