1. 为什么“RPS 换算 Tbps”值得单独拎出来讲做后端性能压测、容量规划或者网络设备选型的人几乎都遇到过这种对话业务方说“我们峰值每秒要扛 50 万请求”网络组回一句“那你带宽得按几个 T 算”。两边说的其实不是一回事但会上没人把它翻译清楚最后要么带宽买多了浪费预算要么上线当天链路先被打满应用层还没开始报错网络层已经丢包了。每秒请求数RPSRequests Per Second和 TbpsTerabits 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 字节响应体 2KB2048 字节那么单次交互的应用层字节约 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 拆成下面几块分别测组成项典型取值测量方式请求行 请求头200~800 字节抓包看单请求原始字节请求体0~数十 KB按业务接口统计响应头200~600 字节抓包统计响应体变化最大按接口分位数统计TCP/IP 头每包约 40 字节按平均包数估算TLS 记录开销每记录约 20~40 字节加密场景必算实操中最省事的办法是抓一段真实流量用统计工具直接算平均单请求字节。Wireshark 里按 HTTP 过滤后看 “Bytes” 列的统计或者用 tcpdump 抓几千个请求导出后用脚本算总字节 / 请求数。注意要抓包含完整请求响应周期的流量别只抓单向。3.2 用分位数而不是平均值平均值会骗人。一个接口 99% 的请求响应 1KB1% 的请求响应 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比特是小写 b1 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 排查速查表现象可能原因排查动作算出的带宽远小于实测漏算协议头/重传抓包对比应用层与链路层字节应用没到瓶颈但链路丢包峰值 RPS 被低估看秒级 RPS 曲线而非分钟均值上下行差异巨大业务本身不对称分别统计请求/响应字节换算结果与设备标称对不上单位混淆统一换算到 bit/s 再比较压测 RPS 上不去链路先打满同步看网卡吞吐与 CPU这张表我贴在团队 wiki 上新人排查时按行对基本能覆盖八成问题。5.3 一个真实的排查记录之前有个服务压测到 30 万 RPS 就上不去了应用 CPU 才 40%。一开始怀疑是压测机不够加了机器还是卡在 30 万。后来同步看网卡发现下行已经跑到 9.2Gbps接近 10G 网卡上限——原来这个接口响应体平均 3KB30 万 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”这种问题翻译成人话。
