香港服务器15M与25M CN2带宽能承载多少业务并发？如何估算峰值余量

15M CN2 和 25M CN2 通常分别指 15Mbps 与 25Mbps 的网络带宽。按十进制换算，15M 的理论传输能力约为 1.875MB/s，25M 约为 3.125MB/s，后者比前者多 10Mbps，理论吞吐提升约 66.7%。但带宽不能直接等同于在线人数：响应大小、请求频率、峰值持续时间、网络延迟以及 CPU、数据库和磁盘性能，都会改变实际并发承载能力。

按照“带宽利用率控制在 70%，协议及加密等开销约占 15%”的规划口径，15M 可用于业务响应的数据预算约为 8.925Mbps，25M 约为 14.875Mbps。以单次响应 20KB、100KB 和 1MB 为例，15M 大致可承载 55.8、11.2 和 1.1 次请求/秒，25M 大致可承载 93.0、18.6 和 1.9 次请求/秒。这些是明确条件下的带宽估算，不是某台服务器的实测承诺，也不代表可同时在线的用户数。

先统一15M与25M的计算口径

Mbps、MB/s和业务请求的关系

本文将“15M”和“25M”按 Mbps 处理：

• 1Mbps = 1,000,000 bit/s；
• 8bit = 1Byte；
• 15Mbps ÷ 8 = 1.875MB/s；
• 25Mbps ÷ 8 = 3.125MB/s。

因此，理论上连续传输 1GB 十进制数据时：

• 15M 需要约 533 秒，约 8.9 分钟；
• 25M 需要约 320 秒，约 5.3 分钟。

这是没有协议开销、丢包重传、其他请求竞争和突发流量的理想值。实际容量规划不能把端口跑到 100%，否则网页资源、接口响应和后台任务可能互相争抢带宽。

一个便于规划的计算关系是：

业务可用带宽 = 标称带宽 × 目标利用率 × 有效载荷比例

本文示例使用：

• 目标利用率：70%；
• 有效载荷比例：85%，用于粗略覆盖 TCP/IP、TLS、HTTP 头部、重传等开销；
• 15M 业务可用带宽：15 × 70% × 85% = 8.925Mbps；
• 25M 业务可用带宽：25 × 70% × 85% = 14.875Mbps。

如果已经从网卡或监控系统取得了实际传输字节数，数据本身已经包含协议开销，就不应再次乘以 85%。此时可以直接使用：

可承载请求数/秒 = 可用带宽 × 1,000,000 ÷（8 × 单次传输字节数）

15M与25M的同口径差异

25M 并不是把所有服务器资源都提升 1.67 倍。它主要增加了数据传输空间和峰值余量。如果业务瓶颈位于数据库锁等待、PHP 或 Java 线程池、磁盘 I/O、CPU 加密开销，单纯从 15M 升到 25M，业务请求数未必同步增长。

先建立业务负载画像

带宽估算应先回答四个问题：请求是什么类型、每次传输多少数据、峰值有多集中、增长是否可预测。

按请求类型区分数据规模

不同业务的单次传输量差异很大。一个只返回几KB JSON 的接口，与一个返回图片、安装包或视频片段的请求，不能使用相同的并发换算关系。

常见的负载可以按以下方式拆分：

这里的“单次传输量”最好使用压缩和缓存之后的实际字节数。比如一个逻辑大小为 100KB 的 JSON，经 gzip 压缩后可能只在网络上传输 20KB～40KB；反过来，如果接口返回未压缩的大量文本，带宽消耗会明显增加。

区分请求速率与在线用户数

请求速率通常使用 RPS 表示，即每秒请求数。在线用户数则包括正在浏览、保持连接或等待下一次操作的用户，两者不是同一个指标。

在平均响应时间相对稳定时，可以使用近似关系：

活跃请求数 ≈ RPS × 平均响应时间（秒）

例如，混合业务在 15M 带宽下估算为 8.3RPS，峰值期间平均响应时间为 400毫秒，则同时处于处理状态的请求约为：

8.3 × 0.4 ≈ 3.3 个

这不表示服务器只能承载 3 个用户。若每个用户平均 10 秒才发起一次请求，100 个用户平均只产生约 10RPS；如果大量用户在同一秒刷新页面，则会形成突发请求，瞬时并发可能远高于平均值。

因此，容量规划至少要分别记录：

• 在线会话数；
• 活跃 HTTP 请求数；
• 每秒请求数；
• 长连接数量；
• 单次请求和响应的字节数；
• 峰值持续时间。

15M与25M的请求承载估算

单一请求类型的带宽上限

以下估算采用前述条件：带宽利用率 70%，有效载荷比例 85%，并且以单次响应体大小为主要传输量。结果表示持续请求速率上限附近的参考值，实际还要受到 CPU、连接处理和后端响应速度限制。

例如，一个接口每次返回 100KB，业务高峰稳定在 10RPS，那么仅从带宽角度看，15M 已经接近规划线；25M 仍有一定空间。但如果这 10RPS 是每秒突然出现的短时尖峰，TCP 慢启动、线程调度、数据库连接建立和缓存未命中，都可能让实际响应情况差于静态换算结果。

如果响应是 1MB，15M 的理论规划速率只有约 1.1RPS，意味着短时间内几个并行下载就可能占满带宽。此时应优先考虑静态资源缓存、对象存储或 CDN 分发，而不是只依赖提升应用服务器带宽。

混合业务的加权估算

真实业务通常同时包含接口、页面和静态资源，可以先计算平均单次传输量。

设一个请求集合中：

• 70% 请求返回 20KB；
• 20% 请求返回 100KB；
• 10% 请求返回 1MB。

加权平均传输量为：

20KB × 70% + 100KB × 20% + 1MB × 10%

= 14KB + 20KB + 100KB

= 134KB

按照 15M 和 25M 的业务可用带宽计算：

• 15M：8,925,000 ÷（134,000 × 8）≈ 8.3RPS；
• 25M：14,875,000 ÷（134,000 × 8）≈ 13.9RPS。

若峰值期间平均响应时间为 400毫秒，对应的活跃请求数约为：

• 15M：8.3 × 0.4 ≈ 3.3；
• 25M：13.9 × 0.4 ≈ 5.6。

这个案例说明，25M 相比 15M 增加的是网络处理空间，约增加 5.6RPS 的混合业务余量；它并不意味着在线用户数一定从某个固定数值增长到 1.67 倍。

上行请求也要单独核算

文件上传、图片上传、备份同步和接口提交大报文时，消耗的是上行方向带宽。下载页面、图片、安装包和接口响应则主要消耗下行方向带宽。

需要确认具体服务的带宽口径：

• 上行和下行是否对称；
• 15M、25M 是端口速率还是保证带宽；
• 是否允许短时突发；
• 流量计费按单向流量还是双向流量；
• 业务高峰时是否存在其他实例或后台任务共用出口。

如果同一台服务器同时进行大文件上传和下载，应分别监控 rx 与 tx，不能只看一条总流量曲线。即使下载方向尚未达到上限，上传任务也可能占用 CPU、磁盘和连接资源，间接拖慢下载请求。

数据规模与持续传输能力

带宽不仅决定瞬时并发，也决定连续传输的数据规模。以下按十进制 GB 计算，未计协议开销：

如果进一步按 85% 有效载荷估算，15M 的业务有效数据约为 96.4GB/天，25M 约为 160.7GB/天。这只是“持续有数据可传”的数学结果，不代表每天一定能产生这些业务流量，也不包含磁盘读写、缓存命中、压缩率和重传差异。

例如，某业务每天需要向外提供 500GB 安装包：

• 15M 在理想连续传输下也需要超过 2.5 天；
• 25M 在理想连续传输下仍需要接近 1.9 天；
• 如果还要保留网页访问、接口请求和业务峰值余量，实际时间会更长。

对于这类大文件业务，应把“单台香港服务器带宽是否足够”和“文件是否适合从应用服务器直接下载”分开判断。若大部分流量是静态文件，缓存分发、分离文件存储或增加专用下载带宽，通常比单纯增加应用进程更直接。

瓶颈不一定在带宽

小请求业务可能先受CPU和数据库限制

轻量 API 的单次响应只有 10KB～20KB 时，15M 从理论上已经可以提供较高的请求速率。此时更常见的瓶颈包括：

• 数据库查询耗时上升；
• 数据库连接池耗尽；
• 应用线程池或进程数不足；
• PHP-FPM、Java、Node.js 等工作进程排队；
• TLS 握手和加密占用 CPU；
• 日志写入导致磁盘 I/O 等待；
• 外部接口响应变慢。

如果带宽利用率只有 30%，但接口 p99 延迟和 5xx 错误率已经上升，升级到 25M 通常不能直接解决问题。

大资源业务可能先受出口带宽限制

当页面包含较多图片、脚本和字体，或者业务提供视频片段、备份包和报表导出时，单次响应体会快速增大。此时可以重点观察：

• 网卡发送速率是否长期接近规划线；
• 静态资源缓存命中率；
• 大文件下载是否与动态请求争抢出口；
• 磁盘读取是否跟不上并发下载；
• 下载连接是否长期占用工作进程；
• 高峰期间丢包、重传和访问延迟是否同步上升。

如果网卡发送速率先达到 80%～90%，同时应用 CPU 和数据库仍有余量，带宽才是更明确的扩容方向。

小报文高并发可能受连接和数据包处理影响

带宽以 bit/s 衡量，但服务器还要处理每秒数据包数量。大量小请求可能在总流量不高时产生较高的：

• 新建连接数；
• TCP 状态数量；
• 每秒数据包数；
• 中断和软中断；
• 文件描述符占用；
• 反向代理连接数；
• 内核连接跟踪表压力。

因此，20KB 响应的 50RPS 不能只用“约 1MB/s”判断，还要查看应用和系统是否能稳定处理这些请求。启用长连接、合理使用缓存、减少重复握手，可能比直接增加 10Mbps 更有效。

如何计算峰值余量

先区分当前余量和规划余量

设：

• B 为购买带宽；
• P 为观察到的峰值网卡流量；
• U 为目标利用率，例如 70%。

可以分别计算：

当前原始余量 = B - P

规划余量 = B × U - P

以 15M 为例，如果峰值发送流量为 8Mbps：

• 原始余量：15 - 8 = 7Mbps；
• 70%规划线：15 × 70% = 10.5Mbps；
• 规划余量：10.5 - 8 = 2.5Mbps；
• 当前峰值已占规划线约 76.2%。

对于 25M：

• 原始余量：25 - 8 = 17Mbps；
• 70%规划线：25 × 70% = 17.5Mbps；
• 规划余量：17.5 - 8 = 9.5Mbps；
• 当前峰值占规划线约 45.7%。

这里的峰值不应只看某一个瞬时采样点。建议同时保存：

• 1分钟最大值，用于观察突发；
• 5分钟平均值，用于观察持续压力；
• 业务高峰时段的 p95；
• 7天或更长周期内的同一时段对比；
• 发布、活动、备份等特殊任务产生的独立峰值。

把增长率和季节性加入预测

如果当前高峰为 P，月增长率为 g，预计观察 n 个月，季节或活动放大系数为 k，则可以先估算未来峰值：

未来峰值 = P ×（1 + g）^n × k

再用目标利用率计算需要的标称带宽：

所需带宽 = 未来峰值 ÷ 目标利用率

示例：

• 当前业务高峰：8Mbps；
• 月增长率：20%；
• 规划周期：3个月；
• 季节性放大系数：1.2；
• 目标利用率：70%。

未来峰值约为：

8 × 1.2³ × 1.2 ≈ 16.6Mbps

所需标称带宽约为：

16.6 ÷ 70% ≈ 23.7Mbps

在这个增长假设下，25M 可以覆盖近阶段预测，但只剩约 0.9Mbps 的规划余量；15M 的 70%规划线只有 10.5Mbps，无法覆盖预测峰值。若增长率、活动峰值或响应大小存在较大不确定性，25M 更适合作为过渡容量，同时提前确认后续升级路径。

15M还是25M：按业务条件选择

15M更适合的情况

15M 可以优先考虑以下业务：

• 企业官网、展示型网站和后台管理系统；
• 以轻量 API 为主，单次响应较小；
• 静态资源有较高缓存命中率；
• 监控到的高峰网卡流量长期低于 8Mbps～10Mbps；
• 文件下载量较小，且不会与核心业务高峰重叠；
• 业务增长较稳定，短期没有明显的活动流量。

如果业务属于“小请求、高计算”类型，15M 是否足够应重点看应用处理能力，而不能只看在线用户数。

25M更适合的情况

25M 更适合以下容量规划：

• 动态页面和 API 的平均响应体较大；
• 图片、脚本、报表或安装包下载较多；
• 高峰期间 15M 已接近 70%～80%规划线；
• 未来数月存在明确的用户量或数据量增长；
• 需要为突发访问保留更大网络余量；
• 多个站点、接口和后台任务共用同一台服务器出口。

25M 能为大约 1.67 倍的网络吞吐提供空间，但如果并发增长伴随数据库查询增长、连接数增长和缓存失效，仍然需要同步评估其他资源。

两种带宽都不适合的情况

以下场景不宜只在 15M 与 25M 之间做选择：

• 长时间连续的视频或大文件分发；
• 多用户同时下载数百MB以上的文件；
• 备份、同步和下载任务集中在同一高峰；
• 预计峰值已经超过 25M 的 70%～80%规划线；
• 业务对低延迟和高峰稳定性有严格要求，但尚未进行目标地区链路验证。

此时可以将动态应用、静态文件和大文件传输拆开规划，分别评估更高带宽、缓存分发、对象存储或独立下载节点。

围绕香港业务对带宽、链路与服务器资源的协同需求，A5数据提供香港物理服务器租用，覆盖入门建站、Xeon Gold及AMD EPYC等配置，并配有CN2与国际带宽方案。SSD、NVMe、大内存及多IP资源，可承载网站、业务后台、数据库、接口服务和静态资源传输；针对大文件、备份归档等场景，还提供香港存储型服务器，形成从网络出口到计算与存储的资源组合。

CN2带宽需要验证哪些产品条件

CN2主要体现网络路径、互联质量和面向特定访问方向的链路条件，不会自动把 15M 或 25M 转换成固定的业务并发数。容量判断仍应以实际业务传输量为基础。

在购买或交付验收时，应分别核对以下内容：

• 标称的 15M、25M 是 Mbps 还是其他单位；
• 是端口上限、保证带宽，还是允许短时突发的峰值带宽；
• 上行和下行是否对称；
• 带宽是否由多个实例或多个站点共享；
• 流量统计按单向还是双向计算；
• 是否存在月流量额度、超额处理或限速条件；
• 目标访问地区的延迟、丢包和高峰期稳定性；
• 业务出口是否还承担备份、更新、镜像同步等任务。

验收时，不宜只用一次测速结果判断容量。更有参考价值的是使用与实际用户接近的网络位置，在受控时间内分别测试小接口、大响应和文件传输，同时记录吞吐、延迟、丢包、CPU、磁盘和应用错误率。

用监控结果确定阈值和扩容时机

可以先建立一套可调整的容量策略，而不是等到带宽完全占满后再处理。

建议监控的核心指标

网络侧：

• 网卡入站和出站 Mbps；
• 1分钟、5分钟平均值；
• 高峰期 p95、p99 和最大值；
• 丢包、重传、网卡错误和队列丢弃；
• 长连接数量和新建连接速率。

应用侧：

• RPS 和每个接口的请求占比；
• 平均响应大小、压缩后响应大小；
• p95、p99 响应时间；
• 4xx、5xx、超时和排队请求；
• 缓存命中率；
• 大文件下载连接数量。

系统与后端侧：

• CPU 使用率及用户态、内核态占比；
• iowait、磁盘吞吐和 IOPS；
• 内存、文件描述符和连接状态；
• 应用进程、线程池和连接池；
• 数据库慢查询、锁等待和连接数。

一套可执行的起始阈值

以下阈值适合作为初始策略，具体数值应结合业务的延迟目标和突发特征调整：

最终的扩容触发点应同时满足“当前监控”和“未来预测”两个条件。若当前峰值尚未超过 70%，但按增长率计算将在下一个活动周期逼近 80%，也应提前准备；若带宽只有 40%，但数据库已经出现锁等待，则应先处理后端瓶颈，而不是仅升级带宽。

通过“实际出站字节数、加权平均响应大小、峰值RPS、p95延迟和未来增长率”建立持续记录，就能把 15M 与 25M 的选择从固定并发猜测，转化为可复核的容量规划：先确认业务传输规模，再判断网络是否为瓶颈，最后用规划线和增长预测确定扩容时间。