Eine Anfrage, mehrere klar getrennte Fragen.
Du öffnest eine Website. Der Browser kennt eine URL, der Rechner eine Route und der Netzwerkadapter ein Übertragungsverfahren. Keiner dieser Begriffe ersetzt die anderen. HTTP beschreibt die Anfrage an den Webdienst; IP ermöglicht die Weiterleitung zwischen Netzen; Ethernet bringt Daten auf einem lokalen Link zum nächsten Empfänger. Schichtenmodelle helfen, diese Aufgaben auseinanderzuhalten. Sie sind besonders nützlich, wenn eine Verbindung scheitert: Eine funktionierende Kabelverbindung erklärt noch nicht, warum ein Server einen HTTP-Fehler meldet.
Eine Schicht bietet der darüberliegenden Ebene einen Dienst und verwendet die Ebene darunter. Vereinfacht übergibt eine Anwendung Daten an einen Transportdienst, ohne selbst elektrische Signalpegel festzulegen. Zusammengehörige Protokollfunktionen auf verschiedenen Rechnern folgen gemeinsamen Regeln. Ihre tatsächlichen Nachrichten reisen trotzdem durch den darunterliegenden Stack und die beteiligten Netze. Die gedachte horizontale Beziehung zwischen zwei HTTP-Instanzen ist deshalb keine zusätzliche direkte Leitung.
Mit diesem Artikel kannst du sieben OSI-Schichten benennen, sie auf das TCP/IP-Modell abbilden und eine Nachricht schrittweise einpacken. Die wichtigste Leitfrage lautet dabei: Welche Information braucht diese Funktion, und wie weit gilt sie? Namen, Ports, IP-Adressen und MAC-Adressen haben unterschiedliche Aufgaben und Reichweiten. Die Grundlagen zu IPv4 und Ethernet und ARP ergänzen die konkreten Adressbeispiele.
Die sieben OSI-Schichten beschreiben Verantwortlichkeiten.
Das OSI-Referenzmodell unterscheidet von unten nach oben sieben Ebenen. Die Nummerierung ist eine gemeinsame Sprache für Aufgaben, kein Beweis für sieben getrennte Programme in jedem Gerät. Die offizielle Grundlage ist ITU-T X.200. Für unseren Internetalltag verwenden wir die Begriffe als Orientierung, nicht als Behauptung, moderne Internetprotokolle seien vollständig aus dem OSI-Protokollstapel entstanden.
- Bitübertragung, Physical Layer: Signale und Übertragungsmedium, beispielsweise elektrische oder optische Ethernet-Übertragung. Hier geht es um die physische Darstellung von Bits und um die Verbindungseigenschaften.
- Sicherung, Data Link Layer: Übertragung von Frames über den jeweiligen Link beziehungsweise das lokale gebrückte Netz. Ethernet-MAC-Adressen und die Fehlererkennung eines Frames gehören in diesen Zusammenhang.
- Vermittlung, Network Layer: Adressierung und Weiterleitung über Netzgrenzen. IP-Pakete tragen Quell- und Ziel-IP; Router bestimmen ihren nächsten Weiterleitungsschritt.
- Transport, Transport Layer: Kommunikation zwischen Endpunkten von Anwendungen. TCP liefert einen geordneten Bytestrom; UDP transportiert Datagramme. Ports unterscheiden die beteiligten Transportendpunkte.
- Sitzung, Session Layer: Organisation und Steuerung von Dialogen, etwa die Koordination einer länger laufenden Kommunikation. Eine Browser-Anmeldesitzung lässt sich nicht allein wegen ihres Namens hier vollständig einsortieren.
- Darstellung, Presentation Layer: Vereinbarte Darstellung und Umwandlung von Daten. Codierung, Serialisierung und kryptografische Verarbeitung haben einen Bezug zu diesen Aufgaben; reale Bibliotheken verteilen sie unterschiedlich.
- Anwendung, Application Layer: Netzwerkdienste für Anwendungen. HTTP formuliert beispielsweise Anforderungen und Antworten, DNS stellt Namensinformationen bereit. Die grafische Browseroberfläche selbst ist kein Netzwerkprotokoll.
Ein Merksatz kann die Reihenfolge erleichtern. Für das Verständnis ist jedoch wichtiger, konkrete Entscheidungen zuzuordnen: Ein falscher Zielport ist etwas anderes als ein falsches Subnetz. Beide können denselben sichtbaren Effekt haben, nämlich einen fehlgeschlagenen Zugriff. „Layer 4“ benennt dann eine Untersuchungsrichtung und noch keine nachgewiesene Ursache.
TCP/IP fasst Aufgaben anders zusammen.
Die Internetarchitektur beschreibt häufig vier Ebenen: Anwendung, Transport, Internet und Link. Diese Einteilung findet sich in RFC 1122, Abschnitt 1.1.3. Die Anwendungsebene bündelt dabei Aufgaben, die das OSI-Modell auf die oberen drei Ebenen verteilt. Die Link-Ebene umfasst die Kommunikation mit dem direkt angeschlossenen Netz einschließlich der notwendigen unteren Übertragungsfunktionen.
In Lehrbüchern begegnet dir außerdem ein Fünfschichtenmodell: Anwendung, Transport, Vermittlung beziehungsweise Internet, Sicherung und Bitübertragung. Es trennt die untere Link-Ebene für die Lehre wieder auf. Vier und fünf sind deshalb nicht automatisch widersprüchliche Antworten. Nenne bei einer Prüfung oder Dokumentation immer die verwendete Darstellung und ihre Begriffe. Aus einer zusätzlichen gezeichneten Ebene entsteht weder ein neues Protokoll noch ein zusätzlicher Header.
Typische Zuordnungen lauten HTTP und DNS zur Anwendung, TCP und UDP zum Transport, IPv4 und IPv6 zur Internetebene sowie Ethernet zur Link-Ebene. Ethernet umfasst dabei MAC- und physische Verfahren. ARP verbindet im IPv4-Ethernet den gewählten nächsten IP-Nachbarn mit dessen Link-Adresse; es wird direkt in Ethernet übertragen. Eine starre Behauptung, ARP müsse vollständig einer einzigen OSI-Schicht entsprechen, verdeckt diese verbindende Aufgabe.
Nutzdaten einer Ebene enthalten die Struktur der nächsten.
Ein Header enthält Steuerinformationen für ein Protokoll. Der verbleibende übergebene Inhalt heißt aus dessen Sicht Nutzlast oder Payload. „Nutzdaten“ bedeutet dabei nicht zwingend den für Menschen sichtbaren Text: Für IP kann ein TCP-Header bereits zur Nutzlast gehören. Ethernet transportiert wiederum den IP-Header samt IP-Nutzlast. Ein Protokoll kann zusätzlich einen Trailer am Ende verwenden; beim Ethernet-Frame steht dort die Frame Check Sequence zur Fehlererkennung.
Für den Hauptfall nehmen wir eine bereits aufgebaute TCP-Verbindung über IPv4 und Ethernet an. Namensauflösung und Nachbarauflösung sind schon erledigt; Fragmentierung, Tunnel und Hardware-Offloading lassen wir zunächst aus. Eine kleine unverschlüsselte HTTP/1.1-Anfrage dient nur dazu, die sichtbaren Daten zu erklären. Bei einer echten HTTPS-Verbindung würden in diesem Schritt TLS-geschützte Daten über TCP laufen.
TCP-Segment, IP-Paket und Ethernet-Frame benennen unterschiedliche Protokolleinheiten. Ein UDP-Header mit seiner Nutzlast heißt UDP-Datagramm. „Paket“ wird umgangssprachlich breiter gebraucht; in einer präzisen Erklärung sollte immer klar sein, welche Ebene gemeint ist. Auch IP verwendet den Begriff Datagramm. Ein QUIC-Paket ist wiederum eine QUIC-Einheit innerhalb einer UDP-Nutzlast; gleich klingende Wörter machen die Ebenen nicht identisch.
Die Grenzen einer Anwendungsausgabe müssen nicht den Grenzen einzelner TCP-Segmente entsprechen. TCP ist ein Bytestrom: Ein Schreibaufruf kann verteilt, mehrere kleine Schreibaufrufe können zusammen übertragen werden. Ebenso entspricht eine große Website nicht einem einzigen Ethernet-Frame. MTU, Transportlogik und weitere Mechanismen beeinflussen die Aufteilung. Beim Empfänger entsteht der geordnete TCP-Bytestrom wieder; erst die Anwendung interpretiert daraus ihre Nachrichten.
Was ergänzt jede Ebene konkret?
Im vereinfachten Lab sendet der Client 192.168.10.20 an den simulierten Webserver 198.51.100.80. Die Serveradresse stammt aus einem Dokumentationsbereich und ist kein tatsächliches Auflösungsergebnis. TCP verwendet beispielhaft Quellport 51514 und Zielport 80. Die Ports stehen im TCP-Header, die beiden IP-Adressen im IP-Header. Für das entfernte Ziel trägt der erste Ethernet-Frame als Ziel-MAC die Adresse des lokalen Gateways.
Ein Layer-2-Switch leitet diesen Frame innerhalb des betreffenden VLANs weiter. Der Router entfernt die eingehende Link-Kapselung, entscheidet über den IP-Weg und erzeugt für den Ausgangslink eine passende neue Link-Kapselung. Auf einem weiteren Ethernet-Link stehen andere Quell- und Ziel-MAC-Adressen. Ohne Adressübersetzung bleibt die Ziel-IP die des Webservers. Das IP-Paket ist dennoch nicht in jedem Bit unverändert: Ein IPv4-Router vermindert die TTL und aktualisiert damit die IPv4-Headerprüfsumme.
Am Ziel werden die Protokollinformationen passend ausgewertet: Ethernet ordnet den Inhalt über seinen Typ zu, IP erkennt das darüberliegende Protokoll, TCP verarbeitet Verbindung und Bytefolge. Die Anwendung liest schließlich die Anfrage. Diese Entkapselung ist das Gegenstück zum Einpacken. Sie bedeutet nicht, dass jeder Zwischenrouter den HTTP-Inhalt verstehen muss. Ein Proxy, eine Firewall oder eine NAT-Funktion kann jedoch zusätzliche Ebenen verarbeiten.
Reale Stacks passen nicht in sieben starre Schubladen.
HTTPS über HTTP/2 nutzt typischerweise HTTP/2, TLS und TCP. TLS stellt Schutzfunktionen zwischen Anwendung und TCP bereit; seine Zuordnung zu OSI-Darstellung oder Sitzung ist eine didaktische Annäherung. HTTP/3 nutzt dagegen QUIC über UDP. QUIC stellt selbst Transportfunktionen wie zuverlässige Streams bereit und integriert den TLS-Handshake. UDP bleibt die äußere Transportschnittstelle, auf der QUIC seine Pakete verschickt. QUIC ist deshalb nicht bloß eine unzuverlässige HTTP-Anwendung.
Die Protokollfolge lässt sich kompakt gegenüberstellen: HTTP/2 → TLS → TCP → IP → Ethernet beziehungsweise HTTP/3 → QUIC → UDP → IP → Ethernet. Die Pfeile bedeuten „wird getragen von“. Sie behaupten nicht, dass jede Schicht genau einen Header oder eine Betriebssystemkomponente besitzt. TCP, UDP und QUIC erklärt die Unterschiede genauer; der vollständige Webseitenaufruf verbindet die Abläufe.
Auch Geräte sind keine reinen Layer-Nummern. Ein gewöhnlicher Ethernet-Switch arbeitet für die Datenweiterleitung hauptsächlich auf Layer 2; seine Verwaltungsoberfläche verwendet trotzdem IP und Anwendungsprotokolle. Ein Layer-3-Switch routet zusätzlich. Eine Netzwerkkarte übernimmt physische und Link-Aufgaben sowie je nach Funktion weitere Verarbeitung. Ein Heimrouter vereint oft Switch, Router, Firewall, WLAN und NAT in einem Gehäuse. Benenne deshalb die gerade betrachtete Funktion.
Bei der Fehlersuche prüfst du schrittweise Beobachtungen: Link vorhanden? Adresse und Route plausibel? Nachbar erreichbar? Transportverbindung möglich? Erwartete Anwendungsantwort? Ein erfolgreicher Ping belegt weder einen offenen TCP-Port noch einen korrekten HTTP-Dienst. Umgekehrt kann ein Webdienst trotz gefilterter Echo-Anfragen arbeiten. Das Modell ordnet Tests, ersetzt aber ihre Interpretation nicht.
Drei ähnlich aussehende Fehler verlangen andere Belege.
Erster Fall: Der Adapter meldet keinen Link. Dann untersuchst du zunächst Anschluss, Medium und Gegenstelle. Eine neue HTTP-Anfrage erklärt diesen Befund nicht. Zweiter Fall: Der Link steht, aber der Rechner hält wegen eines falschen Präfixes ein entferntes Ziel für direkt erreichbar. Dann wartet er möglicherweise auf eine lokale Nachbarantwort, obwohl die vorgesehene Route über ein Gateway führen müsste. Hier helfen Adress- und Routingdaten.
Dritter Fall: Die Verbindung zum richtigen Dienst gelingt und der Server antwortet mit einem HTTP-Statuscode für einen Fehler. Damit gibt es bereits eine Anwendungsantwort. Ihre Ursache kann etwa in Berechtigungen, einem ungültigen Pfad oder einer überlasteten Anwendung liegen. Das Kabel pauschal auszutauschen wäre durch diese Beobachtung nicht begründet. Die Beispiele zeigen eine Arbeitsweise: Beginne mit dem konkreten Befund, ordne seine Voraussetzungen ein und suche den nächsten unterscheidenden Beleg. Ein Schichtenname allein ist noch keine Diagnose.
Ein Mitschnitt zeigt eine Perspektive, nicht die ganze Verbindung.
Stell dir vor, du zeichnest gleichzeitig am Client und am Routerausgang auf. Du erwartest dieselbe Anwendungsnachricht, aber andere Ethernet-Adressen. Auch die TTL unterscheidet sich nach der Weiterleitung. Bei zusätzlichem NAT ändert sich die sichtbare Quell-IP. Diese Unterschiede widersprechen der gemeinsamen Kommunikation nicht: Die Aufzeichnungen zeigen verschiedene Abschnitte und verschiedene Verarbeitungsschritte.
Ein Mitschnitt direkt im Host kann außerdem durch Offloading größere zusammengefasste Einheiten oder noch nicht fertig berechnete Prüfsummen zeigen. Daraus darfst du nicht unmittelbar auf kaputte Frames auf der Leitung schließen. Entscheidend sind Aufzeichnungspunkt und Werkzeugperspektive. Für den Einstieg reicht deshalb eine klar begrenzte Frage: Welchen Header müsste die gerade untersuchte Funktion tatsächlich auswerten? Wer nur den Browserfehler betrachtet, sieht die unteren Ebenen nicht; wer nur Ethernet betrachtet, sieht noch nicht den fachlichen Erfolg einer Anfrage. Die Linux-Serverdiagnose verbindet solche Einzelbeobachtungen mit konkreten Dienstprüfungen.
Zwei Wege durch den Stack selbst erklären.
Aufgabe 1: Ein Rechner sendet über einen Ethernet-Switch und einen Router an einen entfernten Server. Welche Zieladresse verwendet der erste Frame, welche Zieladresse das IP-Paket? Muss der Switch die HTTP-Methode lesen, um weiterzuleiten?
Lösung: Link-Ziel und IP-Ziel trennen
Der erste Frame adressiert die MAC des gewählten lokalen Next Hops, hier des Gateways. Das enthaltene IP-Paket adressiert weiterhin den Server. Ein gewöhnlicher Layer-2-Switch entscheidet mit VLAN-Kontext und Ziel-MAC, ohne die HTTP-Methode zu benötigen. Der Router erzeugt am Ausgang eine neue Link-Kapselung. Erst eine zusätzliche Funktion wie ein Anwendungsproxy müsste HTTP auswerten.
Aufgabe 2: Jemand zeichnet HTTP/3 direkt über TCP und behauptet, UDP könne niemals zuverlässige Daten übertragen. Korrigiere beide Aussagen und benenne die Einheit unmittelbar unter einem UDP-Datagramm in unserem Ethernet-Lab.
Lösung: QUIC ergänzt die fehlenden Dienste
Die Folge lautet HTTP/3 über QUIC über UDP über IP über Ethernet. UDP garantiert selbst weder Reihenfolge noch Zustellung; QUIC implementiert darüber unter anderem zuverlässige Streams. Das UDP-Datagramm ist Nutzlast eines IP-Pakets, das wiederum im Ethernet-Frame liegt. Ein oberes Protokoll kann also zusätzliche Eigenschaften bereitstellen, die sein Träger nicht selbst garantiert.
Quellen und fachlicher Stand.
Geprüft am . Eigene Beispiele und SVGs. Die Modellabbildung ist bewusst funktional vereinfacht; Tunnel, Fragmentierung und Offloading sind nicht als vollständiger Paketmitschnitt dargestellt.
- ITU-T X.200 (07/1994): gültiges OSI-Basisreferenzmodell. RFC 1122, Abschnitt 1.1.3: Internetarchitektur; TCP-Teil durch RFC 9293 aktualisiert.
- RFC 9293: aktuelle TCP-Basisspezifikation und Bytestrom. RFC 768: UDP-Grundformat; die RFC-Info nennt RFC 9868 als Update.
- RFC 9000 und RFC 9114: QUIC und HTTP/3. RFC 9846: TLS 1.3, ersetzt RFC 8446.
- RFC 894: IPv4 in Ethernet. RFC 8200, aktualisiert durch RFC 9673: IPv6 und Hop-by-Hop-Verarbeitung. RFC 5737: IPv4-Dokumentationsbereiche.