つい先日、Googleのページを読み込むのに非常に長い時間（10秒以上）がかかるというネットワーク上の問題が発生し始めました。他のウェブサイトは結構です。この問題はGoogleでのみ起こるようです。私は最初にChromeを実行しているWindows 8.1マシンでこれに遭遇しました。 www.google.comのping時間は約20ミリ秒で、パケットがドロップされることはありませんでした。私はそれが私のルーターまたは私のComcastインターネットアクセスに問題があると思ったので、私は私が問題を再現することができないことがわかったUbuntuに私のマシンを再起動しようとしました。私はまた私のWi-Fiネットワークに接続されたAndroid携帯電話を持っています、そしてグーグルへの接続もそこで完全に問題ありません。マルウェア、ネットワーク、またはファイアウォールの設定に問題があると思いましたが、Windows 7を実行している2台目のコンピューターで同じ問題が同時に発生したため、両方に影響を及ぼしたのかはわかりません。ところで、私はプロキシを設定していません。インターネット設定で、プロキシが設定されておらず、プロキシの自動検出が無効になっていることを確認しました。これらのWindowsマシンは両方ともCAT6ケーブルを介して私のルータに直接接続されています。
私はもともとChrome 61.0.3163.100を実行していたので、Chromeの問題かもしれないと思いましたが、Internet Explorer 11とFirefox 46.0.1を同じマシンで実行しても同じ問題に遭遇しました。 Chrome Canaryもダウンロードしましたが、同じ問題がありました。典型的な例を挙げると、これはChrome Canaryのクエリからのネットワークコンソールです。
その18秒クエリのタイミングを見ると、私はこれを得ます：
言い換えれば、その時間のほとんどすべてが、クエリが停止することに費やされます。このためにchrome：// net-internalsでイベントログを見ると、これが私の見ていることです。
この場合、接続がタイムアウトするまでサーバーが無視するように要求したように見えますが、再試行時には正常に動作します。このクエリに関連するHTTP2_SESSIONログもあります。
これはソケットエラーで終了したように見えますが、エラー101でオンラインでごくわずかな情報を見つけています。別の試みで、私はこれを得ました：
この場合、接続を開くだけでタイムアウトになるまで何もしません。私はこれを誤解していますか？ちなみに、Chrome Canaryの私のダウンロードは、それを500kダウンロードした後、非常に長い時間の間、残りの方法を終える前に一時停止した。そのためのログは次のとおりです（Chrome 61以降）。
私はそのダウンロードに関するいくつかの関連HTTP2_SESSIONログも持っています：
Chrome Canaryのダウンロードに関するHTTP2_SESSIONログ
Chromeが接続をpingしてから別のリクエストを送信するまで、ダウンロードは停止したようです。 pingが失敗するまで長時間アイドル状態になる接続を示す、同様のHTTP2_SESSIONログがかなりありますが、通常はエラー101で終了します。ですから、これはChromeの問題ではないことがわかります。IE11のF12開発者ツールからも同様のタイムラインがあります。
ここでは、クエリの「開始」段階でかなりの時間を費やしているようです。それはIE 11ではもう少し断続的なようです。時にはクエリはうまく実行され、時にはタイムアウトになります。問題のあるセッションはすべてHTTP / 2セッションであるため、これはWindowsでのHTTP / 2の問題になる可能性があると思いましたが、他のHTTP / 2サイトで問題なく動作することを試みました。
Ubuntu上のChrome上のユーザーエージェントを、Mozilla / 5.0（Windows NT 6.3; Win64; x64）AppleWebKit / 537.36（GeckoのようなKHTML）Chrome / 64.0に設定しました。 .3259.0 Safari / 537.36。それは何も変わらなかった。 Ubuntuの下のGoogleは問題なく動作します。
私のDNSはComcastの2001：558：feed :: 1のIPv6 DNSサーバーを使うように設定されています。これはwww.google.comを2607：f8b0：4007：80a :: 2004または172.217.4.164に解決します。また、www.google.comを2607：f8b0：4005：806 :: 2004または172.217.5.100に解決する、GoogleのDNSサーバー8.8.8.8を使用してみました。デフォルトのDNSとして8.8.8.8を設定してからChromeのDNSキャッシュをフラッシュしても問題は解決しませんでした。
GoogleのDNS用のIPv6アドレスを試して、それが完全に失敗した後、私は私のネットワークアダプタでIPv6を無効にし、そして今、すべてが再びうまくいっている。奇妙なことに、私のAndroid携帯電話もWifi経由でIPv6を使用しており、同じ問題を抱えていません。私は、IPv6を使うように設定された私のUbuntuインストールでもこれをテストし、そしてグーグルDNS IPv6アドレスを試してみました、そしてそれはうまく働きました。これは、私のArris TG862Gルーターまたは私の地元のComcastインターネットのいずれかでのIPv6の実装が貧弱だからかもしれませんが、それがWindowsマシンにしか影響を与えない理由を説明するものではありません。それが全く関係しているなら、私のルータのIPv6はDHCPではなく、ステートレスに設定されています。私が最近ネットワークに加えた唯一の変更は、私のWindows 8.1マシンが使用していないがWindows 7マシンが使用しているDD-WRT版のセカンダリアクセスポイント/スイッチ（元々はNetgearルーター）を更新したことです。 Netgearルーターは厳密にはIPv4です。
私は新しいモデムに私のケーブルモデム/ルーターを交換しました、そしてそれは1日の間問題を解決するようでした、しかし今、24時間後に、それは再び起こっています。私のWindowsマシンではまだIPv6を無効にする必要があります。今、新しいWindows 10インストールを実行していますが、それでも同じ問題を抱えています。