我是我组织的分析程序员，在我们的networking中使用CVS和HTTP请求时，发现了某种间歇性的超时问题。
超时后，请求完成，但只需要超过60秒，这就是为什么我猜测这是某种超时故障发生的问题。
我想试着弄清楚如果可能的话find问题是什么，我假设有一个不好的路由在某个地方，或者某个DNS服务器有问题。 基础设施团队告诉我，networking没有任何问题，我个人认为这是一个警察。
我有两台Linux（RHEL 5.4）机器的root权限。
请原谅，如果这个任务是显而易见的，因为我是一个软件开发人员而不是networking工程师。
UPDATE
我想我可能会提到，客户端和CVS服务器和使用VPN和HTTP服务器的客户端之间发生此问题。 我们的VPN客户端不会反向解决问题，我已经请求networking工程师提出build议，但是他们并不认为这是一个问题。
通常地方会搞砸他们的反向logging。 你可以告诉你已经搞砸了反向logging，因为如果你运行netstat -a类的东西，并且需要很长时间才能运行，并且你在rfc1918地址空间中得到一堆IP地址。 在这个空间本身没有反向logging并不是一个真正的问题，但是如果你的DNS人员把他们的DNS请求转发给提供者或者破坏的DNS服务器，那么这是一个问题。
validation是否是DNS问题的快速方法是login到系统并查找连接到系统的某人的IP（查看netstat -a并查找已build立的连接），然后运行
nslookup abcd (or whatever the IP of that host is)
如果您的系统较旧，则可能需要input
nslookup dcbain-addr.arpa.
无论哪种情况，结果都可能是“无法find该地址”，但答案需要快速回来。 DNS超时时间可能是几秒钟，如果你的resolv.conf中有3个DNS服务器，你的服务器会在放弃之前尝试每一个。 这可以很容易地加起来非常烦人的时间。
向老板说明问题的一个快速方法是运行netstat -an ，然后运行netstat -a ，然后说“如果我们的DNS工作正常，这两者的运行时间几乎完全相同。
如果是反向logging问题，则可以通过closures应用程序中的反向查找来“解决”问题。 在这种情况下，可能比让另一组参与更容易。
您的服务器和交换机之间也存在双工不匹配的情况。 可以通过查看（Windows）netstat -e或（unix）netstat -i的输出来testing。 你正在寻找“错误”或“碰撞”。 如果你看到“碰撞”，那么你的结局是错误的configuration; 它是半双工的，应该是全双工的。 如果你看到“错误”，交换机端是半双工的，而你是全双工的。 两个计数器应该是零，或者至less很小，而不是增加。 这些问题可能很难追查到，因为链路在卸载时工作得很好，而且在有很多stream量的情况下完全崩溃。
如果请求完成，那么这不是一个超时问题。 如果是超时问题，请求将永远不会完成，因此名称为“超时”。 你的意思是说，一些请求超时，并在一段时间后完成一些，因为这比你在文章中陈述的更有意义。
就追查问题而言，有很多方面需要考虑。 以下是一些build议，帮助您入门：
从客户端机器运行一个tracert到正在讨论的服务器。 计算它经过的跳数。 每一跳都是某种路由器。 如果tracert直接从客户端机器到服务器，则path中没有路由器。
运行从客户端计算机到相关服务器的path，查找两者之间的延迟和数据包丢失。
在服务器上安装数据包嗅探器并开始捕获。 提交来自客户端的请求，并查看服务器上的数据包嗅探器的输出。 如果您在嗅探器输出中的请求和回复之间看到明显的延迟，那么这是一个服务器问题。 如果没有显着的延迟，那么这是一个networking问题。