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