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?
Odpowiedzi:
„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:
... 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.
źródło
dig +trace -x 80.90.233.38. Jestem w 95% pewien, że to jest przyczyna, tylko czekam na potwierdzenie, że włamanie rzeczywiście wykonuje odwrotne wyszukiwanie DNS.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”.)
źródło
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:
[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.
źródło
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żeping 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.
źródło