頻寬使用量量測：方法、KPI 與設定
Published
無論您營運的是飯店、校園還是連鎖場域，每月報告都顯示上行鏈路僅部分使用。然而到了晚上，訪客網路變慢，客服工單照樣湧入。這種落差就是只看月總量時，不良的頻寬使用量測量會呈現的狀況。
平均流量是一個很有用的基準，但無法說明尖峰時段、流量方向，或晚上 9 點是哪個群組在使用網路。加密技術使舊有捷徑更加不可行，因為連接埠號碼與封包內容檢測已無法再準確識別應用程式。
目前依然有效的做法更為精確：在指定地點計算雙向位元組、維持足夠的抽樣頻率以觀察需求輪廓，並將使用量歸因至特定工作階段、VLAN 或金鑰。任何更細微的分析都應標示為推論。以下設定涵蓋了哪個數據源能回答什麼問題、哪些 KPI 值得發出警報，以及在全場域推廣前，如何在單一場域驗證這些數字。
目錄
- 選擇符合您問題的方法
- 顯示需求而非僅是流量的 KPI
- 如何透過八個步驟設定測量
- 抽樣與完整擷取的比較及其各自成本
- 當大多數流量加密時歸因使用量
- 為什麼您的數據不一致以及如何進行調節
- 在全公司提報前先於單一站點進行驗證
選擇符合您需求的測量方法
飯店集團全天的上行容量使用率可能維持在 35% 左右，但每天晚上仍然會收到房客的投訴。平均值回答的是容量問題，而房客提問的則是尖峰時段的問題。頻寬使用量測量只有在數據來源與問題互相對齊時才有幫助，因此大多數場域在繪製圖表之前，都需要兩種數據來源：一種用於總量與趨勢，另一種則用於歸因。
您幾乎不需要新硬體。基地台、控制器、路由器和驗證服務上已經具備六種資料來源。
| 來源 | 報告內容 | 粒度 | 最佳用途 | 開銷 |
|---|---|---|---|---|
| SNMP 介面計數器 (ifHCInOctets, ifHCOutOctets) | 每個連接埠或無線電的進出位元組數 | 每個介面，每 1 - 5 分鐘輪詢一次 | 上行鏈路趨勢與容量規劃 | 低 |
| NetFlow v9 或 IPFIX | 包含來源、目的地、連接埠、位元組和封包的流量記錄 | 每筆流量，通常每 1 - 5 分鐘匯出一資料 | 高流量使用者（Top talkers）與通訊對象分析 | 中，來自匯出與 CPU 負載 |
| sFlow | 抽樣的封包表頭加上介面計數器 | N 個封包中抽樣 1 個，按比例按估算值放縮 | 高速鏈路（10G 及以上）與近乎即時的高流量使用者分析 | 低，抽樣在硬體中執行 |
| 個別 SSID 與個別 VLAN 計數器 | 每個無線網路或 VLAN 的位元組數和客戶端數量 | 每個 SSID、VLAN 和無線基地台 | 訪客與員工負載以及每個 SSID 的空口時間成本 | 低 |
| RADIUS 計費 (Acct-Input-Octets, Acct-Output-Octets) | 每個已驗證工作階段的位元組數 | 每個工作階段，每 5 - 15 分鐘進行期中更新 | 將使用量歸因給特定使用者、裝置或金鑰 | 低 |
| DNS 與防護型 DNS 記錄檔 | 依策略或類別區分的網域名稱查詢 | 每次查詢 | 無需進行封包負載檢視的類別級別深入分析 | 低至中 |
使計數器與分析問題互相匹配
SNMP 計數器是總量的資料來源。請輪詢 64 位元物件 ifHCInOctets 與 ifHCOutOctets。在 1 Gbps 連接埠上，32 位元的位元組計數器在大流量下約 34 秒就會循環一次，因此在舊物件上進行 5 分鐘輪詢會產生負數或毫無意義的差值。Per-SSID 計數器可顯示用戶端負載以及每個 WiFi 網路的空口時間（Airtime）成本。當封包內容經加密時，RADIUS accounting 會將位元組連結至特定使用者、裝置或金鑰，作為歸因分析的資料來源。
行動網路需求龐大，將其混入固定據點的總量中會掩蓋關鍵的限制。根據 ITU 事實與數據 2024，2023 年全球網際網路流量中的行動寬頻終端使用者流量達到了 1 ZB。場地上行鏈路與蜂巢式網路分流路徑是兩種截然不同的測量指標。
在設定任何項目之前，請先為每個據點挑選一個主要總量來源與一個歸因來源。日後新增第三個來源很容易，但在一個月後解開兩個未標籤的來源卻十分困難。
反映真實需求而不僅是流量的關鍵績效指標
可用的基準會在終端使用者存取點計算總流量（下載量與上傳量相加），並在一個一致的時間段內進行（通常為一個日曆月）。引自 ITU 方法學的歐盟統計局元資料 以此方式定義固定寬頻流量，並透過排除批發和圍牆花園（walled-garden）流量來區分行動寬頻流量。這種邊界對場域網路來說同樣重要。顧客使用量並不等同於骨幹容量或從未離開營運商的流量。
在每份報告中載明測量點名稱。說明是否已排除管理與控制訊框。若缺少這些控制變數，即使兩個場地的使用者數量相同，結果也無法相互比較。
實用規則：如果 KPI 未載明端點、方向、採樣間隔與時間範圍，就表示尚未準備好作為警示依據。
可手動核對的計算公式
平均吞吐量為總位元組數乘以 8，再除以該時段的秒數。峰值吞吐量是最高 1 分鐘或 5 分鐘的採樣值，而非每月平均值。第 95 百分位數會對每個採樣進行排序，並取 95% 處的值，因此單次檔案複製不會直接判定繁忙程度。繁忙時段流量是單一最高時段內的位元組數，而該時段就是您規劃容量的基準。同時連線的活動用戶端會計算在同一個時間視窗內傳輸資料的裝置數。空中時間利用率是頻道處於繁忙狀態的時間比例，取自基地台無線電計數器；當上行鏈路看似正常時，這往往是無線網路的效能瓶頸所在。上行比例則是上行位元組數除以總位元組數。
| KPI | 計算方式 | 代表意義 | 計算範例 |
|---|---|---|---|
| 總流量 | 指定期間內的進出位元組總和 | 容量基準與每月趨勢 | 每天 40 GB 乘以 30 天等於每月 1.2 TB |
| 平均吞吐量 | （位元組 x 8）除以秒數 | 平均負載 | 每天 40 GB 約等於平均 3.7 Mbps |
| 峰值吞吐量 | 最高值的 1 分鐘或 5 分鐘採樣 | 突發需求 | 該上行鏈路上最繁忙的 5 分鐘採樣 |
| 第 95 百分位吞吐量 | 將採樣排序並取第 95% 的數值 | 扣除罕見尖峰後的持續繁忙程度 | 整個月 5 分鐘輪詢採樣中的 95% 標記點 |
| 繁忙小時流量 | 最高流量小時內的位元組數 | 最糟小時的容量評估 | 晚上 9 點該小時內產生 9 GB |
| 同時連線的活動用戶端 | 在同一採樣區間內傳輸資料的用戶端 | 資源爭奪與空口時間（Airtime）壓力 | 在單一 5 分鐘區間內有 45 個用戶端傳輸資料 |
| 空口時間利用率 | 來自 AP 無線電計數器的頻道繁忙時間 | 無線網路擁塞程度 | 頻道保持繁忙的時間比例 |
| 上行流量佔比 | 上行位元組數除以總位元組數 | 視訊通話、雲端備份、檔案上傳 | 總流量 10 GB 中上行佔 2 GB，相當於 20% |
這些計算出來的數據僅供算術核對，並非您各場地應達成的目標。平均傳輸速率為 3.7 Mbps 的場地，仍有可能在某個小時內呈現飽和狀態。
儀表板之前的警報
在發送第一份報告之前先設定好門檻。合理的第一步是標記任何第 95 百分位數在整個繁忙時段內持續高於上行鏈路容量 80% 的站點，並調查任何在連續數個晚上空中時間利用率皆居高不下的頻道。在累積一個月的基準資料後調整這兩項參數。按站點、SSID 和 VLAN 進行報告。單一的整體平均值會掩蓋效能不佳的據點，這也是為什麼 單一位置使用量檢視 必須與原始計數器搭配使用的原因。
在公開任何數據之前，您應該能夠用一句話說明其測量點、方向、抽樣間隔以及時間週期。
設定測量的八個步驟
在動到任何設備之前，請先規劃好資料收集設計。下列八個步驟是歷經人員更迭與韌體升級後仍能維持運作的最基本要求。
先記錄規格，再開始收集
用一句話寫出問題與範圍。範例：每個訪客 SSID、每個據點、每月、雙向的位元組數。如果這句話包含兩個問題，您最終會製作出兩個半成品報表。常見的失誤是從儀表板範本開始，而不是從您試圖解釋的工單開始。
選擇測量點。上行鏈路或無線控制器提供總量。核心路由器提供流量 (flows)。邊緣防火牆僅提供外部流量，並會遺漏 LAN 到 LAN 的傳輸。請勿將這三者相加。常見的失誤是將它們視為同一個數字的重複項目。
啟用 64 位元計數器輪詢。繁忙的上行鏈路使用 1 分鐘間隔，長期趨勢使用 5 分鐘間隔。一分鐘的資料能顯示出五分鐘平均值所平撫的突發流量。輪詢 32 位元物件是會先損壞最繁忙連接埠的失誤。
將流量匯出至收集器。將活動逾時設定為 1 到 5 分鐘，以便長會話在結束前就能顯示。如果沒有該逾時設定，視訊通話在訪客斷開連線之前看起來就像完全沒有消耗流量一樣。請留意路由器上的 CPU 和匯出丟失情況。落後的收集器會在不知不覺中少算流量。
標籤每個系列。據點、SSID、VLAN 和基地台名稱在儲存記錄時必須包含在內。未標籤的資料日後無法進行切片分析，而且在下個季度重新命名 SSID 也無法修復歷史資料。常見的失誤是假設裝置主機名稱是一個穩定的據點金鑰。
開啟具備過渡更新的 RADIUS 計費。十五分鐘是一個實用的間隔。過渡記錄可以保持長會話的可見性，並且能在用戶端未傳送乾淨停止訊號的情況下保留下來。如果您等待斷開連線，只要丟失停止訊號，跨夜會話就會從每日報表中消失。
保留期與已知傳輸測試
明確設定資料保留期。保留 13 個月的 5 分鐘總計資料，以便與明年的同一週進行比較。保留 7 至 14 天的原始流量記錄。為每個站點保留完整的流量歷史紀錄，付出的代價遠高於其帶來的效益。最常見的疏失就是因為沒有人設定刪除工作，而永久保留原始流量記錄。
透過已知傳輸進行驗證。在單一裝置上下載一個 10 GB 的檔案，並確認您選為主要基準的計數器總量變動幅度落在合理的幾個百分比以內。在任何人信任圖表之前先完成此步驟。跳過驗證往往會導致計數器溢位或單向流量匯出被誤用於容量規劃。
如果步驟 8 失敗，請立即停止。修復計數器、超時設定或遺失的路徑。切勿將相同的設定套用到下一個場地。
抽樣與完整擷取的比較及其成本分析
總量來自計數器，主要發送者來自未採樣的流量紀錄，高速連結採用採樣，而全封包擷取則用於短暫的鑑識時間窗。準確度、儲存空間與隱私性呈反向變動，因此若對所有問題都使用單一方法，不是數據失真，就是硬碟被塞滿。
| 方法 | 準確度 | 儲存與開銷 | 隱私暴露風險 | 最適合用於 |
|---|---|---|---|---|
| 每 5 分鐘輪詢一次介面計數器 | 精確的位元組總量 | 極小 | 無 | 總量、趨勢與計費檢查 |
| 未抽樣的流量記錄 (NetFlow 或 IPFIX) | 每條流量皆精確，扣除匯出遺失 | 中等，隨流量數量增加 | 低，僅限標頭 | 高流量使用者與連接埠層級應用程式提示 |
| 1/1,000 至 1/4,000 封包的 sFlow | 估計值，對小流量較不準確 | 低 | 低，標頭與截斷的承載資料 | 10G 及以上的快速鏈路 |
| 完整封包擷取 | 精確，每個封包 | 極高，繁忙的 10G 鏈路上每天數 TB | 高，可能包含個人資料 | 事件期間的短期鑑識時間視窗 |
各個方法的局限與失效情境
介面計數器能精確記錄位元組，但無法說明發送者。當帳單或容量爭議需要提出可信任的依據時可以使用，但它們無法指出具體的發送者。
未抽樣的 NetFlow 或 IPFIX 會記錄每一筆流量，這正是找出高流量使用者（top talkers）所需要的。然而，匯出遺失與過載的收集器仍會在繁忙的路由器上遺失記錄，因此流量總和可能會低於介面計數器，這並非設定錯誤所致。請將此差距視為系統健康訊號，而非未使用的容量。
sFlow 在硬體層面進行抽樣，通常在存取與核心鏈路上採樣約 1/1,000 至 1/4,000 的封包，然後將樣本等比例放大為流量估算值。這在 10G 及 faster 鏈路上能保持低成本運作。不過小流量可能會消失。訊息傳送、DNS 以及大量短暫的 HTTPS 連線，恰好是這種估算最薄弱的地方；因此切勿使用 sFlow 進行計費，也不要用它來證明單一設備的使用量。
全封包擷取十分精確，在繁忙的 10G 線路速率下，一天可能產生數 TB 的資料。封包內容可能包含政策不允許留存的個人資料。
如果為了爭議必須提供精確答案，請使用計數器。如果需要提示應用程式類型，請使用僅含表頭的流量紀錄。如果是單一偶發事件，請進行一小時內的擷取，並在時間窗結束時停止擷取。
當多數流量皆已加密時如何進行使用量歸因
封包內容檢測是命名應用程式的可靠性較低的依據。根據 Help Net Security 對 Cloudflare 2025 年網際網路趨勢的摘要，近期測量結果顯示 至 2025 年底，HTTPS 已佔觀測到的請求量 95% 以上。QUIC、加密 DNS、共享 CDN、VPN 以及隱私功能，讓基於連接埠的標籤更加不可靠。
加密流量並不會讓頻寬使用量測量變得不可能，它只是改變了證據的形式。您依然可以測量位元組、封包、時間點、方向、連線數、重傳次數與延遲。在政策允許的情況下，您還可以加上目的地類別或已驗證的身分。您只是無法宣稱是透過封包負載內容來判斷應用程式而已。
標示信心水準的架構
請根據有據可循的記錄建立歸因模型。
- RADIUS 工作階段位元組數（高可信度）：Acct-Input-Octets 和 Acct-Output-Octets 將流量連結至已驗證的工作階段、裝置或 xPSK 金鑰。當計費路徑完整時，"此裝置消耗了 8 GB" 具有很高的可信度。
- 個別 VLAN 計數器（群組的高可信度）：訪客、員工、收銀機和 IoT 各自落於不同的 VLAN，因此群組負載不需要解密任何內容。
- DNS 策略類別（中等，並已標記）：類別總計提供類似應用程式的深入分析。"影片消耗了 5 GB" 屬於一種推論。請在報告上註明這一點。
- 彙整流量記錄（應用程式名稱的可信度低）：表頭仍會顯示誰與哪個位址通訊以及傳輸了多少位元組。共享的 CDN 位址並不代表特定應用程式。
隨機 MAC 位址會破壞裝置計數。同一部手機跨日可能看起來像兩部裝置，這會膨脹使用者總數並分散其封包流量。當策略提供該身分時，請按每人或每個金鑰來計算會話數。對於零售賣場而言，相同的概念也體現在如何在共享無線電波中區分顧客流量與員工流量，這是完善的 零售 WiFi 設計 的一部分。
這部簡短的導覽影片以通俗易懂的語言解釋了其中的權衡取捨。
僅出於疑難排解、容量規劃與合規性目的保留與身分相關的紀錄。按預定時程刪除它們。在每個數字上標註信賴度標籤無需任何成本，且能防止類別猜測被誤認為是實際帳單。
數據不一致的原因與協調解決方案
月平均值可能看起來很健康，但使用者卻每天晚上都在抱怨。這兩種情況往往同時存在。固定與行動網路的混合流量也是一個動態變化的目標。ITU 的 2023 年流量統計數據 顯示，2019 年至 2023 年的年平均成長率約為 30%，其中成長最劇烈的時期為 2020 年疫情爆發初期。單純的流量成長無法解釋糟糕的夜晚，每日的流量分布形態才是關鍵。
OpenVault 的 2025 年第一季寬頻報告 顯示了為何單一平均值會誤導容量規劃。美國用戶平均使用量達到每月 663.2 GB，年增 9.5%，而企業尖峰時段的下行使用量增長了 21.2%，上行使用量則增長了 23.6%。企業的下行需求在下午 1 點達到尖峰。住宅的上行與下行需求則在晚上 9 點左右達到尖峰。飯店或住宅物業在月度圖表上可能看起來很正常，但仍會在可預測的時間點發生網路故障。單純降低每月 GB 數無法解決該客訴問題。將負載移出尖峰時段，或是改善空口時間（Airtime）與爭奪問題，通常比擴充整體管道頻寬更能有效幫助賓客。
購買頻寬前先辨識數據不一致的情況
| 症狀 | 可能原因 | 檢查項目 |
|---|---|---|
| 計數器顯示容量僅佔 30%，但訪客仍抱怨連線品質 | 平均值掩蓋了夜晚尖峰或空中時間（airtime）爭用問題 | 比較繁忙時段的第 95 百分位數與頻道利用率 |
| 流量（Flow）總計比介面計數器低 15% | 抽樣誤差、不對稱路由或某一路徑缺少匯出器 | 在未抽樣的連結上進行比較，並確認每條路徑都有匯出流量 |
| 每個 SSID 的總計加總不等於 AP 的總計 | 排除管理流量，或用戶端在抽樣期間進行漫遊 | 對齊時間戳記並確認每個計數器包含哪些訊框 |
| RADIUS 總計超過裝置數量 | 重新連線後產生重複的工作階段，或重新驗證時計數器歸零 | 按工作階段 ID 分組並檢查歸零處理方式 |
| 單一站點的使用量是另一個相同站點的兩倍 | 使用者組合不同、快取更新或 VLAN 標籤錯誤 | 按 VLAN 與主要目的地類別進行拆解分析 |
| 推出新功能隔天使用量大幅暴增 | 雲端更新或有新的裝置類型加入了網路 | 檢查 DNS 類別以及推出的確切時間 |
請先修正時間同步問題，接著處理抽樣，最後再進行歸因。後續的錯誤會加劇先前的錯誤。
相同據點之間出現兩倍的差距，通常是因為 VLAN 標籤或不同的裝置組合所致，並非什麼神秘的應用程式。在重寫容量規劃之前，請先確認時鐘、導出器（exporter）與工作階段金鑰。單一全企業的平均值並不能作為每個地點的模式。
先在單一場地進行驗證，再推廣至全公司報告
請勿在第一天就將新的測量架構套用到每一個據點。請先在一個具代表性的據點進行二至四周的試行。觀察的時間窗必須包含至少一個繁忙的晚上與一個清閒的工作日，否則您只會驗證出自己本就不信任的平均值。
請將新的收集機制與您目前運行的網路並行運作。在新的數據系列與現有計數器達成一致（總位元組誤差在 5% 以內）之前，切勿替換現有的計數器。透過並行運作，您才能發現計數器溢位、匯出器遺失或未標籤的 VLAN。
請根據兩項測試來評估試點計畫，而不是看儀表板看起來有多完整。
- 工單：尖峰時段的數據是否與您已收到的投訴相符？如果最糟糕的晚上圖表卻很平穩，代表抽樣間隔或測量點設定有誤。
- 稽核：是否有人能回答實際問題，例如某個設備在特定日期使用了哪一個 VLAN？如果記錄無法回答該問題，代表歸因工作尚未完成。
我們首先會在單一站點上，利用該站點既有的基地台，在線上網路旁驗證設計，並在進行更廣泛的部署之前，依據工單與稽核證據進行評估。只需 45 分鐘的設計會議，工程師即可將現有的 SSID 對應到該硬體上的開放、安全和 xPSK 架構，且計畫完全由您保留。網路健康狀態監控接著可從整體設備深入探討至特定位置與硬體設備，提供測速、驗證成功率、下載與行為資料，讓濫用行為一目瞭然而非憑空猜測。無線電規劃仍必須維持完善。單靠量測無法修復從未妥善設計的頻道規劃，這也是為什麼 WiFi 網路設計 始終是一項獨立工作的的原因。
在擴充至第二個據點之前，先設定好報表規則。在所有地方使用相同的時間段和採樣間隔。標記信賴度。按據點、SSID 與 VLAN 製作報表，並為每個儀表板指定明確的負責人。僅在試點數據與計數器一致，且團隊能從數據中解答前三大問題時才進行推廣。如果無法解答，請重新進行不符項檢查。擴大錯誤的基準線只會更快地公開錯誤。
Purple Access 在您現有的基地台部署開放、安全與 xPSK 機制，搭配可與使用者、裝置或金鑰連結的雲端 RADIUS 計費功能，以及能將平穩的月平均值與糟糕的尖峰小時區隔開來的健康度檢視。在變更其餘資產之前，先在單一據點根據您的事件單與稽核軌跡進行驗證。歡迎造訪 Purple Access，了解其如何適合您的場地。
