Header

Kurz: Der Steuerdatenblock am Anfang eines Datenpakets, der Metainformationen enthält — z. B. Absender, Empfänger, Protokolltyp, Prüfsumme.

Genauer: Jede Netzwerkschicht fügt beim Versenden ihren eigenen Header hinzu (Kapselung): Ein HTTP-Request steckt in einem TCP-Segment mit eigenem Header, das wiederum in einem IP-Paket mit eigenem Header steckt. Der Empfänger liest die Header Schicht für Schicht von außen nach innen aus.

Im Detail

Kapselung als Matroschka-Prinzip

Die Kapselung durch Header lässt sich am besten als Matroschka-Puppe verstehen: Jede Schicht des OSI-Modells fügt beim Versenden ihren eigenen Header VOR die Nutzdaten der darüberliegenden Schicht hinzu, ohne deren Inhalt zu verändern oder zu interpretieren — für die Ethernet-Schicht sind ein TCP-Header und die HTTP-Nutzdaten darin einfach undurchsichtige Bytes:

Ethernet-Header | IP-Header | TCP-Header | HTTP-Header | eigentliche Webseiten-Daten

Jede Schicht “kennt” nur ihren eigenen Header-Typ und reicht alles Übrige unverändert als reine Nutzlast weiter. Das ist der Grund, warum sich Netzwerk-Protokolle so flexibel kombinieren lassen: TCP ist es egal, ob darin HTTP, FTP oder ein komplett proprietäres Anwendungsprotokoll steckt — es transportiert einfach Bytes.

De-Kapselung beim Empfang

Beim Empfang läuft der Prozess genau umgekehrt: Jedes Gerät auf dem Weg liest nur den für seine eigene Schicht relevanten Header, entfernt ihn (De-Kapselung) und reicht den Rest an die nächsthöhere Schicht weiter. Ein Switch arbeitet auf Schicht 2 und liest deshalb nur den Ethernet-Header (um zu wissen, an welchen Port er weiterleiten muss), ein Router arbeitet auf Schicht 3 und liest zusätzlich den IP-Header, und erst der eigentliche Zielserver liest die komplette Kette bis zum HTTP-Header und den eigentlichen Nutzdaten durch. Zwischenstationen auf dem Weg (Router, Switches) interessieren sich grundsätzlich nur für so viele Header-Schichten, wie sie für ihre eigene Weiterleitungsentscheidung brauchen — alles Weitere bleibt für sie unangetastete Nutzlast.

Typische Header-Felder

Trotz unterschiedlicher Protokolle tauchen in fast jedem Header dieselben Grundbausteine auf: Adressierung (Quell-/Ziel-IP-Adresse bzw. MAC-Adresse, je nach Schicht), Protokolltyp (ein Feld, das verrät, welches Protokoll in der Nutzlast als Nächstes folgt — dadurch weiß der Empfänger, wie er die eingepackten Daten weiter interpretieren muss), Längenangabe (wie viele Bytes Nutzdaten folgen, wichtig um zu erkennen, wo ein Paket endet) und häufig eine Prüfsumme zur Fehlererkennung, mit der beschädigte Übertragungen erkannt werden können.

Overhead durch verschachtelte Header

Der Overhead durch diese vielen verschachtelten Header ist ein Grund, warum die tatsächlich nutzbare Bandbreite einer Verbindung immer etwas unter der reinen Leitungskapazität liegt — jeder Header verbraucht Platz, der nicht für Nutzdaten zur Verfügung steht. Bei sehr kleinen Nutzdatenmengen (z. B. einzelne Sensor-Messwerte in IoT-Anwendungen) kann der Header-Overhead sogar größer sein als die eigentliche Nutzlast, weshalb es für solche Szenarien eigene, besonders schlanke Protokolle gibt.

Siehe auch: UDP-Header, Footer, Paket, OSI-Modell