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

Question

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

Что интересно в этой проблеме:

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

• это не связано с 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.

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

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

Answer 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 блокируется брандмауэром по какой-то (вероятно, ошибочной) причине (в моем наряде причина была бы «нетадмин, довольный триггером», и я мог бы назвать имена). В этом случае вам будет гораздо сложнее диагностировать, потому что любые тесты через ISP2 не дадут ничего необычного; вам придется перевести это в Hackage.

Answer 2

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

Answer 3

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

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

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

Что вы можете сделать, чтобы сузить возможности:

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

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

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

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

Answer 4

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

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

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

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

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