V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
通过以下 Referral 链接购买 DigitalOcean 主机,你将可以帮助 V2EX 持续发展
DigitalOcean - SSD Cloud Servers
crontab
V2EX  ›  VPS

iperf3 测试本地( China Unicom)与 VPS (DO-SFO1)带宽问题,请多多指教!

  •  
  •   crontab · 2017-03-12 17:06:38 +08:00 · 556 次点击
    这是一个创建于 2845 天前的主题,其中的信息可能已经有所发展或是发生改变。
    ( PS :本来是有好几个问题要请教的,后来写着写着,再测试了几次,有好几个问题已经有了“答案”。把整个流程贴上来,不对的地方,理解错误的地方,希望大家多多指正!)

    VPS 端 (DO-SFO1-CentOS-512MB )运行:# iperf3 -s
    本地端( China Unicom ) 100Mbps 外网带宽,具备公网 IP , CentOS 7 。

    1. 本地的主服务器, UDP 模式测带宽:
    上午 9 点测试:# iperf3 -c vps -u -b 200M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 114 MBytes 95.5 Mbits/sec 0.105 ms 74102/82459 (90%)
    中午 14 点测试:# iperf3 -c vps -u -b 200M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 114 MBytes 95.3 Mbits/sec 0.191 ms 70051/82256 (85%)
    UDP 带宽测试模式虽然可以达到主服务器的 100Mbps 外网带宽,但是实际上 90% 的包都丢了。
    上午(第一次)丢包率 90%,中午(第二次) UDP 丢包率 85%;

    在 VPS 端得出的报告更可信( UDP iperf3 客户端没有每一秒的丢包情况,在服务器端可以查看到),上午 UDP 测试(对应上面的 90%丢包率)除了第一次咸鱼翻身以外,其他时候都被丢包达 96%。(丢包原因已经确定,参看下文第 2 步最后的结论)
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 5] 0.00-1.00 sec 7.29 MBytes 61.2 Mbits/sec 0.155 ms 932/6214 (15%)
    [ 5] 1.00-2.00 sec 469 KBytes 3.85 Mbits/sec 0.124 ms 7918/8250 (96%)
    [ 5] 2.00-3.00 sec 481 KBytes 3.94 Mbits/sec 0.081 ms 7912/8252 (96%)
    [ 5] 3.00-4.00 sec 460 KBytes 3.76 Mbits/sec 0.104 ms 7901/8226 (96%)
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 5] 0.00-10.75 sec 0.00 Bytes 0.00 bits/sec 0.105 ms 74102/82459 (90%)

    中午的 UDP 测试(对应上面的 85% 丢包率), VPS 端的报告,有趣的地方来了!(典型值: 485KB/s , 4Mbps , UDP 传输成功的包 342 个)
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 5] 0.00-1.00 sec 8.56 MBytes 71.8 Mbits/sec 0.120 ms 1/6199 (0.016%)
    [ 5] 1.00-2.00 sec 4.39 MBytes 36.8 Mbits/sec 0.243 ms 5005/8184 (61%)
    [ 5] 2.00-3.00 sec 485 KBytes 3.97 Mbits/sec 0.162 ms 7890/8233 (96%)
    [ 5] 3.00-4.00 sec 485 KBytes 3.97 Mbits/sec 0.176 ms 7891/8234 (96%)
    [ 5] 4.00-5.00 sec 484 KBytes 3.96 Mbits/sec 0.162 ms 7863/8205 (96%)
    [ 5] 5.00-6.00 sec 485 KBytes 3.97 Mbits/sec 0.183 ms 7894/8237 (96%)
    [ 5] 6.00-7.00 sec 485 KBytes 3.97 Mbits/sec 0.190 ms 7871/8214 (96%)
    [ 5] 7.00-8.00 sec 485 KBytes 3.97 Mbits/sec 0.202 ms 7895/8238 (96%)
    [ 5] 8.00-9.00 sec 484 KBytes 3.96 Mbits/sec 0.177 ms 7854/8196 (96%)
    [ 5] 9.00-10.00 sec 485 KBytes 3.97 Mbits/sec 0.107 ms 7903/8246 (96%)
    [ 5] 10.00-10.77 sec 122 KBytes 1.29 Mbits/sec 0.191 ms 1984/2070 (96%)
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 5] 0.00-10.77 sec 0.00 Bytes 0.00 bits/sec 0.191 ms 70051/82256 (85%)

    后面 8 秒整条线路的 UDP 带宽存在 4M 带宽瓶颈,且典型值 96%的丢包率很让人在意啊!
    UDP 丢包是可预知的,不过造成这么高丢包率,请问这是什么原因?线路问题?路由器策略丢 UDP ?联通 QoS 限速?

    线路测试( IP 查询使用 ipip.net 数据):
    # mtr vps
    Host Loss% Snt Last Avg Best Wrst StDev
    1. 公网 IP 网关 (xxx.xxx.xxx.254) 0.0% 28 0.3 1.4 0.3 18.2 3.9
    4. 大局域网?( 10.0.0.2 ) 88.5% 27 0.8 0.9 0.7 1.1 0.0
    5. 本地教育网出口() 0.0% 27 1.8 4.4 1.4 33.8 7.2
    6. 北京教育网 0.0% 27 5.2 3.8 1.6 7.8 1.5
    14. 亚太环通(Pacnet)国际骨干网节点 0.0% 27 58.9 60.4 57.8 97.8 7.9
    15. IPIP (中国香港 telstra.com ) / 纯真 IP 库数据(日本 亚太环通(Pacnet)有限公司) 0.0% 27 59.9 62.0 58.3 82.2 5.2
    16. IPIP (洛杉矶 telstra.com ) / 纯真 IP (日本 亚太环通(Pacnet)有限公司) 0.0% 27 213.9 213.3 212.7 214.9 0.2
    17. IPIP ( PACNET 骨干网 telstra.com )/ 纯真(日本 亚太环通(Pacnet)有限公司) 0.0% 27 228.1 225.2 223.7 229.6 1.4
    ...
    23. VPS digitalocean.com - Los_Angeles 0.0% 4 201.8 203.0 201.8 205.0 1.3

    中间线路的 IP 查询,发现不同数据差距很大,想问问大家,哪个查询 IP 的数据库更可靠?
    目前感觉可信的是 IPIP 数据,从 15 到 16 是从中国 HK 至美国 LA ,延迟从 59.9 到 213.9ms ; VPS 的延迟长期基本稳定在 200ms 左右;
    另外校园网公网 IP 是包在学校的大局域网下的,用 VPS 也是无法 ping 通校园网分配的公网 IP (校园网禁止了 ICMP 包),无法 SSH 登录(改端口也没有用, ssh 卡在连接那一步)。 mtr 中的第 4 跳 88.5% 不是真的意义的丢包,而是路由器端人为限制 ICMP 发送的速率,因为后面跳数都没有丢包。

    目前不太确定 UDP 丢包的瓶颈( 4Mbps , 96%丢包率,怀疑是被限速),因此先测试一下局域网的丢包率。

    2. 本地局域网内的一台计算机(连接 5G Wi-Fi ), UDP 模式测带宽,更是百分比被丢包:
    # iperf3 -c vps -u -b 1000M
    [ ID] Interval Transfer Bandwidth Total Datagrams
    [ 4] 0.00-1.00 sec 49.2 MBytes 413 Mbits/sec 107997
    [ 4] 1.00-2.00 sec 58.5 MBytes 491 Mbits/sec 109859
    ...
    [ 4] 9.00-10.00 sec 49.9 MBytes 418 Mbits/sec 114915
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 530 MBytes 445 Mbits/sec 1.636 ms 1103148/1113165 (99%)

    可以看出 UDP 模式下发包速率虽然可以达到满带宽(百兆网线下的 100Mpbs , 5G Tx Rate 585Mbps 下的 50MB/s 损耗近似满带宽),然并卵, 99%的丢包率。

    测试本地局域网 PC-B --CAT 5 百兆网线 --> LAN Server ,百兆带宽跑满,且无丢包。
    # iperf3 -c 192.168.0.1 -u -b 120M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 113 MBytes 94.9 Mbits/sec 0.021 ms 0/14476 (0%)

    测试本地局域网 PC-A --(5G Wi-Fi)--> LAN Server
    # iperf3 -c 192.168.0.1 -u -b 600M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 528 MBytes 443 Mbits/sec 0.023 ms 739754/1119518 (66%)
    丢包率很高!无线就这么不堪吗?从小到大,逐步增大 UDP 的发包速率看看。

    # iperf3 -c 192.168.0.1 -u -b 200M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 236 MBytes 198 Mbits/sec 0.019 ms 0/171242 (0%)
    # iperf3 -c 192.168.0.1 -u -b 400M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 473 MBytes 397 Mbits/sec 0.027 ms 37162/379864 (9.8%)
    # iperf3 -c 192.168.0.1 -u -b 500M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 541 MBytes 454 Mbits/sec 0.019 ms 710273/1098834 (65%)
    局域网内的 UDP 丢包率,瓶颈是 5G 无线路由器的转发性能?小带宽例如 200M 还是妥妥的 0% 丢包率,渣线路下,发包速率越快,丢包率越高!

    凭借这条结论,我又进行了 VPS 与本地主服务器的 UDP 带宽:
    # iperf3 -c vps -u -b 10M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 11.9 MBytes 10.0 Mbits/sec 0.036 ms 0/8632 (0%)
    # iperf3 -c vps -u -b 20M
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 23.8 MBytes 20.0 Mbits/sec 0.061 ms 11785/17263 (68%)
    UDP 发包速率增加到 20Mbps , UDP 丢包率急剧上升,看 VPS 端的 iperf3 报告。
    刚才第一次 10Mbps UDP 测试,确实没有丢包!
    [ 5] 8.00-9.00 sec 1.19 MBytes 10.0 Mbits/sec 0.054 ms 0/863 (0%)
    [ 5] 9.00-10.00 sec 1.19 MBytes 10.0 Mbits/sec 0.063 ms 0/863 (0%)
    [ 5] 10.00-10.24 sec 293 KBytes 9.98 Mbits/sec 0.099 ms 0/207 (0%)
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 5] 0.00-10.24 sec 0.00 Bytes 0.00 bits/sec 0.099 ms 0/8632 (0%)
    那第二场测试呢?
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 5] 0.00-1.00 sec 1.81 MBytes 15.2 Mbits/sec 0.111 ms 0/1309 (0%)
    [ 5] 1.00-2.00 sec 2.38 MBytes 20.0 Mbits/sec 0.086 ms 0/1727 (0%)
    [ 5] 2.00-3.00 sec 1.67 MBytes 14.0 Mbits/sec 0.073 ms 511/1722 (30%)
    [ 5] 3.00-4.00 sec 485 KBytes 3.97 Mbits/sec 0.067 ms 1387/1730 (80%)
    [ 5] 4.00-5.00 sec 484 KBytes 3.96 Mbits/sec 0.092 ms 1381/1723 (80%)
    [ 5] 5.00-6.00 sec 484 KBytes 3.96 Mbits/sec 0.094 ms 1385/1727 (80%)
    [ 5] 6.00-7.00 sec 485 KBytes 3.97 Mbits/sec 0.081 ms 1386/1729 (80%)
    [ 5] 7.00-8.00 sec 484 KBytes 3.96 Mbits/sec 0.080 ms 1382/1724 (80%)
    [ 5] 8.00-9.00 sec 485 KBytes 3.97 Mbits/sec 0.086 ms 1385/1728 (80%)
    [ 5] 9.00-10.00 sec 484 KBytes 3.96 Mbits/sec 0.080 ms 1383/1725 (80%)
    [ 5] 10.00-10.76 sec 117 KBytes 1.27 Mbits/sec 0.064 ms 336/419 (80%)
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 5] 0.00-10.76 sec 0.00 Bytes 0.00 bits/sec 0.064 ms 10536/17263 (61%)
    真奇妙!从第 3 秒开始丢包,速率被限制为 4Mbps , UDP 传输过去的包是 342 ,刚才中午的 UDP 测试(丢包率 96%)的 UPD 传输成功的包也是 342 个!速率也都是 485KB/s ;

    现在的结论:
    a. iperf3 测试 UDP 带宽,看客户端是没有用的,客户端只负责发出去,显示每一秒的发包数目,没有统计具体丢了多少包,毕竟 UDP 并没有 TCP 的 TCP 差错控制,收不收的到基本“随缘”(当前线路的通信情况)。需要看 iperf3 服务器端接收到的 UDP 统计报告,从而判断线路的 UDP 带宽。
    b. 这次线路当遇到大速率发 UDP 包(粗略测试估计是超过 20Mbps ),会限制 UDP 的速率为 485KB/s ,大约就是 342 pps (包每秒),这难得就是传说中的联通 QoS ?还是校园网 QoS ?


    3. TCP 模式(上午):# iperf3 -c vps
    上午挂 VPS SS 代理,看 1080P YouTube 无压力,测试带宽:
    [ ID] Interval Transfer Bandwidth
    [ 4] 0.00-1.00 sec 337 KBytes 2.76 Mbits/sec
    [ 4] 1.00-2.01 sec 417 KBytes 3.40 Mbits/sec
    [ 4] 2.01-3.00 sec 338 KBytes 2.78 Mbits/sec
    [ 4] 3.00-4.00 sec 356 KBytes 2.92 Mbits/sec
    [ 4] 4.00-5.00 sec 472 KBytes 3.86 Mbits/sec
    [ 4] 5.00-6.00 sec 559 KBytes 4.57 Mbits/sec
    [ 4] 6.00-7.00 sec 710 KBytes 5.81 Mbits/sec
    [ 4] 7.00-8.00 sec 1.08 MBytes 9.01 Mbits/sec
    [ 4] 8.00-9.01 sec 1.39 MBytes 11.7 Mbits/sec
    [ 4] 9.01-10.00 sec 1.91 MBytes 16.1 Mbits/sec

    那么问题来了,为什么带宽是这样逐步增大的趋势,而非固定的数值呢?难得用的时候,需要上层服务器分配对应的带宽吗?
    测试好几次,每次都是 300KB 左右起步,然后不断增大。也不求 100Mbps 满带宽,毕竟线路那么长,但是能稳定到第 10 秒的 2MB/s 就好了啊!

    TCP 模式,中午 16 点测试:# iperf3 -c vps
    [ ID] Interval Transfer Bandwidth Retr Cwnd
    [ 4] 0.00-1.00 sec 181 KBytes 1.48 Mbits/sec 11 24.0 KBytes
    [ 4] 1.00-2.00 sec 99.0 KBytes 811 Kbits/sec 19 15.6 KBytes
    [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 7 5.66 KBytes
    [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 4 2.83 KBytes
    [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 3 1.41 KBytes
    [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 3 1.41 KBytes
    [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 3 2.83 KBytes
    [ 4] 7.00-8.00 sec 63.6 KBytes 521 Kbits/sec 1 2.83 KBytes
    [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 4 1.41 KBytes
    [ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 2 2.83 KBytes
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bandwidth Retr
    [ 4] 0.00-10.00 sec 344 KBytes 281 Kbits/sec 57 sender
    [ 4] 0.00-10.00 sec 201 KBytes 164 Kbits/sec receiver
    VPS 端的报告:
    [ ID] Interval Transfer Bandwidth
    [ 5] 0.00-1.00 sec 32.5 KBytes 266 Kbits/sec
    [ 5] 1.00-2.00 sec 72.1 KBytes 591 Kbits/sec
    [ 5] 2.00-3.00 sec 29.7 KBytes 243 Kbits/sec
    [ 5] 3.00-4.00 sec 11.3 KBytes 92.7 Kbits/sec
    [ 5] 4.00-5.00 sec 2.83 KBytes 23.2 Kbits/sec
    [ 5] 5.00-6.00 sec 2.83 KBytes 23.2 Kbits/sec
    [ 5] 6.00-7.00 sec 9.90 KBytes 81.1 Kbits/sec
    [ 5] 7.00-8.00 sec 18.4 KBytes 151 Kbits/sec
    [ 5] 8.00-9.00 sec 12.7 KBytes 104 Kbits/sec
    [ 5] 9.00-10.00 sec 8.48 KBytes 69.5 Kbits/sec
    [ 5] 10.00-10.20 sec 0.00 Bytes 0.00 bits/sec
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bandwidth
    [ 5] 0.00-10.20 sec 0.00 Bytes 0.00 bits/sec sender
    [ 5] 0.00-10.20 sec 201 KBytes 161 Kbits/sec receiver

    中午和上午的 TCP 速率相差很大,这也是我中午看 YouTube 卡的原因, 720P 都出现卡顿。
    本地端 tcpdump 抓特定端口 (iperf3 端口) 的 TCP 包:
    a. 三次握手,切换另一个端口,与 iperf3 端口进行通信。延时确实挺大, client 都在发送 seq=100000 的包了, server 那边才在应答 50000 的数据包。
    b. 多个应答包情况出现, server 不断发送 ack 57958 的应答( ack 57958,options [ ... sack 1 {59406:63750}]),要求重传数据包。
    c. ack 57958, options [sack 2 {81126:82574}{59406:79678}]
    d. ack 57958, options [sack 3 {101398:130358}{97054:99950}{92710:94158}]
    e. ack 79678, options [sack 3 {101398:130358}{97054:99950}{92710:94158}]
    f. 满屏都是 sack 数据包丢失的情况。

    现在已经可以确定是运营商的锅了吗?这样的线路,应该如何选择 VPS ?换香港?
    顺便向大家请教一下 VPS 选择的有关技巧!
    4 条回复    2017-03-13 09:17:38 +08:00
    akwIX
        1
    akwIX  
       2017-03-12 19:29:48 +08:00
    不用测都知道垃圾 do 之类的没有使用必要
    sunflyer
        2
    sunflyer  
       2017-03-12 20:41:55 +08:00
    其实 DO 和 Vultr 搬瓦工这种难道不是 AFFMAN 带起来的吗(
    d7101120120
        3
    d7101120120  
       2017-03-12 23:45:43 +08:00 via Android
    联通最近一段时间似乎到美国都有很大问题
    zk8802
        4
    zk8802  
       2017-03-13 09:17:38 +08:00
    iperf3 的某些版本有 UDP 丢包误判的问题,会将所有乱序的 UDP 包都判定为丢包。你可以编译一下 GitHub 上最新的版本试试: https://github.com/esnet/iperf
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1569 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 17:00 · PVG 01:00 · LAX 09:00 · JFK 12:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.