☰

Большая задержка при загрузке страницы с определенного сайта

tag-icon • tag-icon http
Большая задержка при загрузке страницы с определенного сайта

У меня следующая проблема: когда я извлекаю страницу изВзлом, получаю большую задержку (около 30 секунд). Дальнейшие запросы выполняются быстро, но если я не подключаюсь к нему в течение пары минут, проблема возвращается.

Что интересно в этой задаче:

  • это характерно для этого конкретного сайта (взлом) — у меня нет подобной проблемы ни с одним другим сайтом (а я посещаю довольно много);
  • похоже, это проблема моего интернет-провайдера — когда я подключаюсь из других мест, такой проблемы нет;

  • это не связано с проблемами DNS или подключения — на самом деле TCP-соединение устанавливается быстро; HTTP-ответ занимает слишком много времени, как видно из следующего примера захвата пакета:

      1 0.000000000 192.168.1.101 -> 66.193.37.204 TCP 66 41518 > http [SYN] Seq=0 Win=13600 Len=0 MSS=1360 SACK_PERM=1 WS=16
  2 0.205708000 66.193.37.204 -> 192.168.1.101 TCP 66 http > 41518 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1440 SACK_PERM=1 WS=128
  3 0.205759000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=1 Ack=1 Win=13600 Len=0
  4 0.205846000 192.168.1.101 -> 66.193.37.204 HTTP 158 GET /packages/hackage.html HTTP/1.1 
  5 0.406461000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [ACK] Seq=1 Ack=105 Win=5888 Len=0
  6 28.433860000 66.193.37.204 -> 192.168.1.101 TCP 1494 [TCP segment of a reassembled PDU]
  7 28.433904000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=1441 Win=16480 Len=0
  8 28.434211000 66.193.37.204 -> 192.168.1.101 HTTP 1404 HTTP/1.1 200 OK  (text/html)
  9 28.434228000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=2791 Win=19360 Len=0
 10 28.434437000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [FIN, ACK] Seq=105 Ack=2791 Win=19360 Len=0
 11 28.635146000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [FIN, ACK] Seq=2791 Ack=106 Win=5888 Len=0
 12 28.635191000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=106 Ack=2792 Win=19360 Len=0

    (захват пакетов в формате pcap-ng). Этот снимок показывает, что происходит во время простого curl http://hackage.haskell.org/packages/hackage.html.

Также не имеет значения, что я нахожусь за роутером — при прямом подключении все то же самое. Тип подключения — PPPoE.

Я воспроизвел проблему на трех компьютерах под управлением Linux и Windows.

Как диагностировать такую ​​проблему?

решение1

«30 секунд» и «через две минуты» — это, на мой взгляд, точная копия проблемы с DNS.

Если предположить, что страница, к которой вы подключаетесь, выполняет что-то вроде DNS-запроса на подключающемся IP-адресе, и этот запрос по какой-то причине не выполняется, вы увидите:

  • TCP-соединение почти мгновенное, так каксерверне выполняет проверки DNS
  • скрипт выполняет DNS-запроси застревает.
  • через 30 секунд истекает тайм-аут по умолчанию, и скрипт продолжается (теперь вы «Неизвестный»).
  • при последующих запросах отрицательное попадание DNS все еще кэшируется, и этап 1 передается практически мгновенно
  • по истечении отрицательного тайм-аута (RFC 2308), а это от 2 до 5 минут, при следующем подключении отправляется новый запрос, и история повторяется.

...и это именно те симптомы, которые вы описываете.

Вы можете попробовать запустить DNS-запрос от другого провайдера (например, ISP2) на IP, который вы получаете от ISP1. Это не 100% доказательство, но я ожидаю высокой вероятности того, что запрос займет 30 секунд для завершения. Это будет означать, что DNS-сервер ISP1 испытывает проблемы с ответами на запросыснаружи.

Другой возможной причиной может быть то, что DNS ISP1 был заблокирован брандмауэром Hackage по какой-то (вероятно, ошибочной) причине (вмой(Наряд, причиной может быть «любящий нажимать на курок сетевой администратор», и я могу назвать имена). В этом случае вам будет гораздо сложнее диагностировать, поскольку любые тесты через ISP2 не дадут ничего необычного; вам придется передать это на рассмотрение Hackage.

решение2

Проблема звучит как проблема с "MTU". Если вы введете в Google "windows setting mtu", вы должны получить ряд ответов, которые покажут вам, как проверить эту теорию и понизить MTU соответствующим образом. (Если бы вы использовали маршрутизатор Linux, я мог бы создать команду IPTables, чтобы сделать это динамически, но я не "делаю" Windows.)

решение3

Я повторил захват ваших пакетов, которые на моей стороне выглядят так:

захватить изображение

Фактически есть небольшая необнаруживаемая пауза, пока пакет собирается заново, но нигде не такая длинная, как у вас. Я также проверил все IP-адреса и HTML, и все правильно и выглядит крайне просто и безвредно.

Короче говоря, нет никаких причин для этой задержки, что касается Интернета. Вывод - проблема с вашим провайдером.

Чтобы сузить круг возможностей, можно сделать следующее:

  1. Попробуйте подключиться кдругой пакет haskell.orgи посмотрите, есть ли подобная задержка
  2. Попробуйте использовать другой маршрутизатор с несколькими компьютерами, использующими разные сетевые адаптеры.
  3. Постарайтесь найти в вашем районе кого-нибудь, кто используеттакой жеИнтернет-провайдер повторите подключение
  4. Постарайтесь найти в вашем районе кого-то, кто используетдругойИнтернет-провайдер повторите подключение
  5. Если, получив эту информацию, вы по-прежнему не можете объяснить причину задержки, обратитесь в службу поддержки вашего интернет-провайдера, чтобы узнать, что происходит.

[РЕДАКТИРОВАТЬ]

Я заметил, что haskell.org отправляетETag, поэтому это объясняет, почему первый доступ медленный, а последующие быстрые: потому что, пока ETag действителен, страница фактически берется из кэша вашего браузера.

Странно то, почему провайдер не тормозит при передаче запроса ETag. Объяснением может быть то, что в течение ограниченного времени они удовлетворяют запрос из собственного кэша, а не обращаются к haskell.org.

решение4

Похоже на проблему с сервером. У меня он загружался быстро. Чтобы проверить, не нравится ли вам сервер, попробуйте зайти на него через прокси, например TOR или HideMyAss.com. Если он быстрый, то проблема между haskell.org и вашим домом.

Другой тест, который вы можете выполнить, — это найти ресурс на этом сайте, например файл HTML, файл CSS или файл XML, и передать эту ссылку HTML-валидатору и т. д. Если сторонние службы долго загружают данные, то проблема связана с сервером.

Другой тест: очистите кэш DNS. Возможно, поиск IP-адреса haskell.org занимает много времени. ipconfig /flushdns. Также попробуйте ping hackage.haskell.orgиз командной строки посмотреть, сколько времени занимает поиск IP-адреса.

Еще один тест: откройте приватный сеанс просмотра в Chrome (и других браузерах), чтобы избежать отправки файлов cookie.

Еще один тест: откройте F12 в Chrome или Opera, перейдите на вкладку «Сеть», а затем перейдите на сайт, чтобы увидеть время для каждого ресурса.

Связанный контент