У меня следующая проблема: когда я получаю страницу из 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.
Как диагностировать такую проблему?
Ответы:
«30 секунд» и «через две минуты» - мертвый звонок для проблемы с DNS для меня.
Если мы предположим, что страница, к которой вы подключаетесь, выполняет что-то вроде DNS-запроса на подключающемся IP-адресе, и этот запрос по какой-то причине не выполняется, вы увидите:
... и это именно те симптомы, которые вы описываете.
Вы можете попробовать выполнить DNS-запрос от другого провайдера (скажем, ISP2) на IP, который вы получаете от провайдера ISP1. Это не 100% доказательство, но я ожидаю высокой вероятности того, что выполнение запроса займет 30 секунд. Это означает, что DNS-сервер ISP1 испытывает проблемы с ответом на запросы извне .
Другой возможной причиной может быть то, что DNS-провайдер ISP1 блокируется брандмауэром по какой-то (вероятно, ошибочной) причине (в моем наряде причина была бы «нетадмин, довольный триггером», и я мог бы назвать имена). В этом случае вам будет гораздо сложнее диагностировать, потому что любые тесты через ISP2 не дадут ничего необычного; вам придется перевести это в Hackage.
источник
dig +trace -x 80.90.233.38. Я на 95% уверен, что это причина, просто жду подтверждения, что хакер действительно выполняет обратный поиск DNS.Проблема звучит как проблема с "MTU". Если вы гуглите «windows setting mtu», вы должны получить ряд ответов, которые покажут вам, как проверить эту теорию, и понизьте свой MTU по мере необходимости. (Если бы вы использовали маршрутизатор Linux, я мог бы создать команду IPTables, чтобы сделать это динамически для вас, но я не "делаю" Windows.)
источник
Я повторил захват ваших пакетов, которые на моем конце выглядят так:
Фактически, есть небольшая неопределяемая пауза, пока пакет повторно собирается, но нигде, пока ваш. Я также проверил все IP-адреса и HTML, и все правильно и выглядит очень просто и безвредно.
Короче говоря, нет никаких причин для такой задержки, что касается Интернета. Вывод: проблема с вашим провайдером.
Что вы можете сделать, чтобы сузить возможности:
[РЕДАКТИРОВАТЬ]
Я заметил, что haskell.org отправляет ETag , что объясняет, почему первый доступ медленный, а следующие быстрые: потому что пока ETag действителен, страница фактически поступает из кэша вашего браузера.
Странная часть здесь заключается в том, что интернет-провайдер не работает медленно при передаче запроса ETag. Объяснение может быть в том, что в течение ограниченного времени они удовлетворяют запрос из своего собственного кэша, а не переходят на haskell.org.
источник
Это звучит как проблема с сервером. Он быстро загрузился для меня. Чтобы проверить, не нравится ли вам сервер, попробуйте получить к нему доступ через прокси-сервер, например TOR или HideMyAss.com. Если это быстро, то есть проблема между haskell.org и вашим домом.
Другой тест, который вы можете запустить, - это найти на этом ресурсе ресурс, такой как HTML-файл, CSS-файл или XML-файл, и передать эту ссылку валидатору HTML и т. Д. Если сторонним службам требуется много времени для извлечения, то он это проблема с сервером.
Еще один тест: очистить кэш DNS. Это может быть поиск IP-адреса haskell.org занимает много времени.
ipconfig /flushdns, Также попробуйтеping hackage.haskell.orgиз командной строки узнать, сколько времени занимает поиск IP-адреса.Еще один тест: откройте приватную сессию просмотра с Chrome (и другими), чтобы избежать отправки куки.
Еще один тест: откройте F12 в Chrome или Opera, перейдите на вкладку Сеть и перейдите на сайт, чтобы узнать время для каждого ресурса.
источник