网络缓慢状况的故障排查
从某种角度来说,网络无法工作的问题更容易解决。当一台主机无法访问,我们可以执行前面讨论过的故障排查步骤直到一切恢复正常。但如果仅仅是网络缓慢,追查其根本原因往往变得更为棘手。本章节将讨论一些相关技巧,帮助大家追踪导致网络速度缓慢的各种原因。
DNS问题
虽然DNS在网络出现问题时常常蒙冤受责,但在导致网络性能不佳方面,DNS倒真该被优先检查一番。举例来说,如果我们为某个域名配置了两台DNS服务器,那么在第一台出现问题时,我们发出的DNS请求会等待30秒之后才传输至第二台DNS服务器。虽然当我们使用像dig或nslookup这样的工具时此类情况显得一目了然,但对于日常使用来说,DNS故障往往会以令人意外的方式造成网络缓慢;这是因为有太多服务需要借助DNS实现将主机名称解析为IP地址的工作。这些问题甚至有可能影响到我们的网络故障诊断工具。
Ping、tracerouter、oute、netstat甚至包括iptables在内的多款网络故障排查工具都会受到DNS问题的牵连而导致速度缓慢。在默认情况下,上述所有工具都会尽可能尝试将IP地址解析为主机名称。一旦DNS服务器有了毛病,这些命令就会在查找IP地址的过程中停滞不前并最终导致执行失效。在ping或traceroute方面,问题表现为整个ping应答周期耗时相当长,但最终的请求往返时间却比较短。而在netstat与iptables方面,其请求结果可能会拖延很久才输出到屏幕上,这是因为系统一直在等待已经超时的DNS请求。
在前面提到的各种情况中,我们都能很容易地绕过DNS来保证故障排查结果的准确性。所有列举的命令都可以通过添加-n参数来禁止其将IP地址解析为主机名称。我也是刚刚养成在所有命令后加-n的好习惯–正如第一章提到的那样–除非我确定自己想解析IP地址。
注意:DNS解析还可能以其它一些意想不到的方式影响我们的web服务器性能。某些web服务器会根据配置对访问的第一个IP地址进行解析,并将得到的主机名称记录下来。虽然这会让记录信息更具可读性,但同时也会在出现问题时大大降低web服务器的速度–例如存在大量访问者时。这时web服务器会忙着解决这些IP地址的解析工作,而选择将服务流量搁置在一边。
利用traceroute解决网络缓慢问题
当处于不同网络中的服务器与主机间的连接发生拖慢状况时,我们可能很难追查到真正的罪魁祸首。尤其是在拖慢以延迟形式(即响应所消耗的时间)出现而不涉及全局带宽的情况下,真正能力挽狂澜的就只有traceroute了。正如前文所说,tracerout是一种在远程网络中测试客户机与服务器间全局连接的有效方式,但它同时也能有效诊断出导致网络缓慢的潜在根源。由于traceroute会输出当前与目标设备之间每次数据转发所消耗的时间,因此我们可以利用它追踪由地域相距过大或网关问题所引发的过载及网络缓慢原因。举例来说,我们利用traceroute检查美国与中国两边的雅虎服务器,输出结果如下所示:
$ traceroute yahoo.cn
traceroute to yahoo.cn (202.165.102.205), 30 hops max, 60 byte packets
1 64-142-56-169.static.sonic.net (64.142.56.169) 1.666 ms 2.351 ms 3.038 ms
2 2.ge-1-1-0.gw.sr.sonic.net (209.204.191.36) 1.241 ms 1.243 ms 1.229 ms
3 265.ge-7-1-0.gw.pao1.sonic.net (64.142.0.198) 3.388 ms 3.612 ms 3.592 ms
4 xe-1-0-6.ar1.pao1.us.nlayer.net (69.22.130.85) 6.464 ms 6.607 ms 6.642 ms
5 ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18) 3.320 ms 3.404 ms 3.496 ms
6 ae1-50g.cr1.sjc1.us.nlayer.net (69.22.143.165) 4.335 ms 3.955 ms 3.957 ms
7 ae1-40g.ar2.sjc1.us.nlayer.net (69.22.143.118) 8.748 ms 5.500 ms 7.657 ms
8 as4837.xe-4-0-2.ar2.sjc1.us.nlayer.net (69.22.153.146) 3.864 ms 3.863 ms 3.865 ms
9 219.158.30.177 (219.158.30.177) 275.648 ms 275.702 ms 275.687 ms
10 219.158.97.117 (219.158.97.117) 284.506 ms 284.552 ms 262.416 ms
11 219.158.97.93 (219.158.97.93) 263.538 ms 270.178 ms 270.121 ms
12 219.158.4.65 (219.158.4.65) 303.441 ms * 303.465 ms
13 202.96.12.190 (202.96.12.190) 306.968 ms 306.971 ms 307.052 ms
14 61.148.143.10 (61.148.143.10) 295.916 ms 295.780 ms 295.860 ms
.既然不了解有关网络的更多细节信息,我们也能够单纯通过往返时间把握数据包的动向。从第九次跳转开始,IP地址变成了219.158.30.177,这意味着数据包已经离开美国抵达中国,而跳转的往返时间也从3毫秒提高到275毫秒。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
Linux服务器故障排查指南5:远程端口打开了吗?
现在我们已经能够路由至目标设备,但仍然无法在端口80上访问web服务器。接下来的测试意在检查端口是否打开。
-
Linux服务器故障排查指南4:我能路由至远程主机吗?
在排除了DNS问题并看到web1被正确解析为IP 10.1.2.5之后,大家需要测试自己能否路由至远程主机。假如我们的网络启用了ICMP,那么最快捷的测试办法是ping web1。
-
Linux服务器故障排查指南8:出是谁占用了带宽
有时候我们的网络缓慢并不是由远程服务器或路由器所引起,而只是因为系统中的某些进程占用了太多可用带宽。本文利用iftop找出是谁占用了带宽。
-
Linux服务器故障排查指南6:在本地测试远程主机
经过之前的几个步骤之后,到了这里,摆在我们面前的就有两种可能性:要么将故障范围缩小为网络问题,要么认定毛病出在主机自身。