☰

Diagnostizieren einer 2-minütigen Verzögerung bei der HTTP-GET-Anforderung

tag-icon • tag-icon apache-2.2 networking http
Diagnostizieren einer 2-minütigen Verzögerung bei der HTTP-GET-Anforderung

Unter engen Umständen tritt beim Anfordern einer öffentlichen Webseite eine 100 % reproduzierbare Verzögerung von etwa 2 Minuten auf.

Die betreffende Seite:https://id.openjdk.java.net/console/login

Wenn man Client- (curl) und Server- (Apache) Protokolle zusammenfügt, sieht ein typischer Austausch folgendermaßen aus:

[client] 15:42:03.694959 => Send header, 96 bytes (0x60) 0000: GET /console/login HTTP/1.1
<DELAY HERE>
[server] [24/Feb/2015:22:44:26 +0000] "GET /console/login HTTP/1.1"
[client] 15:44:25.984150 <= Recv header, 17 bytes (0x11) 0000: HTTP/1.1 200 OK

(Die Stundenangaben sind aufgrund der Zeitzonen unterschiedlich und die Sekundenangaben können aufgrund nicht synchronisierter Uhren leicht abweichen.)

Dinge, die wichtig sind:

  • Der Client ist über meinen Heim-ISP verbunden und erhält eine öffentliche IP-Adresse in einem bestimmten Subnetz. Bei einer statischen IP-Adresse aus einem anderen Bereich ist das Problem behoben.
  • Die Seite „/console/login“ auf diesem Server wird angefordert. Es gibt keine Verzögerung, wenn ich „console/forgotPassword“ anfordere. Ich habe auf keinem anderen Server eine ähnliche Verzögerung bemerkt.

Dinge, die (scheinbar) nicht relevant sind:

  • Heimnetzwerk. Das Problem besteht weiterhin, unabhängig davon, wie der Client eine Verbindung zum Modem des ISPs herstellt und ob er unterschiedliche Modems ausprobiert.
  • Tageszeit/Überlastung. Die Verzögerung ist konstant, unabhängig davon, wann die Anfrage erfolgt.
  • DNS. Das Verhalten ist dasselbe, wenn ich eine IP-Adresse anstelle eines Hostnamens verwende.
  • HTTPS-Handshake. Dieser Teil der „curl“-Interaktion läuft immer ohne Verzögerung ab; und es gibt keine Verzögerung beim Zugriff auf „console/forgotPassword“ über HTTPS.
  • Client-Konfiguration. Reproduzierbar in mehreren Browsern und über „curl“ auf der Befehlszeile. Reproduzierbar auf mehreren Client-Systemen und Betriebssystemen.
  • Bild/Skript/usw. wird geladen. Die Verzögerung tritt bei Verwendung von „curl“ auf, das keine zusätzlichen Ressourcen erfordert.

Meine Frage: Was ist die plausibelste Erklärung dafür? Oder: Was muss ich als Nächstes tun, um es zu diagnostizieren?

Serverprobleme? So wie ich das verstehe,Apache-Protokollformat, die Verzögerung tritt aufVorder Server erhält die GET-Anforderung, aber ich wäre dankbar, wenn jemand bestätigen könnte, dass dies die richtige Methode zum Lesen der Protokollzeitstempel ist. Wenn ja, ist mir nicht klar, was der Server, wenn überhaupt, möglicherweise tut, bevor er die Anforderung an httpd weitergibt, oder was httpd möglicherweise tut, bevor er einen Zeitstempel erhält.

Netzwerkprobleme? Das Schwierige dabei ist, dass die Verzögerung anscheinend vom Nachrichteninhalt auf Anwendungsebene abhängt: der konkreten Seite, die angefordert wird. Und die sollte verschlüsselt sein. Die (Kleinstadt-)ISP-Administratoren sagen, dass sie keine Inhaltsfilterung durchführen ... Ich frage mich jedenfalls, ob mein IP-Adressbereich auf einem Knoten auf dem Weg auf einer schwarzen Liste oder so steht.

Antwort1

Ich hatte ein ähnliches Problem, das anscheinend durch ein Timeout der Xdebug-Remoteverbindung verursacht wurde. Wenn Ihre Seite PHP mit Xdebug verwendet, liegt das möglicherweise an Ihrem Problem.

Antwort2

Bei mir wird die Seite sofort geladen.
(Ich weiß, das spielt keine große Rolle, aber das ist meine Erfahrung damit.)

Von wo aus verbinden Sie sich? Es ist sehr wahrscheinlich, dass Sie auf eine Art DDOS-Schutz stoßen.

Möglicherweise steht Ihre IP-Adresse auf der schwarzen Liste oder wird zumindest genauer untersucht als alles andere.

verwandte Informationen