带宽使用测量：方法、KPI 与设置
Published
您运营着一家酒店、一个园区或一个连锁场所。月度报告显示上行链路仅使用了部分容量。然而到了晚上，访客网络变慢，工单依然随之而来。这种差距正是不完善的带宽使用量测量止步于月度汇总时的典型表现。
平均流量是一个有用的基准线。但它无法反映高峰时段、流量方向，或者晚上 9 点是哪个群体在使用网络。加密技术让旧的捷径变得更加不可靠，因为端口号和数据包载荷检查已无法准确判断应用类型。
依然有效的方法范围更窄。在指定节点计算双向字节数，以足够高的频率采样以观察需求形态，并将使用量归因于某个会话、VLAN 或密钥。任何更细颗粒度的标注都应视为推论。以下设置涵盖了哪个数据源回答哪个问题、哪些 KPI 值得警报，以及在向所有场所推广之前如何在单个场所验证这些数据。
目录
- 选择匹配您问题的测量方法
- 展示需求而不仅是流量的 KPI
- 通过八个步骤配置测量体系
- 抽样捕获与全量捕获的对比及各自成本
- 大多数流量加密时的用量归因
- 数据不一致的原因及调和方法
- 在全公司报告前先在单一站点进行验证
选择符合您需求的方法
酒店集团的上行链路利用率全天可能仅保持在 35% 左右，但每天晚上仍会收到住客投诉。平均值回答的是容量问题。而住客提出的则是高峰时段问题。只有当数据源与所要解决的问题相匹配时，带宽使用量测量才有意义，因此在绘制图表之前，大多数场所都需要两条数据源 Feed。一条 Feed 用于汇总和趋势分析。另一条 Feed 用于归因。
您很少需要购买新硬件。接入点、控制器、路由器和身份验证服务上已经具备了六种数据源。
| 来源 | 报告内容 | 粒度 | 最适合 | 开销 |
|---|---|---|---|---|
| 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 分钟的轮询会产生负数或无意义的增量。按 SSID 计的计数器可以显示客户端负载以及每个无线网络的空口成本。RADIUS 记账将字节数与用户、设备或密钥关联起来，这是数据包被加密时的归因数据源。
移动网络需求规模庞大，将其混入固定站点总量中会掩盖关键的限制瓶颈。根据 ITU Facts and Figures 2024，2023 年全球移动宽带终端用户互联网流量达到了 1 ZB。场所上行链路与蜂窝网络分流路径是完全不同的衡量指标。
在配置任何内容之前，请为每个站点指定一个主要的总量数据源和一个归因数据源。以后添加第三个数据源很容易。但在一个月后去梳理两个未标记的数据源却非常困难。
展现实际需求而非仅反映流量的 KPI
一个实用的基准是在终端用户接入点统计一个固定周期（通常为一个自然月）内的总流量，即下载量和上传量相加。欧洲委员会基于 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 流量 |
| 并发活跃客户端 | 同一采样窗口内传输数据的客户端数量 | 竞争与空口资源压力 | 在一个 5 分钟窗口内有 45 个客户端在传输数据 |
| 空口利用率 | 来自 AP 射频计数器的信道占用时间 | 无线网络拥塞程度 | 信道保持占用状态的时间比例 |
| 上行流量占比 | 上行字节数除以总字节数 | 视频通话、云端备份和上传活动 | 10 GB 总流量中有 2 GB 为上行流量，占比 20% |
这些计算出的数据仅用于算术核对，而不是您场所的目标值。平均速率为 3.7 Mbps 的场所，仍然可能出现长达一小时的网络饱和。
仪表板之前的警报
在发送第一份报告之前先设定一个阈值。一个合理的起点是：标记任何在整个繁忙小时内第 95 百分位值持续高于上行链路容量 80% 的站点，并调查任何在连续几个晚上空口利用率持续偏高的信道。在一个月的基线测试后对两者进行调整。按站点、SSID 和 VLAN 进行报告。单一的总体平均值会掩盖正在发生故障的特定场所，这就是为什么 按位置划分的使用情况视图 应当与原始计数器并列显示的原因。
在发布任何数据之前，您应该能够用一句话明确说出它的测量点、方向、采样间隔和周期。
分八步设置测量
在接触任何设备之前，先编写好采集设计方案。以下八个步骤是历经一年的人员变动和固件升级后仍能保持有效的最低标准。
先记录方案，再进行采集
用一句话写出问题和边界。 例如：每个访客 SSID、每个站点、每月、双向的字节数。如果一句话里包含两个问题，你就会做出两个半成品报告。常见的失误是直接从仪表板模板开始，而不是从你要解答的工单开始。
选择测量点。 上行链路或无线控制器提供总量。核心路由器提供流（flow）。边缘防火墙仅提供外部流量，并且会遗漏局域网到局域网（LAN-to-LAN）的传输。不要将这三者加在一起。常见的失误是将它们视为同一个数字的重复项。
启用 64 位计数器轮询。 对繁忙的上行链路使用 1 分钟间隔，对长期趋势使用 5 分钟间隔。1 分钟的数据能展示被 5 分钟平均值抹平的突发流量。轮询 32 位对象是导致最繁忙端口数据最先损坏的失误。
将流导出到收集器。 将活动超时设置为 1 - 5 分钟，以便长会话在结束前就能显示出来。如果没有该超时设置，视频通话在访客断开连接之前看起来就像没有消耗任何流量一样。注意路由器的 CPU 和导出丢弃率。落后的收集器会在静默状态下少计数据。
标记每个序列。 存储记录时，必须包含站点、SSID、VLAN 和接入点名称。未标记的数据后续无法进行分片分析，而且下个季度重命名 SSID 也无法修复历史数据。常见的失误是假设设备主机名是稳定的站点键值。
开启带有中间更新的 RADIUS 记账。 15 分钟是一个实用的间隔。中间记录可以保持长会话可见，并且在客户端未发送正常停止信号时依然有效。如果等待断开连接，只要停止信号丢失，过夜会话就会从每日报告中消失。
数据保留与已知传输验证
明确设置保留策略。保留 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,000 到 4,000 个数据包采样 1 个，然后将采样放大为流量估计值。它在 10G 及更快链路上保持低成本。小流量可能会丢失。即时消息、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" 属于推理结论。请在报告中予以明确说明。
- 聚合流记录（应用名称置信度低）：数据包头仍会显示谁与哪个 IP 地址通信以及传输了多少字节。但共享的 CDN 地址并不等同于具体应用。
随机 MAC 地址会破坏设备计数的准确性。一部手机在几天内可能看起来像两台不同的设备，这会虚增客户端总量并分散其流量字节。当策略允许您获取身份时，请按个人或密钥统计会话数。对于零售场景，同样的理念体现在如何在共享无线信道上区分顾客流量与员工流量，这也是合理的 零售 WiFi 设计 的一部分。
这段简短的演示简单明了地说明了其中的权衡取舍。
与身份绑定的记录仅可用于故障排查、容量规划和合规审计。应按计划定期删除。为每个数据标明置信度标签无需任何成本，却能防止分类猜测被误认为是账单依据。
为什么您的数据不一致以及如何调和它们
月度平均数据可能看起来很正常，但用户却每天晚上都在抱怨。这两句话往往都是事实。固定和移动混合流量也是一个动态变化的目标。ITU 2023 年流量统计数据 显示，2019 年至 2023 年的年均增长率约为 30%，其中 2020 年疫情初期增长最为迅猛。单凭业务增长无法解释体验差劲的夜晚，但一日之内的流量形态趋势可以。
OpenVault 的 2025 年第一季度宽带报告 展示了为什么单一平均值会误导容量规划工作。美国用户的平均使用量达到了每月 663.2 GB，同比增长 9.5%，而企业高峰时段的下行使用量增长了 21.2%，上行使用量增长了 23.6%。企业下行需求在下午 1 点达到峰值。住宅区的上行和下行需求则在晚上 9 点左右达到峰值。酒店或住宅物业的月度图表看起来可能很正常，但仍可能在可预测的特定时段发生故障。仅仅削减月度计量的 G 字节数并不能解决这类投诉。将负载移出高峰时段，或者解决空口利用率和竞争问题，往往比升级更大的总带宽管道对宾客更有帮助。
在购买带宽之前先分析数据偏差
| 症状 | 可能的原因 | 检查项目 |
|---|---|---|
| 计数器显示占容量的 30%，但访客仍有抱怨 | 平均值掩盖了晚高峰或空口时间竞争（Airtime Contention） | 对比忙时 95 位数值与信道利用率 |
| 流总量比接口计数器低 15% | 抽样误差、不对称路由或某一路径缺失导出器 | 在非抽样链路进行对比，并确认每条路径均导出流数据 |
| 单 SSID 总量相加不等于 AP 总量 | 未包含管理流量，或客户端在抽样期间发生漫游 | 对齐时间戳并确认每个计数器包含哪些帧类型 |
| RADIUS 总量超过设备数量 | 重新连接后产生重复会话，或重新认证时计数器重置 | 按会话 ID 分组并检查重置处理机制 |
| 某一站点的用量是完全相同站点的两倍 | 用户构成不同、存在缓存更新或 VLAN 标签错误 | 按 VLAN 和顶级目标类别进行拆分分析 |
| 部署次日用量大幅激增 | 云端更新或有全新设备类型加入了网络 | 检查 DNS 类别以及部署的具体时间点 |
先解决时间同步问题，其次是采样，最后是归因。后期的错误会加剧前期的偏差。
相同站点之间两倍的差距通常是因为 VLAN 标签或不同的设备组合，而非某种神秘的应用。在重写容量规划之前，请先确认时钟、导出设备和会话密钥。全企业统一的平均值无法作为每个具体场所的模型。
在全公司报告前先在一个场所进行验证
第一天不要将新的测量方案推行到所有场所。先在一个有代表性的站点开展为期两到四周的试点。测试时间窗口必须包含至少一个繁忙的夜晚和一个空闲的工作日，否则你只能证明自己原本就不信任的平均值。
将新的数据采集并行部署在您当前运行的网络旁。在新的数据系列与现有计数器保持一致（总字节数误差在 5% 以内）之前，请勿替换现有计数器。并行运行是发现计数器溢出重置、导出器缺失或未标记 VLAN 的有效方式。
根据两项测试来评估试点项目，而不是看仪表板看起来有多完整。
- 工单：高峰时段的数据是否与您已收到的投诉吻合？如果图表在最糟糕的晚上依然平缓，说明采样间隔或测量点设置错误。
- 审计：是否有人能回答实际问题，例如某台设备在特定日期使用了哪个 VLAN？如果日志轨迹无法回答该问题，则归因尚未完成。
我们首先会在一个星期的某一台现有的接入点上，在现有生产网络旁对设计方案进行验证，并在全面推广之前，根据工单和审计凭据对其进行评估。只需 45 分钟的设计会话，工程师即可将现有的 SSID 映射到该硬件上的开放、安全和 xPSK 模式，且计划由您保留。随后，网络健康状况监控可以从整个资产下钻到具体位置和硬件设备，提供测速、身份验证率、下载及行为数据，使误用行为清晰可见而非盲目猜测。当然，无线电规划仍必须合理。仅凭测量无法修复从未经过精心设计的信道规划，这就是为什么 WiFi 网络设计 仍然是一项独立工作的原因。
在扩展至第二个站点之前制定好报表规则。在所有地方使用相同的周期和采样间隔。标记置信度。按站点、SSID 和 VLAN 进行汇报，并为每个仪表板指定明确的负责人。只有当试点数据与计数器对齐，且团队能够根据数据回答最核心的三大问题时，才进行全面推广。如果做不到，请重新检查不匹配项。扩大一个存在缺陷的基线只会加速错误的传播。
Purple Access 可在您现有的 AP 上部署开放、安全及 xPSK 网络，提供可与用户、设备或密钥绑定的云 RADIUS 计费功能，以及能够区分平稳月均数据与恶劣高峰时段的健康状况视图。在更改其余资产之前，先在一个站点上针对您的工单和审计日志进行验证。请访问 Purple Access，了解其如何匹配您的场所需求。
