Große Verzögerung beim Abrufen einer Seite von einer bestimmten Site

Question

Ich habe folgendes Problem: Wenn ich eine Seite abrufe vonHacken, es kommt zu einer großen Verzögerung (ca. 30 Sekunden). Weitere Anfragen erfolgen schnell, aber wenn ich innerhalb einiger Minuten keine Verbindung herstelle, tritt das Problem erneut auf.

Das Interessante an diesem Problem ist:

• es ist spezifisch für diese bestimmte Site (Hackage) – ich habe ein ähnliches Problem mit keiner anderen Site (und ich besuche ziemlich viele);
• es scheint spezifisch für meinen ISP zu sein – wenn ich mich von anderen Orten aus verbinde, gibt es dieses Problem nicht;

• es hängt nicht mit DNS- oder Verbindungsproblemen zusammen – tatsächlich wird die TCP-Verbindung schnell hergestellt; es ist die HTTP-Antwort, die zu lange dauert, wie aus der folgenden Beispielpaketerfassung ersichtlich ist:

    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
  

  (Paketerfassung im PCAP-NG-Format). Diese Aufnahme zeigt, was während eines einfachen passiert curl http://hackage.haskell.org/packages/hackage.html.

Es spielt auch keine Rolle, ob ich mich hinter einem Router befinde – das Gleiche passiert, wenn ich mich direkt verbinde. Der Verbindungstyp ist PPPoE.

Ich habe das Problem auf drei Computern reproduziert, auf denen Linux und Windows laufen.

Wie lässt sich ein solches Problem diagnostizieren?

Answer 1

„30 Sekunden“ und „nach zwei Minuten“ sind für mich ein todsicherer Hinweis auf ein DNS-Problem.

Wenn wir davon ausgehen, dass die Seite, mit der Sie eine Verbindung herstellen, so etwas wie eine DNS-Abfrage an die Verbindungs-IP ausführt und diese Abfrage aus irgendeinem Grund fehlschlägt, würden Sie Folgendes sehen:

• TCP-Verbindung fast sofort dader Kellnerführt keine DNS-Checks durch
• Das Skript führt eine DNS-Abfrage ausund bleibt stecken.
• nach 30 Sekunden läuft das Standard-Timeout ab und das Skript wird fortgesetzt (Sie sind jetzt „Unbekannt“)
• bei nachfolgenden Abfragen wird der negative DNS-Treffer immer noch zwischengespeichert und Stufe 1 wird in kürzester Zeit durchlaufen
• Nach Ablauf des negativen Timeouts (RFC 2308), also nach 2 bis 5 Minuten, wird bei der nächsten Verbindung eine neue Abfrage ausgegeben und der Vorgang wiederholt sich.

...und das sind genau die Symptome, die Sie beschreiben.

Sie könnten versuchen, eine DNS-Abfrage von einem anderen ISP (z. B. ISP2) auf der IP-Adresse auszuführen, die Sie von ISP1 erhalten. Das ist kein 100%iger Beweis, aber ich gehe davon aus, dass die Abfrage mit hoher Wahrscheinlichkeit 30 Sekunden dauert. Das würde bedeuten, dass der DNS-Server von ISP1 Probleme hat, auf Anfragen zu antworten.von außen.

Eine weitere mögliche Ursache könnte sein, dass der DNS von ISP1 von Hackage aus irgendeinem (wahrscheinlich falschen) Grund per Firewall abgeschirmt wird (inMeinOutfit, der Grund wäre „ein schießwütiger Netadmin“, und ich könnte Namen nennen). In diesem Fall wäre die Diagnose viel schwieriger, da alle Tests über ISP2 nichts Ungewöhnliches ergeben würden; Sie müssten dies an Hackage weiterleiten.

Answer 2

Das Problem klingt nach einem Problem mit „MTU“. Wenn Sie „Windows-MTU-Einstellung“ googeln, sollten Sie eine Reihe von Antworten erhalten, die Ihnen zeigen, wie Sie diese Theorie testen und Ihre MTU entsprechend senken können. (Wenn Sie einen Linux-Router verwenden würden, könnte ich einen IPTables-Befehl erstellen, der dies dynamisch für Sie erledigt, aber ich „mach“ kein Windows.)

Answer 3

Ich habe Ihre Paketerfassung wiederholt, die bei mir so aussieht:

Tatsächlich gibt es eine kleine, nicht wahrnehmbare Pause, während das Paket neu zusammengesetzt wird, aber bei weitem nicht so lang wie bei Ihnen. Ich habe auch alle IP-Adressen und das HTML überprüft, und alles ist korrekt und sieht äußerst einfach und harmlos aus.

Kurz gesagt, es gibt keinen Grund für diese Verzögerung, soweit es das Internet betrifft. Die Schlussfolgerung ist, dass es ein Problem mit Ihrem ISP gibt.

So können Sie die Möglichkeiten eingrenzen:

1. Versuchen Sie eine Verbindung zuein weiteres haskell.org-Paketund prüfen Sie, ob es eine ähnliche Verzögerung gibt
2. Versuchen Sie, einen anderen Router von Ihrem Standort aus mit mehreren Computern mit unterschiedlichen Netzwerkadaptern zu verwenden
3. Versuchen Sie, jemanden in Ihrer Nähe zu haben, der das verwendetDasselbeISP wiederholt die Verbindung
4. Versuchen Sie, jemanden in Ihrer Nähe zu haben, derein andererISP wiederholt die Verbindung
5. Wenn Sie mit diesen Informationen immer noch keine Erklärung für die Verzögerung haben, wenden Sie sich an den Support Ihres ISPs und fragen Sie, was los ist.

[BEARBEITEN]

Mir ist aufgefallen, dass haskell.org eineETag, das erklärt, warum der erste Zugriff langsam ist, die folgenden aber schnell: Denn solange der ETag gültig ist, kommt die Seite tatsächlich aus dem Cache Ihres Browsers.

Das Seltsame dabei ist, warum der ISP bei der Übermittlung einer ETag-Anforderung nicht langsam ist. Eine Erklärung könnte sein, dass er die Anforderung für eine begrenzte Zeit aus seinem eigenen Cache beantwortet, anstatt auf haskell.org zuzugreifen.

Answer 4

Das klingt nach einem Serverproblem. Bei mir wurde es schnell geladen. Um zu testen, ob der Server Sie nicht mag, versuchen Sie, über einen Proxy wie TOR oder HideMyAss.com darauf zuzugreifen. Wenn es schnell ist, gibt es ein Problem zwischen haskell.org und Ihrem Haus.

Sie können auch einen anderen Test durchführen, indem Sie auf dieser Site nach einer Ressource suchen, z. B. einer HTML-, CSS- oder XML-Datei, und diesen Link an einen HTML-Validator usw. weiterleiten. Wenn das Abrufen durch die Dienste von Drittanbietern lange dauert, liegt ein Problem mit dem Server vor.

Ein weiterer Test: Leeren Sie Ihren DNS-Cache. Es könnte sein, dass die Suche nach der IP-Adresse von haskell.org sehr lange dauert. ipconfig /flushdnsVersuchen Sie es auch ping hackage.haskell.orgüber die Befehlszeile, um zu sehen, wie lange die Suche nach der IP-Adresse dauert.

Ein weiterer Test: Öffnen Sie eine private Browsersitzung mit Chrome (und anderen), um das Senden von Cookies zu vermeiden.

Ein weiterer Test: Öffnen Sie F12 in Chrome oder Opera, gehen Sie zur Registerkarte „Netzwerk“ und dann zur Site, um die Zeit für jede Ressource anzuzeigen.