RPS与Tbps换算：从请求计数到比特吞吐的容量规划指南

1. 为什么“RPS 换算 Tbps”值得单独拎出来讲

做后端性能压测、容量规划或者网络设备选型的人，几乎都遇到过这种对话：业务方说“我们峰值每秒要扛 50 万请求”，网络组回一句“那你带宽得按几个 T 算”。两边说的其实不是一回事，但会上没人把它翻译清楚，最后要么带宽买多了浪费预算，要么上线当天链路先被打满，应用层还没开始报错，网络层已经丢包了。

每秒请求数（RPS，Requests Per Second）和 Tbps（Terabits per second）之间的换算，本质上是把“应用层的请求计数”翻译成“物理层的比特吞吐”。这个换算没有唯一答案，因为它取决于每个请求平均携带多少字节、协议开销占多少、连接复用效率如何、上下行是否对称。标题里问“你知道吗”，问的其实是那个最容易被忽略的中间变量——平均请求大小。很多人下意识拿一个拍脑袋的数字去乘，比如“一个请求算 1KB 吧”，结果误差能到十倍以上。

这篇内容适合三类人看：一是做容量规划的后端或 SRE，需要给网络团队报带宽数字；二是做压测的测试工程师，压出 RPS 之后要判断瓶颈到底在应用还是链路；三是刚接触网络设备选型的同学，看到“整机吞吐 4Tbps”这种参数想知道跟自己业务的 RPS 怎么对上。下面我会把换算的推导、每个参数的取值逻辑、实操中怎么测、以及踩过的坑，一条条拆开讲。全程用从业者之间交流的口吻，能直接抄的公式和步骤都会给出来。

2. 换算的底层逻辑：从“次数”到“比特”中间隔着什么

2.1 一个请求到底占多少比特

先把最朴素的公式摆出来。假设平均每个请求（含请求行、头部、正文，以及对应的响应）在网络上传送的总字节数是S字节，那么单个请求占用的比特数就是S × 8。RPS 为R时，所需带宽（单位 bit/s）为：

带宽(bit/s) = R × S × 8

换算成 Tbps 就是再除以 10^12：

带宽(Tbps) = R × S × 8 / 10^12

看起来简单得不像话，问题全在S上。S 不是一个固定值，它是“请求 + 响应”双向字节的总和，而且必须包含协议头。我见过太多人只算响应体大小，把请求头、响应头、TCP/IP 头全漏掉，小请求场景下误差能到 40% 以上。

举个具体例子帮你建立数量感。假设一个典型 REST 接口，请求头约 400 字节，请求体 200 字节，响应头 300 字节，响应体 2KB（2048 字节），那么单次交互的应用层字节约 2948 字节。再叠加 TCP/IP 头（IPv4 下每包 40 字节，假设平均 3 个包）约 120 字节，以太网帧头尾约 18 字节 × 3，粗算下来 S ≈ 3100 字节左右。这个数字乘以 8 得到约 24800 bit，也就是单请求约 24.8 Kbit。如果 RPS 是 10 万，带宽就是 2.48 Gbps，约 0.0025 Tbps。你看，10 万 RPS 听起来很猛，实际带宽才 2.5G 量级——这就是为什么很多高并发业务其实卡在应用层而不是带宽。

2.2 为什么不能直接用“响应体大小”乘 RPS

只算响应体是新手最容易犯的错，原因有三层。第一，请求方向也有流量，尤其是有上传、表单提交、gRPC 大 payload 的场景，请求体可能比响应体还大。第二，协议头是固定开销，请求越小，头部占比越高。一个 100 字节的响应配上 300 字节的响应头，头部开销是正文的三倍，这时候你按正文算带宽会严重低估。第三，TCP 重传、TLS 握手、连接建立这些控制面流量虽然不直接对应业务请求，但在高 RPS 下会显著抬高实际链路吞吐，尤其是短连接场景。

我一般建议用一个“放大系数”来兜底：在算出的应用层带宽基础上乘 1.2 到 1.5，短连接多、TLS 握手频繁的乘 1.5 甚至 2。这个系数不是拍脑袋，后面第 4 节会讲怎么用实测数据反推它。

2.3 上下行不对称时该怎么算

很多业务的请求和响应大小差异巨大。比如图片服务，请求可能就几百字节（一个 GET），响应是几百 KB 的图片；反过来，日志上报或文件上传，请求大响应小。这时候不能简单用“平均单请求字节”一刀切，而要分别算上行和下行：

上行带宽 = R × S_req × 8 下行带宽 = R × S_resp × 8

网络设备选型看的是单向吞吐能力，链路带宽通常按较大的一侧来规划，但交换机、网卡的收发能力要分别核对。我遇到过一个小坑：某次压测下行才 3Gbps，上行却因为请求头里带了一个巨大的 cookie 冲到了 5Gbps，结果瓶颈出在上行方向，排查了半天才反应过来。

3. 关键参数怎么取：S 的拆解与实测方法

3.1 把 S 拆成可测量的几块

要让换算靠谱，S 必须来自真实数据而不是猜测。我习惯把 S 拆成下面几块分别测：

实操中最省事的办法是抓一段真实流量，用统计工具直接算平均单请求字节。Wireshark 里按 HTTP 过滤后看 “Bytes” 列的统计，或者用 tcpdump 抓几千个请求，导出后用脚本算总字节 / 请求数。注意要抓包含完整请求响应周期的流量，别只抓单向。

3.2 用分位数而不是平均值

平均值会骗人。一个接口 99% 的请求响应 1KB，1% 的请求响应 5MB，平均值会被拉到 50KB 左右，但实际带宽峰值往往由那 1% 的大请求决定。容量规划要看P95 或 P99 的单请求字节数，再结合 RPS 的峰值来算，而不是拿平均 RPS 乘平均字节。

我的做法是：日常容量按 P95 字节 × 平均 RPS 算基线，峰值容量按 P99 字节 × 峰值 RPS 算，两者取大再乘安全系数。这样既不会过度预留，也不会在突发大请求时翻车。

3.3 一个可直接套用的计算示例

假设某服务压测得到峰值 RPS = 80,000，抓包统计 P99 单请求总字节 S = 6KB（含头含 TLS 开销），安全系数取 1.3：

基线带宽 = 80000 × 6144 × 8 = 3.93 Gbps 含安全系数 = 3.93 × 1.3 ≈ 5.1 Gbps ≈ 0.0051 Tbps

结论是这个服务峰值带宽需求约 5Gbps，选 10G 网卡和对应上联绰绰有余。如果业务方张口就说“我们要 1Tbps”，你可以拿这个算式回去对：1Tbps 对应的是 80000 RPS 下每请求 1.5MB 以上，显然不符合实际。换算的价值就在于把模糊的“很大”变成可核对的数字。

4. 实操：从压测数据反推真实带宽

4.1 压测时同步采集网络指标

光看压测工具报的 RPS 不够，必须同步采集网络层数据。我常用的组合是：压测机侧用sar -n DEV 1或nload看网卡收发速率，服务端侧用同样的命令对照，再配合应用层的 QPS 统计。三组数据对齐时间轴，就能算出“每 RPS 对应多少实际带宽”。

具体操作上，压测跑稳之后截取一段 60 秒的平稳期，记录：

• 应用层总请求数 N
• 网卡收字节数 B_in、发字节数 B_out（注意是字节不是比特）
• 平均单请求字节 = (B_in + B_out) / N

这个实测值比任何估算都可靠，因为它自动包含了重传、握手、协议头所有开销。我一般会把这个值记下来，作为后续同类服务的换算基准。

4.2 用实测值校准放大系数

前面提到的 1.2~1.5 放大系数，其实可以用实测反推。做法是：先用“纯应用层字节”算一个理论带宽，再用网卡实测带宽除以理论值，得到的比值就是你这个场景的真实放大系数。短连接多、TLS 全握手的场景，这个比值经常到 1.6 以上；长连接、纯内网明文的场景可能只有 1.05。

把这个系数固化到团队的容量规划模板里，下次新服务上线直接套用，比每次重新抓包省事得多。这也是我觉得换算这件事最值得沉淀的地方——它不是一次性计算，而是一套可以复用的参数体系。

4.3 注意单位陷阱：B 和 b、G 和 Gi

换算里最容易翻车的地方是单位。字节是大写 B，比特是小写 b，1 B = 8 b。网络设备标称的 Tbps 用的是十进制 10^12，而操作系统里sar显示的往往是字节或 KB/s，有些工具又用 GiB。我踩过的坑：把sar的 KB/s 当成 Kbit/s 直接乘，结果算出来的带宽小了 8 倍，差点把一个 10G 链路当成 1G 来规划。

统一做法是：所有中间计算一律换成 bit/s，最后再除 10^12 转 Tbps。写个小脚本做单位归一，比心算靠谱。

5. 常见误区与排查速查表

5.1 五个高频误区

第一个误区是拿 RPS 直接乘一个“经验字节数”，不看业务类型。API 网关和视频分发，单请求字节能差三个数量级，经验值毫无意义。第二个是忽略双向流量，只算下行。第三个是把 Tbps 和 TB/s 混用，前者是比特吞吐，后者是存储容量单位，差 8 倍还多。第四个是用平均 RPS 算峰值带宽，秒杀、开抢这类场景 RPS 瞬时能翻十倍。第五个是忘记控制面流量，健康检查、监控上报、DNS 查询这些零碎流量在高 RPS 下累积起来不可忽视。

5.2 排查速查表

这张表我贴在团队 wiki 上，新人排查时按行对，基本能覆盖八成问题。

5.3 一个真实的排查记录

之前有个服务压测到 30 万 RPS 就上不去了，应用 CPU 才 40%。一开始怀疑是压测机不够，加了机器还是卡在 30 万。后来同步看网卡，发现下行已经跑到 9.2Gbps，接近 10G 网卡上限——原来这个接口响应体平均 3KB，30 万 RPS 对应约 7.2Gbps 应用层流量，加上协议开销正好顶满。换算一下：要上 50 万 RPS，带宽得 12Gbps 以上，必须换 25G 网卡或做多网卡分流。这个案例说明，RPS 和带宽必须一起看，单看任何一个都会误判瓶颈。

6. 把换算做成团队可复用的模板

6.1 模板该包含哪些字段

我现在的做法是给每个核心服务维护一张容量卡片，字段包括：峰值 RPS、P99 单请求字节、实测放大系数、计算带宽、安全系数、规划带宽、对应网卡规格。新服务上线前填一遍，评审时直接对数字，不用每次重新推导。这张卡片还会随版本更新，比如某次改版响应体从 2KB 涨到 5KB，卡片一更新，带宽规划立刻跟着变，避免“代码改了带宽没改”的隐性风险。

6.2 换算之外还要看什么

带宽只是容量规划的一个维度，RPS 高了之后还要看连接数、文件描述符、端口耗尽、TLS 握手 CPU 开销。换算解决的是“链路够不够”的问题，但链路够了不代表系统能扛住。我的经验是：先用换算排除网络瓶颈，再回头查应用层，顺序反了容易在错误的方向上优化半天。

最后分享一个我常用的心算口诀：10 万 RPS × 1KB 单请求 ≈ 0.8 Gbps。记住这个锚点，遇到任何 RPS 和字节数都能快速估个量级，再决定要不要精确计算。比如 50 万 RPS × 2KB，就是 5 × 2 × 0.8 = 8Gbps，心里立刻有数。这个口诀帮我挡掉过好几次明显不合理的带宽需求，也让我在会议上能当场把“50 万请求要几个 T”这种问题翻译成人话。