服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 间歇性的高ping /延迟问题
Intereting Posts
高负载，低CPU，内存和磁盘IO – Highend服务器 SMTP连接到gmail-smtp-in.l.google.com 相同的硬件/软件，性能差异显着 防火墙规则阻止MSN Messenger？ 在AWS Elastic Beanstalk上使用多个SSL证书 如何将目录添加到我想要共享的samba PowerShell v1移动项目不移动项目 check_mk IPMI PCM传感器读数随机失败 如何检查Postfix是否支持Do​​vecot SASL？ Windows XPlogin使用Radius身份validation VMware ESX虚拟机，Windows 2008 Server R2，内存已满，但进程总在哪里？ 如何确定无法启动的机器上的OS X版本？ 在预算这是用于数据库镜像的SQL 2008磁盘布局 ADFS 3.0如何添加帐户合作伙伴？ 将某些网站caching1小时，而不pipe到期标题

间歇性的高ping /延迟问题

我一直在与我的ISP（这是一个WISP，实际上是固定宽带无线），试图找出为什么我间歇性地得到高延迟。 在线游戏和其他stream媒体应用程序中可检测到延迟。 如果我执行跟踪路由，则可以通过回程networking查看path： 

Tracing route to google.com [74.125.67.105] over a maximum of 30 hops: 1 1 ms 4 ms <1 ms 192.168.23.1 2 1 ms 8 ms 9 ms 10.100.100.1 3 9 ms 9 ms 3 ms 10.7.37.1 4 15 ms 24 ms 19 ms 10.7.36.1 5 10 ms 79 ms 9 ms 10.7.31.3 6 10 ms 39 ms 39 ms 10.10.5.9 7 19 ms 19 ms 19 ms 10.10.5.5 8 9 ms 19 ms 19 ms 10.10.5.1 9 341 ms 237 ms 226 ms 10.250.200.1 10 249 ms 280 ms 991 ms <ISP WAN IP> 11 703 ms 681 ms 401 ms <ISP WAN IP> 12 819 ms 628 ms 484 ms <AT&T IP> <- Traffic enters AT&T backbone 13 699 ms 528 ms 290 ms <AT&T IP> 14 201 ms 106 ms 52 ms <AT&T IP> 15 624 ms 392 ms 436 ms <AT&T IP> 16 666 ms * 252 ms <AT&T IP> 17 456 ms 403 ms 581 ms 209.85.254.120 18 430 ms 339 ms * 209.85.242.215 19 1061 ms 56 ms 53 ms 72.14.239.131 20 3514 ms 734 ms 219 ms 209.85.255.190 21 49 ms 59 ms 56 ms 74.125.67.105

这似乎表明，问题是主机在10.250.200.1。 但是，如果我直接ping主机一切似乎很好（~10ms往返）。 在怀疑节点给出合理的往返时间之后，ping随后的跳数。 高延迟一次只能持续几秒钟到几分钟。

编辑是这是一个迹象显示一个确定的问题的坏例子，但经过反复testing之前，从来没有潜伏> 100毫秒前跳9，这就是为什么我认为这可能是一个问题。

在事件过程中产生以下结果： 

  Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 192.168.23.129 0/ 100 = 0% | 1 2ms 0/ 100 = 0% 0/ 100 = 0% 192.168.23.1 0/ 100 = 0% | 2 3ms 0/ 100 = 0% 0/ 100 = 0% 10.100.100.1 0/ 100 = 0% | 3 14ms 0/ 100 = 0% 0/ 100 = 0% 10.7.37.1 0/ 100 = 0% | 4 15ms 0/ 100 = 0% 0/ 100 = 0% 10.7.36.1 0/ 100 = 0% | 5 19ms 0/ 100 = 0% 0/ 100 = 0% 10.7.31.3 0/ 100 = 0% | 6 27ms 0/ 100 = 0% 0/ 100 = 0% 10.10.5.9 0/ 100 = 0% | 7 28ms 0/ 100 = 0% 0/ 100 = 0% 10.10.5.5 0/ 100 = 0% | 8 --- 100/ 100 =100% 100/ 100 =100% 10.10.5.1 0/ 100 = 0% | 9 25ms 0/ 100 = 0% 0/ 100 = 0% 10.250.200.1 0/ 100 = 0% | 10 24ms 1/ 100 = 1% 1/ 100 = 1% <ISP WAN IP> 0/ 100 = 0% | 11 25ms 4/ 100 = 4% 4/ 100 = 4% <ISP WAN IP> 0/ 100 = 0% | 12 35ms 0/ 100 = 0% 0/ 100 = 0% <AT&T IP> 0/ 100 = 0% | 13 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP> 0/ 100 = 0% | 14 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP> 0/ 100 = 0% | 15 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP> 0/ 100 = 0% | 16 58ms 0/ 100 = 0% 0/ 100 = 0% <AT&T IP> 1/ 100 = 1% | 17 59ms 1/ 100 = 1% 0/ 100 = 0% 209.85.254.120 0/ 100 = 0% | 18 59ms 1/ 100 = 1% 0/ 100 = 0% 209.85.242.215 0/ 100 = 0% | 19 56ms 1/ 100 = 1% 0/ 100 = 0% 72.14.239.127 0/ 100 = 0% | 20 60ms 1/ 100 = 1% 0/ 100 = 0% 209.85.255.194 0/ 100 = 0% | 21 59ms 1/ 100 = 1% 0/ 100 = 0% 74.125.67.105

为什么这个延迟只会在跟踪路由中显示，而不是正常的ping？ 我在应用程序中看到的性能不足，恰逢其时。

换句话说，当我的应用程序出现问题的时候，如果我同时运行一个跟踪，我同时得到上面的结果，同时 ping可疑主机显示正常的ping。

WISP？ 含义无线 ISP？ 如果是这样，你可能会有答案。 无线是不可靠的，你看到的证据。

你不能真正解决这个问题，因为你的媒体（气氛）传输数据真的很糟糕。 首先是因为空气是一个集线器，而不是交换机，所以你要和周围的任何人共享数据包，其次是因为CSMA / CA比CSMA / CD慢，第三，因为无线通常是半双工而不是全双工，第四，因为通过空气与铜相比有更高的数量级的干扰。 例如，微波的工作波长与802.11b / g相同，但是微波的工作频率约为500-1000瓦，而无线天线的功率为100毫瓦。 微波屏蔽，但屏蔽不完美，微波炉不受FCCpipe制，所以它不是非法的，如果他们造成干扰]加上事实上，你是经历了10多跳才上网。 这不能帮助，特别是如果有任何NAT或防火墙正在进行。

正如@dbasnett所说，给定主机的traceroute ping等待时间只能指示当时整个接口之间的整个networking的状态。 这就是为什么响应时间有时会减less 。 他们尖锐，因为networking是不可靠的。 你的pathping看起来不错，因为它正在运行大量的查询，而不是运行tracert的只有3个。 因此， pathping显示了networking在325秒内（缺省情况下）所做的工作，而tracert会向您显示networking上每跳3个数据包正在做什么。

10次​​跟踪路由结果中有9次不是networking问题的指示。 Traceroute将ICMP回应请求数据包发送到源和目标之间的每个连续跳跃，为每个连续跃点递增1。 每一跳的结果都表明该跳对于ICMPstream量的反应如何，这并不意味着跳过path的质量。 路由器的工作就是转发stream量，因此很多stream量都被编程为忽略，丢弃或给予指向自己的ICMPstream量的低优先级。 跳数14,19和21具有非常好的响应时间的事实表明path没有任何问题。 如果在第12跳（如您突出显示的）或其他任何跳动影响到path时出现问题，则您将在每个连续跳跃中看到问题，并且您会看到每一跳都比以前更糟。 只有当您在traceroute中看到这些types的结果时，才会怀疑path问题。 第21跳是目的地，用59ms的响应时间，告诉你源和目的地之间的path是好的。 分析path问题的关键是在真实数据正在传输时分析它的性能，除非您在每一跳都有数据包嗅探器/networking监视器，并且可以访问每个节点上的内存，CPU和吞吐量计数器networking节点（路由器和交换机）在从源到目的地的path中。

您应该专注于源和目标之间的实际TCP会话，并着眼于这两个端点之间的响应时间（延迟）和任何数据包丢失，而不是试图找出为什么基于tracertpath存在性能问题。

跟踪路由，正如其名称所暗示的，是发现两个端点之间path的工具，它不是分析该path质量的工具。

我必须同意joeqwerty，ICMP很久以前就停止了对性能，延迟或吞吐量的可靠衡量。 对于在未知networking上有很多跳的路由尤其如此。

一个更现实的testing将是您正在使用的协议。 例如，如果它是http，则可以设置Wiresharknetworking数据包捕获。 过滤与指定主机的对话，并使用Wireshark的统计> TCPstream图>往返时间图。 如果您执行至less几分钟的捕获，则此testing更准确。

另一个有趣的select是PingPlotter标准 （不是免费的，但function完整的30天）。 这为通过指定端口号的协议特定的吞吐量testing提供了非常好的能力，并且具有往返时间图，并且可以被保存和加载。

平局和追踪路线（具有特定TTL的平局）是暂时的。 你在某个特定时刻看到的就是这样，而与过去或未来的事件无关。

互联网的一部分带宽（2％ish）是pingstream量，除非你是互联网的骨干，否则没有真正的目的。 如果您遇到问题，请致电您的ISP。

经过更多testing后，这是UDP延迟的一个问题。

高延迟与不良应用程序性能相吻合的原因似乎是CPU限制的主机。 TTL过期的ICMP数据包需要CPU时间来制定响应，因此大多数路由器被configuration为“当我感觉到应答”时。 在这种情况下，过期TTL ICMPstream量的延迟表示繁忙的路由器。 主机似乎在他们的networking边缘，所以所有的stream量大部分是通过该跳。

我高度怀疑ISP正在进行一些UDP协议的stream量检查或整形，这也需要CPU时间。

确保减less饱和链接上的缓冲区 。