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

11

У меня следующая проблема: когда я получаю страницу из 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.

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

http 
— Роман Чепляка
источник
Привет, я думаю, что вам нужно использовать браузер с включенными инструментами разработчика, чтобы видеть диалог уровня HTTP, а не диалог уровня IP. Нам нужно посмотреть, что вызывает задержку, и вы можете сделать это, только взглянув на общий набор HTTP-взаимодействий для страницы. Вместо этого вы можете использовать GMetrix .
— Джулиан Найт
Запуск GMetrix на сайте дал мне довольно хорошие результаты с парой значительных ожиданий, которые могут указать вам верное направление.
— Джулиан Найт
@JulianKnight: в вопросе есть ссылка на полный файл захвата - там есть вся информация
— Роман Чепляка
Ваша ссылка PCAP, я имею в виду что-то на гораздо более высоком уровне. Пожалуйста, сообщите, используя браузерный анализ разработчика или GMetrix или оба.
— Джулиан Найт
1
@JulianKnight: позвольте мне повторить - CSS здесь не имеет значения, и мы говорим о 30- секундной задержке для одного HTTP-запроса.
— Роман Чепляка

Ответы:

5

«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.

— LSerni
источник
Это выглядит очень правдоподобно! Позвольте мне проверить это.
— Роман Чепляка
По первой причине я попытался перейти на haskell, используя анонимный прокси-сервер, и это было быстро, что может указывать на то, что эта причина маловероятна. Во втором случае следует ожидать такой же паузы при доступе к haskell от любого провайдера, поэтому это также маловероятно. DNS все еще может быть причиной, но это может быть более сложным для объяснения.
— harrymc
@harrymc: на самом деле все очень просто. DNS-серверы моего провайдера, отвечающие за обратный DNS, не работают. Итак, попытки сделать обратное разрешение тайм-аута. Попробуйте это: dig +trace -x 80.90.233.38. Я на 95% уверен, что это причина, просто жду подтверждения, что хакер действительно выполняет обратный поиск DNS.
— Роман Чепляка
0

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

— davidgo
источник
Согласно руководству по Wireshark, «сегмент TCP повторно собранного PDU» на самом деле не соответствует фрагментации IP, а просто указывает, что ответ действительно содержит несколько пакетов, как и следовало ожидать от веб-страницы.
— Джулиан Найт
Это не похоже на MTU. Я проверил это, подключившись напрямую через Ethernet и установив mtu на 1000. Проблема осталась.
— Роман Чепляка
0

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

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

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

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

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

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

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

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

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

— harrymc
источник
1. Это одинаково для всех страниц взлома. 2. Как я уже сказал, я попробовал это на нескольких компьютерах и с несколькими маршрутизаторами (и без одного). 4. Проблема не существует, если я использую другого провайдера в моем регионе.
— Роман Чепляка
Теперь проблема ISP действительно выглядит как единственно возможное решение, но что это за проблема? Они, вероятно, даже не подозревают о существовании взлома, поэтому он не может быть преднамеренным. Если я скажу им: «Эй, этот сайт не работает для меня (но все остальные работают)», они не будут слушать.
— Роман Чепляка
Я добавил выше объяснение, почему только первый доступ медленный. Пункт 3 все еще нуждается в ответе, прежде чем говорить с провайдером. Их проблема может быть связана с программным обеспечением безопасности, которое они используют, и по какой-то причине очень медленно проверяют действительность haskell.org.
— harrymc
Etag не имеет значения, так как я использую curl для тестирования. В любом случае, ответ об обратном днс, скорее всего, правильный.
— Роман Чепляка
-2

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

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

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

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

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

— Хлоя
источник
При использовании прокси проблема исчезает. Ваши другие предложения уже рассмотрены в самом вопросе.
— Роман Чепляка
Сервер не любит вас. Это душит ваш IP по любой причине. Вы ничего не можете сделать.
— Хлоя
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.