![如何找到配置不当的路由器或诊断间歇性请求超时?](https://linux22.com/image/499499/%E5%A6%82%E4%BD%95%E6%89%BE%E5%88%B0%E9%85%8D%E7%BD%AE%E4%B8%8D%E5%BD%93%E7%9A%84%E8%B7%AF%E7%94%B1%E5%99%A8%E6%88%96%E8%AF%8A%E6%96%AD%E9%97%B4%E6%AD%87%E6%80%A7%E8%AF%B7%E6%B1%82%E8%B6%85%E6%97%B6%EF%BC%9F.png)
我是我所在组织的分析程序员,我发现在我们的网络中使用 CVS 和 HTTP 请求时会出现某种间歇性超时问题。
超时后,请求确实完成了,尽管它只花费了 60 多秒的时间,这就是为什么我猜测发生了某种超时故障转移问题。
我希望尝试找出问题所在,如果可能的话,我猜想是某个地方出现了错误路由,或者某个 DNS 服务器出了问题。基础设施团队告诉我网络没有任何问题,我个人认为这是一种逃避。
我对两台 Linux(RHEL 5.4)机器有 root 访问权限。
如果这项任务很明显,请原谅我,因为我是一名软件开发人员而不是网络工程师。
更新
我想我应该提一下,这个问题发生在客户端和 CVS 服务器以及使用 VPN 的客户端和 HTTP 服务器之间。我们的 VPN 客户端不进行反向解析,我已要求网络工程师对此进行修改,但他们并不认为这是个问题。
答案1
很多地方都会搞砸他们的反向记录。你可以判断你搞砸了反向记录,因为如果你运行类似这样的程序netstat -a
,它需要很长时间才能运行,然后你会得到一堆 IP 地址rfc1918地址空间。在这个空间中没有反向记录本身并不是一个问题,但它是如果您的 DNS 人员将其 DNS 请求转发给提供商或损坏的 DNS 服务器,则会出现问题。
验证是否为 DNS 问题的快速方法是登录系统并查找连接到系统的某人的 IP(查看 netstat -a 并查找已建立的连接),然后运行
nslookup a.b.c.d (or whatever the IP of that host is)
如果你的系统比较旧,你可能需要输入
nslookup d.c.b.a.in-addr.arpa.
无论哪种情况,结果都可能是“找不到该地址”,但答案需要返回迅速地。DNS 超时时间可能达到秒级,如果您的 resolv.conf 中有 3 个 DNS 服务器,您的服务器将在放弃之前尝试每一个。这很容易累积成非常烦人的时间。
向你的老板说明问题的一个快速方法是运行netstat -an
,然后运行netstat -a
,然后说“如果我们的 DNS 工作正常,那么这两个程序将在几乎完全相同的时间内运行。
如果是反向记录问题,您可能可以通过关闭应用程序中的反向查找来“解决”问题。在这种情况下,这可能比让另一个团队参与进来更容易。
还有一种可能性很小,即您的服务器和交换机之间可能存在双工不匹配的情况。可以通过查看 (windows) netstat -e 或 (unix) netstat -i 的输出来测试。您要查找“错误”或“冲突”。如果看到“冲突”,则说明您的一端配置错误;它是半双工的,应该是全双工的。如果看到“错误”,则说明交换机一端是半双工的,而您是全双工的。两个计数器都应该为零,或者至少很小且没有增加。这些问题可能很难追踪,因为如果链路没有负载,它会工作得很好,而当有大量流量时,它会完全崩溃。
答案2
如果请求完成,那么这不是超时问题。如果是超时问题,请求将永远无法完成,因此得名“超时”。你的意思是有些请求超时,有些请求经过很长一段时间后才完成,因为这比你在帖子中所说的更有意义。
至于如何追踪问题,有很多方面需要关注。以下是一些建议,可帮助您入门:
从客户端计算机运行 tracert 到相关服务器。计算它经过了多少跳。每个跳都是某种路由器。如果 tracert 直接从您的客户端计算机到服务器,则路径中没有路由器。
从客户端机器运行 pathping 到相关服务器并查找两者之间的延迟和数据包丢失。
在服务器上安装数据包嗅探器并开始捕获。从客户端提交请求并查看服务器上数据包嗅探器的输出。如果您在嗅探器输出中看到请求和回复之间存在明显延迟,则这是服务器问题。如果没有明显延迟,则这是网络问题。