估算方法：分三步走
带宽估算分三步，每一步的确定性不同，建议分开计算而不是直接套一个总数：基准参数（实测参考值）
以下参数在真实 Web 应用上实测得出，可直接作为估算起点：第一步：带宽 → 事件/秒
单事件 1.9 KB，开启压缩后约 0.28 KB：
换算公式：
带宽(Mbps) × 1000 ÷ 8 ÷ 单事件 KB = 事件/秒
第二步：事件/秒 → 并发用户
每个活跃用户产生事件的速率随应用类型变化很大：
以「开启压缩 + 一般 Web 应用」为例：10 Mbps ÷ 0.5 事件/秒 ≈ 9,000 并发用户。
事件率取决于网络传输方式，而不是业务繁忙程度。SDK 只对
XMLHttpRequest 和 fetch 插桩，不追踪 WebSocket，也不记录键盘输入。因此 WebSocket 高频收发消息不产生任何事件；反之，HTTP 短轮询每次轮询都是一个 resource 事件（3 秒轮询 = 每用户 +0.33 事件/秒）。估算前先确认应用的数据通道类型。第三步：并发用户 → 日活
- 人均每日在线秒数：后台类应用可达 3,000 秒以上，面向公众的应用通常低得多
- 峰值系数：业务时段集中度，一般取 3 ~ 5；业务高度集中（考试、抢购类）可达 8 以上
影响带宽的两个关键开关
上报压缩（Web 端默认关闭）
浏览器 SDK 的compressIntakeRequests 默认关闭，开启后带宽降至约 1/6.8，且没有数据损失：
会话重放（默认关闭）
会话重放的数据量与常规事件不在一个量级：实测约为常规 RUM 事件总量的 20 ~ 30 倍，具体取决于页面 DOM 变更频率。启用重放前建议先对小比例会话开启，实测一天后再确定采样率，不要直接套用倍数估算。详见会话重放。移动端与 Web 的差异
移动端不能直接套用 Web 参数，人均带宽成本约为 Web 的 1/20：
混合客户端（Web + App）应分端估算后相加，不要用统一事件率。
降低带宽的手段
按性价比排序：私有化部署：两段链路的容量关系
私有化部署常见「公网接入机 + 内部机房」两段链路。若接入层为 nginxproxy_pass 透传（不解压、不解析），两段的字节数基本相等，容量按同一个数字准备；客户端压缩一次配置即同时降低两段。
接入层三项常见配置检查：
- 上游连接复用：
upstream配置keepalive，并设proxy_http_version 1.1、清空Connection请求头，避免跨机房每请求重建连接 - 请求体上限：
client_max_body_size默认 1 MB，会话重放分片与 SourceMap 上传会超出触发 413，建议调至 20 MB 以上 - 回程流量：上报响应约 0.4 KB/请求，开启压缩后约为入方向的 18%，出方向计费的链路不宜忽略
用实测校准估算
上文参数是通用参考值，正式采购前建议用两种方式之一校准：- 灰度外推（推荐）：对 1% 用户开启采集运行一天，读取入口实际流量后线性放大，误差通常在 20% 以内
- 单请求实测（快速）：开发者工具中过滤上报域名，读取请求头的
Content-Length（注意 Network 面板 Size 列显示的是响应体积，不是上传体积），结合请求频率推算
表中数值为估算参考，用于确定采购档位与容量规划，不构成服务等级承诺。实际用量以校准结果为准。