迁移之前，必须留一套完整的带宽基线，否则迁移后带宽缩水、延迟抖动都缺乏对照依据，验收只能靠猜。
为什么迁移前必须留带宽基线
带宽基线不是一份可有可无的表格，它是迁移前的网络性能快照，很多人以为迁移就是把数据搬过去，结果搬完才发现访问变慢、接口超时、视频卡顿，却说不清是云服务商的问题还是自己业务的问题，没有基线,所有争论都停留在体感层面。
- 有基线，迁移后可以逐项对比吞吐、延迟、丢包。
- 没基线，迁移后只能凭印象说“好像慢了”。
- 带宽问题往往在迁移后才暴露,但根源在迁移前没留底。
- 业内专家指出,多数迁移性能争议的起点都是缺少可量化的基线数据。
基线的价值在于把网络质量从主观感受变成客观数字，它不解决性能问题,但能帮你定位问题到底出在哪一段。
迁移前如何测试带宽基线：先定时间窗口和对象
选对测试窗口比测试本身重要
带宽不是恒定值，业务高峰期和凌晨三点的可用带宽可能差出很远，公网出口尤其明显，只测一次就写进文档,等于拿偶然当规律。
- 至少选取三个时间窗口：业务低峰、业务高峰、夜间维护时段。
- 每个窗口测试持续时间建议不少于60秒,TCP测试需要爬坡时间。
- 如果业务有周期性，比如周末促销或月底结算,测试窗口要覆盖这些节点。
- 记录测试时的并发连接数、包大小、协议类型,否则数据无法复现。
时间窗口定错，基线就失真，后续对比迁移前后数据时,相同窗口才有可比性。
测试对象要拆成三段
一次完整带宽基线不能只测一个方向，很多迁移踩坑是因为只测了源站到目标站,忽略了对外服务链路。
- 第一段：源主机到目标主机,看迁移链路本身的质量。
- 第二段：源主机到互联网出口,看原有环境对外提供服务的真实能力。
- 第三段：目标主机到互联网出口,看新环境能不能接住原有流量。
三段都要留数据，迁移后如果用户访问变慢，但源到目标内网速度正常,问题大概率出在目标端的公网出口或安全策略上。
工具组合：不花钱也能测
带宽基线检测工具免费方案有很多，Linux生态下尤其成熟,不需要一上来就买商业监控系统。
- iperf3：测TCP/UDP吞吐，开源免费，Linux/Windows/macOS都能跑。
- qperf：支持延迟和吞吐同时测,适合快速验证。
- netperf：老牌工具,适合需要精细控制测试参数的场景。
- ping：测RTT和丢包,最简单也最容易忽略。
- mtr：结合ping和traceroute,能看出丢包发生在哪一跳。
这些工具足够完成一次完整的基线记录，商业工具的优势在长期趋势展示，但对一次性迁移基线来说,免费方案完全够用。
服务器迁移带宽基线怎么记录：三类数据必须留档
吞吐量记录：迁移后最直接的对比项
吞吐量是带宽基线里最核心的数字，它回答一个问题：这条链路在单位时间内到底能传多少数据。
Linux下常用命令如下：
- 服务端启动：
iperf3 -s - 客户端测试TCP上行：
iperf3 -c 目标IP -t 60 -P 4 - 客户端测试TCP下行：
iperf3 -c 目标IP -t 60 -P 4 -R - 记录指标：发送端和接收端的平均吞吐、P50、P95,以及重传次数。
-P 4表示4个并发流，能更贴近真实业务多连接场景，单流测试往往测不出带宽上限,因为TCP窗口增长需要时间。
延迟与抖动记录：接口响应变慢的元凶
吞吐量高不代表体验好，如果一个接口每次调用都要多等几十毫秒，即使带宽很大，用户端依然感觉卡,延迟和抖动必须单独留档。
- 使用
ping -c 100 目标IP持续发送100个包。 - 记录最小RTT、平均RTT、最大RTT、mdev值。
- mdev代表抖动,数值越大说明延迟波动越剧烈。
- 对数据库同步、实时消息类业务,抖动比平均延迟更关键。
延迟基线要单独成表，不要和吞吐数据混在一起，迁移后如果平均延迟没变但抖动变大,同样会引发业务异常。
丢包率记录：最容易被忽视的暗病
少量丢包在公网环境里很难完全避免，但迁移后如果丢包率明显上升，TCP会频繁重传，表现就是速度骤降、连接不稳定。
- 使用
ping -c 200 目标IP,统计丢包数。 - 使用
mtr -r -c 100 目标IP,查看每一跳的丢包率。 - 公网路径丢包率多数情况下应保持在一个很低的水平。
- 内网路径如果出现持续丢包,几乎可以判定链路或网卡有问题。
丢包基线是迁移后排查问题的关键证据，很多时候带宽没变，但丢包率翻倍，用户感知就是“网络不稳定”。
三组场景测试命令速查
| 测试场景 | 推荐工具 | 关键记录指标 | 建议时长 |
|---|---|---|---|
| 内网吞吐 | iperf3 | 平均吞吐、P95、重传数 | 60秒以上 |
| 公网延迟 | ping | 最小/平均/最大RTT、mdev | 100个包 |
| 路径丢包 | mtr | 每跳丢包率、平均延迟 | 100个包 |
这套记录方式不依赖复杂系统，一次迁移准备阶段用半天就能完成，关键是坚持在相同时间窗口重复测试,取中位数作为基线。
云迁移前后带宽对比方法：同一路径同一参数
对比前先固定变量
迁移后复测时，最容易犯的错误是换了测试条件，源端用内网IP测，目标端用公网IP测,得到的数据根本没有可比性。
- 相同协议：TCP都用TCP，UDP都用UDP,别混着比。
- 相同端口：源端测试用的端口号,目标端复测也要一致。
- 相同并发数：
-P参数必须一致,4流就都4流。 - 相同包大小：iperf3默认包大小可以指定,前后要统一。
- 相同时间窗口：迁移前周三下午3点测,迁移后就周三下午3点复测。
变量不固定，对比就是自欺欺人，固定变量后，哪怕数据有波动,也能判断是真实差异还是环境噪声。
偏差容忍线怎么定
迁移后带宽不可能和迁移前完全一样，云环境和物理机环境天然存在差异,关键是要有一个判断标准。
- 行业共识认为，同规格同地域下，迁移前后带宽波动在10%以内多数属于正常范围。
- 延迟增加几毫秒通常不会影响普通业务,但实时类业务要单独评估。
- 丢包率从0变成持续丢包,无论数值多小都应立即排查。
- 如果吞吐下降超过容忍线，优先检查云实例的网络带宽上限、突发带宽机制、安全组规则。
不要追求完全一致，要追求落在可接受区间,基线就是用来画这个区间的。
用历史基线做验收
迁移完成后，把复测数据填到基线表格旁边，每一行逐一对照,肉眼扫一遍就能看出哪些指标偏离。
- 吞吐下降超过容忍线的,先调整实例规格或带宽包。
- 延迟明显升高的，检查是否跨地域迁移、是否存在链路绕行。
- 丢包率异常的,优先排查目标端公网IP的线路质量和防火墙策略。
- 全部落在区间内的,验收签字才有底气。
没有基线，验收就是走形式，有了基线，迁移后才不会陷入“我觉得变慢了”的扯皮。
北京服务器迁移带宽基线：地域差异不能忽略
跨地域与同地域不一样
北京服务器迁移带宽基线有个特殊点：源站和目标站是否都在北京，结果可能完全不同，同地域可用区间内网带宽通常远高于公网带宽,延迟也低得多。
- 北京到北京同地域：内网吞吐大，延迟1毫秒以内,适合做热迁移。
- 北京到上海跨地域：走骨干网或专线，延迟20到30毫秒,吞吐受距离和线路影响。
- 北京到广州跨地域：延迟更高，公网路径复杂,丢包风险增加。
- 跨地域专线价格昂贵，但稳定性远好于公网,基线要分开记录。
如果迁移后出现跨地域访问需求，必须单独建立跨地域基线,不能拿同地域数据硬套。
地域选择影响基线
云厂商的北京区域通常有多个可用区，比如北京可用区A、可用区B，同一区域不同可用区之间内网延迟通常只有零点几毫秒,但跨区域就会明显增加。
- 目标端在北京可用区A，源站也在北京可用区A,内网基线最有参考价值。
- 源站在自建机房，目标是北京云服务器,公网基线是唯一选择。
- 公网基线受运营商BGP线路影响,不同时段波动比内网大得多。
- 如果业务用户主要集中在华北,北京地域的选择能显著降低公网延迟。
记录基线时要把源站地域、目标地域、可用区写清楚,否则过两周自己都忘了当时测的是哪条路径。
价格与带宽的隐性关系
北京地域的带宽价格通常高于部分其他地域，迁移前如果不对照基线调整带宽包,迁移后很容易出现带宽买小了或买大了的情况。
- 固定带宽计费：按峰值购买,基线能告诉你实际需要多大峰值。
- 流量计费：按出站流量算钱,基线能帮你预估月度流量消耗。
- 带宽基线检测工具免费方案测出来的数据,可以直接用于选择带宽包规格。
- 如果基线显示高峰吞吐只有50Mbps，买100Mbps固定带宽就是浪费；如果高峰接近100Mbps,就要预留余量。
先测基线，再买带宽,顺序不能反。
问答：迁移之前记录一次完整的带宽基线
迁移前如何测试带宽基线更准确？
使用iperf3进行TCP多流测试，每个时间窗口至少测三次，去掉明显异常值后取中位数，同时用ping记录延迟和丢包，用mtr确认路径状态，测试时关闭无关业务进程,避免自身流量干扰测试结果。
服务器迁移带宽基线需要记录多久的数据？
至少覆盖一个完整业务周期，如果业务有明显周规律，建议连续记录7天，每天在相同时间窗口测试，这样能看出工作日和周末的差异,也能捕捉到周期性的网络波动。
没有公网IP怎么测内网带宽基线？
直接用内网IP运行iperf3即可，服务端在目标机器上执行iperf3 -s，客户端执行iperf3 -c 内网IP -t 60 -P 4，需要确保两端防火墙放行iperf3默认端口5201，或者用-p参数指定其他端口。
把带宽基线留成迁移文档的一部分,迁移后验收才不会变成扯皮。