我一直在使用smokeping来监视networking延迟（用于早期的问题检测）在8.8.8.8几个月。 星期五平均延迟时间从12ms到55ms，一直在3天55ms的高原。 我们的广域网使用相同的提供商来连接所有的互联网连接，所以我们对是否存在问题感到好奇，或者8.8.8.8只是决定扼杀pipe道。
我们的ISP声称问题是8.8.8.8，但我仍然怀疑。
我注意到我得到了与4.2.2.2相同的（55ms）延迟，但是我没有绘制IP，所以我没有任何参考数据来certificate服务性能下降。
任何关于如何解决这个exception的build议都是有帮助的。
PS：stream量在我们的路由器上没有显示过多的stream量，这将指向行为驱动的服务下降。
当你看到这样的延迟变化，原因99％的时间是互联网路由变化。 不幸的是，除非你捕获周期性的跟踪路由，否则你无法看到路由是什么。
我非常怀疑8.8.8.8是否正在做任何直接导致延迟跳跃的事情。
8.8.8.8是Google的公共DNS服务。
它们通过BGP选播实现了地理上的接近，这意味着有一天你打的物理服务器和你到达的物理服务器可能会发生巨大的变化，取决于Google的广告来源以及最短path到达哪个位置。
这听起来像你的stream量从附近的服务器改变到更远的一个 – 谷歌可能已经取消了附近的一个，或者你的ISP的BGP进程可能会看到另一个8.8.8.0/24的广告更接近于路由跳转到到达目的地。
那不是在这里，也不在那里; 问题是8.8.8.8不是一个很好的地址来衡量你的互联网链接的性能，如果你这样做，这样的波动应该是可以预料的。
traceroute会告诉你每一跳需要多长时间，并且你可以计算出你的55ms周转时间的最大贡献者在哪里。 正如ErikA所说，没有以前的数据，这将不会有什么帮助，但至less你会有一些想法。