查看厂商标注的带宽(通常以Mbps或Gbps为单位)只是第一步,关键是把带宽转换为实际吞吐量并结合业务场景计算:按单用户平均速率×并发用户数,再乘以峰值系数(通常1.2~1.5)。如果你要做文件下载或视频推流,建议预留至少20%~30%的冗余。注意区分带宽上行与下行,网站、API等对上行要求更高,且关注是否为独享带宽或共享带宽,独享更稳定。
用Ping测试得到的往返时间(RTT)能反映延迟,但单纯RTT不足以评估质量。一般在线游戏/实时语音要求RTT<100ms,交互型网站或SSH要求<200ms,大文件传输可容忍更高延迟。还需关注丢包率与抖动(jitter):丢包>1%或抖动大,会严重影响体验。实际评估时应多次测试取均值与95百分位。
常用工具包括 iperf(测吞吐)、ping、traceroute、mtr(综合延迟和丢包)以及基于浏览器的 Speedtest。提供的流程:1) 先用ping测RTT与丢包;2) 用iperf测试到最近测试点的真实带宽(上/下行);3) 用mtr查看路径中哪里发生抖动或丢包。要求供应商提供测试账号或临时IP,最好在不同时间段测试(高峰/非高峰)以判断波动。
按峰值并发计算带宽:单用户平均占用(KB/s或Mbps)×峰值并发数,再乘以网络开销系数。对于突发流量,考虑使用带宽突发(burst)或流量清洗策略。若业务有短时高峰(如秒杀、直播),建议采用流量自动扩容或CDN分流,避免因短时并发超出带宽导致延迟飙升与丢包。
简单建议:静态网站/博客:下行带宽10~50Mbps通常足够,容忍较高延迟;电子商务/动态站点:上行与下行均衡,50~200Mbps,RTT<150ms优先;实时语音/视频会议:低延迟(RTT<100ms)、低丢包(<0.5%)且上行带宽充足;在线游戏/实时交互:尽量选择延迟最低的节点,RTT<80~100ms为佳,并保持稳定的带宽和极低丢包。若面向全球用户,优先使用CDN与多节点部署。