Duże opóźnienie przy pobieraniu strony z określonej witryny

Mam następujący problem: gdy odzyskuję stronę z Hakowania , mam duże opóźnienie (około 30 sekund). Dalsze żądania są szybkie, ale jeśli nie połączę się z nim przez kilka minut, problem wróci.

Interesujące w tym problemie jest:

• jest specyficzny dla tej konkretnej strony (Hackage) - nie mam podobnego problemu z żadną inną witryną (i odwiedzam sporo);
• wydaje się, że jest specyficzny dla mojego dostawcy usług internetowych - kiedy łączę się z innych miejsc, nie ma takiego problemu;

• nie ma to związku z DNS ani problemami z łącznością - w rzeczywistości połączenie TCP jest ustanawiane szybko; jest to odpowiedź HTTP, która trwa zbyt długo, co można zobaczyć na podstawie następującego przykładowego przechwytywania pakietu:

    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
  

  ( przechwytywanie pakietów w formacie pcap-ng ). To zdjęcie pokazuje, co dzieje się podczas prostego curl http://hackage.haskell.org/packages/hackage.html.

Nie ma również znaczenia, że ​​jestem za routerem - tak samo jest, gdy łączę się bezpośrednio. Typ połączenia to PPPoE.

Problem odtworzyłem na 3 komputerach z systemem Linux i Windows.

Jak zdiagnozować taki problem?

„30 sekund” i „po dwóch minutach” to dla mnie problem z DNS.

Jeśli przypuszczamy, że strona, z którą się łączysz, działa jak zapytanie DNS na łączącym się IP, a zapytanie to z jakiegoś powodu nie powiedzie się, zobaczysz:

• Połączenie TCP prawie natychmiastowe, ponieważ serwer nie sprawdza DNS
• skrypt uruchamia zapytanie DNS i blokuje się .
• po 30 sekundach upłynął domyślny limit czasu i skrypt kontynuuje działanie (jesteś teraz „Nieznany”)
• przy kolejnych zapytaniach negatywne trafienie DNS jest nadal buforowane, a etap 1 jest przekazywany w mgnieniu oka
• po upływie ujemnego limitu czasu (RFC 2308), czyli od 2 do 5 minut, przy następnym połączeniu wydawane jest nowe zapytanie i historia się powtarza.

... i to są dokładnie objawy, które opisujesz.

Możesz spróbować uruchomić zapytanie DNS od innego dostawcy (powiedzmy ISP2) na adresie IP otrzymanym od ISP1. Nie jest to 100% dowód, ale spodziewam się, że wykonanie zapytania zajmie 30 sekund. Oznaczałoby to, że serwer DNS ISP1 ma problemy z odpowiadaniem na zapytania z zewnątrz .

Inną możliwą przyczyną może być zapora ogniowa DNS ISP1 z jakiegoś (prawdopodobnie błędnego) powodu (w moim zestawie przyczyną byłby „szczęśliwy administrator sieci” i mogłem wymieniać nazwy). W takim przypadku znacznie trudniej byłoby ci zdiagnozować, ponieważ wszelkie testy za pośrednictwem ISP2 nie zwróciłyby niczego niezwykłego; musiałbyś to eskalować do Hackage.

Problem brzmi jak problem z „MTU”. Jeśli korzystasz z Google „Windows Setting Mtu”, powinieneś znaleźć szereg odpowiedzi, które pokażą ci, jak przetestować tę teorię, i odpowiednio obniż MTU. (Jeśli korzystasz z routera Linux, mógłbym utworzyć polecenie IPTables, aby zrobić to za Ciebie dynamicznie, ale nie „Windows”.)

Powtórzyłem przechwytywanie pakietów, które wyglądają w ten sposób po mojej stronie:

W efekcie następuje niewielka niewykrywalna przerwa podczas ponownego składania pakietu, ale nigdzie tak długo jak Twoja. Sprawdziłem również wszystkie adresy IP i HTML, a wszystko jest poprawne i wygląda niezwykle prosto i nieszkodliwie.

Krótko mówiąc, nie ma powodu do tego opóźnienia, jeśli chodzi o Internet. Wniosek jest taki, że istnieje problem z twoim dostawcą usług internetowych.

Aby zawęzić możliwości, możesz:

1. Spróbuj połączyć się z innym pakietem haskell.org i sprawdź, czy występuje podobne opóźnienie
2. Spróbuj użyć innego routera ze swojego miejsca z kilkoma komputerami korzystającymi z różnych kart sieciowych
3. Postaraj się, aby ktoś w Twojej okolicy, który korzysta z tego samego usługodawcy internetowego, powtórzył połączenie
4. Postaraj się, aby ktoś w Twojej okolicy, który korzysta z usług innego dostawcy usług internetowych, powtórzył połączenie
5. Dzięki tym informacjom, jeśli nadal nie masz wyjaśnienia tego opóźnienia, skontaktuj się z pomocą techniczną swojego dostawcy usług internetowych, aby zapytać, co się dzieje.

[EDYTOWAĆ]

Zauważyłem, że haskell.org wysyła znacznik ETag , więc to wyjaśnia, dlaczego pierwszy dostęp jest wolny, ale następne są szybkie: Ponieważ tak długo, jak ETag jest ważny, strona faktycznie pochodzi z pamięci podręcznej przeglądarki.

Dziwne jest to, że dostawca usług internetowych nie jest wolny podczas przesyłania żądania ETag. Wyjaśnieniem może być to, że przez ograniczony czas zaspokajają żądanie z własnej pamięci podręcznej, zamiast przechodzić na stronę haskell.org.

Brzmi jak problem z serwerem. Szybko się dla mnie załadował. Aby sprawdzić, czy serwer Ci się nie podoba, spróbuj uzyskać do niego dostęp z serwera proxy, takiego jak TOR lub HideMyAss.com. Jeśli jest szybki, oznacza to, że istnieje problem między haskell.org a twoim domem.

Kolejnym testem, który możesz uruchomić, jest znalezienie zasobu na ten widok, takiego jak plik HTML, plik CSS lub plik XML, i przekazanie tego linku do weryfikatora HTML itp. Jeśli pobieranie danych przez usługi innych firm zajmuje dużo czasu, oznacza to, że jest problem z serwerem.

Kolejny test: wyczyść pamięć podręczną DNS. Wyszukiwanie adresu IP haskell.org zajmuje dużo czasu. ipconfig /flushdns. Spróbuj także ping hackage.haskell.orgz wiersza polecenia, aby sprawdzić, ile czasu zajmuje sprawdzenie adresu IP.

Kolejny test: otwórz prywatną sesję przeglądania w Chrome (i innych), aby uniknąć wysyłania plików cookie.

Kolejny test: otwórz F12 w przeglądarce Chrome lub Opera, przejdź do karty Sieć, a następnie przejdź do witryny, aby sprawdzić czas dla każdego zasobu.