E1 – Internetprotokolle und Kommunikation in Netzwerken

Bevor der technische Ablauf des Webseitenabrufs im Detail betrachtet wird, ordnet dieses Accordion das Thema curricular ein. Die KCGO-Bausteine stehen hier nicht als getrennte Einzelthemen nebeneinander, sondern bilden Teilantworten auf dieselbe Grundfrage: Wie kann ein Client einen entfernten Dienst zuverlässig erreichen?

Curriculare Einordnung

Themenfeld E.1 Internetprotokolle ist Teil der verbindlichen Themenfelder 1–3 der Einführungsphase und legt die fachliche Basis für vernetzte Kommunikation. Rechnernetze liefern die Struktur, IP-Adressen und Subnetzmasken ermöglichen Zustellentscheidungen, DNS verbindet Namen mit Adressen, TCP/IP ordnet die Aufgaben in Schichten, und das Client-Server-Modell beschreibt die Nutzung konkreter Dienste.

Status und Themenfeldbezug

• Verbindlich: ja (Themenfelder 1–3)
• Themenfeld: E.1 Internetprotokolle
• Schwerpunkt: Modellorientierte Erklärung von Netzwerkkommunikation

Zentrale Inhalte in E.1

• Rechnernetze: Aufbau, Bestandteile und Funktionen von Komponenten
• Grundlagen des Internets als Verbund von Teilnetzen
• IP-Adresse, Subnetzmaske und Gateway
• DNS zur Namensauflösung
• TCP/IP-Referenzmodell als Strukturierungsrahmen
• Client-Server-Architektur und Dienste
• Protokolle und Sicherheitsgrundlagen

Wenn ein Client web.schule.lan/index.html laden möchte, muss er eine Nachricht so formulieren und übertragen, dass ein Server sie eindeutig versteht. Das allgemeine Kommunikationsmodell liefert dafür die Grundstruktur: Sender, Nachricht, Codierung, Kanal, Decodierung und Empfänger.

1) Allgemeines Kommunikationsmodell

Kommunikation ist ein geregelter Prozess: Ein Sender codiert eine Nachricht, überträgt sie über einen Kanal, der Empfänger decodiert und interpretiert sie. Diese Modellkette erklärt, warum gemeinsame Regeln nötig sind: Ohne abgestimmte Codierung und Erwartungen entsteht keine verlässliche Bedeutung.

Für Rechnernetze bedeutet das: Sender und Empfänger werden zu Hosts, die Nachricht wird in ein Protokollformat gebracht, der Kanal besteht aus Übertragungswegen und Vermittlungsknoten, und die Decodierung entspricht der Protokollauswertung auf der Gegenseite. Eine Störung kann daher auf unterschiedlichen Ebenen entstehen: im Medium, bei der Adressierung, beim Transport oder bei der Interpretation der Nachricht.

2) Übertragung auf Rechnernetze

Ein Netzwerk ist ein Verbund aus Knoten und Verbindungen, in dem Nachrichten zwischen vielen Beteiligten koordiniert werden. Das Internet skaliert dieses Prinzip als „Netz von Netzen", verbunden über Router und standardisierte Protokolle.

Topologien als Ordnungsprinzip

Topologien beschreiben die Struktur von Verbindungen. Sie erklären, wie robust ein Netz ist, wie leicht Fehler gefunden werden und wie stark ein Netz skaliert. Diese Struktur liefert die räumliche Perspektive auf Kommunikation; die Regelperspektive folgt mit den Protokollen im nächsten Kapitel.

Topologien beschreiben also die Struktur möglicher Übertragungswege. Sie zeigen, welche Wege, Engstellen und Ausfallpunkte ein Netz haben kann. Damit ist aber nur die Strukturperspektive geklärt. Für funktionierende Kommunikation reicht ein möglicher Weg nicht aus: Die beteiligten Geräte müssen auch wissen, wie Nachrichten aufgebaut, adressiert, weitergeleitet, bestätigt und interpretiert werden. Genau diese Regelperspektive übernehmen Protokolle.

Beim Laden von web.schule.lan/index.html entsteht nicht eine einzige große Internetnachricht. Verschiedene Aufgaben müssen zusammen gelöst werden: Der Name wird einer Adresse zugeordnet, der Zielhost muss erreichbar sein, Daten werden in übertragbare Einheiten zerlegt, verlorene Teile müssen erkennbar bleiben, und auf Anwendungsebene muss formuliert werden, welche Ressource angefragt wird.

Warum ein einzelnes Protokoll nicht reicht

Internetkommunikation ist arbeitsteilig: Adressierung, Weiterleitung, Transportzuverlässigkeit und Anwendungsinhalt haben jeweils eigene Anforderungen. Würde ein einziges Universalprotokoll alles zugleich regeln, wäre der Ablauf schwer erklärbar, schlecht austauschbar und kaum systematisch zu prüfen.

Deshalb arbeitet das Internet mit einer Protokollfamilie. Jedes Protokoll übernimmt eine begrenzte, aber klar bestimmte Aufgabe; erst ihr Zusammenspiel ergibt den vollständigen Webseitenabruf.

Was ist ein Protokoll?

Ein Protokoll ist ein verbindlicher Regelsatz für digitale Kommunikation. Es regelt:

• Syntax: Wie Daten strukturiert sind (z. B. Headerfelder).
• Semantik: Welche Bedeutung Felder und Statuswerte haben.
• Ablauf: In welcher Reihenfolge Nachrichten ausgetauscht werden.
• Fehlerbehandlung: Wie mit Verlust, Verzögerung oder Abbruch umgegangen wird.

Wichtig ist die Abgrenzung: Ein Protokoll deckt immer nur einen Teil der Gesamtkommunikation ab. Erst die Kombination mehrerer Protokolle ergibt einen vollständigen Kommunikationsablauf.

Ablauf: Wie mehrere Protokolle zusammenarbeiten

Beim Laden einer Webseite greifen mehrere Protokolle ineinander. Nach außen wirkt die Kommunikation wie ein einziger Vorgang; fachlich lassen sich jedoch Teilaufgaben unterscheiden, die im Ablauf zeitlich verschränkt sind.

Die Schrittfolge hilft zunächst beim Verstehen der Reihenfolge. Gleichzeitig muss sie als Modell gelesen werden: DNS, TCP, HTTP und IP sind keine isolierten Stationen, sondern arbeitsteilige Regeln desselben Kommunikationsvorgangs.

Vom Domainnamen zur Website

Der Ablauf beginnt für Nutzende mit einem Namen wie web.schule.lan/index.html. Fachlich steckt darin aber bereits eine Kette von Teilaufgaben: Der Domainname muss in eine IP-Adresse übersetzt werden, der Zielhost muss erreichbar sein, eine zuverlässige Verbindung muss aufgebaut werden, und auf Anwendungsebene muss die konkrete Ressource angefragt werden.

Als Ablaufperspektive entsteht daraus die Bewegung: Domainname → DNS → IP-Adresse → TCP-Verbindung → HTTP-Request → IP-Weiterleitung → TCP-Zuverlässigkeit → HTTP-Response/Webseite. Das folgende Schaubild liest den Webseitenabruf deshalb als Weg vom Domainnamen zur Website. Es zeigt nicht nur eine zeitliche Reihenfolge, sondern macht sichtbar, welches Protokoll welche Teilaufgabe übernimmt.

Genau daraus entsteht die Grundidee der Internetprotokollfamilie: Nicht ein einzelnes Protokoll löst die gesamte Kommunikation, sondern mehrere spezialisierte Protokolle arbeiten zusammen.

Schrittfolge: vom Domainnamen zur Website

Die Schrittfolge erklärt den Ablauf. Sie beantwortet aber noch nicht, wie diese vielen Protokolle systematisch geordnet werden können. Dafür wird im nächsten Schritt die Schichtenperspektive eingeführt: Protokolle werden nach Aufgaben gruppiert. DNS und HTTP gehören zur Anwendungsebene, TCP zur Transportebene, IP zur Internetebene und Ethernet oder WLAN zur Netzzugangsebene.

Vom Ablauf zur Schichtung

Das Schichtenmodell ist eine Abstraktion über den konkreten Ablauf. Es fragt nicht zuerst: „Was passiert zeitlich nacheinander?“, sondern: „Welche Aufgabe übernimmt welche Ebene?“ Dadurch lassen sich Protokolle gruppieren, vergleichen und später gezielt diagnostizieren.

Das OSI-Modell bietet dafür ein allgemeines Referenzmodell mit sieben Schichten. Das TCP/IP-Modell fasst diese Perspektive für das Internet praktischer in vier Schichten zusammen. Für E1 ist nicht das Auswendiglernen beider Modelle entscheidend, sondern die Einsicht: Protokolle gehören zu unterschiedlichen Aufgabenbereichen und arbeiten beim Webseitenabruf zusammen.

OSI (7)	TCP/IP (4)	Funktion im Webseitenabruf
Anwendung, Darstellung, Sitzung	Anwendung	HTTP und DNS beschreiben den fachlichen Inhalt und die Namensauflösung.
Transport	Transport	TCP segmentiert und nummeriert Datenströme. ACK (Acknowledgement) bestätigt, bis zu welcher Position alles angekommen ist; so erkennt TCP Lücken und überträgt fehlende Segmente erneut.
Vermittlung	Internet	IP adressiert Pakete und leitet sie über Router weiter.
Sicherung, Bitübertragung	Netzzugang	Übertragung auf Medium/Link (z. B. Ethernet, WLAN).

Warum Schichten nötig sind: Die Schichten trennen Aufgaben, die im Webseitenabruf gleichzeitig zusammenspielen: Inhalt und Namensauflösung (HTTP, DNS), Transportzuverlässigkeit (TCP), paketbasierte Weiterleitung (IP) und Übertragung auf dem Medium. So können Protokolle unabhängig beschrieben und weiterentwickelt werden, ohne den Gesamtzusammenhang zu verlieren.

Zentral: Paketvermittlung: Eine Webseite wird nicht als unteilbarer Block durch das Netz geschickt. Daten werden in kleinere Einheiten zerlegt, über IP paketweise weitergeleitet und auf der Transportebene wieder geordnet. TCP nutzt dafür Sequenznummern und Bestätigungen. ACK bedeutet dabei nicht einfach „alles ist angekommen": Ein ACK gibt an, bis zu welcher Stelle der Datenstrom korrekt empfangen wurde. Dadurch kann TCP Lücken erkennen und fehlende Segmente erneut übertragen.

Struktur vs. Ablauf direkt zusammen gedacht: Das Schichtenmodell zeigt die Strukturperspektive: Welche Aufgabe gehört zu welcher Ebene? Das Sequenzdiagramm zeigt die Ablaufperspektive: In welcher Reihenfolge werden Request, Segmentübertragung, ACK-Bestätigung und Response sichtbar? Erst beide Perspektiven zusammen erklären Internetkommunikation als geordneten Vorgang.

Integriertes Sequenz-/Schichtendiagramm

Damit der Client web.schule.lan/index.html erreichen kann, reicht der HTTP-Request allein nicht aus. Zuerst braucht das Gerät eine gültige Netzkonfiguration und eine Entscheidungsregel: Liegt das Ziel im eigenen Netz oder muss das Paket an das Gateway übergeben werden?

Grundkonfiguration eines Netzwerkgeräts

Adressierung ist mehr als das Eintragen einer IP-Adresse. Ein Gerät wird erst durch Konfiguration zu einem funktionsfähigen Netzwerkteilnehmer. Dabei wirken vier Angaben als zusammenhängendes System: Die IP-Adresse macht den Host identifizierbar, die Subnetzmaske liefert die Entscheidungsregel für lokale und entfernte Ziele, das Gateway ist der verpflichtende Übergabepunkt in andere Netze und ein DNS-Server ermöglicht die Nutzung von Hostnamen. Erst dieses Zusammenspiel erlaubt es, lokale Ziele direkt und entfernte Ziele über das Gateway zu erreichen sowie adressierte Dienste sinnvoll anzusprechen.

Beispiel: Ein Rechner im Schulnetz erhält eine IP-Adresse, eine Subnetzmaske, ein Gateway und einen DNS-Server. Erst dadurch kann er sowohl lokale Ziele erreichen als auch Webseiten über Hostnamen ansprechen.

Aus der Grundkonfiguration entsteht die fachliche Reihenfolge: Konfiguration → Netzentscheidung → Weiterleitung. Die folgenden Unterabschnitte entfalten diese Logik schrittweise.

IP-Adresse und Subnetzmaske

Die IP-Adresse ist nicht nur eine logische Adresse im Modell, sondern eine notwendige Host-Konfiguration: Ohne sie kann ein Gerät weder als Quelle noch als Ziel in IP-Kommunikation auftreten. Die Subnetzmaske ist nicht nur eine formale Netz-/Host-Trennung, sondern die konkrete Regel, nach der das Gerät seine Kommunikationsentscheidung trifft.

Entscheidung: lokales Ziel oder entferntes Ziel

Nach der Konfiguration folgt die Netzentscheidung: Das Gerät vergleicht die eigene Netzadresse mit der Netzadresse des Ziels. Bei gleicher Netzadresse bleibt die Kommunikation lokal, typischerweise vermittelt durch einen Switch. Bei unterschiedlicher Netzadresse gilt das Ziel als entfernt und muss weitergeleitet werden.

Gateway als notwendiger Übergang

Ergibt die Entscheidung ein entferntes Ziel, ist das Gateway kein optionaler Zusatz, sondern der verpflichtende Übergabepunkt für fremde Netze. Ein falsch gesetztes Gateway würde dazu führen, dass ein Host trotz korrekter lokaler Adressierung keine entfernten Ziele erreicht.

Routing als Folge dieser Entscheidung

Erst nach der Übergabe an das Gateway beginnt Routing im engeren Sinn: Router wählen auf Basis von Zielnetzen den nächsten Hop und leiten Pakete zwischen Netzen weiter. Damit ist Routing die systematische Folge der vorherigen Host-Entscheidung und nicht deren Ersatz.

So bleibt die Kette konsistent: Ein Host entscheidet lokal über Netzgleichheit, ein Router setzt diese Entscheidung als Wegwahl über Netzgrenzen fort.

Diese Adressierungslogik wird in Kapitel 6 wieder aufgenommen: Wer die Entscheidung „lokal oder Gateway?" versteht, kann Erreichbarkeit systematisch prüfen und Fehlkonfigurationen gezielter eingrenzen.

Nach der Adressierungslogik ist klar, wie ein Client mit IP-Adressen, Subnetzmaske und Gateway über lokale oder entfernte Ziele entscheidet. Im Beispiel kennt der Nutzer aber zunächst keinen Zahlenwert, sondern den Namen web.schule.lan. DNS löst in dieser Kette genau die Namensfrage: Aus dem Hostnamen wird eine IP-Adresse, mit der die zuvor erklärte Weiterleitungslogik arbeiten kann.

Wichtig ist die Trennung der Aufgaben: DNS löst nicht den gesamten Webseitenabruf, sondern liefert nur die Zuordnung von Name zu IP-Adresse. Ob der Zielhost erreichbar ist und ob dort ein Webdienst antwortet, entscheidet sich erst in den folgenden Schritten.

Nach der Namensauflösung kennt der Client die Zieladresse. Noch offen ist, ob auf diesem Host der erwartete Dienst auf dem passenden Port erreichbar ist. Das ist die Aufgabe des Client-Server-Modells im nächsten Kapitel.

Nach der DNS-Auflösung kennt der Client die IP-Adresse des Zielhosts. Damit ist aber noch nicht entschieden, welcher Dienst dort angesprochen werden soll: Auf einem Host können mehrere Dienste gleichzeitig laufen, und erst der Port macht sie unterscheidbar.

Das Client-Server-Modell beschreibt diesen Zugriff als Interaktion zwischen Rollen: Der Client initiiert die Anfrage, der Serverdienst wartet auf eingehende Verbindungen und beantwortet passende Requests. Es geht dabei nicht um die räumliche Netzwerkstruktur, sondern um die Rollen und den Ablauf der Dienstnutzung.

Ein Dienst ist kein eigenes Gerät, sondern ein Programm bzw. Prozess, der auf einem Host über einen Port erreichbar ist. Für den Webseitenabruf bedeutet das: Die IP-Adresse identifiziert den Webserver als Host, Port 80 oder 443 adressiert den Webdienst, und HTTP beschreibt die fachliche Anfrage nach index.html.

Im Sequenzdiagramm erscheint dieser Dienst deshalb als Kontext der Nachrichten (z. B. HTTP über Port 80) und nicht als eigenes Gerät. HTTPS ist die gesicherte Variante des Webzugriffs; Sicherheitsaspekte gehören damit zur Dienstnutzung, werden hier aber nur grundlegend angebahnt.

Damit wird die Unterscheidung klar: Ein Host kann erreichbar sein, während der Dienst nicht erfolgreich antwortet. Diese Trennung ist für die spätere Diagnose in Kapitel 6 zentral.

Für das Verständnis des Dienstzugriffs reicht hier die Verarbeitung als Server-Aktivierung: Der Client sendet einen HTTP-Request, der Webdienst nimmt ihn am passenden Port entgegen, verarbeitet die Anfrage und liefert anschließend die HTTP-Response.

Rollenabgrenzung im Netzwerk: Rechner sind Endgeräte/Hosts, Switches vermitteln lokal im Teilnetz, Router verbinden Netze über Grenzen hinweg, DNS-Server übernehmen Namensauflösung und Webserver stellen Inhalte als Dienst bereit.

Kurzer Exkurs: Abgrenzung zu Peer-to-Peer

Die folgende Tabelle dient der Abgrenzung. Für den roten Faden des Webseitenabrufs bleibt das Client-Server-Modell zentral, weil ein Browser gezielt einen Webdienst auf einem Server anfragt.

Merkmal	Client-Server	Peer-to-Peer
Rollen	klar getrennt	wechselnd, gleichberechtigt
Verwaltung	zentral gut steuerbar	dezentral verteilt
Ausfallwirkung	Serverausfall oft kritisch	einzelne Ausfälle meist besser tolerierbar

Damit entsteht die letzte Diagnosefrage: Ist nicht nur der Host erreichbar und der Name auflösbar, sondern antwortet auch der erwartete Dienst auf dem Zielport?

Wenn web.schule.lan/index.html nicht geladen wird, ist das Problem nicht automatisch „das Internet“. Die Diagnose wiederholt die vorherigen Kapitel nicht, sondern wendet ihre Fachlogik an: Gibt es einen sinnvollen Netzpfad? Ist der Zielhost erreichbar? Wird der Name korrekt aufgelöst? Antwortet der erwartete Dienst auf dem passenden Port?

Die diagnostische Prüflogik ist damit keine neue Theorie, sondern die Anwendung der zuvor entwickelten Kette. Ein Fehler kann in der Verbindung, in der IP-Konfiguration, beim Gateway, bei der Namensauflösung, beim Zielhost oder beim Webdienst liegen. Die Prüfreihenfolge folgt bewusst derselben Struktur wie der Webseitenabruf selbst.

1) Ping = grundlegende Erreichbarkeit

Ping liefert einen Hinweis darauf, ob ein Zielhost auf Netzwerkebene erreichbar ist. Diese Prüfung wird erst dann fachlich sinnvoll interpretierbar, wenn die Adressierung, die Subnetzentscheidung und das Routing aus Kapitel 3 verstanden sind. Die Verfügbarkeit eines Webdienstes prüft Ping nicht.

2) DNS = Namensauflösung

Die DNS-Prüfung klärt, ob ein Hostname in eine IP-Adresse aufgelöst wird. Diese Prüfung setzt voraus, dass Hostkonfiguration und Namensauflösung als getrennte Systemebenen verstanden sind (Kapitel 4). Ein Name kann korrekt auflösbar sein, obwohl der Zielhost nicht erreichbar ist.

3) HTTP/Webabruf = Dienstverfügbarkeit

Der HTTP- bzw. Webabruf prüft, ob nach Erreichbarkeit und ggf. DNS-Auflösung ein aktiver Dienst auf dem Zielport antwortet. Diese dritte Stufe setzt Erreichbarkeit, optional Namensauflösung und die Dienstlogik aus Kapitel 5 voraus.

Wird statt des Namens direkt die IP-Adresse verwendet, entfällt die DNS-Phase. Der Webabruf prüft dann den Netzpfad zum Zielhost und die Dienstantwort auf dem Zielport.

Zusammenführung: Der Webseitenabruf ist nun als Kette lesbar: Struktur ermöglicht Wege, Protokolle regeln den Austausch, IP/Subnetz/Gateway entscheiden die Zustellung, DNS übersetzt Namen und der Webdienst beantwortet die Anfrage. Dieselbe Kette dient auch der Fehlersuche. Wer die Ebenen sauber trennt, kann gezielt eingrenzen, ob ein Problem bei Verbindung, Adresse, Name oder Dienst liegt.