我在我的项目中遇到一个问题。我们支持托管在 unix 服务器上的应用程序。
合作伙伴尝试从许多地区访问相同的内容。现在某个地区的一些用户说“R”抱怨速度慢，我们有理由相信这可能是由于他们终端的网络问题造成的。
我可以在他们的终端系统中运行哪些命令，通过这些命令我可以向他们证明这是他们终端的网络问题？
还有一些命令可以向他们证明过去几分钟内其他 Web 应用程序也占用了他们系统的大量时间？
我对 UNIX 非常陌生。提前致谢。
答案1
固有的局限性
该问题可能是可变的（例如，到 ISP 的链路拥塞或 ISP 内拥塞）。它也可能是可怕的（“防火墙”甚至“防病毒”进行深度数据包检查）；下面的工具可能根本不会显示任何问题。它们值得拥有，但仅在终端中输入命令所能达到的效果是有限的。
你应该知道的 2 个测试
用于
ping测量通过 ICMP/IP 到服务器的往返延迟。您还可以traceroute访问tracepath您的服务器，并检查前几跳的往返延迟有多少。您主要是尝试检查缓冲区膨胀的症状，因此请注意，只有在链接完全使用时才会发生这种情况！ （“负载下的延迟”测量）。wget您可以仅使用或curl --remote-name下载文件来检查可用的网络下载带宽（单流） 。如果您没有灵感，我建议您下载 Linux :-)。找到下载链接并使用右键菜单中的“复制链接位置”。您可能不必让下载运行完成，因为它会显示当前的下载速率 - 使用 Control+C 取消它。你可以测试一个镜子与您的服务器位于同一区域（这可能很重要）。我想如果您正在考虑使用终端，那么很高兴知道它wget的存在。我个人更喜欢使用http://testmy.net/mirror。
基本上就是这样它，根据您提供的信息。其中一个结果有一个警告ping，我在下面强调了这一点。
ping非常适合初始测试。 traceroute是一个专家工具。我仅建议traceroute作为尝试和说明缓冲区膨胀的一种方法，如果这似乎ping表明...实际上可能更好地ping在您在 中看到的路由器上使用traceroute。
下载率低作为直接原因很容易被高估。网络应用程序没有需要提供大量数据来响应用户请求，除非有未缓存的图像。例如，unix.stackexchange.com 为 75K，以 4Mb/s 的速度下载需要 0.2 秒。但运行测试很容易，并且提供了一些数据点来解决这个难题。
丢包 (ping) 多少算过多？
任何明显的丢包率都会限制下载速率，尤其是跨大陆的距离。
不幸的是，损失对短期交易的影响是比那复杂一点。对于大约 20Kb 的传输，看起来一次丢失可能不会导致超过 100% 的增长。除非来自服务器（或客户端）的第一个数据包被丢弃，在这种情况下它不会恢复，直到完全“接收超时” -3秒。
测量丢失时存在一个问题/警告，因为它可能会受到数据包大小的影响。 当使用 测量丢失时ping，您应该注意到它默认使用小数据包。这类似于来自客户端和服务器的第一个数据包（分别为 SYN / SYN-ACK）。综上所述，如果您在ping $SERVER没有选项的情况下运行时看到 5% 的损失，那么您就不会期望使用该 Web 应用程序获得完美的体验。 （即，在 20 个用户操作中，预计其中 1 个需要 3 秒才能发生任何事情。给定的持久连接不会减轻这种情况常见的网络服务器配置）
您可以检查全尺寸数据包的统计信息，例如ping -s 1400在 UNIX 上。原则上可能还有更多因素（路由器上的“优先级”，又名 QoS），您特别想要的是来自特定应用程序的 TCP 重传详细信息，从内核或数据包追踪。
请注意，从端点来看，很难区分链路是否拥塞，以及链路是否物理不可靠。丢包是路由器告诉 TCP 放慢速度的方式；链路越拥塞，丢包率越高。我认为您最好的期望是识别（“证明”）丢包率较高的链接，并要求有权访问的人员进行调查或监控。