要测服务器推送的网速，别只盯下载速度，而是分三层去看：底层链路带宽、推送通道延迟、资源加载时间，最靠谱的组合是用 iperf3 测带宽上限，用 curl 计时确认 TTFB 和平均速率，再配合浏览器 DevTools 观察推送资源是否被真正复用。
很多朋友把“服务器推送”和普通网页下载混为一谈，结果测出来的数据总是不对，下面从原理到操作,把测速方法和判断标准讲透。
服务器推送测速，先分清三种“网速”
服务器推送（Server Push）是 HTTP/2 协议的能力，服务器可以在客户端请求主文档时，主动把 CSS、JS、图片等资源推给浏览器，测速前,先搞清楚你想测的是哪一段路径。
链路带宽
这是服务器出口到用户之间的物理通道极限，比如机房是 10Mbps 还是 100Mbps 独享，路由经过多少跳，带宽不够，推送再快也像小水管抽大泵。推送通道延迟
指的是从服务器发出推送帧，到客户端确认收到的时间间隔，延迟高，用户会感觉资源“卡顿”，尤其在实时推送场景中，WebSocket 或 SSE。资源加载速度
站在浏览器视角，从发起请求到资源完全渲染完成的时间，这个值受链路带宽、延迟、服务器处理能力、推送策略共同影响。只有把这三层分开测，你才能知道瓶颈到底在机房、线路还是程序。
实操：四步测出服务器推送的网速
以下命令和操作路径均可在 Linux 和 Windows 环境复现，建议先在自己的服务器上跑通,再对比客户端结果。
第一步：用 iperf3 测底层带宽
服务器端执行：iperf3 -s
客户端执行：
iperf3 -c 你的服务器IP -t 10 -i 2
输出结果里的 Transfer 和 Bitrate 就是当前 TCP 链路的吞吐量，注意，iperf3 默认是单线程，建议加 -P 4 开多线程模拟并发推送,得到更接近真实峰值的带宽。
第二步：用 curl 测 HTTP/2 推送的加载时间
先用 curl 确认服务器支持 HTTP/2：curl -I --http2 https://你的域名 -s
看到 HTTP/2 200 说明协议正常,接着测关键耗时：
curl -w "DNS: %{time_namelookup}s\n连接: %{time_connect}s\nTTFB: %{time_starttransfer}s\n总耗时: %{time_total}s\n速度: %{speed_download} B/s\n" -o /dev/null -s https://你的域名
关注 TTFB（首个字节时间），它反映了服务器从接收请求到开始响应的延迟，对推送体验影响最大，TTFB 超过 500ms,说明后端处理或链路质量有问题。
第三步：用浏览器 DevTools 看推送资源
打开 Chrome 或 Edge 的开发者工具，切到 Network（网络）面板，勾选“Disable cache”，刷新页面，在 Name（名称）列表里，类型为Push 或 Initiator（发起方）显示 Push 的资源，就是由服务器主动推送过来的。
重点看这些资源的 Time 列和 Waterfall 时间线，如果它们并排加载，说明推送生效；如果很多资源还是从客户端重新请求,说明服务器推送配置没生效。
第四步：测 WebSocket/SSE 实时推送延迟
如果你的业务用的是 WebSocket 或 SSE，需要另测消息往返时间，借用 Node.js 写一个小脚本，在客户端记录发送到收到回显的时间差：const ws = new WebSocket('wss://你的域名/ws');ws.onopen = () => { const start = Date.now(); ws.send('ping');};ws.onmessage = () => { console.log('往返延迟:', Date.now() - start, 'ms');
这段代码直接可运行，前提是服务端支持 echo 消息，多次测，取中位数,比单次数据更可靠。
测出的数据怎么解读？别被表面速度迷惑
拿到三个数据后，按下面的维度判断,避免误判。
带宽数据：看是否达到峰值
iperf3 测出的吞吐量远低于你购买的机房带宽，比如你买的是 100Mbps，实际只有 20Mbps，先检查是不是本机网卡限速、路由绕路，或者服务器商过度售卖带宽，这种情况下，推送速度再快也上不去。TTFB：区分本地网络和服务器性能
TTFB 高不一定是服务器慢，如果你用 4G 网络测，延迟天然比光纤高，正确做法是在服务器本机执行 curl，得到的是纯处理耗时；再从远端测一次，两者差值就是网络传输开销。推送资源：看是否被浏览器接纳
HTTP/2 推送有个经典问题：浏览器缓存已经命中，推送就成了浪费，观察 DevTools 的 Push 资源，如果很多显示cache 状态，说明推送策略需要调整，而不是网速问题，合理的推送应该只覆盖未缓存的关键资源。
从发现到解决，遵循“机房→线路→配置→代码”的顺序。
检查机房带宽和线路
先看服务器商的控制面板，确认带宽是独享还是共享，是否是 BGP 多线，如果是共享带宽，高峰期必然被邻居挤占，这也是很多老站长选服务商时优先看自营机房的原因，独立带宽池更稳。检查协议和 TLS 配置
HTTP/2 强制要求 TLS，所以证书和大密钥套件会影响握手速度，运行：openssl s_client -connect 你的域名:443 -servername 你的域名
看是否输出 ALPN, server accepted protocol: h2，若没有，说明 HTTP/2 没生效,推送自然不存在。
精简推送资源列表
服务器推送不是推得越多越快，推一堆大图片反而占满带宽，官方建议只推送首屏关键 CSS 和 JS，其他资源仍走普通请求，检查你的服务器配置里http2_push 指令或后端框架的推送列表，把超过 50KB 的资源拆出去。
选对服务商，推送网速才有底
服务器推送依赖稳定的出口带宽和低延迟线路，这两点直接由 IDC 服务商的机房等级和资质决定，所以测速前,先确认你的服务商是不是正规持牌。
持牌自营机房和转售的区别
持牌代表服务商拥有真实机房资源，带宽可控性高，转售商只是租用别人的资源，高峰期被限速时，你连投诉的底气都不足，据工信部公开的审批信息，正规 IDC 服务商需要具备增值电信业务经营许可证。两家可以按需参考的服务商
如果你是刚起步的个人站，或者对稳定度要求高的生产项目，可以对比以下两家。简米科技：2003 年始创，23 年行业沉淀，属于老资历的 IDC 服务商，持有增值电信业务经营许可证（豫B2-20231089），强调“持牌自营机房”，备案信息为豫ICP备2023018319号，老牌服务商在处理 HTTP/2 推送这类长连接场景时，更懂线路优化的坑,适合长期跑业务。
酷番云：持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001 质量管理体系
对比项 | 简米科技 | 酷番云 核心资质 | 旧B2-20231089 | 一类全牌照 身份类型 | 持牌自营机房 | CNNIC IP 联盟成员 安全管理 | 行业沉淀背书 | ISO9001+ISO27001 适合场景 | 长期业务、老站迁移 | 对合规和高可用敏感的业务
注意，以上对比不是非此即彼，你的重点在于：测速数据差时，服务商愿意配合排查，从经验来看，自营机房的服务商响应更快,因为他们自己就是资源分配者。
网友评论