什麼是 Probe Request？深入了解裝置如何探索網路

什麼是探針請求（Probe Request）？了解裝置如何探索網路。Purple 技術簡報。 簡介與背景。 歡迎閱讀本次的 Purple 技術簡報。我將帶您深入了解企業級 WiFi 中最基本、但也最常被誤解的機制之一：探針請求。如果您負責管理訪客 WiFi 部署、多站點零售網路或場域分析專案，了解探針請求並非可有可無。它是所有其他應用的基石——從人流量分析、停留時間測量，到 MAC 隨機化挑戰以及 GDPR 合規性。 現在，讓我們深入探討。 每當智慧型手機、筆記型電腦或平板電腦等裝置未連線至網路時，它就會不斷掃描尋找網路。這個掃描過程就是從探針請求開始的。它是一個在 IEEE 802.11 規範下定義的管理訊框（Management Frame），由用戶端裝置發送，而非無線基地台（Access Point）。您可以把它想像成裝置在房間裡大喊：「這裡有我認識的人嗎？」無線基地台會進行監聽，如果識別出該請求，就會做出回應。 這種情況每天會發生數百次，而裝置擁有者通常毫不知情。對於網路架構師和場域營運商而言，如果您知道如何正確擷取和解析這些探針請求，它們就是營運數據的寶庫。 技術深度解析。 讓我們深入了解其運作機制。 探針請求是在 2.4 GHz 或 5 GHz 無線頻段上傳輸的 Layer 2 管理訊框。在 IEEE 802.11 標準下，它被歸類為子類型 4（Subtype 4）管理訊框。該訊框包含幾個關鍵資訊元素：SSID 欄位、支援速率元素、延伸支援速率元素，以及包含 HT（高吞吐量）和適用於 802.11ac 裝置之 VHT 功能的容量資訊。 探針請求有兩種類型。第一種是廣播探針請求（Broadcast Probe Request），有時也稱為萬用字元探針（Wildcard Probe）。此時 SSID 欄位為空——裝置基本上是在要求範圍內的任何無線基地台表明身份。第二種是定向探針請求（Directed Probe Request），其中 SSID 欄位包含特定的網路名稱。當裝置正在主動尋找先前曾連線過且已儲存在其偏好網路清單中的網路時，就會發生這種情況。 無線基地台的回應——探針回應訊框（Probe Response Frame）——鏡像了大部分信標訊框（Beacon Frame）的內容。它包括 SSID、BSSID、信標間隔、時間戳記和完整的容量集。這種互動機制讓裝置在使用者打開 Wi-Fi 設定之前，就能建立其可用網路的清單。 現在，主動掃描與被動掃描之間存在著一個重要的區別。主動掃描就是我剛才描述的探測請求與回應循環。被動掃描則不同——裝置只是單純地監聽存取點定期（通常是每 100 毫秒）廣播的信標訊框（beacon frames）。被動掃描速度較慢，但耗電量較低。大多數現代裝置會根據其電源狀態和所處的法規網域，結合使用這兩種掃描方式。 這在營運上具有重大意義。在高密度場所——如體育場、會議中心、大型零售賣場——可能會有數千台裝置同時在多個頻道上發送探測請求。這會造成所謂的「探測風暴（probe storm）」現象。每個探測請求都會消耗空中傳輸時間（airtime）。在設計不良的網路中，這種管理訊框的開銷會顯著降低已連線用戶端的吞吐量。這就是為什麼企業級存取點會將探測請求過濾和速率限制列為標準配置。 現在我們來談談 MAC 位址，以及為什麼這對數據分析極為重要。 在過去，每個探測請求都攜帶裝置真實的硬體 MAC 位址——這是一個燒錄在網路介面卡中、全球唯一的 48 位元識別碼。這使得基於探測的數據分析非常可靠。您可以追蹤整個場所內的裝置、測量停留時間、識別重複訪客，並以極高的可信度建立人流熱圖。 然而，隨著 2020 年的 iOS 14 以及更早的 Android 10 推出，情況發生了重大變化。Apple 和 Google 針對探測請求引入了 MAC 位址隨機化技術。裝置不再廣播真實的硬體 MAC，而是產生一個隨機的 MAC 位址進行掃描。在 iOS 上，這種隨機化是針對每個 SSID 進行的——這意味著裝置在連線到特定網路時會使用一致的隨機 MAC，但在進行探測時則使用不同的隨機 MAC。在 Android 上，具體實作方式則因製造商而異。 這對場所營運商的實際影響非常顯著。對於未連線的裝置，依賴持久性 MAC 位址的探測型人流分析現在已不再可靠。不重複的裝置數量會被高估。僅憑探測數據來識別重複訪客已不再可行。 解決方案——這也是經身分驗證的訪客 WiFi 變得至關重要的原因——是將您的身分識別層從 MAC 位址轉移到已驗證的使用者。當訪客透過 Captive Portal 或社群媒體登入連線時，您就能擷取到一個持久且經同意的身分識別，該識別不會受到 MAC 隨機化的影響。Purple 的訪客 WiFi 平台正是這樣做的——它將分析與已驗證的會話（session）綁定，而非硬體位址，無論裝置的 MAC 行為如何，都能為您提供準確且符合 GDPR 規範的人流數據。 探測請求（probe requests）還存在網路安全分析人員需要瞭解的安全維度。由於探測請求是未加密的管理訊框，因此任何使用監聽模式封包擷取工具的人都可以看見它們。定向探測請求會洩露裝置先前連接過的網路 SSID — 即所謂的偏好網路清單（PNL）。這是一個真實存在的隱私洩露風險。在您場域中移動的裝置正在廣播它曾加入過的每個網路名稱。這也是當初引入 MAC 隨機化技術的原因之一。 從攻擊面的角度來看，探測請求會促成邪惡雙生（evil twin）攻擊。擷取到特定 SSID 定向探測請求的攻擊者，可以架設一個使用該 SSID 的惡意存取點，並等待裝置自動連接。WPA3 的增強型開放（enhanced open）和對等實體同時驗證（SAE）協定顯著降低了這種風險，但前提是您的基礎設施必須支援並強制執行這些協定。 實作建議與常見陷阱。 好的，讓我們來看看在實際部署中該如何具體應對。 首先，如果您要在高密度場域中部署或更新訪客 WiFi 網路，您的存取點配置和頻道規劃必須考慮到探測請求的開銷。採用最小頻道寬度策略（在 2.4 GHz 上為 20 MHz），並實施最小 RSSI 閾值以防止遠處的裝置進行關聯。大多數企業級控制器允許您設定探測回應過濾，以便 AP 僅回應高於特定訊號強度的裝置。這能顯著減少管理訊框的雜訊。 其次，如果您正在進行客流量或停留時間分析，請接受僅靠探測數據已不再足夠的事實。您的分析策略需要圍繞著已驗證的連線階段來建構。這意味著您的 Captive Portal 或登入流程必須足夠流暢，才能讓訪客真正建立連線。Purple 的數據顯示，擁有設計良好的登入體驗（社群登入、電子郵件擷取或免密碼流程）的場域，其裝置連線率可達場域內裝置的 60% 到 80%。這才是您的分析樣本群。 第三，為了符合英國和歐盟的 GDPR 規範，收集探測請求數據（即使已去識別化）也需要進行仔細的法律依據評估。如果您為了分析而擷取並儲存探測訊框，您需要記錄您的正當利益依據並確保數據最小化。資訊專員辦公室（ICO）關於 WiFi 追蹤的指引非常明確：如果您能從數據中識別出個人（即使是間接識別），它就屬於個人資料。在部署任何基於探測的分析系統之前，請先與您的資料保護官（DPO）合作。第四，在密集環境中要留意探測風暴（probe storms）。如果您在人流量大的場域中發現無法解釋的吞吐量下降，請提取您的 AP 日誌並查看管理訊框率。探測風暴通常是罪魁禍首。解決方法是結合最小 RSSI 過濾、探測回應速率限制，並確保您的 5 GHz 頻段已正確廣播，以便支援的裝置優先選擇它而非 2.4 GHz。 快速問答。 讓我快速解答幾個經常出現的問題。 我可以在沒有 Captive Portal 的情況下使用探測請求來計算人流量嗎？技術上可以，但在 iOS 14 之後，準確度很差。您會看到膨脹的唯一計數，且沒有重複訪客的數據。對於粗略估算之外的任何需求，您都需要經過驗證的會話。 探測請求在 6 GHz WiFi 6E 網路中有效嗎？有效，但有所不同。6 GHz 頻段使用一種稱為 FILS（快速初始連結建立）的探索機制和帶外探索，這改變了探測動態。如果您正在部署 WiFi 6E，請查看您的硬體廠商關於 6 GHz 掃描行為的說明文件。 探測請求（probe request）和關聯請求（association request）有何不同？探測請求是關聯前的階段——裝置正在探索網路。關聯請求則是在驗證之後，當裝置正式請求加入特定網路時發出。它們是 802.11 連線狀態機的不同階段。 連線後 MAC 隨機化會保持一致嗎？在 iOS 上，是的——裝置會針對特定的 SSID 使用穩定的隨機化 MAC。在 Android 上則有所不同，某些實作會在每次連線時重新隨機化。這就是為什麼以會話為基礎的識別，而非以 MAC 為基礎的識別，才是正確的架構。 總結與後續步驟。 總結來說：探測請求是 WiFi 探索的脈搏。您場域中的每台裝置都在不斷產生這些請求。了解它們的結構、限制和安全性影響，對於設計可靠、具備分析能力且合規的訪客 WiFi 部署至關重要。 關鍵要點如下。第一：在 MAC 隨機化普及的世界中，沒有驗證的探測型分析是不可靠的。第二：經過驗證的訪客 WiFi 是您的身分識別層——它是讓您的分析精確且數據符合 GDPR 規範的關鍵。第三：探測風暴管理在高密度場域中是一個實際的營運問題，需要在基礎設施設計階段予以解決。第四：定向探測請求會暴露您裝置的偏好網路清單——這是 WPA3 和網路維護實踐可以減輕的真實安全風險。 如果您想深入了解，Purple 的技術文件介紹了我們的硬體無關平台如何擷取和處理探測數據以及驗證的會話數據，從而為您提供精確的場域分析。您也可以探索我們關於 WiFi 導航和三邊測量的指南，這些指南直接建立在我們今天介紹的探測請求基礎之上。 感謝您的收聽。以上是 Purple 技術簡報。