ICMP vs. TCP vs. UDP: der Unterschied, für Entwickler erklärt

Kurz gesagt

ICMP, TCP und UDP reisen alle in IP-Paketen, aber sie stellen unterschiedliche Fragen. ICMP-Echo (Ping) fragt: „Antwortet diese Adresse überhaupt?“, und braucht dafür keinen Port. TCP fragt: „Lauscht auf diesem Port ein Programm?“, und bekommt ein klares Ja, ein klares Nein oder Stille. UDP fragt von sich aus gar nichts: Sie erfahren nur dann etwas, wenn das Programm auf der anderen Seite beschließt zu antworten. Ein geschlossener Port antwortet bei allen dreien anders, und dieser Unterschied ist der Großteil dessen, was ein Netzwerk-Check Ihnen sagen kann und was nicht.

Eine Adresse, drei Arten anzuklopfen

Jedes Paket im Internet ist ein IP-Paket. IP weiß, wie man ein Paket von einer Adresse zu einer anderen bringt, und sonst nichts. Ein Byte im IP-Header sagt, was darin steckt, und die IANA führt die Liste: ICMP ist Protokoll 1, TCP Protokoll 6, UDP Protokoll 17. Die drei sind Geschwister: dieselben Adressen, dieselben Router und jeweils ein anderes Versprechen darüber, was passiert, sobald das Paket ankommt.

ICMP: Das Netzwerk spricht über sich selbst

ICMP ist kein Transportprotokoll. RFC 792 sagt klar, dass es zu IP selbst gehört: ICMP „is actually an integral part of IP, and must be implemented by every IP module.“ Es existiert, damit Router und Hosts über die Zustellung berichten können: Dieses Ziel ist nicht erreichbar, jenes Paket hat sein Hop-Limit aufgebraucht. ICMP-Nachrichten haben einen Typ und einen Code, aber keine Ports, denn über ICMP sitzt nichts, das auf sie wartet. Der IP-Stack verarbeitet sie selbst.

Die eine ICMP-Nachricht, die jeder schon einmal eingetippt hat, ist das Echo. ping sendet eine Echo-Anfrage (Typ 8, bei ICMPv6 Typ 128), und der Kernel des entfernten Hosts schickt eine Echo-Antwort zurück (Typ 0 bzw. 129). Dafür musste kein Programm laufen. RFC 1122, der Standard für die Anforderungen an Hosts, macht daraus eine Pflicht: „Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies.“

$ ping -c 1 uptimepage.dev
PING uptimepage.dev (204.168.246.94): 56 data bytes
64 bytes from 204.168.246.94: icmp_seq=0 ttl=50 time=96.069 ms

Eine Antwort beweist zwei Dinge: Die Adresse gehört zu einer Maschine, die eingeschaltet ist, und Pakete kommen hin und zurück. Die Round-Trip-Zeit bekommen Sie gratis dazu.

Mehr beweist ein Ping nicht. Er sagt nichts darüber, ob ein Webserver, eine Datenbank oder sonst etwas läuft, und ein Host kann jeden Ping beantworten, während jeder Dienst auf ihm tot ist.

Zwei Dinge an ICMP überraschen viele. Erstens: Keine Antwort heißt nicht ausgefallen. Firewalls verwerfen ICMP ständig. Bei AWS blockiert eine frisch angelegte Security Group es, und die Dokumentation sagt das auch: „To ping your instance, you must add one of the following inbound ICMP rules.“ Bevor Sie sich bei einem Host auf Ping verlassen, prüfen Sie, ob er überhaupt auf Ping antwortet.

Zweitens: Wer ICMP senden will, braucht Rechte. Ein Raw Socket braucht CAP_NET_RAW. Linux hat eine Alternative ohne Privilegien, den ICMP-Datagram-Socket, aber laut Kernel-Dokumentation ist der Standardwert von ping_group_range „1 0“, „meaning, that nobody (not even root) may create ping sockets.“ Docker öffnet diesen Bereich in jedem Container, der einen eigenen Network Namespace bekommt, und deshalb funktioniert Ping dort, ohne dass jemand darüber nachdenkt; ein Container mit --network host übernimmt stattdessen die Einstellung des Hosts. Wo die Grenzen davon liegen, habe ich mühsam gelernt: Dasselbe Prüfprogramm, das in Docker problemlos pingte, konnte auf einer Firecracker-microVM überhaupt keinen ICMP-Socket öffnen, bis ich ihm CAP_NET_RAW gab.

TCP: ein Versprechen vor dem ersten Byte

TCP ist eine Verbindung. Bevor eine der beiden Seiten auch nur ein Byte Daten sendet, führen die beiden Enden den Drei-Wege-Handshake aus: SYN, SYN-ACK, ACK. RFC 9293, der 2022 die Spezifikation von 1981 abgelöst hat, nennt ihn „the procedure used to establish a connection.“ Er kostet einen Round Trip, und dieser Round Trip bezahlt jedes Versprechen, das TCP danach gibt: Bytes kommen in der richtigen Reihenfolge an, verlorene Segmente werden erneut gesendet, der Empfänger wird nicht überflutet (Flusskontrolle), und das Netz wird nicht überflutet (Überlastkontrolle). Für das Programm sieht das aus wie ein Datenstrom. Sie schreiben auf der einen Seite Bytes und lesen auf der anderen dieselben Bytes in derselben Reihenfolge.

Darauf laufen HTTP/1.1, HTTP/2, TLS, SSH, PostgreSQL, MySQL, SMTP und das meiste, was Sie deployen.

Der Handshake taugt auch gut als Prüfung, denn ein SYN bekommt eine von drei Antworten:

1. SYN-ACK. Ein Programm lauscht. Der Verbindungsaufbau gelingt.
2. RST. Nichts lauscht. RFC 9293 legt fest, dass bei einer nicht existierenden Verbindung gilt: „a reset is sent in response to any incoming segment except another reset.“ Ihr Verbindungsaufbau scheitert sofort mit „connection refused“.
3. Nichts. Eine Firewall hat das SYN verworfen, oder der Host ist weg. Der Kernel versucht es immer wieder. Unter Linux ist tcp_syn_retries standardmäßig 6, und die Kernel-Dokumentation beziffert das endgültige Timeout eines aktiven Verbindungsversuchs auf 131 Sekunden.

Hier alle drei von meinem Laptop aus. Der letzte hat ein Limit von drei Sekunden; ohne das wartet macOS 75 Sekunden.

$ nc -zv uptimepage.dev 443
Connection to uptimepage.dev port 443 [tcp/https] succeeded!

$ nc -zv 127.0.0.1 9
nc: connectx to 127.0.0.1 port 9 (tcp) failed: Connection refused

$ nc -zv -G 3 uptimepage.dev 8443
nc: connectx to uptimepage.dev port 8443 (tcp) failed: Operation timed out

Die Dokumentation von Nmap gibt diesen Zuständen die Namen, die alle verwenden: open, closed und filtered.

Was ein erfolgreicher Handshake beweist: Ein Prozess hat auf diesem Port eine Verbindung angenommen. Nicht, dass er gesund ist. Eine Datenbank, die Verbindungen annimmt und dann jede Abfrage ablehnt, besteht trotzdem. Deshalb gehört ein TCP-Check zu allem, was keine HTTP-Schnittstelle hat (SSH, SMTP, ein Datenbank-Port), und ein HTTP-Check zu allem, was eine hat.

UDP: eine Nachricht, mehr nicht

UDP ist das kleinste Transportprotokoll, das es gibt. RFC 768 passt auf drei Seiten. Es ergänzt ein IP-Paket um Quellport, Zielport, Länge und Prüfsumme, insgesamt 8 Byte, und das ist alles. Im RFC heißt es: „The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed.“ Es gibt keinen Handshake, keine Bestätigung, keine Reihenfolge und keine Neuübertragung, und auch keine Überlastkontrolle. RFC 8085 stellt gleich zu Beginn fest, dass UDP „has no inherent congestion control mechanisms“, und erklärt dann auf mehr als fünfzig Seiten, wie Entwickler von Anwendungen ihre eigene einbauen.

Warum man es trotzdem nutzt: Latenz und Kontrolle. Eine DNS-Abfrage ist ein Paket hin und ein Paket zurück, ohne Handshake. RFC 1035 begrenzte eine DNS-Antwort über UDP auf 512 Byte. EDNS(0) (RFC 6891) erlaubte einem Client später, einen größeren Puffer anzukündigen, sodass heute die meisten Antworten in ein Datagramm passen; eine, die trotzdem nicht passt, wird gekürzt und mit gesetztem TC-Bit verschickt, und der Client fragt über TCP erneut (RFC 7766). NTP, der meiste Spieleverkehr und Echtzeitvideo nutzen UDP, weil ein verspätetes Paket weniger wert ist als das nächste, und deshalb wäre das Warten auf eine Neuübertragung der falsche Tausch. Und QUIC, das Transportprotokoll unter HTTP/3, baut komplett auf UDP auf. RFC 9000 hält fest, dass „QUIC packets are carried in UDP datagrams“, und nennt als Grund „to better facilitate deployment in existing systems and networks“. In der Praxis heißt das: QUIC erledigt Handshake, Verlustbehandlung und Überlastkontrolle selbst in der Anwendung und kann all das ändern, ohne darauf zu warten, dass jedes Betriebssystem seinen TCP-Stack aktualisiert.

$ dig @1.1.1.1 uptimepage.dev A +noall +answer +stats
; <<>> DiG 9.10.6 <<>> @1.1.1.1 uptimepage.dev A +noall +answer +stats
; (1 server found)
;; global options: +cmd
uptimepage.dev.		3600	IN	A	204.168.246.94
;; Query time: 125 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Sep 02 11:40:44 EEST 2026
;; MSG SIZE  rcvd: 59

Ein Datagramm hin, ein Datagramm zurück mit einer Antwort von 59 Byte (67 Byte mit dem UDP-Header), und davor kein Handshake. Über TCP kostet dieselbe Abfrage zwei Round Trips, einen für den Handshake und einen für die Abfrage, und deshalb nutzt DNS standardmäßig UDP.

Jetzt zum Problem beim Prüfen. Sie schicken ein UDP-Datagramm an einen Port. Was kommt zurück?

Wenn dort nichts lauscht, sollte der IP-Stack des Hosts mit einem ICMP-Fehler antworten. Wieder RFC 1122: „If a datagram arrives addressed to a UDP port for which there is no pending LISTEN call, UDP SHOULD send an ICMP Port Unreachable message.“ „Geschlossen“ lässt sich also erkennen, und es ist ICMP, das es erkennt.

Wenn etwas lauscht, bekommen Sie, was auch immer dieses Programm senden will. Ein DNS-Server sendet eine Antwort. Ein Syslog-Empfänger sendet nie etwas. Stille heißt also offen, gefiltert oder tot, und Nmap hat dafür einen eigenen Zustand, open|filtered. Die Dokumentation erklärt: „This occurs for scan types in which open ports give no response.“

Die Folge: Einen allgemeinen „UDP-Port-Check“ gibt es nicht. Um einen UDP-Dienst zu prüfen, müssen Sie sein Protokoll sprechen: eine echte DNS-Abfrage senden und die Antwort lesen, eine echte NTP-Anfrage senden und den Zeitstempel prüfen. Deshalb haben Überwachungstools einen DNS-Check und einen TCP-Check, aber selten einen UDP-Check.

Dieselbe geschlossene Tür, drei Antworten

Lesen Sie die Tabelle spaltenweise. TCP ist das einzige der drei, bei dem „geschlossen“ und „gefiltert“ von sich aus unterschiedlich aussehen, UDP leiht sich ICMP, um „geschlossen“ zu sagen, und ICMP sieht überhaupt keine Ports. Stille ist bei allen dreien die mehrdeutige Antwort, und deshalb sollte kein Check aus einer einzigen stillen Prüfung von einem einzigen Ort auf „ausgefallen“ schließen. Zwei oder drei Fehlschläge hintereinander, gesehen aus mehr als einem Netz, sind die ehrliche Messlatte. Mehr dazu habe ich unter Fehlalarme bei der Uptime-Überwachung abstellen geschrieben.

Was das für einen Monitor bedeutet

Ich entwickle Uptimepage, und seine Check-Typen bilden genau diese Fragen ab. So wird aus der Theorie eine Konfiguration.

• Ping sendet ein ICMP-Echo mit 32 Byte Nutzdaten, der Größe, die ping unter Windows verwendet (ping unter Unix sendet 56, wie die Ausgabe oben zeigt), damit Middleboxes gewöhnlichen Diagnoseverkehr sehen. Er probiert die erste IPv4- und die erste IPv6-Adresse des Hosts und teilt das Timeout zwischen ihnen auf. Stille über das gesamte Zeitbudget gilt als ausgefallen, denn ein Echo kann nicht ablehnen. Nutzen Sie ihn für Router, Gateways und Hosts, die keinen Dienst anbieten.
• TCP führt den Handshake aus und schließt die Verbindung wieder. Angenommen gilt als verfügbar, abgelehnt als ausgefallen, und ein Timeout wird als Fehler mit der verstrichenen Zeit erfasst. Für Alarme zählt ein Fehler genau wie ein Ausfall als fehlgeschlagener Check, ein Port hinter einer Firewall öffnet also trotzdem eine Störung, sobald die Bestätigungsschwelle erreicht ist. Nutzen Sie ihn für Datenbanken, Broker, SSH und Mail, wo „ein Prozess hat die Verbindung angenommen“ das Äußerste ist, was Sie von außen feststellen können.
• DNS sendet eine echte Abfrage und prüft den Inhalt der Antwort. Damit ist er der UDP-Check für den einen UDP-Dienst, von dem fast alle abhängen. Er kann einen bestimmten Resolver ansprechen, was wichtig ist, wenn Sie die Sicht dieses Servers wollen und nicht die Ihres Caches.
• HTTP ist ein TCP-Handshake, dann TLS, dann eine Anfrage, und er erfasst die Zeit jeder Phase: DNS, Verbindungsaufbau, TLS und Time-to-First-Byte. Die Phase des Verbindungsaufbaus ist der Handshake aus diesem Artikel, gemessen innerhalb eines größeren Checks.

Wählen Sie den Check, der die Frage stellt, die Sie interessiert, und denken Sie daran, was jeder einzelne nicht sehen kann. Eine ausführlichere Version dieser Entscheidung steht in der Dokumentation der Monitor-Typen, und eine als Geschichte erzählte in dem Rätsel der „ausgefallenen“ Website.

Häufige Fragen

Ist ICMP ein Transportprotokoll wie TCP und UDP?

Nein. ICMP ist ein Steuerprotokoll, das zu IP selbst gehört, und RFC 792 schreibt vor, dass jedes IP-Modul es implementieren muss. Es hat keine Ports und transportiert keine Anwendungsdaten. Es berichtet über die Zustellung: Ein Ziel ist nicht erreichbar, ein Paket hat sein Hop-Limit aufgebraucht, dazu kommt das Echo-Paar, das Ping verwendet.

Warum funktioniert Ping, obwohl meine Website ausgefallen ist?

Weil Ping nur beweist, dass der IP-Stack des Hosts antwortet und dass Pakete hin und zurück gelangen. Die Echo-Antwort sendet der Kernel, es muss also weder ein Webserver noch eine Datenbank noch sonst ein Programm laufen. Ein Host kann jeden Ping beantworten, während jeder Dienst auf ihm tot ist.

Warum scheitert ein geschlossener TCP-Port sofort, während einer hinter einer Firewall hängt?

Ein geschlossener Port schickt einen TCP-Reset zurück, der Verbindungsaufbau scheitert also sofort mit „connection refused“. Eine Firewall, die das SYN verwirft, schickt nichts, und der Kernel versucht es immer wieder. Unter Linux sind es standardmäßig sechs Wiederholungen, und die Kernel-Dokumentation beziffert das endgültige Timeout auf 131 Sekunden.

Kann ich einen UDP-Port so prüfen wie einen TCP-Port?

Nein, denn ein offener UDP-Port schickt nichts zurück, es sei denn, das Programm dahinter antwortet von sich aus. Ein geschlossener Port lässt sich erkennen, weil der Host mit der ICMP-Meldung „Port Unreachable“ antworten sollte, aber offen und gefiltert sehen beide wie Stille aus. Um einen UDP-Dienst zu prüfen, müssen Sie sein Protokoll sprechen, zum Beispiel eine echte DNS-Abfrage senden.

Wenn UDP unzuverlässig ist, warum nutzt HTTP/3 es dann?

UDP selbst gibt keine Zustellgarantie, QUIC bringt seine eigene obendrauf mit. QUIC läuft in UDP-Datagrammen und erledigt Handshake, Neuübertragung und Überlastkontrolle selbst in der Anwendung. So kann es sich weiterentwickeln, ohne darauf zu warten, dass jedes Betriebssystem seinen TCP-Stack aktualisiert.

Quellen

• IETF, RFC 792: Internet Control Message Protocol, September 1981.
• IETF, RFC 4443: ICMPv6 for the Internet Protocol Version 6, März 2006.
• IETF, RFC 768: User Datagram Protocol, August 1980.
• IETF, RFC 9293: Transmission Control Protocol, August 2022.
• IETF, RFC 1122: Requirements for Internet Hosts, Communication Layers, Oktober 1989. Abschnitte 3.2.2.6 und 4.1.3.1.
• IETF, RFC 8085: UDP Usage Guidelines, März 2017.
• IETF, RFC 1035: Domain Names, Implementation and Specification, November 1987. Abschnitt 4.2.1.
• IETF, RFC 6891: Extension Mechanisms for DNS (EDNS(0)), April 2013.
• IETF, RFC 7766: DNS Transport over TCP, Implementation Requirements, März 2016.
• IETF, RFC 9000: QUIC, a UDP-Based Multiplexed and Secure Transport, Mai 2021.
• IANA, Assigned Internet Protocol Numbers.
• Linux-Kernel, Dokumentation zu IP-sysctl, tcp_syn_retries und ping_group_range.
• Nmap, Port scanning basics, die sechs Port-Zustände.
• Amazon Web Services, Security group rules for different use cases, Regeln für Ping/ICMP.