某公寓大楼拥有光纤互联网，上个月出现了延迟问题。
租户经常会遇到超时和网页损坏的情况。目前的解决方法是刷新网页六次，直到正确加载。
症状如下：
- 不稳定，每个租户每天发生几次
- 在笔记本电脑上请求新的 dhcp 租约并不能解决问题
影响 Mac 和 Windows 机器更新：仅影响 MAC 用户！*- 影响无线和有线
- 这不是 DNS 问题，因为我们已经尝试过 ISP 的 DNS 和谷歌的 DNS 服务器，但没有任何改善
- iTunes 受此影响严重。iTunes 商店经常超时（iPad、iPhone、Mac）
可以使用哪些其他诊断工具来识别问题？ISP 说一切正常。
跟踪路由显示第 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 *
更新 2
进一步调查显示，这只会影响 Mac 用户！
第二次与 Veracity 的电话沟通证实，有相当多的 Mac 用户报告了 iTunes 问题。Level 3 技术人员不知道是什么原因造成的。
更新 3
同时在两台计算机上使用 wireshark 捕获事件
苹果（有问题）
http://cl.ly/0o1D2r0K1s2s
过滤器 = “ip.dst==e3570.b.akamaiedge.net”
视窗（该问题不影响 Windows PC）
http://cl.ly/3v3e1s2M1W27
文件管理器 = “ip.dst==e3570.b.akamaiedge.net”
Ctrl + F “beachbody”
我不知道为什么源/目的地是 ip.dst==e3570.b.akamaiedge.net 而不是“beachbody.com”或 66.208.81.68（beach body 网站 ip）
答案1
从您的 Wireshark 捕获中，出现了两个明显的错误：
您发送的所有 IP 数据包都具有无效的校验和 0。这可能是操作系统捕获数据包的方式造成的，因此我们暂时将其忽略...
这可能会给您带来很多麻烦：您的 ISP 似乎正在用 ICMP 超时响应来响应您的部分（但不是全部）请求，这会导致您的连接中断。例如，查看第 324 行中的 SYN 数据包和第 327 行中来自 97.75.190.142 的 ISP 响应。由于您的数据包中设置的 TTL 为 64，这强烈表明您的 ISP 在其网络中的某个地方存在路由循环。
将此 pcap 文件的副本发送给您的 ISP 网络人员。他们应该能够找出他们的网络中出了什么问题。
答案2
最近，我遇到了网络随机减速和断线的问题。对我来说，使用低级工具向他们证明存在问题的最好方法是：
- 确保将有线连接直接连接到墙上，省去路由器和其他设备。如果可以使用多台机器做到这一点，那就更好了。
- 运行连续 ping 并观察响应时间是否有较大变化或更糟的情况，超时（表示数据包被丢弃）。
ping -t -w 1000 google.com
- 如果流中有中断，请截屏或将输出发送给他们。您希望看到响应时间的差异很小，只有几毫秒，并且几乎没有掉线（如果有的话）。运行此操作很长时间，超过几分钟。例如：
C:>ping -t -w 1000 google.com
正在 Ping google.com [74.125.140.102]，数据为 32 字节：来自 74.125.140.102 的回复：字节=32 时间=19ms TTL=48来自 74.125.140.102 的回复：字节=32 时间=17ms TTL=48来自 74.125.140.102 的回复：字节=32 时间=21ms TTL=48来自 74.125.140.102 的回复：字节=32 时间=16ms TTL=48来自 74.125.140.102 的回复：字节=32 时间=17ms TTL=48来自 74.125.140.102 的回复：字节=32 时间=29ms TTL=48来自 74.125.140.102 的回复：字节=32 时间=20ms TTL=48 来自 74.125.140.102 的回复：字节=32 时间=45ms TTL=48 来自 74.125.140.102 的回复：字节=32 时间=16ms TTL=48 来自 74.125.140.102 的回复：字节=32 时间=19ms TTL=48 来自 74.125.140.102 的回复：字节=32 时间=15ms TTL=48 来自 74.125.140.102 的回复：字节=32 时间=15ms TTL=48
- 如果你能证明存在问题，请继续给他们打电话。可能需要一段时间才能让人们注意到。
希望有所帮助。
答案3
仅供参考 -ping是检查延迟的工具。这是在数据平面中处理的，是数据包延迟的真实指示。
traceroute或tracert在控制平面中处理，响应时间不是网络延迟的指示，但可能受到高 CPU 利用率的影响。traceroute并且tracert只应用于显示路径选择。