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

Ich habe das folgende Problem: Wenn ich eine Seite von Hackage abrufe , tritt eine große Verzögerung auf (ca. 30 Sekunden). Weitere Anfragen sind schnell, aber wenn ich innerhalb weniger 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 kein ähnliches Problem mit einer anderen Site (und ich besuche einige).
• Es scheint spezifisch für meinen ISP zu sein. Wenn ich mich von anderen Orten aus verbinde, gibt es kein solches Problem.

• Es hängt nicht mit DNS- oder Konnektivitätsproblemen zusammen. Tatsächlich wird die TCP-Verbindung schnell hergestellt. Es ist die HTTP-Antwort, die zu lange dauert, wie aus der folgenden Beispielpaketerfassung hervorgeht:

    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 einer einfachen passiert curl http://hackage.haskell.org/packages/hackage.html.

Es spielt auch keine Rolle, dass ich mich hinter einem Router befinde - es ist dasselbe, wenn ich mich direkt verbinde. Der Verbindungstyp ist PPPoE.

Ich habe das Problem auf 3 Computern reproduziert, auf denen Linux und Windows ausgeführt werden.

Wie kann man ein solches Problem diagnostizieren?

"30 Sekunden" und "nach zwei Minuten" sind für mich ein toter Wecker für ein DNS-Problem.

Wenn wir annehmen, dass die Seite, zu der Sie eine Verbindung herstellen, eine DNS-Abfrage für die Verbindungs-IP ausführt und diese Abfrage aus irgendeinem Grund fehlschlägt, sehen Sie Folgendes:

• Die TCP-Verbindung erfolgt fast sofort, da der Server keine DNS-Überprüfungen durchführt
• Das Skript führt eine DNS-Abfrage aus und bleibt hängen .
• Nach 30 Sekunden läuft das Standardzeitlimit 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 übergeben
• Nach Ablauf des negativen Zeitlimits (RFC 2308), dh zwischen 2 und 5 Minuten, wird bei der nächsten Verbindung eine neue Abfrage ausgegeben, und die Story wird wiederholt.

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

Sie können versuchen, eine DNS-Abfrage von einem anderen ISP (z. B. ISP2) auf der IP auszuführen, die Sie von ISP1 erhalten. Es ist kein 100% iger Beweis, aber ich erwarte eine hohe Wahrscheinlichkeit, dass die Abfrage 30 Sekunden dauert. Dies würde bedeuten, dass der ISP1-DNS-Server Probleme hat, Fragen von außen zu beantworten .

Eine andere mögliche Ursache könnte sein, dass das DNS von ISP1 aus irgendeinem (wahrscheinlich irrtümlichen) Grund von Hackage durch eine Firewall gesperrt wird (in meinem Outfit wäre der Grund "ein triggerfreudiger Netadmin", und ich könnte Namen nennen). In diesem Fall würde es Ihnen viel schwerer fallen, eine Diagnose zu stellen, da Tests über ISP2 nichts Ungewöhnliches zurückgeben würden. Sie müssten dies zu Hackage eskalieren.

Problem klingt wie ein Problem mit "MTU". Wenn Sie "Windows Setting MTU" googeln, sollten Sie eine Reihe von Antworten finden, die Ihnen zeigen, wie Sie diese Theorie testen und Ihre MTU entsprechend senken können. (Wenn Sie einen Linux-Router verwenden, könnte ich einen IPTables-Befehl erstellen, um dies dynamisch für Sie zu erledigen, aber ich "mache" Windows nicht.)

Ich habe Ihre Paketerfassung wiederholt, die an meinem Ende so aussieht:

Tatsächlich gibt es eine kleine nicht nachweisbare Pause, während das Paket wieder zusammengesetzt wird, aber nirgendwo so lange wie bei Ihnen. Ich habe auch alle IP-Adressen und den HTML-Code überprüft, und alles ist korrekt und sieht extrem einfach und harmlos aus.

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

Was Sie tun können, um die Möglichkeiten einzugrenzen, ist:

1. Versuchen Sie, eine Verbindung zu einem anderen haskell.org-Paket herzustellen, und prüfen Sie, ob es eine ähnliche Verzögerung gibt
2. Versuchen Sie, einen anderen Router von Ihrem Standort aus mit mehreren Computern zu verwenden, die unterschiedliche Netzwerkadapter verwenden
3. Versuchen Sie, jemanden in Ihrer Nähe, der denselben ISP verwendet, die Verbindung wiederholen zu lassen
4. Versuchen Sie, jemanden in Ihrer Nähe, der einen anderen ISP verwendet, die Verbindung wiederholen zu lassen
5. Wenn Sie mit diesen Informationen noch keine Erklärung für diese Verzögerung haben, wenden Sie sich an den Support Ihres Internetdienstanbieters, um zu erfahren, was los ist.

[BEARBEITEN]

Ich habe festgestellt, dass haskell.org ein ETag sendet. Dies erklärt, warum der erste Zugriff langsam ist, der nächste jedoch schnell: Solange der ETag gültig ist, stammt die Seite tatsächlich aus dem Cache Ihres Browsers.

Der seltsame Teil hier ist, warum der ISP beim Senden einer ETag-Anfrage nicht langsam ist. Eine Erklärung könnte sein, dass sie für eine begrenzte Zeit die Anfrage aus ihrem eigenen Cache erfüllen, anstatt zu haskell.org zu gehen.

Es klingt wie ein Serverproblem. Es wurde schnell für mich 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 geht, gibt es ein Problem zwischen haskell.org und Ihrem Haus.

Ein weiterer Test, den Sie ausführen können, besteht darin, eine Ressource in diesem Bereich zu finden, z. B. eine HTML-Datei, eine CSS-Datei oder eine XML-Datei, und diesen Link an einen HTML-Validator usw. zu übergeben. Wenn das Abrufen der Dienste von Drittanbietern lange dauert, ist dies der Fall ist ein Problem mit dem Server.

Ein weiterer Test: Leeren Sie Ihren DNS-Cache. Das Nachschlagen der IP-Adresse von haskell.org kann lange dauern. ipconfig /flushdns. Versuchen Sie auch ping hackage.haskell.orgüber die Befehlszeile zu sehen, wie lange es dauert, die IP-Adresse nachzuschlagen.

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, wechseln Sie zur Registerkarte Netzwerk und dann zur Website, um die Uhrzeit für jede Ressource anzuzeigen.