Как раз в последний день у меня возникла проблема с сетью, когда загрузка любой страницы из Google занимает очень много времени (> 10 секунд). Другие сайты в порядке; эта проблема, кажется, только с Google. Сначала я столкнулся с этим на машине с Windows 8.1 под управлением Chrome. Время пинга для www.google.com составляло около 20 мс, и, похоже, не было пропущенных пакетов. Я подумал, что это может быть проблема с моим роутером или доступом к Интернету через Comcast, поэтому я попытался перезагрузить свою машину в Ubuntu, где я обнаружил, что не могу воспроизвести проблему, и Google там работал очень быстро. У меня также есть телефон с Android, подключенный к моей сети Wi-Fi, и подключения к Google там тоже в порядке. Я подумал, что это может быть проблема с каким-либо вредоносным ПО, конфигурацией сети или брандмауэра, но у меня есть второй компьютер под управлением Windows 7, на котором возникла та же проблема в одно и то же время, поэтому я не уверен, что могло бы повлиять на нас обоих. Кстати, у меня не настроен прокси. Я проверил через настройки Интернета, что прокси-сервер не настроен и прокси-автоопределение отключено. Обе эти машины Windows подключены к моему маршрутизатору через кабели CAT6, один напрямую, один через другой коммутатор.
Первоначально у меня был Chrome 61.0.3163.100, и я подумал, что это может быть проблемой с Chrome, но я также столкнулся с той же проблемой при запуске Internet Explorer 11 и Firefox 46.0.1 на одной машине. Я также скачал Chrome Canary, и у него тоже была та же проблема. В качестве типичного примера приведем сетевую консоль из запроса в Chrome Canary:
Глядя на время запроса 18-х годов, я получаю следующее:
Другими словами, почти все это время затрачивается на остановку запроса. Если я посмотрю журнал событий в chrome://net-internals для этого, вот что я вижу:
Бревенчатый дамп из Chrome Canary
Похоже, что в этом случае он сделал запрос, что сервер просто игнорирует, пока не истечет время ожидания соединения, а затем он отлично работает на повторной попытке. Для этого запроса также есть связанный журнал HTTP2_SESSION:
HTTP2_SESSION дамп журнала из запроса выше
Похоже, это заканчивается ошибкой сокета, но я нахожу очень мало информации в Интернете об ошибке 101. В другой попытке я получил это:
В этом случае кажется, что он просто открывает соединение и ничего не делает, пока не истечет время ожидания. Я неправильно это понимаю? Между прочим, моя загрузка Chrome Canary была приостановлена на очень долгое время после загрузки 500 тыс. Штук, прежде чем закончить оставшуюся часть пути. Вот журналы для этого (из Chrome 61):
У меня также есть некоторые связанные журналы HTTP2_SESSION для этой загрузки:
HTTP2_SESSION журналы для загрузки Chrome Canary
Похоже, что здесь загрузка просто остановилась, пока Chrome не пропинговал соединение, а затем отправил еще один запрос. У меня есть довольно много похожих журналов HTTP2_SESSION, которые показывают, что соединения простаивают в течение долгого времени до сбоя эхо-запросов, но обычно они заканчиваются ошибкой 101. Я не уверен, что проблема здесь. Итак, вы знаете, что это не проблема Chrome, у меня также есть аналогичная временная шкала из F12 Developer Tools в IE 11:
Здесь, кажется, тратится довольно много времени на этапе "Старт" запроса. Похоже, что в IE 11 он немного прерывистый. Иногда запросы выполняются нормально, иногда они истекают. Я подумал, что это может быть проблема с HTTP/2 под Windows, так как все сеансы с проблемами - это сеансы HTTP/2, но я пробовал другие сайты HTTP/2, которые работают нормально.
Еще одна вещь, которую я попробовал, - настроить пользовательский агент на Chrome в Ubuntu на тот же, который использовался Chrome на Windows, - Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/64.0 .3259.0 Safari/537.36. Это ничего не изменило. Гугл под Ubuntu работает отлично.
Мой DNS настроен на использование DNS-сервера Comcast IPv6 2001:558:feed::1, который разрешает www.google.com 2607:f8b0:4007:80a::2004 или 172.217.4.164. Я также попытался использовать DNS-сервер Google 8.8.8.8, который разрешает www.google.com 2607:f8b0:4005:806::2004 или 172.217.5.100. Установка 8.8.8.8 в качестве DNS по умолчанию, а затем очистка DNS-кэша Chrome также не устранили проблему.
Попробовав IPv6-адрес для DNS от Google и полностью провалив его, я отключил IPv6 в своем сетевом адаптере, и теперь все снова работает нормально. Как ни странно, мой телефон Android также использует IPv6 через Wi-Fi и не имеет таких же проблем. Я также проверил это на своей установке Ubuntu, которая настроена на использование IPv6, и попробовал использовать IPv6-адреса Google DNS, и она работала нормально. Это может быть связано с плохой реализацией IPv6 либо в моем маршрутизаторе Arris TG862G, либо в моем локальном Интернете Comcast, но это не объясняет, почему это влияет только на машины с Windows. Если это вообще актуально, IPv6 на моем маршрутизаторе настроен на сохранение состояния, а не на DHCP. Единственное изменение, которое я недавно сделал в своей сети, было то, что я обновил версию DD-WRT вторичной точки доступа / коммутатора (первоначально маршрутизатора Netgear), которую моя машина Windows 8.1 не использует, но машина Windows 7 делает. Маршрутизатор Netgear строго IPv4.
Я переключил свой кабельный модем / маршрутизатор на более новый, и это, казалось, решило проблему за день, но теперь, спустя 24 часа, это происходит снова. Все равно придется отключить IPv6 на моих машинах с Windows. Сейчас выполняется новая установка Windows 10, но проблема остается той же.