RPS与Tbps换算全解析：从请求到比特的容量规划指南

1. 从两个“风马牛不相及”的指标说起

第一次被问到“RPS 和 Tbps 怎么换算”的时候，我正蹲在机房角落里排查一条链路的丢包问题。对方是刚接手容量规划的新同事，手里攥着一份压测报告，上面写着“目标 50 万 RPS”，又翻到一份带宽采购清单，上面标着“10 Tbps 出口”。他一脸困惑地问我：这两个数到底能不能对上？如果不能，那我买带宽的时候该按哪个来算？

这个问题看似简单，实际上踩中了性能工程里一个非常经典的认知盲区。RPS（Requests Per Second，每秒请求数）衡量的是“单位时间内系统处理了多少次请求”，属于应用层或业务层的吞吐指标；Tbps（Terabits Per Second，太比特每秒）衡量的是“单位时间内链路上流过了多少比特”，属于物理层或网络层的带宽指标。两者一个在“数请求”，一个在“数比特”，中间隔着一整条协议栈，还隔着一个叫“平均请求大小”的变量。所以严格来说，它们之间不存在一个放之四海而皆准的固定换算系数，但存在一条可以推导、可以估算、可以在工程实践中反复校准的换算路径。

我写这篇东西的目的很直接：把这条换算路径讲清楚，让做容量规划的人知道压测报告上的 RPS 怎么折算成带宽需求，让做网络的人知道链路带宽能撑住多少业务请求，也让刚入行的朋友不再把这两个指标混为一谈。文中会给出完整的推导公式、参数取值经验、实操计算示例，以及我在实际项目中踩过的坑。适合后端开发、SRE、运维、容量规划、网络工程等方向的同学参考，不需要你精通协议栈，但需要你对“请求”和“字节”有基本概念。

2. 换算的底层逻辑：从请求到比特的完整链路

2.1 为什么不能直接乘一个系数

很多人第一反应是“一个请求大概多少字节，乘一下不就行了”。方向是对的，但直接乘会漏掉大量开销。一个 HTTP 请求从客户端发出到服务端响应，链路上流动的比特远不止“请求体 + 响应体”那么简单。我把这条链路上所有会占用带宽的部分拆开来看，大致包括以下几层：

• 应用层载荷：请求头、请求体、响应头、响应体。这是业务真正关心的数据。
• 传输层开销：TCP 头（20 字节起步，带选项会更多）、可能的 TLS 记录头。
• 网络层开销：IP 头（IPv4 是 20 字节，IPv6 是 40 字节）。
• 链路层开销：以太网帧头、帧尾（合计约 18 字节），以及帧间隙。
• 协议握手开销：TCP 三次握手、TLS 握手（如果是 HTTPS），这些包不承载业务数据，但实实在在占用带宽。
• 重传与确认开销：TCP 的 ACK 包、丢包重传，在高丢包率链路上这部分占比会显著上升。

所以正确的思路不是“请求大小 × RPS”，而是“单请求平均在线比特数 × RPS”，其中“在线比特数”要把上述所有开销都算进去。这个值我习惯叫它单请求带宽当量，单位是 bit/request。

2.2 核心换算公式的推导

把逻辑理顺之后，公式其实很朴素：

带宽需求（bps） = RPS × 单请求带宽当量（bit/request） 带宽需求（Tbps） = RPS × 单请求带宽当量 / 10^12

反过来，已知带宽求能承载的 RPS：

可承载 RPS = 带宽（bps） / 单请求带宽当量（bit/request）

这里的关键变量只有一个：单请求带宽当量。它不是一个理论常数，而是一个需要根据业务特征实测或估算的经验值。下面我给一个估算它的分解公式：

单请求带宽当量 = (请求头 + 请求体 + 响应头 + 响应体) × 8 × 协议开销系数 × 握手摊销系数 × 重传系数

其中乘以 8 是因为字节转比特。三个系数的含义和取值经验，我在下一节展开讲。这里先强调一点：这个公式算出来的是“单向”还是“双向”，取决于你把请求和响应算在一起还是分开算。工程上做容量规划时，通常按“上下行合计”来估算链路总带宽，因为大多数链路是双向对称计费的（或者至少上下行共享物理介质）。如果你的场景是下行远大于上行（比如视频分发），那就要分开算，别用一个系数糊弄过去。

2.3 一个必须澄清的常见误解

网上有些说法会告诉你“1 Tbps 大约等于多少万 RPS”，然后给一个拍脑袋的数字。这种说法在特定业务下可能碰巧接近，但作为通用规则是危险的。原因很简单：单请求带宽当量的跨度可以差三到四个数量级。一个健康检查接口的响应可能只有几百字节，而一个图片下载接口的响应可能是几兆字节。同样是 10 万 RPS，前者可能只需要几百 Mbps，后者可能要几十 Tbps。所以任何脱离“请求大小分布”谈换算的说法，都是耍流氓。

我在实际工作中判断一个换算是否靠谱，会先问三个问题：请求和响应的平均大小是多少？P99 大小是多少？HTTPS 占比多少？这三个问题答不上来，后面的计算就没有意义。

3. 单请求带宽当量：把经验值算明白

3.1 各层开销的实测取值

为了让换算有据可循，我把各层开销的典型值整理成表。这些数字来自我在多个项目中抓包统计的经验，不同环境会有浮动，但量级是可靠的。

把这些加起来，一个“空载”的 HTTPS 请求（不带业务数据）在链路上实际占用的字节数，轻松就能到 400~1000 字节。这就是为什么很多压测报告里“响应体只有 100 字节”的接口，实际带宽消耗却是按 500 字节甚至更多在跑。

3.2 协议开销系数的估算方法

协议开销系数定义为“链路总字节数 / 应用层载荷字节数”。它的估算有个简单办法：抓一段真实流量，用抓包工具统计总字节数和应用层载荷字节数，两者相除即可。如果没有抓包条件，可以按下面的经验值起步：

• 纯 HTTP/1.1，小请求：系数约 1.5~2.5。请求头占比高，开销明显。
• HTTPS，小请求：系数约 2.0~3.5。TLS 记录头和握手摊销都算进去。
• HTTP/2，多路复用：系数约 1.3~2.0。头压缩和多路复用降低了单请求开销。
• 大响应体（如文件下载）：系数趋近 1.05~1.2。载荷占绝对主导，协议头可忽略。

这里有个容易忽略的点：小请求的协议开销系数远高于大请求。一个 10 KB 的响应，协议头占比可能不到 5%；但一个 200 字节的响应，协议头可能比载荷还大。所以做容量规划时，如果业务以小请求为主（比如 API 网关、鉴权服务），系数一定要往高了取，否则算出来的带宽会严重偏低。

3.3 握手摊销系数怎么算

TCP 和 TLS 握手产生的包不承载业务数据，但会占用带宽。摊销系数的算法是：（握手总字节数 / 连接复用次数 + 单请求字节数）/ 单请求字节数。

举个具体例子。一次完整的 TCP + TLS 1.3 握手，往返加起来大约 2~4 KB 的流量（含证书传输，证书链大的话更多）。如果一条连接上复用了 100 个请求，那握手开销摊销到每个请求上就是 20~40 字节，相对单请求几百字节的载荷来说占比不大。但如果连接复用率很低（比如每个请求新建连接），握手开销就会成为带宽消耗的大头，摊销系数可能达到 2 以上。

提示：连接复用率是影响换算结果的关键变量，做容量规划时一定要拿到真实的连接复用数据，不能想当然按“长连接”估算。

3.4 重传系数的取值经验

重传系数 = 1 / (1 - 丢包率)。在丢包率 0.1% 的优质链路上，系数约 1.001，可以忽略；在丢包率 1% 的链路上，系数约 1.01；在丢包率 5% 的链路上，系数约 1.05，这时候就不能忽略了。跨境链路、无线链路、拥塞链路的丢包率往往高于 1%，做带宽规划时要留出这部分余量。

把四个部分串起来，一个完整的估算示例如下：某 API 服务，平均请求 300 字节，平均响应 800 字节，HTTPS 占比 100%，连接复用率约 50 请求/连接，链路丢包率 0.5%。应用层载荷合计 1100 字节，协议开销系数取 2.2，握手摊销系数取 1.05，重传系数取 1.005。单请求带宽当量 = 1100 × 8 × 2.2 × 1.05 × 1.005 ≈ 20,400 bit/request，约 2.55 KB/request。这个数字意味着，10 万 RPS 对应的带宽需求约 2.04 Gbps，也就是 0.00204 Tbps。你看，10 万 RPS 离 1 Tbps 还差着两个数量级，这就是为什么不能拍脑袋换算。

4. 实操计算：从压测报告到带宽采购单

4.1 完整计算流程的五个步骤

我把整个换算流程固化成五步，每次做容量规划都按这个顺序走，基本不会漏项。

1. 确定目标 RPS 及其分布：不只看平均值，要看峰值 RPS 和峰谷比。容量规划要按峰值算，不能按均值算。
2. 统计请求和响应的大小分布：至少拿到平均值和 P95/P99 值。平均值用于估算总量，P99 用于评估突发带宽。
3. 确定协议栈特征：HTTP 版本、是否 HTTPS、连接复用策略、是否启用压缩。
4. 计算单请求带宽当量：按上一节的分解公式逐项代入。
5. 乘以 RPS 得到带宽需求，再留安全余量：安全余量一般取 1.3~1.5，应对突发和增长。

4.2 一个可复现的计算示例

假设某服务压测报告给出：峰值 20 万 RPS，平均请求 500 字节，平均响应 2 KB，P99 响应 8 KB，全站 HTTPS，HTTP/2，连接复用率约 80 请求/连接，链路丢包率 0.3%。

先算应用层载荷：平均 500 + 2000 = 2500 字节。协议开销系数按 HTTP/2 + HTTPS 取 1.8。握手摊销系数：握手约 3 KB，摊销到 80 个请求上约 37.5 字节，系数 = (2500 + 37.5) / 2500 ≈ 1.015。重传系数 = 1 / (1 - 0.003) ≈ 1.003。

单请求带宽当量 = 2500 × 8 × 1.8 × 1.015 × 1.003 ≈ 36,650 bit/request，约 4.58 KB/request。

峰值带宽需求 = 200,000 × 36,650 ≈ 7.33 Gbps，约 0.00733 Tbps。留 1.4 倍安全余量后约 10.3 Gbps。所以采购 10 Gbps 链路是合理的，而如果有人告诉你这个服务需要 1 Tbps，那一定是哪里算错了。

4.3 反向换算：已知带宽能撑多少 RPS

反向换算在排查“链路打满”问题时特别有用。假设你有一条 25 Gbps 的链路，业务单请求带宽当量约 4.58 KB/request，那么理论可承载 RPS = 25 × 10^9 / 36,650 ≈ 682,000 RPS。但这是理论值，实际要打七折左右，因为链路不可能 100% 利用率运行，还要留出突发余量。所以实际可承载约 47~48 万 RPS。如果监控显示当前 RPS 已经接近这个数，链路利用率又超过 80%，那就该考虑扩容了。

注意：反向换算时一定要用“当前业务”的单请求带宽当量，不能套用别的业务的经验值。业务结构一变，这个当量就变了。

4.4 用表格管理不同业务的换算参数

实际项目中往往同时维护多个业务线，每个业务的请求特征不同。我习惯用一张表把参数管起来，每次容量评审直接查表，避免重复计算和口径不一致。

这张表一眼就能看出，图片下载业务虽然 RPS 最低，但带宽需求最高。这就是为什么容量规划不能只看 RPS，必须把单请求当量一起看。

5. 常见问题与排查技巧实录

5.1 换算结果和监控数据对不上怎么办

这是最常见的问题。算出来需要 5 Gbps，监控显示链路只跑了 2 Gbps，或者反过来。排查思路按以下顺序走：

• 先核对口径：监控统计的是不是双向合计？是不是只统计了业务端口？有没有把健康检查、监控上报、日志传输这些“背景流量”算进去？
• 再核对单请求当量：抓一段真实流量重新统计，看看实际载荷和协议开销系数是否和假设一致。很多时候是请求头比预想的大（Cookie、UA 很长），或者响应体被压缩了但没算进去。
• 检查连接复用：如果实际复用率远低于假设，握手开销会显著推高带宽。
• 检查突发流量：平均值对得上但峰值对不上，说明业务有突发特征，需要按 P99 甚至更高分位来规划。

5.2 为什么小请求业务的带宽总是估不准

小请求业务的协议开销占比高，任何一点参数偏差都会被放大。我的经验是：小请求业务的单请求当量，实测值往往比理论估算高 30%~50%。原因是理论估算容易漏掉 TCP 选项、TLS 记录分片、ACK 包等细碎开销。所以对这类业务，我建议直接抓包实测，不要依赖公式估算。实测方法很简单：在服务端抓 1 万个请求的流量，统计总字节数除以请求数，得到的就是真实的单请求当量。

5.3 常见问题速查表

5.4 几个容易踩的坑

第一个坑是把 Mbps 和 MB/s 搞混。带宽单位是 bit，存储单位是 Byte，差 8 倍。我见过有人把 100 Mbps 当成 100 MB/s 来规划，结果差了整整 8 倍，链路直接打爆。

第二个坑是忽略压缩。如果服务端启用了 gzip 或 brotli，响应体在链路上传输的字节数会显著小于应用层看到的字节数。做带宽换算时要用压缩后的字节数，而不是压缩前的。这个细节在文本类业务里影响很大，压缩比轻松到 3~5 倍。

第三个坑是用平均值做容量规划。平均值只反映常态，容量规划要看峰值。我习惯用“峰值 RPS × P95 单请求当量”来估算带宽上限，这样算出来的数字更接近真实峰值需求。

第四个坑是忘记算背景流量。健康检查、监控采集、日志上报、配置下发，这些流量单看都不大，但架不住频率高、节点多。在一个几千节点的集群里，背景流量占到总带宽 10%~20% 是常有的事。做容量规划时留的安全余量，有一部分就是给它们留的。

6. 把换算规则用进日常容量评审

6.1 建立团队内的换算基线

换算规则本身不难，难的是团队内口径统一。我的做法是维护一份“单请求带宽当量基线表”，按业务线记录实测值，每次容量评审前更新一次。新业务上线时，先按同类业务的基线值估算，上线后一周内抓包校准，把实测值回填到表里。这样积累几个月，团队就有了自己的经验数据，再也不用每次从头推导。

基线表里我建议至少记录这几个字段：业务线名称、平均载荷、P95 载荷、协议特征、实测单请求当量、实测日期、备注。备注里写清楚这次实测的特殊情况，比如“大促期间统计，含突发流量”或者“灰度环境，连接复用率偏低”。这些备注在后续复用时非常有用，能避免误用。

6.2 容量评审时的三个必问问题

每次评审带宽需求，我都会问三个问题，答不上来就说明测算不扎实：

• 单请求当量是怎么来的？是实测还是估算？实测的话抓了多少样本？估算的话系数怎么取的？
• 峰值 RPS 的口径是什么？是单集群还是全站？含不含重试流量？重试流量在故障时可能翻倍。
• 安全余量留了多少，为什么？1.3 倍和 1.5 倍对应的风险不同，要说清楚依据。

这三个问题问下来，大部分测算漏洞都会暴露。我见过最离谱的一次，是有人把“每秒查询数”和“每秒请求数”混为一谈，一个页面加载触发 20 个接口请求，结果带宽需求少算了 20 倍。这种错误在评审时一问口径就能发现。

6.3 换算规则的适用边界

最后要说清楚这个换算规则什么时候不适用。它适用于“请求-响应”模型的业务，比如 Web API、RPC 调用、HTTP 下载。对于长连接推送、流媒体、实时音视频这类业务，带宽计算逻辑完全不同，不能套用 RPS 换算。流媒体业务直接按码率 × 并发数算带宽，跟 RPS 没关系。长连接推送业务按“连接数 × 单连接平均流量”算，也不走 RPS 这条路。

所以拿到一个业务场景，先判断它属于哪类流量模型，再决定用哪套换算方法。RPS 到 Tbps 的换算只是其中一种，别把它当成万能公式。我在实际项目中遇到过有人拿这套公式去算视频直播的带宽，算出来的数字和实际差了三个数量级，原因就是流量模型选错了。

我个人在实际操作中的体会是，换算规则的价值不在于算出一个精确数字，而在于强迫你把“请求特征、协议开销、连接行为、流量分布”这些平时容易忽略的因素逐一量化。算得多了，你对业务的带宽画像会越来越清晰，看到 RPS 和响应大小就能大致判断带宽量级，这种直觉在应急排查和快速评估时特别管用。