Велика затримка під час отримання сторінки з певного сайту

У мене є така проблема: коли я завантажую сторінку з 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-адресі, і цей запит чомусь не вдається, ви побачите:

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

... і саме такі симптоми ви описуєте.

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

Ще однією можливою причиною може бути DNS ISP1, який Hackage усунув з певної (ймовірно, помилкової) причини (в моєму вбранні причиною буде "щасливий нетадмін", і я можу назвати імена). У такому випадку у вас буде набагато складніше діагностувати, оскільки будь-які тести через ISP2 не повернуть нічого незвичайного; вам доведеться ескалювати це до Hackage.

Проблема звучить як проблема з "MTU". Якщо ви google "windows setup mtu", вам слід придумати ряд відповідей, які покажуть вам, як перевірити цю теорію, і знизить MTU, як це доречно. (Якщо ви використовували маршрутизатор Linux, я міг би створити команду IPTables, щоб зробити це динамічно для вас, але я не "роблю" Windows.)

Я повторив ваше захоплення пакетів, які виглядають так на моєму кінці:

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

Коротше кажучи, немає жодної причини для цієї затримки, що стосується Інтернету. Висновок полягає в тому, що з вашим провайдером є проблеми.

Що ви можете зробити, щоб звузити можливості:

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

[EDIT]

Я помітив, що haskell.org надсилає ETag , так що пояснює, чому перший доступ повільний, а наступний - швидкий: Тому що, поки ETag дійсний, сторінка фактично надходить із кешу браузера.

Дивна частина тут полягає в тому, що ISP не повільний при передачі запиту ETag. Поясненням може бути те, що вони протягом обмеженого часу задовольняють запит із власного кешу, а не переходять на haskell.org.

Це звучить як проблема із сервером. Це швидко завантажувалося для мене. Щоб перевірити, чи не подобається вам сервер, спробуйте отримати доступ до нього через проксі-сервер, наприклад 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, перейдіть на вкладку Мережа та перейдіть на сайт, щоб побачити час для кожного ресурсу.