如何在不購買新基地台的情況下提升 WiFi 速度

如何在不購買新基地台的情況下提升 WiFi 速度 Purple 技術簡報 — 長度約 10 分鐘 --- 導言與背景（約 1 分鐘） --- 歡迎來到 Purple 技術簡報系列。我是你們的主持人，今天我們要探討一個我經常與企業場域的 IT 總監和 CTO 討論的話題 — WiFi 容量問題。 您可能管理著一家飯店、一個零售物業、一個會議中心或一個體育場。您的顧客和員工正在抱怨 WiFi 速度慢。您的第一直覺 — 坦白說，也是您的基礎設施廠商所期待的直覺 — 就是購買更多基地台。新硬體、更大的部署規模、更龐大的帳單。 但事實是，在我評估過的大多數案例中，問題根本不在於基地台。問題在於流經它們的流量。這是一個軟體問題，意味著它需要一個軟體解決方案。 今天，我將帶您了解 DNS 過濾和軟體層優化如何具體收回現有頻寬的 30% 或更多 — 而無需動用任何一件硬體。我們將涵蓋技術架構、實際部署場景，以及您可以向 CFO 呈報的商業案例。 讓我們開始吧。 --- 技術深挖（約 5 分鐘） --- 首先，讓我們確立核心問題。當您查看典型企業顧客 WiFi 網路上實際消耗頻寬的內容時，其細分結果著實令大多數人感到驚訝。 廣告網路和第三方追蹤器 — 每個裝置上的每個應用程式不斷發送的背景遙測數據 — 佔典型顧客網路上 DNS 查詢量的 25% 到 40%。這些並非您的顧客自覺發起的請求。它們是自動運行的。每當有人在手機上打開新聞應用程式、社群媒體平台或零售應用程式時，該應用程式就會向廣告伺服器、分析平台和追蹤像素發送數十次 DNS 查詢。這些流量都沒有為您的顧客帶來價值，卻消耗了您的上行鏈路容量。 最重要的是，還有惡意軟體和殭屍網路流量。受感染的裝置 — 在大型顧客網路上，您一定會遇到受感染的裝置 — 不斷嘗試與命令與控制伺服器進行通訊。這種流量不僅浪費頻寬，還帶來了合規性和安全性風險。 因此，在任何合法的流量（如視訊通話、網頁瀏覽、支付交易）到達您的上行鏈路之前，您就已經在雜訊上消耗了三分之一到一半的可用容量。 現在，DNS 過濾在解析層運作。每個網路請求都始於 DNS 查詢 — 一種將網域名稱轉換為 IP 地址的查詢。DNS 過濾在查詢到達您的上行鏈路之前將其攔截。如果該網域解析為廣告網路、已知的惡意軟體主機或受策略限制的類別，則該查詢會在 DNS 層被阻擋。裝置會收到空回應。不傳輸任何資料，不消耗任何頻寬。 這與防火牆或代理伺服器有本質上的不同。防火牆在封包到達後進行檢查。代理伺服器在傳輸過程中攔截流量。而 DNS 過濾在請求開始之前就將其阻止 — 這就是為什麼頻寬收回效果如此顯著的原因。您不是在清理已經到達的流量，而是在源頭阻止其被請求。 從架構的角度來看，部署非常簡單。您只需設定 DHCP 伺服器，將用戶端裝置指向您的 DNS 過濾解析器，而非 ISP 的預設 DNS。這通常只需在您的 DHCP 設定中修改兩行內容。過濾規則是集中維護的 — 根據您的合規性要求，可以部署在雲端或本地 — 並統一套用到所有已連線的裝置，無論它們與哪個基地台關聯。 對於多站點營運商來說，這是一個關鍵點。擁有 200 家門市的零售連鎖店或擁有 50 家物業的飯店集團，可以從單一管理主控台在整個物業中部署一致的 DNS 過濾策略。無需現場工程師拜訪，無需針對每個站點進行設定。策略變更可在數分鐘內傳播完畢。 現在，這裡有一個重要的技術考量，我想為在座的架構師們特別指出。DNS over HTTPS（即 DoH）的出現，給傳統的 DNS 過濾帶來了挑戰。當裝置使用 DoH 時，它會加密其 DNS 查詢並將其直接發送到特定的解析器（通常由瀏覽器廠商營運），從而完全繞過您的網路級 DNS。這意味著您的過濾規則會被規避。 解決方案是在網路層級強制執行 DoH 攔截。這涉及識別 DoH 流量（該流量在連接埠 443 上運行到已知的解析器 IP 範圍），並將其阻擋或重導向到您自己支援 DoH 的過濾解析器。這是一個更進階的設定，但對於在 Chrome、Firefox 和 iOS 越來越預設使用加密 DNS 的現代網路上維持過濾效果至關重要。Purple 已經發布了一份關於 DNS over HTTPS 對公共 WiFi 過濾影響的詳細指南，我建議您與本次簡報一起閱讀。 除了 DNS 過濾之外，還有幾種輔助的軟體層優化值得同時實施。 頻段引導是影響最深遠的優化之一。大多數現代基地台都支援 2.4 GHz 和 5 GHz 頻段。5 GHz 頻段提供顯著提高的吞吐量，但傳輸距離較短。如果沒有主動的頻段引導，裝置通常會預設連線到 2.4 GHz 頻段 — 尤其是舊型裝置和 IoT 硬體 — 從而在已經擁擠了舊型流量的頻段上造成擁塞。在您的無線控制器中啟用頻段引導可以將支援該功能的裝置推向 5 GHz，為真正需要它的裝置釋放 2.4 GHz 空間。 SSID 整合是另一個可以快速見效的方案。您廣播的每個 SSID 都會透過信標訊框（每個範圍內的裝置都必須處理的管理流量）消耗空中時間。一個為不同部門、承包商和顧客級別運行 8 到 10 個 SSID 的場域，在管理開銷上消耗了可觀的空中時間比例。將其整合為 3 到 4 個 SSID（顧客、員工、IoT 和管理），並使用 VLAN 標記進行分割而非使用獨立的 SSID，可以立即回收這些空中時間。 QoS（服務品質）策略執行是第三個槓桿。如果沒有 QoS，單個觀看 4K 影片的顧客就可能使無線電單元飽和，從而降低該基地台上所有其他裝置的體驗。實施每用戶端速率限制和流量優先級排序 — 將 VoIP 和 POS 交易流量提升到大容量串流媒體之上 — 可確保業務關鍵流量即使在尖峰負載下也能受到保護。 最後是頻道規劃和發射功率優化。這些通常在初始部署期間設定後就再也沒有重新評估。隨著射頻環境的變化 — 新建築、新干擾源、裝置密度的變化 — 您的頻道分配可能會產生同頻道干擾，從而顯著降低吞吐量。進行被動射頻調查並重新優化頻道分配是一項零成本的干預措施，可以帶來實質性的吞吐量提升。 --- 實施建議與常見陷阱（約 2 分鐘） --- 讓我為中型場域（例如擁有 200 間客房的飯店或區域性零售配送中心）提供一個實用的部署順序。 第一步：從基準測量開始。在您更改任何內容之前，先配置您的網路以擷取按類別分類的 DNS 查詢量、每用戶端頻寬消耗以及按一天中不同時間段分類的上行鏈路利用率。這為您的 ROI 計算提供了「調整前」的狀態。大多數企業級 WiFi 分析平台都會原生呈現這些數據 — 例如，Purple 的分析平台提供裝置級別的可視性，使這項基準評估變得非常簡單。 第二步：在監控模式下部署 DNS 過濾。大多數企業級 DNS 過濾解決方案都支援被動模式，在此模式下會記錄查詢並進行分類，但不會予以阻擋。在您執行任何策略之前，先運行此模式 48 到 72 小時，以了解您的流量組成。這可以防止誤判在第一天干擾合法的流量。 第三步：分階段啟用阻擋。從置信度最高的類別開始 — 已知的惡意軟體網域、殭屍網路命令與控制以及廣告網路。這些是低風險但對頻寬影響巨大的阻擋。在第一週每天審查日誌，以捕獲任何意外的阻擋。 第四步：加入 QoS 和頻段引導。一旦 DNS 過濾穩定運行，即可實施每用戶端速率限制和頻段引導。在非尖峰時段測試這些變更，並驗證 POS 終端機、VoIP 手持裝置和其他業務關鍵裝置是否正常運作。 第五步：記錄與測量。30 天后，提取您的頻寬利用率指標並與您的基準進行比較。在大多數部署中，您會看到上行鏈路利用率減少 20% 到 40%。這就是您的 ROI 數據。 現在來談談陷阱。我最常看到的是過度阻擋。如果您在未先審查日誌的情況下啟用激進的內容過濾類別，您將會阻擋合法的服務。雲端儲存、企業 SaaS 應用程式，甚至某些金流處理網域都可能出現在廣泛的分類阻擋中。務必從保守開始，逐步擴大。 第二個陷阱是忽視 DoH 繞過。如果您在部署 DNS 過濾時沒有解決 DoH 問題，隨著越來越多的裝置預設使用加密 DNS，您會發現過濾效果隨著時間推移而下降。從第一天起就在網路策略層級解決這個問題。 第三個陷阱是未能分割 IoT 流量。IoT 裝置（智慧電視、建築管理系統、數位看板）通常會向製造商的遙測伺服器產生大量的 DNS 流量。如果您沒有將 IoT 分割到具有其自身過濾策略的獨立 VLAN 上，當您收緊過濾規則時，可能會無意中阻擋裝置的功能。 --- 快速問答（約 1 分鐘） --- 讓我解答一下我最常收到的問題。 「DNS 過濾會影響顧客體驗嗎？」在實際應用中，顧客根本不會注意到。被阻擋的網域是背景遙測，而不是他們主動請求的內容。如果說有什麼變化的話，那就是他們的體驗得到了提升，因為有更多頻寬可用於他們真正想做的事情。 「這需要對我們的基地台進行更改嗎？」不需要。DNS 過濾是在 DHCP 和 DNS 解析器層級設定的。您的基地台不會受到任何影響。 「這符合 GDPR 規範嗎？」DNS 過濾記錄的是網域查詢，而非內容。您沒有進行深層封包檢測。只要您有適當的資料保留策略，且您的隱私聲明涵蓋了網路監控（無論如何都應該涵蓋），DNS 過濾就完全符合 GDPR。對於公共部門和醫療保健部署，這通常是合規性要求，而非選擇。 「那 PCI DSS 呢？」DNS 過濾實際上透過阻止持卡人資料環境與已知惡意網域進行通訊，加強了您的 PCI DSS 安全態勢。這是一種積極的控制措施，而非風險。 --- 總結與後續步驟（約 1 分鐘） --- 總結一下：大多數企業 WiFi 效能問題並非硬體問題。它們是軟體問題 — 具體而言，是在 DNS 層缺乏智慧流量管理。 透過部署 DNS 過濾，您可以收回 30% 或更多的現有頻寬，將現有基地台基礎設施的營運壽命延長 2 到 4 年，並同時提升您的安全性和合規性態勢。部署時間以小時計算，而非以月計算。資本支出僅為硬體更新的一小部分。 實際的後續步驟非常簡單。本週在您的網路上執行一次 DNS 流量稽核 — 大多數企業平台都可以在無需任何額外工具的情況下為您提供這些數據。識別消耗頻寬最多的網域類別。然後針對這些類別評估 DNS 過濾解決方案。 如果您正在大規模營運顧客 WiFi 網路 — 飯店、零售、活動、公共部門 — Purple 的平台在單一部署中將 DNS 過濾與顧客 WiFi 管理和分析整合在一起。這意味著您可以從同一個平台（而非三個平台）獲得頻寬收回、合規性控制和顧客數據洞察。 感謝收聽 Purple 技術簡報。隨附的書面指南中提供了完整的實施指南、架構圖和應用範例。我們下次再見。