Echo Request

Kurz: Die ausgehende ICMP-Nachricht bei einem Ping — fragt das Zielgerät, ob es erreichbar ist und antworten kann.

Genauer: Ein Echo Request enthält eine ID und Sequenznummer, die das Zielgerät in seiner Echo Reply unverändert zurückschickt — so lässt sich die Antwort eindeutig dem ursprünglichen Request zuordnen, auch wenn mehrere Pings gleichzeitig laufen.

Im Detail

Grundlage des ping-Befehls

Ein Echo Request ist ICMP-Typ 8 und Grundlage des ping-Befehls, den es in praktisch identischer Form auf jedem Betriebssystem gibt — eines der ältesten und am weitesten verbreiteten Netzwerk-Diagnosewerkzeuge überhaupt:

$ ping -c 4 8.8.8.8
PING 8.8.8.8: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=14.1 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=13.9 ms

Der Name “Ping” ist eine bewusste Anspielung auf die Sonar-Technik in der U-Boot-Ortung — ein Signal wird ausgesendet, und aus dem Echo lässt sich auf die Entfernung (hier: die Netzwerk-Latenz) schließen.

Payload und MTU-Diagnose

Neben ID und Sequenznummer kann ein Echo Request auch beliebige Nutzdaten (Payload) mitschicken, die das Zielgerät unverändert zurückspiegeln muss. Größere Pings (per Flag, z. B. ping -s 1472) testen damit gleichzeitig, ob auch größere Pakete entlang des gesamten Wegs ohne Fragmentierungsprobleme durchkommen — relevant für die sogenannte MTU-Diagnose (Maximum Transmission Unit), bei der iterativ die größte Paketgröße ermittelt wird, die eine Route ohne Aufteilung in kleinere Fragmente durchqueren kann. Kombiniert mit dem “Don’t Fragment”-Flag lässt sich damit gezielt herausfinden, an welcher Stelle im Übertragungsweg ein zu kleiner MTU-Wert eines Zwischengeräts Probleme verursacht.

Was ping NICHT testet

Wichtig für die Problemdiagnose: Ein Echo Request testet ausschließlich die reine Netzwerk-Erreichbarkeit auf ICMP-Ebene, nicht ob ein bestimmter Dienst auf dem Zielgerät tatsächlich läuft. Ein Server kann problemlos auf Ping antworten und trotzdem keinen funktionierenden Webserver haben (weil der entsprechende Dienst abgestürzt ist), oder umgekehrt: Manche gut abgesicherten Server blockieren ICMP komplett, laufen aber völlig normal und beantworten HTTP-Anfragen anstandslos. “Der Server pingt nicht” ist deshalb allein kein verlässlicher Beweis für einen echten Ausfall — es zeigt nur, dass ICMP-Antworten ausbleiben, aus welchem Grund auch immer.

Praxis: Warum viele Server nicht antworten

Viele öffentliche Server blockieren Echo Requests inzwischen bewusst per Firewall-Regel, um sich vor automatisierten Netzwerk-Scans zu verstecken und Angreifern die erste, einfachste Erkundungsmethode (“ist da überhaupt was erreichbar?”) zu erschweren. Das ist einer der Gründe, warum manche moderneren Monitoring- und Uptime-Tools nicht primär auf Ping setzen, sondern direkt Anwendungsebenen-Checks durchführen (z. B. einen echten HTTP-Request mit erwartetem Statuscode).

Siehe auch: Echo Reply, Ping, ICMP, Problemdiagnose