几个月来，我一直在使用 smokeping 来监控 8.8.8.8 的互联网延迟（以便及早发现问题）。周五，平均延迟从 12 毫秒降至 55 毫秒，并且已经连续 3 天保持在 55 毫秒的稳定水平。我们的 WAN 使用同一个提供商来提供所有互联网连接，因此我们很好奇他们是否有问题，或者 8.8.8.8 是否决定堵塞管道。
我们的 ISP 声称问题出在 8.8.8.8，但我仍然怀疑。
我注意到我得到了与 4.2.2.2 相同的延迟（55ms），但我没有绘制该 IP 的图表，因此没有任何参考数据来证明服务质量下降。
关于如何处理这个异常现象的任何建议都会有帮助。
PS：Flow 显示我们的路由器上没有过多的流量，这表明行为驱动了服务下降。
答案1
当您看到这样的延迟变化时，99% 的时间都是互联网路由变化造成的。不幸的是，除非您定期捕获跟踪路由，否则您无法查看以前的路由。
我非常怀疑 8.8.8.8 是否直接做了导致延迟增加的事情。
答案2
8.8.8.8 是 Google 的公共 DNS 服务。
它们通过 BGP 任播实现地理邻近性，这意味着您某一天访问的物理服务器以及到达该服务器所采用的路径可能会发生巨大变化，具体取决于 Google 从何处发布广告以及到达该位置的最短路径。
听起来你的流量从去往附近的服务器变成了去往更远的服务器 - Google 可能已经关闭了附近的服务器，或者你的 ISP 的 BGP 进程可能会看到另一个 8.8.8.0/24 的通告在路由跳数方面更接近到达目的地。
这无关紧要；关键是 8.8.8.8 并不是一个用来衡量互联网链接性能的好地址，如果你这样做，应该会出现这样的波动。
答案3
traceroute 会显示每次跳跃需要多长时间，你可以找出 55ms 往返时间的最大贡献者在哪里。正如 ErikA 所说，如果没有以前的数据，它不会有太大帮助，但至少你会有一些想法。