主页 / server / 问题 / 511072
Accepted
spuder
Asked: 2013-05-27 21:44:00 +0800 CST

网络延迟故障排除

  • 772

一个公寓大楼有光纤互联网，但在上个月遇到了延迟问题。

租户经常遇到超时和损坏的网页。当前的解决方法是刷新网页六次，直到它正确加载。

症状是：

  • 不稳定，每个租户每天发生几次
  • 在笔记本电脑上请求新的 dhcp 租约并不能解决问题
  • 影响 mac 和 windows 机器 更新：只影响 MAC 用户！*
  • 影响无线和有线
  • 不是 DNS 问题，因为我们已经尝试过 ISP 的 dns 和 google 的 dns 服务器，但没有任何改进
  • iTunes 受此影响很大。iTunes 商店经常超时（iPad、iPhone、Mac）

可以使用哪些其他诊断工具来识别问题？ISP 说一切正常。

traceroute 显示第 9 跳有巨大的延迟（几秒）。

traceroute google.com

traceroute: Warning: google.com has multiple addresses; using 74.125.224.168
traceroute to google.com (74.125.224.168), 64 hops max, 52 byte packets
 1  10.90.4.1 (10.90.4.1)  3.086 ms  0.738 ms  0.683 ms
 2  69.169.148.1.provo.static.broadweavenetworks.net (69.169.148.1)  0.907 ms  1.135 ms  0.893 ms
 3  10.8.201.41 (10.8.201.41)  1.040 ms  1.552 ms  11.494 ms
 4  97.75.190.142 (97.75.190.142)  1.343 ms  1.347 ms  0.946 ms
 5  97.75.190.137 (97.75.190.137)  1.290 ms  1.609 ms  1.202 ms
 6  97.75.191.66 (97.75.191.66)  2.463 ms  2.146 ms  2.161 ms
 7  97.75.191.54 (97.75.191.54)  2.406 ms  2.281 ms  2.616 ms
 8  te-9-3.car1.saltlakecity1.level3.net (4.53.40.105)  3.014 ms  2.330 ms  2.241 ms
 9  * * *
10  ae-61-61.csw1.losangeles1.level3.net (4.69.137.2)  15.805 ms
    ae-91-91.csw4.losangeles1.level3.net (4.69.137.14)  15.441 ms  15.160 ms
11  * ae-1-60.edge1.losangeles9.level3.net (4.69.144.10)  17.204 ms  15.983 ms
12  google-inc.edge1.losangeles9.level3.net (4.53.228.6)  92.445 ms  82.679 ms  107.813 ms
13  64.233.174.238 (64.233.174.238)  21.234 ms  21.016 ms  21.321 ms
14  72.14.236.11 (72.14.236.11)  21.577 ms  21.630 ms  21.568 ms
15  lax02s01-in-f8.1e100.net (74.125.224.168)  20.798 ms  20.687 ms  20.666 ms

影响大多数网页（google、apple.com、facebook.com 等）

（第 9、17 和 18 行都需要很长时间）。

traceroute beachbody.com
traceroute to beachbody.com (66.208.81.68), 64 hops max, 52 byte packets
 1  10.90.4.1 (10.90.4.1)  1.038 ms  0.830 ms  0.767 ms
 2  69.169.148.1.provo.static.broadweavenetworks.net (69.169.148.1)  0.988 ms  0.934 ms  0.928 ms
 3  10.8.201.41 (10.8.201.41)  1.357 ms  1.375 ms  1.500 ms
 4  10.8.101.5 (10.8.101.5)  1.405 ms  1.579 ms  1.115 ms
 5  eth_3-3_prv02-rt02.veracitynetworks.com (97.75.190.166)  10.601 ms  1.563 ms  1.754 ms
 6  97.75.191.66 (97.75.191.66)  2.857 ms  13.554 ms  2.833 ms
 7  97.75.191.54 (97.75.191.54)  2.760 ms  2.394 ms  4.350 ms
 8  te-9-3.car1.saltlakecity1.level3.net (4.53.40.105)  2.352 ms  2.311 ms  2.340 ms
 9  * * *
10  ae-61-61.csw1.losangeles1.level3.net (4.69.137.2)  29.086 ms
    ae-71-71.csw2.losangeles1.level3.net (4.69.137.6)  28.958 ms
    ae-91-91.csw4.losangeles1.level3.net (4.69.137.14)  28.863 ms
11  ae-82-82.ebr2.losangeles1.level3.net (4.69.137.25)  28.075 ms
    ae-72-72.ebr2.losangeles1.level3.net (4.69.137.21)  28.508 ms
    ae-62-62.ebr2.losangeles1.level3.net (4.69.137.17)  29.029 ms
12  ae-6-6.ebr2.sanjose5.level3.net (4.69.148.202)  28.672 ms  28.586 ms  28.223 ms
13  ae-2-2.ebr2.sanjose1.level3.net (4.69.148.142)  28.426 ms  28.341 ms  29.611 ms
14  ae-4-4.car2.sacramento1.level3.net (4.69.132.157)  28.834 ms  29.236 ms  29.231 ms
15  ragingwire.car2.sacramento1.level3.net (4.53.202.22)  29.339 ms  29.406 ms  29.584 ms
16  resisp-74-221-224-49.smf.ragingwire.net (74.221.224.49)  26.096 ms  25.930 ms  26.575 ms
17  * 204.212.188.26 (204.212.188.26)  28.459 ms !X *
18  204.212.188.26 (204.212.188.26)  25.650 ms !X *  26.197 ms !X

在此处输入图像描述


更新 1
这是同一台笔记本电脑的跟踪路由，但网络位置不同（已清理）。

beachbody.com 在位置 1 有 95% 的时间失败。beachbody.com 在位置 2 有 100% 的时间成功。

traceroute beachbody.com
traceroute to beachbody.com (66.208.81.68), 64 hops max, 52 byte packets
 1  foo.acme (y.y.y.y)  1.716 ms  13.343 ms  6.139 ms
 2  x.x.x.x (x.x.x.x)  74.524 ms  158.532 ms  6.721 ms
 3  tg9-2.cr01.slkcutxd.integra.net (209.63.98.37)  33.225 ms  24.794 ms  24.587 ms
 4  * be4.sc01.sntdcabl.integra.net (209.63.82.166)  32.474 ms  36.895 ms
 5  be1.br02.plalca01.integra.net (209.63.100.118)  24.120 ms  22.298 ms  22.176 ms
 6  peer-02.palo.twtelecom.net (198.32.175.111)  21.401 ms  22.576 ms  21.492 ms
 7  oak1-ar1-xe-0-1-0-0.us.twtelecom.net (206.222.120.214)  23.042 ms  22.441 ms  48.562 ms
 8  74.202.6.2 (74.202.6.2)  29.358 ms  32.253 ms  30.283 ms
 9  204.212.188.26 (204.212.188.26)  25.949 ms !X  30.199 ms !X *


Update 2
进一步调查显示这只影响 Mac 用户！
与 Veracity 的第二次电话确认异常高比例的 Mac 用户报告了 iTunes 问题。3 级技术人员不知道是什么原因造成的。

同时更新
2 台计算机上 wireshark 中的 3 个捕获事件

Mac（有问题）
http://cl.ly/0o1D2r0K1s2s
Filter = "ip.dst==e3570.b.akamaiedge.net"

Windows（问题不影响 Windows 电脑）
http://cl.ly/3v3e1s2M1W27
Filer = "ip.dst==e3570.b.akamaiedge.net"
Ctrl + F "beachbody"

我不知道为什么源/目的地是 ip.dst==e3570.b.akamaiedge.net 而不是“beachbody.com”或 66.208.81.68（沙滩身体网站 ip）

networking

3 个回答

  1. Best Answer

    从您的 Wireshark 捕获中，出现了两个明显的错误：

    1. 您发送的所有 IP 数据包都具有无效校验和 0。这可能是操作系统捕获数据包的方式造成的，所以我们暂时忽略它……

    2. 这可能会让您很伤心：看起来您的 ISP 正在使用 ICMP Time Exceeded 响应来响应您的一些（但不是全部）请求，这会导致您的连接中断。例如，在第 324 行查看您的 SYN 数据包，在第 327 行查看您的 ISP 来自 97.75.190.142 的响应。由于您的数据包中设置了 64 的 TTL，这强烈表明您的 ISP 在其网络中某处存在路由环路。

    将此 pcap 文件的副本发送给您的 ISP 的网络人员。他们应该能够弄清楚他们的网络中有什么问题。

    • 4

  2. 我最近在我的综合大楼遇到了随机减速和连接中断的问题。我向他们证明使用低级工具存在问题的最佳方式：

    1. 确保将有线连接直接连接到墙上，尽可能不使用任何路由器和其他设备。如果您可以使用多台机器执行此操作，那就更好了。
    2. 运行连续的 ping 并观察响应时间的大变化或更糟糕的超时（表明数据包被丢弃）。

    ping -t -w 1000 google.com

    1. 如果流中有中断，请截屏或将输出发送给他们。您希望看到响应时间的几毫秒差异的低方差，并且很少（如果有的话）下降。长时间运行此程序，超过几分钟。如：

    C:>ping -t -w 1000 google.com

    使用 32 字节数据 Ping google.com [74.125.140.102]： 来自 74.125.140.102 的回复：bytes=32 time=19ms TTL=48 来自 74.125.140.102 的回复：bytes=32 time=17ms TTL=48 来自 74.125.140.102 的回复: bytes=32 time=21ms TTL=48 Reply from 74.125.140.102: bytes=32 time=16ms TTL=48 Reply from 74.125.140.102: bytes=32 time=17ms TTL=48 Reply from 74.125.140.102: bytes=32 time =29ms TTL=48 来自 74.125.140.102 的回复：bytes=32 time=20ms TTL=48 来自 74.125.140.102 的回复：bytes=32 time=45ms TTL=48 来自 74.125.140.102 的回复：bytes=32 time=16ms TTL=48 74.125.140.102回复：bytes=32 time=19ms TTL=48 74.125.140.102回复：bytes=32 time=15ms TTL=48 74.125.140.102回复：bytes=32 time=15ms TTL=48

    1. 如果您能证明存在问题，请继续给他们打电话。可能需要一段时间才能引起人们的注意。

    希望有所帮助。

    • 1

  3. 仅供参考 -ping是检查延迟的工具。这是在数据平面中处理的，是数据包滞后的真实指示。 traceroute或tracert在控制平面中进行处理，响应时间不是网络延迟的指示，但可能会受到高 CPU 利用率的影响。traceroute并且tracert应该只用于显示路径选择。

    • 1

相关问题