我是我所在组织的分析程序员，我发现在我们的网络中使用 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 到相关服务器并查找两者之间的延迟和数据包丢失。
在服务器上安装数据包嗅探器并开始捕获。从客户端提交请求并查看服务器上数据包嗅探器的输出。如果您在嗅探器输出中看到请求和回复之间存在明显延迟，则这是服务器问题。如果没有明显延迟，则这是网络问题。