阿里云服务器网络问题咨询

2017-02-22 12:00:57 +08:00
 anyforever

现象:所在阿里云服务器的程序(在别的机房稳定运行至少两年), php 环境,使用 curl 访问又拍接口,非常高几率(有正常上传成功的记录)的 HTTP 返回状态码为 0 。

以下为在服务器端使用 traceroute 和 mtr 工具测试又拍接口的链路返回情况。以前没怎么接触过网络相关的调试,一般只是简单的用下 ping ,虽然百度了下这两个命令的结果解读,但是对理解的不是很有底,所以还是请有经验的朋友帮忙解读一下下面的测试结果。

$ traceroute v0.api.upyun.com traceroute to v0.api.upyun.com (111.206.105.226), 30 hops max, 60 byte packets 1 11.242.177.50 (11.242.177.50) 0.848 ms 11.242.176.142 (11.242.176.142) 0.932 ms 11.242.158.114 (11.242.158.114) 0.905 ms 2 11.242.177.46 (11.242.177.46) 0.829 ms 11.242.157.218 (11.242.157.218) 0.848 ms 11.242.177.62 (11.242.177.62) 0.873 ms 3 42.120.243.90 (42.120.243.90) 2.587 ms 42.120.243.86 (42.120.243.86) 2.500 ms 42.120.243.182 (42.120.243.182) 3.477 ms 4 123.56.34.21 (123.56.34.21) 1.898 ms 101.200.109.150 (101.200.109.150) 44.165 ms 123.56.34.5 (123.56.34.5) 1.958 ms 5 * * * 6 61.51.116.225 (61.51.116.225) 4.663 ms 3.004 ms 123.126.8.37 (123.126.8.37) 1.434 ms 7 124.65.61.177 (124.65.61.177) 4.113 ms 123.126.8.218 (123.126.8.218) 6.914 ms 124.65.61.173 (124.65.61.173) 5.466 ms 8 61.51.247.186 (61.51.247.186) 1.742 ms 123.126.8.218 (123.126.8.218) 6.888 ms 61.51.247.186 (61.51.247.186) 1.757 ms 9 61.51.247.186 (61.51.247.186) 2.484 ms 2.376 ms 61.148.163.194 (61.148.163.194) 2.982 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

$ traceroute -r v0.api.upyun.com traceroute to v0.api.upyun.com (111.206.105.226), 30 hops max, 60 byte packets connect: Network is unreachable

使用 trace 测试,链路不通。阿里客服说上面工具不准,让使用 mtr 测试,发了测试结果给他们,他们反馈说,网络是正常的。

$ mtr -c 20 -n --report v0.api.upyun.com HOST: iZ2zeienl21fksruegqz Loss% Snt Last Avg Best Wrst StDev

  1. 11.242.176.146 0.0% 20 0.9 1.0 0.9 1.9 0.2
  2. 11.242.176.146 0.0% 20 0.8 0.8 0.8 1.0 0.0
  3. 106.11.37.34 0.0% 20 1.8 1.8 1.0 3.1 0.6
  4. 123.56.34.26 0.0% 20 1.7 1.8 1.7 2.8 0.3
  5. 61.49.137.53 70.0% 20 13485 14085 13485 14823 505.6
  6. 123.126.8.37 0.0% 20 2.2 2.2 2.2 2.3 0.0
  7. 123.126.8.113 0.0% 20 5.2 4.6 3.3 6.6 1.1
  8. 202.106.34.54 0.0% 20 5.6 5.2 3.1 7.0 1.3
  9. 61.51.247.186 0.0% 20 2.6 2.6 2.5 2.6 0.0
  10. 61.49.163.78 0.0% 20 4.0 4.5 3.9 8.4 1.0
  11. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0
  12. 111.206.105.226 0.0% 20 3.1 3.2 3.0 3.7 0.1

在多个测试结果中,第 5 跳,均有不同程度的丢包。 11 跳均是 100%,这个到底能不能到达目标服务器?或者是网络的哪个节点有问题?

找了个国外 VPS 试了下

$ mtr -c 20 -n --report v0.api.upyun.com Start: Wed Feb 22 10:56:50 2017 HOST: apple Loss% Snt Last Avg Best Wrst StDev

1.|-- 107.182.184.23 0.0% 20 0.0 0.1 0.0 0.2 0.0 2.|-- 173.254.225.65 0.0% 20 0.4 1.3 0.3 16.9 3.0 3.|-- 96.44.180.97 0.0% 20 0.3 0.4 0.2 1.1 0.0 4.|-- 213.248.71.105 0.0% 20 0.5 1.0 0.4 3.4 0.5 5.|-- 213.248.101.50 0.0% 20 3.4 4.8 1.5 11.7 2.9 6.|-- 129.250.5.29 0.0% 20 3.6 5.3 1.3 13.8 3.5 7.|-- 128.242.180.190 0.0% 20 3.4 4.1 3.4 10.8 1.7 8.|-- 10.16.18.98 0.0% 20 11.4 6.7 3.5 11.4 2.7 9.|-- 165.254.60.146 0.0% 20 1.1 3.7 0.7 8.7 2.5

3523 次点击
所在节点    云计算
4 条回复
ovear
2017-02-22 12:21:07 +08:00
网络中的节点不一定会回应你的 ICMP
linbiaye
2017-02-22 12:28:43 +08:00
看最后一跳,@overa 说的对,有些设备就是不回 icmp 。
linbiaye
2017-02-22 12:32:29 +08:00
curl 返回的状态码为 0 这个问题你需要两边都抓包看。能返回状态码就不是 tcp/网络的问题, curl 是拿到了 http response 的。
anyforever
2017-02-22 12:48:57 +08:00
@ovear
@linbiaye 嗯。谢谢。我再想想其它办法测试这个。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/342274

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX