Ping, Jitter und 0 ms: HTTP-Latenz richtig verstehen
Ping und Jitter richtig lesen: 0 ms, fehlende Zeitwerte und wiederverwendete Verbindungen verstehen. Warum HTTP/3 QUIC statt TCP nutzt und was der Test misst.
Median, Spannweite und Jitter gemeinsam lesen
Das Tool misst nach einer Aufwärmanfrage acht aufeinanderfolgende HTTP-Antwortzeiten. Der Median liegt in der Mitte der sortierten Messwerte, die Spannweite zeigt kleinsten und größten Wert. Jitter ist hier die mittlere absolute Änderung zwischen benachbarten Messwerten, keine Messung auf Paketebene.
Rechenbeispiel mit acht Messwerten: 20, 30, 10, 40, 20, 30, 10, 40 ms. Sortiert liegen 20 und 30 in der Mitte; der Median beträgt daher 25 ms. Die sieben aufeinanderfolgenden Änderungen ergeben insgesamt 140 ms; geteilt durch sieben sind das 20 ms Schwankung. Die Spannweite reicht von 10 bis 40 ms. Dies sind Beispielwerte für die Berechnung, keine Messungen einer Besucherverbindung.
Was 0 ms oder fehlende Zeitwerte bedeuten
Antwortzeiten und die Aufschlüsselung des Verbindungsaufbaus sind getrennte Messungen. Eine wiederverwendete Verbindung kann neue Anfragen ohne weitere DNS-Abfrage oder neuen Handshake übertragen.
| Anzeige | Bedeutung | Nächster Schritt |
|---|---|---|
| Aus dem Cache oder Verbindung wiederverwendet | Für diese Anfrage wurde keine neue DNS-Phase gemessen | Nicht als Abfragegeschwindigkeit des DNS-Resolvers verstehen |
| Kein neuer Verbindungsaufbau (Verbindung wiederverwendet) | Der Resource-Timing-Eintrag enthält kein neues Aufbauintervall | Antwortzeiten vergleichen, den Aufbau nicht als Umlaufzeit deuten |
| TCP nicht verwendet (HTTP/3 · QUIC) | Die Anfrage nutzte HTTP/3 mit QUIC als Transport | QUIC-RTT lesen, sofern vom Zugangsknoten gemeldet |
| Nicht gemeldet | Der erforderliche Zeitwert fehlt oder ist unbrauchbar | Unbekannt lassen, kein gemessener Nullwert |
| 0 ms gemeldet (Genauigkeit unbekannt) | Der Zugangsknoten lieferte null ohne ausreichende Genauigkeitsangabe | Daraus weder verzögerungsfreie Übertragung noch Wiederverwendung ableiten |
WLAN, mobile Daten und VPN fair vergleichen
Für einen kleinen Vergleich dasselbe Gerät und denselben Browser verwenden. Das Ergebnis ist eine Beobachtung zur Fehlersuche, kein kalibrierter Leistungstest des gesamten Internetanschlusses.
- Downloads, Streams und anderen umfangreichen Datenverkehr pausieren. Den Latenztest starten und Median, Spannweite und Schwankung notieren.
- Nur das zu vergleichende Netzwerk oder die VPN-Konfiguration ändern, die Stabilisierung abwarten und erneut messen.
- Mehrere Durchläufe und Testzeiten notieren. Ändert sich der beobachtete Zugangsknoten oder Pfad, das Ergebnis als Vergleich der vollständigen Pfade werten.
- Den TLS-Check für HTTP-Protokoll und gemeldete RTT nutzen. Diese Metadaten gehören zu einer eigenen Prüfanfrage und müssen nicht einem Latenzmesswert entsprechen.
Ein aussagekräftiges Vergleichsprotokoll führen
Je Durchlauf Zeit, Netzwerkbezeichnung, VPN-Einstellung, Median, Spannweite und Schwankung notieren. Beim VPN-Vergleich WLAN und Gerät unverändert lassen. Beim Vergleich von WLAN mit mobilen Daten die VPN-Einstellung beibehalten. Ein höherer Median nach zwei gleichzeitigen Änderungen zeigt nicht, welche davon die Ursache war.
Vergleiche das Rechenbeispiel mit acht Werten von genau 25 ms: Beide Mediane betragen 25 ms, doch die konstante Folge hat eine Spannweite von 25–25 ms und 0 ms aufeinanderfolgende Schwankung. Gleiche Mediane können sehr unterschiedliche Gleichmäßigkeit verdecken. Diese synthetischen Beispiele zeigen nur die Berechnung; reale Browser-Zeitplanung fügt Rauschen hinzu. Wiederhole auffällige Durchläufe und notiere die Aufbauhinweise. Addiere die Edge-RTT nicht zur gesamten Browser-Anfragezeit: Die Werte können sich überschneiden und aus verschiedenen Anfragen stammen.
Warum Browser-Ping und Spiel-Ping abweichen
Eine HTTP-Anfrage enthält neben Netzwerkzeit auch Browser- und Serverarbeit. Ein Spiel kommuniziert mit einem anderen Endpunkt und nutzt gegebenenfalls ein anderes Protokoll. Ein nahegelegenes Cloudflare-Ergebnis sagt die Latenz zu einem bestimmten Spielserver nicht voraus. Das Tool misst weder ICMP-Ping noch Paketverlust oder Downloadgeschwindigkeit.
Für einen eigenen Spielserver auf der Gaming-IP-Seite eine Adresse vorbereiten und WAN-Hinweise prüfen. Bei Verzögerungen im Spiel zusätzlich dessen Netzwerkstatistiken ansehen und bei Auftreten des Problems erneut testen. CGNAT-Hinweise und hohe Latenz sind getrennte Beobachtungen. Eine beweist nicht die andere.
Häufige Fragen
Warum steht bei TCP-RTT mit HTTP/3 „nicht verwendet“?
HTTP/3 nutzt QUIC statt TCP. Das TCP-Feld gilt für diese Anfrage nicht. IPNixa zeigt QUIC-RTT separat, sofern der Zugangsknoten sie meldet.
Bedeutet 0 ms, dass die Verbindung keine Verzögerung hat?
Nein. Bei wiederverwendeten Verbindungen können Aufbauphasen entfallen. Ein Server kann auch den Wert 0 melden, ohne dass die Genauigkeit für eine weitere Einordnung ausreicht. Diese Fälle sind getrennt von fehlenden Werten gekennzeichnet.
Ist Browserlatenz dasselbe wie ICMP-Ping?
Nein. Die Messwerte erfassen kleine HTTP-Anfragen an IPNixa einschließlich Browser- und Endpunktverarbeitung. ICMP, Spiele und andere Ziele verwenden andere Messungen.
Erkennt dieser Test Paketverlust oder Bufferbloat?
Nein. Acht kleine HTTP-Anfragen messen weder Paketverlust noch Latenz unter kontrollierter Upload- oder Downloadlast. Dafür ist ein speziell ausgelegtes Tool nötig.