> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# RUM 上报带宽估算与容量规划

> 在接入 RUM 前估算上报流量需要多少带宽：从用户规模换算到带宽档位的三步方法、实测参考参数、降低带宽的手段与实测校准方式。

接入 RUM 后，终端用户的监控数据会持续上报到接收端。对于需要提前采购带宽或规划私有化部署链路容量的团队，本文给出一套可代入自己业务参数的估算方法，以及基于真实应用实测的参考值。

## 估算方法：分三步走

带宽估算分三步，每一步的确定性不同，建议分开计算而不是直接套一个总数：

| 步骤 | 换算          | 确定性               |
| -- | ----------- | ----------------- |
| 1  | 带宽 → 事件/秒   | 高。只取决于单事件体积和是否压缩  |
| 2  | 事件/秒 → 并发用户 | 中。随应用类型有 10 倍以上差异 |
| 3  | 并发用户 → 日活   | 低。取决于人均在线时长与业务峰谷比 |

### 基准参数（实测参考值）

以下参数在真实 Web 应用上实测得出，可直接作为估算起点：

| 参数      | 参考值                            | 说明                      |
| ------- | ------------------------------ | ----------------------- |
| 单事件原始体积 | 约 1.9 KB                       | 含会话、页面、设备等公共上下文         |
| 单次上报请求  | 约 15 KB                        | 一个批次约 8 个事件             |
| 批量触发阈值  | 16 KiB / 50 条 / 30 秒           | 任一条件满足即发送               |
| 压缩比     | 约 6.8 : 1                      | deflate，回放与常规事件两类数据实测一致 |
| 事件构成    | resource 约 72%，long task 约 22% | 事件量主要由页面网络请求数驱动         |

### 第一步：带宽 → 事件/秒

单事件 1.9 KB，开启压缩后约 0.28 KB：

| 带宽       | 不开压缩       | 开启压缩         |
| -------- | ---------- | ------------ |
| 10 Mbps  | 约 660 事件/秒 | 约 4,500 事件/秒 |
| 20 Mbps  | 约 1,300    | 约 9,000      |
| 50 Mbps  | 约 3,300    | 约 22,500     |
| 100 Mbps | 约 6,600    | 约 45,000     |

换算公式：`带宽(Mbps) × 1000 ÷ 8 ÷ 单事件 KB = 事件/秒`

### 第二步：事件/秒 → 并发用户

每个活跃用户产生事件的速率随应用类型变化很大：

```text theme={null}
每用户事件率 ≈ 每次页面浏览的事件数 ÷ 页面平均停留秒数
```

| 应用类型               | 事件率（事件/秒/用户） | 说明            |
| ------------------ | ------------ | ------------- |
| 长驻单页（WebSocket 通信） | 约 0.1        | 消息收发不产生事件，见下文 |
| 控制台 / 后台管理         | 约 0.2        | 实测值           |
| 一般 Web 应用          | 约 0.5        | 推算值           |
| 内容 / 电商（高频导航）      | 约 1.3        | 推算值           |

以「开启压缩 + 一般 Web 应用」为例：10 Mbps ÷ 0.5 事件/秒 ≈ **9,000 并发用户**。

<Note>
  事件率取决于**网络传输方式**，而不是业务繁忙程度。SDK 只对 `XMLHttpRequest` 和 `fetch` 插桩，不追踪 WebSocket，也不记录键盘输入。因此 WebSocket 高频收发消息**不产生任何事件**；反之，HTTP 短轮询每次轮询都是一个 resource 事件（3 秒轮询 = 每用户 +0.33 事件/秒）。估算前先确认应用的数据通道类型。
</Note>

### 第三步：并发用户 → 日活

```text theme={null}
日活 = 峰值并发 × 86400 ÷（人均每日在线秒数 × 峰值系数）
```

* **人均每日在线秒数**：后台类应用可达 3,000 秒以上，面向公众的应用通常低得多
* **峰值系数**：业务时段集中度，一般取 3 \~ 5；业务高度集中（考试、抢购类）可达 8 以上

这一步没有通用值，务必代入自己的业务数据。

## 影响带宽的两个关键开关

### 上报压缩（Web 端默认关闭）

浏览器 SDK 的 `compressIntakeRequests` 默认关闭，开启后带宽降至约 1/6.8，且没有数据损失：

```js theme={null}
flashcatRum.init({
  // ...
  compressIntakeRequests: true,
});
```

这是所有降带宽手段里唯一零代价的一项，建议始终开启。移动端（Android / iOS / HarmonyOS）SDK 默认已开启压缩，无需配置。

### 会话重放（默认关闭）

会话重放的数据量与常规事件不在一个量级：实测约为常规 RUM 事件总量的 **20 \~ 30 倍**，具体取决于页面 DOM 变更频率。启用重放前建议先对小比例会话开启，实测一天后再确定采样率，不要直接套用倍数估算。详见[会话重放](/zh/rum/session-replay/overview)。

## 移动端与 Web 的差异

移动端不能直接套用 Web 参数，人均带宽成本约为 Web 的 1/20：

|               | Web 浏览器 SDK          | Android / iOS / HarmonyOS SDK |
| ------------- | -------------------- | ----------------------------- |
| 上报压缩默认值       | 关闭（需手动开启）            | **默认开启**                      |
| 单事件原始体积       | 约 1.9 KB             | 约 1.2 KB                      |
| resource 事件来源 | 页面全部静态资源 + XHR/fetch | 仅 App 主动发起的 API 请求            |

混合客户端（Web + App）应分端估算后相加，不要用统一事件率。

## 降低带宽的手段

按性价比排序：

| 手段                                         | 效果        | 代价            |
| ------------------------------------------ | --------- | ------------- |
| 开启上报压缩（Web）                                | 降至约 1/6.8 | 无             |
| 降低[会话采样率](/zh/rum/best-practices/sampling) | 线性下降      | 长尾问题复现能力下降    |
| 关闭资源采集（`trackResources: false`）            | 降至约 1/3.6 | 失去接口与静态资源性能数据 |
| 过滤第三方域名资源                                  | 视页面构成而定   | 通常无损          |
| 关闭长任务采集（`trackLongTasks: false`）           | 降至约 1/1.3 | 失去主线程阻塞分析     |

## 私有化部署：两段链路的容量关系

私有化部署常见「公网接入机 + 内部机房」两段链路。若接入层为 nginx `proxy_pass` 透传（不解压、不解析），两段的字节数基本相等，**容量按同一个数字准备**；客户端压缩一次配置即同时降低两段。

接入层三项常见配置检查：

1. **上游连接复用**：`upstream` 配置 `keepalive`，并设 `proxy_http_version 1.1`、清空 `Connection` 请求头，避免跨机房每请求重建连接
2. **请求体上限**：`client_max_body_size` 默认 1 MB，会话重放分片与 SourceMap 上传会超出触发 413，建议调至 20 MB 以上
3. **回程流量**：上报响应约 0.4 KB/请求，开启压缩后约为入方向的 18%，出方向计费的链路不宜忽略

## 用实测校准估算

上文参数是通用参考值，正式采购前建议用两种方式之一校准：

* **灰度外推（推荐）**：对 1% 用户开启采集运行一天，读取入口实际流量后线性放大，误差通常在 20% 以内
* **单请求实测（快速）**：开发者工具中过滤上报域名，读取请求头的 `Content-Length`（注意 Network 面板 Size 列显示的是响应体积，不是上传体积），结合请求频率推算

<Note>
  表中数值为估算参考，用于确定采购档位与容量规划，不构成服务等级承诺。实际用量以校准结果为准。
</Note>