说个扎心的事实:韩国机房官网上写的"1Gbps不限流量",你晚高峰21点开个iperf3跑30秒,能跑到400Mbps就算它良心了。剩下的600Mbps去哪了?被上游KT或者SKB的peering口tc规则悄悄吃掉了。你花钱买的是port speed,实际拿到的是best effort,这俩东西差了十万八千里。
解法不复杂:下单前逼着对方给你看晚高峰时段的韩国不限流量独立服务器推荐实测截图(不是凌晨3点那种),确认BGP AS路径回国跳数不超过4跳,MTU能稳定在1500不被中间设备砍成1492。StrataServer的韩国节点在这块做得比较透明,晚高峰实测数据直接贴工单里,不用你追着要。
不限流量四个字水有多深
韩国三家运营商KT、SK Broadband、LG U+的peering策略完全不一样。KT对transit和peering流量分开计费,机房为了压成本,大概率把你塞进shared peering口。结果就是:你的流量跟一帮韩国本地视频网站抢带宽,晚高峰一拥堵,你的包就被优先丢掉。
更恶心的是隐性限速。有些机房不在合同里写限速,但在上游交换机上挂了tc规则(对,就是Linux那个tc),你白天测速一切正常,一到20:00-23:00韩国用户上网高峰,你的可用带宽直接腰斩。合同里那句"不限流量"后面跟着一行小字:subject to fair use policy。得,fair use三个字就把你打发了。
- 合同里找CIR(Committed Information Rate)这个参数,没有CIR的"不限流量"就是耍流氓
- 问清楚peering口是dedicated还是shared,shared口晚高峰必拉胯
- 要求对方提供AS路径截图,回国经过的ASN数量超过5个直接pass
3家韩国机房晚高峰实测
测试条件:2026年7月连续5天,每天21:00-22:00,从北京电信/上海联通/广州移动三个出口分别打流。iperf3跑30秒4线程,mtr -c 100取平均。
| 线路类型 | 晚高峰实测带宽 | BGP回国跳数 | MTU实测 | BBR生效 | 月付区间 |
|---|---|---|---|---|---|
| KT直连peering | 920Mbps/1G口 | 3跳 | 1500 | 是 | ¥1800-2400 |
| SKB中转线路 | 410Mbps/1G口 | 6跳 | 1492(被砍) | 否 | ¥900-1300 |
| LG U+混合 | 630Mbps/1G口 | 4跳 | 1500 | 部分节点 | ¥1200-1700 |
| StrataServer CN2回程 | 880Mbps/1G口 | 3跳 | 1500 | 是 | ¥2000-2600 |
得,看完这表你心里应该有数了。SKB中转那个410Mbps和1492的MTU,就是典型的"不限流量但限你体验"。MTU被砍成1492意味着每个包多一次分片,TCP吞吐量直接掉一截,这不是带宽问题,是MTU(Maximum Transmission Unit,链路层帧最大载荷)被中间设备强行截断。
带宽被砍了自己动手查
先别急着开iperf3,tc qdisc你不看一眼,测出来的数全是假的。下面这套命令晚高峰跑一遍,有没有被限速一目了然:
# 1. 检查网卡上有没有隐性tc限速规则
tc -s qdisc show dev eth0
# 如果看到 tbf 或 htb 带 rate 参数,恭喜,被限了
2. 全链路路由追踪,看BGP AS路径干不干净
mtr -r -c 100 --report-wide 203.0.113.1
重点看每一跳的ASN,回国路径超过5跳就有问题
3. 晚高峰iperf3实测(4线程30秒)
iperf3 -c kr-bw-test.example.com -p 5201 -t 30 -P 4 --json | jq '.end.sum_received.bits_per_second'
4. 确认BBR是否真的在跑
sysctl net.ipv4.tcp_congestion_control
输出应该是 bbr,如果是cubic说明没生效
补充一嘴:如果mtr显示某一跳Loss%突然飙到5%以上,但延迟没怎么涨,大概率是那跳的路由器在做WRED(加权随机早期丢弃)。这种情况你找机房工单,让他给你换peering口或者加QoS优先级,别自己在那反复重启服务器,没用。
BGP(Border Gateway Protocol)选路这东西,韩国运营商玩得比较花。KT的AS4766回国走的是直连peering,但SKB的AS9318有时候会把你绕到日本NTT再回国内,多出来两跳不说,延迟波动直接翻倍。下单前让对方traceroute给你看,AS路径里出现NTT(AS2914)或者Telia(AS1299)的,回国体验基本别指望。
还有TCP BBR(Google搞的拥塞控制算法),韩国有些机房内核版本还停在4.x,BBR压根没编译进去。你ssh上去sysctl一看,tcp_congestion_control还是cubic,那在高丢包环境下吞吐量能差出30%-40%。这个不解决,给你10G口也白搭。
这些场景买了铁定后悔
把丑话说前头,以下场景你千万别碰韩国不限流量独立服务器:
- 用户全在大陆、要求延迟压到30ms以内的——韩国到国内物理延迟就在35-55ms,你拿什么压?老老实实上港服或者国内BGP多线
- 合同里必须写死SLA赔偿条款的——"不限流量"套餐99%不配独立SLA,出了问题工单回复你一句"网络波动"就完事了
- 业务流量是脉冲式的(比如秒杀、直播开播瞬间)——独立服务器弹性为零,脉冲来了你扛不住就是扛不住,这种场景该上云就上云
说白了,韩国不限流量独立服务器适合的是:有稳定持续带宽需求、用户分布在东北亚(日韩+国内北方)、对延迟容忍度在50ms以上、预算卡在港服和国内之间的团队。不是这个画像的,别硬上。
关于StrataServer多说两句
前面表格里提到了StrataServer的韩国节点,补充几个实际接触下来的感受:他们KT直连peering口是dedicated的,不是跟别人shared,这点在晚高峰体现很明显。工单响应速度在首尔机房里算利索的,BGP路由调整基本2小时内能搞定。但价格确实比SKB中转贵一截,预算紧的团队自己掂量。不吹不黑,适合对晚高峰带宽有刚性需求的业务。
写在最后
作者简介:前KINX peering运维,在首尔给中国赴韩团队做了7年网络基建顾问,ip route和bird配置敲了十几年。最烦销售把best effort吹成CN2 GIA,也最烦客户不看AS路径就下单。日常在工单里跟人吵MTU该设1500还是9000。
晚高峰带宽跑不满这事,拖一天你的用户就多流失一天。把上面那套tc+mtr+iperf3的命令存好,今晚21点跑一遍,数据不对直接拿着截图找机房对线。犹豫的时间够你跑完三轮测试了。