Buffl

BS 3

CR
by Cha R.

Wie kommunizieren zwei Prozesse (ausgeführte Netzwerkanwendungen) auf zwei Rechnern miteinander? Wie funktioniert die Kommunikation in Rechnernetzen?

Einprägsame Erklärung:

Stell dir vor, du möchtest mit einem Freund sprechen, der in einem anderen Haus wohnt. Da ihr keinen gemeinsamen Raum habt, in dem ihr euch treffen könnt, müsst ihr euch Nachrichten schicken, um zu kommunizieren. Genauso funktioniert die Kommunikation in Netzwerkanwendungen:

  1. Endsysteme (Hosts):

    • Die Endsysteme sind wie die Häuser, in denen du und dein Freund wohnt. Jedes Endsystem ist ein eigenständiger Computer, der getrennt von den anderen arbeitet.

  2. Kommunikationsleitungen:

    • Die Kommunikationsleitungen (z. B. Kabel oder WLAN) sind wie die Straßen, die eure Häuser verbinden. Sie ermöglichen den Austausch von Nachrichten zwischen den Endsystemen.

  3. Nachrichtenaustausch:

    • Da die Endsysteme keinen gemeinsamen Speicher haben, müssen sie Nachrichten über das Netzwerk austauschen, um zu kommunizieren. Es ist, als ob ihr euch Briefe schickt, um Informationen auszutauschen.

Prozessübergreifende Kommunikation:

  • In verteilten Anwendungen (z. B. Webseiten, E-Mails oder Online-Spiele) kommunizieren Prozesse auf verschiedenen Endsystemen über Nachrichten. Diese Nachrichten werden über das Netzwerk gesendet und empfangen.

Einfache Erklärung:

  • Endsysteme (Hosts): Getrennte Computer, die über Kommunikationsleitungen verbunden sind.

  • Nachrichtenaustausch: Da die Endsysteme keinen gemeinsamen Speicher haben, kommunizieren sie über Nachrichten, die über das Netzwerk gesendet werden.

  • Prozessübergreifende Kommunikation: In verteilten Anwendungen tauschen Prozesse auf verschiedenen Endsystemen Nachrichten aus.

 

Was ist das Internet? Was ist die Idee hinter dem Internet? Wie funktioniert das Internet? Was ist der Unterschied zwischen Leitungsvermittlung und Paket-vermittlung? Was davon benutzt das Internet und warum? Welche Vorteile hat ein leitungsvermitteltes Netzwerk im Vergleich zu einem paketvermittelten Netzwerk?

Einprägsame Erklärung:

Das Internet ist wie ein riesiges Straßennetz, das aus vielen kleineren Straßen (privaten und öffentlichen Netzwerken) besteht. Zusammen bilden sie ein „logisches Netzwerk“, das wir als Internet kennen. Hier ist, wie es funktioniert:

  1. Netzwerk aus Netzwerken:

    • Das Internet ist ein Verbund aus vielen Netzwerken, die miteinander verbunden sind. Es ist, als ob viele kleine Städte ihre Straßen miteinander verbinden, um ein großes Verkehrsnetz zu schaffen.

  2. Paketvermittlung:

    • Das Internet ist ein paketvermitteltes Netz. Daten werden in kleine Pakete aufgeteilt und über alternative Wege (Routen) von A nach B geschickt. Es ist, als ob du einen Brief in mehrere Teile zerlegst und jeden Teil über eine andere Straße schickst.

    • Im Gegensatz dazu steht die Leitungsvermittlung, bei der eine feste Route vorgegeben ist. Das wäre, als ob du nur eine einzige Straße nutzen dürftest, um deinen Brief zu senden.

  3. Vorteile der Paketvermittlung:

    • Mehrfachnutzung von Leitungen: Mehrere Pakete können gleichzeitig über dieselbe Leitung geschickt werden.

    • Alternative Wege: Wenn eine Route ausfällt, können Pakete über andere Wege umgeleitet werden. Das macht das Internet ausfallsicherer.

    • Herkunft: Dieses Konzept stammt aus dem ARPANET, dem Vorläufer des Internets.

  4. Internet-Standards:

    • Die Regeln und Standards des Internets sind in den RFCs (Request for Comments) dokumentiert, die von der IETF (Internet Engineering Task Force) veröffentlicht werden. Es ist, als ob es ein Handbuch gibt, das festlegt, wie die Straßen gebaut und genutzt werden sollen.

Einfache Erklärung:

  • Das Internet ist ein Netzwerk aus Netzwerken, das private und öffentliche Netzwerke verbindet.

  • Es ist paketvermittelt: Daten werden in Pakete aufgeteilt und über alternative Routen gesendet.

  • Vorteile: Mehrfachnutzung von Leitungen, alternative Wege, Ausfallsicherheit.

  • Standards: Die Regeln des Internets sind in den RFCs der IETF festgehalten.




Was ist ein Rechnernetzwerk?

Einprägsame Erklärung:

Ein Rechnernetz (oder Computernetzwerk) ist wie ein Team von Menschen, die zusammenarbeiten, um eine Aufgabe zu erledigen. Jeder im Team hat eine spezielle Rolle, und sie kommunizieren miteinander, um ihre Ziele zu erreichen. Hier ist, wie es funktioniert:

  1. Zweck:

    • Rechnernetze dienen dazu, verteilte Anwendungen zu realisieren. Diese Anwendungen kommunizieren miteinander, indem sie Nachrichten über das Netzwerk austauschen. Es ist, als ob die Teammitglieder sich Briefe schicken, um Informationen auszutauschen.

  2. Komponenten:

    • Endsysteme (Hosts): Das sind die „Hauptakteure“ im Netzwerk, z. B. Computer oder Server, auf denen die Netzwerkanwendungen laufen.

    • Transitsysteme: Dazu gehören Router, Gateways, Switches und Bridges. Sie sind wie die „Vermittler“, die sicherstellen, dass die Nachrichten den richtigen Weg finden.

    • Kommunikationsleitungen: Das sind die „Verbindungsstraßen“, z. B. Kabel oder WLAN, die die Komponenten miteinander verbinden.

  3. Modell eines Netzwerks:

    • Ein Netzwerk kann als Graph dargestellt werden:

      • Knoten: Die Rechner und Peripheriegeräte (z. B. Drucker).

      • Kanten: Die Kommunikationsleitungen, die die Knoten verbinden.

  4. Systemdefinition:

    • Ein System besteht aus verbundenen Komponenten mit einem erwarteten Verhalten. Es interagiert über Schnittstellen mit seiner Umgebung. Es ist, als ob das Team klare Regeln hat, wie es kommuniziert und zusammenarbeitet.

Einfache Erklärung:

  • Rechnernetze ermöglichen verteilte Anwendungen, die über Nachrichtenaustausch kommunizieren.

  • Komponenten:

    • Endsysteme (Hosts): Computer oder Server, auf denen Anwendungen laufen.

    • Transitsysteme: Router, Gateways, Switches, Bridges.

    • Kommunikationsleitungen: Verbinden die Komponenten.

  • Modell: Ein Netzwerk ist ein Graph mit Knoten (Rechner) und Kanten (Leitungen).

  • System: Verbundene Komponenten mit erwartetem Verhalten, die über Schnittstellen interagieren.


Was ist das Prinzip des Schichtenmodells? Was ist ein Dienstzugangspunkt? Was ist ein Dienstmodell?

Einprägsame Erklärung:

📚 Das Schichtenmodell funktioniert wie ein Briefsystem

💡 Stell dir vor, du willst einen Brief versenden. Jede Schicht hat dabei eine bestimmte Aufgabe:

1️⃣ Verpackung & Adressierung 🏷️

  • Dein Brief wird in einen Umschlag gesteckt (Daten werden mit Headern & Trailern ergänzt).

  • Die Adresse wird außen aufgeschrieben (die Schicht bereitet Daten für die nächste Schicht vor).

2️⃣ Zustellung über verschiedene Stationen 🚚

  • Der Brief wird von der Poststelle abgeholt (Dienste werden über Schnittstellen genutzt).

  • Über verschiedene Zwischenstationen gelangt er zum Ziel (jede Schicht nutzt die darunterliegende Schicht).

3️⃣ Öffnen & Lesen beim Empfänger 📬

  • Beim Empfänger wird der Brief ausgepackt (die Daten werden von den Headern befreit).

  • Die oberste Schicht (Anwendung) verarbeitet den Inhalt.

📌 Wichtig: ✔️ Jede Schicht arbeitet unabhängig von den anderen – solange die Schnittstellen gleich bleiben. ✔️ Die eigentliche Übertragung passiert nur in der untersten Schicht. ✔️ Protokolle sind die „Regeln“, nach denen die Schichten miteinander kommunizieren.

Einfache Erklärung:

Das Schichtenmodell ist wie ein Postsystem:

  • Jede Schicht bearbeitet die Daten weiter, bevor sie zur nächsten Schicht gelangen.

  • Die oberste Schicht ist die Schnittstelle zur Anwendung.

  • Änderungen an einer Schicht beeinflussen die anderen nicht, solange die Schnittstellen gleich bleiben.


Wie läuft die Kommunikation im Internet? Wie ist das Internet aufgebaut? Was ist das IP?

Einprägsame Version

Netzwerk aus Netzwerken (Internet):

  • Endsysteme & Verbund:

    • In großen Netzwerken sind die Endsysteme (Hosts) nicht direkt miteinander verbunden.

    • Das Internet ist ein Verbund aus privaten und öffentlichen Netzwerken – ein „Netzwerk aus Netzwerken“, das als logisches Netzwerk agiert.

  • Transitsysteme:

    • Zwischen den Endsystemen liegen weitere Netzwerke, die über Transitsysteme wie Router und Gateways verbunden sind.

  • Zugangsnetzwerk:

    • Ein Endsystem erhält seinen Zugang zum Internet über den Internet-Service-Provider (ISP).

    • Lokale ISPs verbinden sich mit regionalen, nationalen und internationalen ISPs.

  • Internet-Standards:

    • Die Standards des Internets werden in den RFCs (Request for Comments) festgelegt, die von der IETF (Internet Engineering Task Force) definiert werden.

  • Internet-Protokoll (IP):

    • Grundlage: IP ist das grundlegende Protokoll der Vermittlungsschicht und für das gesamte Internet zentral.

    • Funktion:

      • Es spezifiziert das Format von Datagrammen (auch IP-Pakete genannt), die zwischen Routern und Endsystemen ausgetauscht werden.

      • Route/Pfad: Der Weg, den diese Datagramme von einem Endgerät über verschiedene Transitsysteme zum Ziel nehmen, wird als Route oder Pfad bezeichnet.

      • Fragmentierung: Während der Weiterleitung können Datagramme in Pakete zerlegt werden, wobei auch nicht zerlegte Datagramme als Pakete betrachtet werden.

Einfache Version

  • Netzwerkaufbau:

    • Das Internet ist ein Netzwerk aus Netzwerken – Endsysteme sind nicht direkt verbunden, sondern über verschiedene Netzwerke und Router/Gateways miteinander verknüpft.

  • Zugang:

    • Ein Endsystem bekommt seinen Internetzugang von einem ISP. Lokale ISPs sind mit größeren, regionalen und internationalen ISPs verbunden.

  • Standards:

    • Die Regeln des Internets werden in RFCs von der IETF festgelegt.

  • Internet-Protokoll (IP):

    • IP ist das Basisprotokoll für den Datenaustausch.

    • Es definiert das Format der IP-Pakete (Datagramme) und bestimmt den Weg (Route), den sie durch das Netz nehmen.

    • Datagramme können bei der Übertragung in Pakete zerlegt werden.

Diese Versionen bieten dir eine klare, strukturierte Übersicht über den Aufbau und die Funktionsweise des Internets und seiner Protokolle.

Wie läuft die Wegevermittlung im dezentralen Netz bzw. im Internet?

Einprägsame Version

Paketvermittlung im Internet:

  • Paketvermittlung:

    • Das Internet nutzt das Prinzip der Paketvermittlung. Nachrichten werden in kleine Pakete aufgeteilt und unabhängig voneinander durch das Netzwerk geschickt.

  • Ziel: Flexibilität und Resilienz:

    • Auch in gestörten Systemen sollen Nachrichten ihr Ziel erreichen. Dazu wird das Netzwerk so aufgebaut, dass jeder Router die Pakete nach bestem Wissen weiterleitet (mit best effort).

  • Router und Verbindungsnetzwerke:

    • Ein Verbindungsnetzwerk besteht aus Routern (auch Transitsysteme genannt) und den Verbindungen zwischen ihnen.

  • Vermittlung:

    • Die Router leiten Pakete unabhängig weiter, was bedeutet, dass keine festen Übertragungswege erforderlich sind.

    • Leitungsvermittlung (feste Übertragungswege) ist nicht nötig, sodass Pakete auch unterschiedliche Routen nehmen können, selbst wenn sie zur gleichen Nachricht oder zum gleichen Datagramm gehören.

Einfache Version

  • Paketvermittlung:

    • Das Internet nutzt Paketvermittlung – Nachrichten werden in Pakete aufgeteilt und können über verschiedene Wege zum Ziel gelangen.

  • Ziel:

    • Selbst wenn Teile des Systems gestört sind, können Pakete immer noch den besten Weg zum Ziel finden.

  • Router und Verbindungen:

    • Das Netzwerk besteht aus Routern und den Verbindungen zwischen ihnen.

  • Keine festen Wege:

    • Router leiten die Pakete nach bestem Wissen weiter, ohne feste Übertragungswege. Pakete, die zu derselben Nachricht gehören, können unterschiedliche Wege nehmen.

Diese Versionen fassen den Prozess der Paketvermittlung zusammen und verdeutlichen, wie Flexibilität und Resilienz im Netzwerk durch den Einsatz von Routern erreicht werden.

Welche Schichten hat das OSI-Modell?

Einprägsame Version:

🖥️ Die 7 Schichten des OSI-Modells – Vom Bit zur Anwendung

🔹 Schicht 1: Bitübertragung (Physical Layer) ➡ Physische Übertragung von Bits über Kabel, Funk, Glasfaser.

🔹 Schicht 2: Sicherung (Data Link Layer) ➡ Fehlererkennung & -korrektur für eine zuverlässigere Übertragung.

🔹 Schicht 3: Vermittlung (Network Layer) ➡ Routing & Weiterleitung von Datenpaketen (z. B. IP).

🔹 Schicht 4: Transport (Transport Layer) ➡ Stellt eine Verbindung zwischen Endsystemen her (z. B. TCP/UDP).

🔹 Schicht 5: Sitzung (Session Layer) ➡ Synchronisation & Steuerung von Verbindungen zwischen Anwendungen.

🔹 Schicht 6: Darstellung (Presentation Layer) ➡ Umwandlung von Datenformaten (z. B. Zeichencodierung).

🔹 Schicht 7: Anwendung (Application Layer) ➡ Bereitstellung der eigentlichen Anwendungen (z. B. HTTP, FTP, E-Mail).

📌 Merksatz: Bitte Sichere Verbindungen Transportieren Schöne Daten Anwendungen

Einfache Version:

📌 Die 7 Schichten des OSI-Modells – Kurz & Einfach

1️⃣ Bitübertragung: Sendet & empfängt Rohdaten (Kabel, Funk, Glasfaser). 2️⃣ Sicherung: Prüft & korrigiert Übertragungsfehler. 3️⃣ Vermittlung: Leitet Datenpakete durch das Netzwerk (IP-Adressen, Routing). 4️⃣ Transport: Steuert den Datenfluss & stellt Verbindungen her (TCP/UDP). 5️⃣ Sitzung: Hält Verbindungen stabil & synchronisiert sie. 6️⃣ Darstellung: Übersetzt Datenformate (z. B. Zeichencodierung). 7️⃣ Anwendung: Stellt Dienste & Programme bereit (z. B. Webbrowser, E-Mail).

💡 Wichtig: Das OSI-Modell ist theoretisch, das Internet nutzt stattdessen TCP/IP!

Welche Schichten hat das Internet-Schichtenmodell? Wie sieht das Internet-Schichtenmodell aus? Welche Dienste bietet eine Schicht und welche Protokolle hat jede Schicht? Welche Schichten gibt es und welche Protokolle gibt es auf den einzelnen Schichten? Welches Protokoll wird im Internet verwendet? Zählen Sie die fünf Schichten des Internets auf, nennen Sie je ein Beispielprotokoll und erklären Sie, wer auf den Schichten jeweils kommuniziert!


Hier eine einprägsame und optisch optimierte Zusammenfassung der Top-Down-Reihenfolge des OSI-Modells:

📡 OSI-Modell – Top-Down-Betrachtung

🔹 Schicht 7: Anwendungsschicht (Application Layer) 📌 Funktion: Ermöglicht Anwendungen die Nutzung des Netzwerks. 📌 Protokolle: HTTP (Web), SMTP (E-Mail), FTP (Dateitransfer). 📌 Besonderheit: Steuert, wie Anwendungen miteinander kommunizieren.

🔹 Schicht 6: Darstellungsschicht (Presentation Layer) 📌 Funktion: Übersetzt, kodiert und komprimiert Daten. 📌 Beispiele: Verschlüsselung (TLS/SSL), Zeichencodierung (UTF-8, ASCII). 📌 Besonderheit: Sorgt für eine einheitliche Datenrepräsentation zwischen Sender und Empfänger.

🔹 Schicht 5: Sitzungsschicht (Session Layer) 📌 Funktion: Steuert Sitzungen, d. h. den Aufbau, die Verwaltung und den Abbau von Verbindungen. 📌 Beispiele: Sitzungswiederherstellung nach Unterbrechung. 📌 Besonderheit: Synchronisation und Dialogsteuerung zwischen Anwendungen.

🔹 Schicht 4: Transportschicht (Transport Layer) 📌 Funktion: Prozess-zu-Prozess-Kommunikation zwischen Endgeräten. 📌 Protokolle:TCP – zuverlässig, verbindungsorientiert (z. B. für Webbrowser, E-Mail). ✔ UDP – schnell, verbindungslos (z. B. für Videostreaming, VoIP). 📌 Besonderheit: Fehlerkontrolle mit Prüfsummen für Datenintegrität.

🔹 Schicht 3: Vermittlungsschicht (Network Layer) 📌 Funktion: Weiterleitung und Routing von Daten zwischen Netzwerken. 📌 Protokolle: IP (Internet Protocol), ICMP (Fehlermeldungen). 📌 Besonderheit: Bestimmt optimale Routen für die Datenübertragung.

🔹 Schicht 2: Sicherungsschicht (Data Link Layer) 📌 Funktion: Überträgt Datenrahmen (Frames) zwischen direkt verbundenen Geräten. 📌 Protokolle: Ethernet, WLAN (Wi-Fi), PPP (Point-to-Point Protocol). 📌 Besonderheit: Fehlererkennung auf Verbindungsebene.

🔹 Schicht 1: Bitübertragungsschicht (Physical Layer) 📌 Funktion: Überträgt einzelne Bits über physikalische Medien (Kabel, Funk, Glasfaser). 📌 Beispiele: Twisted-Pair-Kabel (Ethernet), Glasfaserkabel, WLAN-Frequenzen. 📌 Besonderheit: Definiert elektrische und mechanische Übertragungsstandards.

💡 Merksatz für die Schichten (von unten nach oben):

Bitte Sag Vater Tim, Das Pizza Ankommt! (Bitübertragung, Sicherung, Vermittlung, Transport, Darstellung, Präsentation, Anwendung)

Bonus: 📡 Netzwerkschnittstellenschicht (Network Interface Layer) = Kombination aus Schicht 1 & 2 🌍 IP-Schicht (Internet Layer) = Bezeichnung für Schicht 3 im Internet-Protokollstack.

Diese Darstellung ist kompakt, gut lesbar und hilft dir, die wichtigsten Punkte schnell zu erfassen! 🚀


Was ist der Unterschied zwischen dem ISO/OSI-Modell und dem Internet-Modell?

Hier eine optisch optimierte und leicht verständliche Zusammenfassung des Internet-Modells im Vergleich zum OSI-Modell:

🌍 Internet-Modell vs. OSI-Modell

📌 Wichtige Unterschiede:

1️⃣ Schichtenanzahl:

  • OSI-Modell: 7 Schichten

  • Internet-Modell: 5 (bzw. 4) Schichten

  • Grund: Schicht 5-7 des OSI-Modells werden in der Internet-Architektur in einer einzigen Anwendungsschicht zusammengefasst.

2️⃣ Struktur und Praxisnähe:

  • OSI-Modell: Strikte Trennung der Schichten, theoretisches Rahmenwerk für die Protokollentwicklung.

  • Internet-Modell: Flexibler & praxisorientierter, um Netzwerke einfacher zu skalieren.

3️⃣ Sichtbarkeit von Daten:

  • Im Internet-Modell sind Port-Nummern (Transportschicht) und IP-Adressen (Vermittlungsschicht) in der Anwendungsschicht sichtbar.

  • Folge: Änderungen in Schicht 3 oder 4 können direkte Auswirkungen auf die Anwendungsschicht haben.

4️⃣ Routing-Protokolle & Flexibilität:

  • Beispiel: DNS (Domain Name System) liegt im OSI-Modell auf Schicht 7, im Internet-Modell jedoch in der Vermittlungsschicht.

  • Grund: Das Internet-Modell verlagert Komplexität in die Ränder des Netzwerks und in die Anwendungsschicht, um Wachstum und Anpassungsfähigkeit zu ermöglichen.

5️⃣ Flusskontrolle:

  • OSI-Modell hat spezialisierte Mechanismen für Flusskontrolle in mehreren Schichten.

  • Im Internet-Modell müssen Anwendungen bei der Verwendung von UDP selbst Mechanismen zur Flusskontrolle implementieren.

🛠 Vergleich der Schichten

OSI-Modell (7 Schichten)

Internet-Modell (5 Schichten)

Anwendungsschicht (7)

Anwendungsschicht (enthält OSI 5-7)

Darstellungsschicht (6)

(integriert in Anwendungsschicht)

Sitzungsschicht (5)

(integriert in Anwendungsschicht)

Transportschicht (4)

Transportschicht (TCP/UDP)

Vermittlungsschicht (3)

Internet-/Vermittlungsschicht (IP)

Sicherungsschicht (2)

Netzwerkschnittstellenschicht

Bitübertragungsschicht (1)

(Teil der Netzwerkschnittstellenschicht)

✨ Fazit:

Internet-Modell = effizienter & praxisorientierter.OSI-Modell = akademisches Idealmodell.Das Internet-Modell (TCP/IP) hat sich in der Praxis durchgesetzt.

🔹 Merke: 📌 OSI = Theorie 🧠 📌 Internet-Modell = Praxis 🌍

Diese Zusammenfassung ist leicht verständlich und hilft dir, die wichtigsten Unterschiede schnell zu erfassen! 🚀


Welche Unterschiede weisen Hosts, Router und Bridges auf? Welche Transitsysteme implementieren welche Internet-Schichten?

Einprägsame Version:

🔹 Komplexitätsverlagerung in der Internet-Architektur:

  • Endsysteme (Hosts):

    • Implementieren alle fünf Schichten des Internet-Modells.

    • Verantwortlich für alle Funktionen, inkl. Transportprotokolle (z. B. TCP, UDP).

  • Transitsysteme (Router, Gateways, Bridges, Switches, Hubs):

    • Keine Transportprotokolle: Sie leiten Daten nur weiter.

    • Router & Gateways:

      • Implementieren Schichten 1 bis 3 (physikalisch, Sicherung und Vermittlung).

      • Erkennen IP-Adressen, routen und verbinden verschiedene Netzwerke.

    • Bridges & Switches (Paket-Switches) sowie Hubs:

      • Implementieren nur Schichten 1 und 2.

      • Arbeiten auf der Basis von MAC-Adressen (z. B. Ethernet).

  • Spezielle Aufgaben:

    • Bridges: Verbinden Netze unterschiedlicher Technologie.

    • Gateways/Gateway-Router: Verbinden unterschiedliche autonome Systeme (Netzwerke mit verschiedenen Routing-Protokollen).

💡 Merke:

  • Endsysteme tragen die ganze Last der Komplexität,

  • Transitsysteme sind auf die reine Weiterleitung spezialisiert.

  • Beide sind unverzichtbar für das Funktionieren des Internets!

Einfache Version:

📌 Wer macht was im Internet?

  • Endsysteme (z. B. Computer):

    • Haben alle 5 Schichten – sie kümmern sich um alles, auch um Transportprotokolle wie TCP/UDP.

  • Transitsysteme (z. B. Router, Gateways, Switches, Hubs):

    • Leiten nur Daten weiter und implementieren nicht den Transport.

    • Router & Gateways: Arbeiten mit den Schichten 1 bis 3 und kennen IP-Adressen.

    • Switches, Bridges & Hubs: Arbeiten nur mit Schicht 1 und 2 und kennen nur MAC-Adressen (wie bei Ethernet).

  • Besonderheiten:

    • Bridges verbinden verschiedene Technologien.

    • Gateways verbinden unterschiedliche Netzwerke (mit verschiedenen Routing-Protokollen).

💡 Kurz gesagt:

  • Computer machen alles,

  • Router & Co. leiten die Daten weiter.

  • Beide Arten von Systemen sind für das Internet wichtig.


Was ist die Internet-Transportschicht? Was kommuniziert miteinander auf der Transportschicht? Welche zwei Dienstarten der Transportschicht bietet das Internet seinen Anwendungen? Welche Dienstmerkmale weisen sie auf? Wie wird das eintreffende Segment dem Prozess zugewiesen?

Zusammenfassung der Transportschicht und ihrer Protokolle:

1. Kommunikationsdienste der Transportschicht: Die Transportschicht bietet zwei grundlegende Kommunikationsdienste auf den Endsystemen:

  • UDP (User Datagram Protocol)

    • Unzuverlässig und verbindungslos.

    • Kein Garantie für den Erhalt oder die Reihenfolge der Pakete.

    • Ähnlich wie der Versand von Postkarten: Es wird einfach versendet, ohne Bestätigung oder Reihenfolge.

    • Eignet sich für: Zeitsensitive, bandbreitensensitive Anwendungen, die gewisse Verluste tolerieren können (z.B. Audio- oder Video-Streaming).

    • Broadcasts unterstützt, aber nicht routbar.

  • TCP (Transmission Control Protocol)

    • Zuverlässig und verbindungsorientiert.

    • Gewährleistet, dass die Daten in der richtigen Reihenfolge und ohne Fehler übertragen werden.

    • Bietet den Eindruck eines durchgehenden Streams (ähnlich wie Telefonie): Ein stetiger, fehlerfreier Datenstrom zwischen zwei Prozessen.

    • Eignet sich für: Anwendungen, bei denen Zuverlässigkeit erforderlich ist (z.B. Web-Browsing, Dateiübertragung).

2. Kommunikation zwischen Prozessen (Sockel-Schnittstelle):

  • Prozesse kommunizieren miteinander durch Sockel (über die Socket API).

  • Eine Anwendung kann mehrere Kommunikations-Threads gleichzeitig haben, die durch Ports adressiert werden.

3. Multiplexen und Demultiplexen:

  • Multiplexen: Sammelt Daten von verschiedenen Prozessen und verpackt sie für die Übertragung.

  • Demultiplexen: Beim Empfang wird entschieden, an welchen Prozess die Daten weitergegeben werden (basierend auf Port-Nummern und ggf. IP-Adressen).

  • Wichtig: Das Demultiplexen erfordert zusätzliche Informationen, z.B. Quell-IP-Adressen oder Quell-Ports, falls mehrere Prozesse denselben Zielport nutzen.

4. Prüfziffern (Checksummen):

  • Sowohl UDP als auch TCP fügen eine Prüfziffer über den gesamten Header und die Payload hinzu, um sicherzustellen, dass keine Fehler in den übertragenen Daten auftreten, da IP keine Fehlerprüfung bietet.

5. Fazit:

  • UDP ist schneller und flexibler, eignet sich jedoch nur für Anwendungen, die Fehler und Verluste tolerieren können.

  • TCP sorgt für Zuverlässigkeit und Datenintegrität, eignet sich jedoch für Anwendungen, bei denen Fehlerfreiheit und Reihenfolge wichtig sind.

Kurze, Einprägsame Version:

🔹 Transportschicht – UDP vs. TCP:

  • UDP: Unzuverlässig, verbindungslos (Postkarten), eignet sich für zeitsensitive Anwendungen (z.B. Live-Streams).

  • TCP: Zuverlässig, verbindungsorientiert (Telefonie), sorgt für fehlerfreie Übertragung (z.B. beim Surfen).

🔹 Multiplexen & Demultiplexen:

  • Multiplexen: Verschiedene Daten von Prozessen werden gesammelt und übertragen.

  • Demultiplexen: Daten werden an den richtigen Prozess weitergeleitet, oft durch Port-Nummern.

🔹 Prüfziffern:

  • UDP und TCP fügen Prüfziffern hinzu, um Fehler in den Daten zu erkennen.

💡 Merke:

  • UDP: Schnell, aber keine Fehlerkontrolle.

  • TCP: Sicher und zuverlässig, aber etwas langsamer.


Wie wird ein Dienst auf einem Server identifiziert? Wie wird der den Dienst anbietende Prozess im Internet adressiert, und wie der anfragende Prozess?

Einprägsame Erklärung:

Stell dir vor, du möchtest mit einem Freund in einem großen Gebäude (dem Internet) kommunizieren. Jeder Raum im Gebäude hat eine eindeutige Adresse (IP-Adresse) und eine Türnummer (Portnummer). Hier ist, wie die Kommunikation funktioniert:

  1. Portnummer:

    • Jede Server-Netzanwendung wird durch eine eindeutige Portnummer (16 Bit breit) identifiziert. Es ist, als ob jede Tür im Gebäude eine Nummer hat, die den Dienst dahinter beschreibt (z. B. „Zimmer 80“ für Webseiten).

    • Allerdings reicht die Portnummer allein nicht aus, um einen spezifischen Dienstprozess zu identifizieren, da ein Server mehrere Threads oder Sockel gleichzeitig bedienen kann.

  2. 4-Tupel:

    • Eine eindeutige Kommunikation zwischen zwei Anwendungen wird durch ein 4-Tupel definiert:

      • IP-Adresse des Server-Hosts: Das Gebäude, in dem der Dienst angeboten wird.

      • IP-Adresse des Client-Hosts: Das Gebäude, von dem die Anfrage kommt.

      • Port-Nummer des Servers: Die Tür, hinter der der Dienst läuft.

      • Port-Nummer des Clients: Die Tür, von der die Anfrage kommt.

    • Dieses 4-Tupel identifiziert eine Ende-zu-Ende-Kommunikation im Internet.

  3. TCP vs. UDP:

    • Bei TCP (zustandsbehaftet) ist das 4-Tupel notwendig, um mehrere gleichzeitige Verbindungen zu unterscheiden.

    • Bei UDP (zustandslos) könnte theoretisch die IP-Adresse und Portnummer des Servers ausreichen, aber in der Praxis muss der Server auch die Client-IP und den Client-Port kennen, um Antworten zurücksenden zu können.

  4. Client-Server vs. Peer-to-Peer:

    • Die Ende-zu-Ende-Kommunikation ist unabhängig davon, ob es sich um ein Client-Server- oder Peer-to-Peer-Modell handelt. Es geht nur darum, dass zwei Anwendungen miteinander kommunizieren.

Einfache Erklärung:

  • Portnummer: Identifiziert eine Server-Netzanwendung auf einem Host.

  • 4-Tupel: Eindeutige Identifikation einer Kommunikation durch:

    • Server-IP, Client-IP, Server-Port, Client-Port.

  • TCP: Zustandsbehaftet, benötigt das 4-Tupel für mehrere Verbindungen.

  • UDP: Zustandslos, aber der Server benötigt Client-IP und -Port für Antworten.

  • Ende-zu-Ende-Kommunikation: Unabhängig von Client-Server oder Peer-to-Peer.


Was ist HTTP? Welche Nachrichtentypen hat HTTP? Kann HTTP nur HTML-Dateien holen? Was ist der Unterschied zwischen nicht-persistenten und persistenten Verbindungen? Welche Verbindungen unterstützen HTTP-Version 1.0 und HTTP-Version 1.1? Welche Vorteile hat ein Web-Cache? Wie funktioniert ein Web-Cache?

Einprägsame Antwort:

  • HTTP (HyperText Transfer Protocol) ist ein zustandsloses Client-Server-Protokoll, das auf ASCII-Anfragen basiert.

  • Anfrage vom Client:

    • Eine typische Anfrage (z.B. GET) enthält eine WWW-Objekt-Referenz für das angeforderte Objekt (z.B. eine HTML- oder Grafik-Datei).

  • Antwort des Servers:

    • Der Web-Server liefert das angeforderte Objekt im MIME-Format.

  • Persistente Verbindungen (ab HTTP 1.1):

    • Mehrere Objekte können nacheinander von demselben Server geladen werden, ohne jedes Mal eine neue Verbindung aufbauen zu müssen.

    • Pipelining: Der Client kann Anfragen senden, ohne auf die vorherige Antwort zu warten.

  • Web-Cache (Proxy-Server):

    • Ein Cache agiert als Server nach innen und als Client nach außen, um die Reaktionszeit zu erhöhen, die Bandbreite zu reduzieren und den internen Client zu anonymisieren.

  • Nicht persistente Verbindung (mit connection: close):

    • Eine explizite Anfrage des Clients, die Verbindung nach der Antwort zu schließen.

  • Beispiel einer Serverantwort:

    • Statuszeile: HTTP-Version, Statuscode (200 für Erfolg), Phrase ("OK").

    • Header-Zeilen: Details zur Lieferung (Datum, Server-Informationen, Objektbeschreibung).

    • Entity Body: Enthält die eigentlichen Daten.

Zusammenfassung (einfache Antwort):

  • HTTP ist ein zustandsloses Protokoll, bei dem der Client Objekte vom Server anfragt und dieser sie im MIME-Format liefert.

  • Persistente Verbindungen (ab HTTP 1.1) ermöglichen das Laden mehrerer Objekte ohne neue Verbindungen.

  • Pipelining beschleunigt Anfragen, indem der Client parallel senden kann.

  • Web-Cache speichert Antworten, um die Reaktionszeit zu verkürzen und Bandbreite zu sparen.


Was ist ein Rechnernetzwerk?

Einprägsame Erklärung:

Ein Rechnernetz (oder Computernetzwerk) ist wie ein Team von Menschen, die zusammenarbeiten, um eine Aufgabe zu erledigen. Jeder im Team hat eine spezielle Rolle, und sie kommunizieren miteinander, um ihre Ziele zu erreichen. Hier ist, wie es funktioniert:

  1. Zweck:

    • Rechnernetze dienen dazu, verteilte Anwendungen zu realisieren. Diese Anwendungen kommunizieren miteinander, indem sie Nachrichten über das Netzwerk austauschen. Es ist, als ob die Teammitglieder sich Briefe schicken, um Informationen auszutauschen.

  2. Komponenten:

    • Endsysteme (Hosts): Das sind die „Hauptakteure“ im Netzwerk, z. B. Computer oder Server, auf denen die Netzwerkanwendungen laufen.

    • Transitsysteme: Dazu gehören Router, Gateways, Switches und Bridges. Sie sind wie die „Vermittler“, die sicherstellen, dass die Nachrichten den richtigen Weg finden.

    • Kommunikationsleitungen: Das sind die „Verbindungsstraßen“, z. B. Kabel oder WLAN, die die Komponenten miteinander verbinden.

  3. Modell eines Netzwerks:

    • Ein Netzwerk kann als Graph dargestellt werden:

      • Knoten: Die Rechner und Peripheriegeräte (z. B. Drucker).

      • Kanten: Die Kommunikationsleitungen, die die Knoten verbinden.

  4. Systemdefinition:

    • Ein System besteht aus verbundenen Komponenten mit einem erwarteten Verhalten. Es interagiert über Schnittstellen mit seiner Umgebung. Es ist, als ob das Team klare Regeln hat, wie es kommuniziert und zusammenarbeitet.

Einfache Erklärung:

  • Rechnernetze ermöglichen verteilte Anwendungen, die über Nachrichtenaustausch kommunizieren.

  • Komponenten:

    • Endsysteme (Hosts): Computer oder Server, auf denen Anwendungen laufen.

    • Transitsysteme: Router, Gateways, Switches, Bridges.

    • Kommunikationsleitungen: Verbinden die Komponenten.

  • Modell: Ein Netzwerk ist ein Graph mit Knoten (Rechner) und Kanten (Leitungen).

  • System: Verbundene Komponenten mit erwartetem Verhalten, die über Schnittstellen interagieren.

Die erste Erklärung ist anschaulich und einprägsam, während die zweite kurz und präzise ist. 😊

New chat

Was ist der Unterschied zwischen den „Anwendungen“ in Schicht 5 und den „Prozessen“ in Schicht 4? Sind dieses denn nicht identische Anwendungs-Prozesse?

Einprägsame Antwort:

  1. Anwendung vs. Prozess:

    • Der Begriff "Anwendung" kann je nach Kontext unterschiedlich gemeint sein:

      • Typ der Anwendung (z. B. Web-Browser wie Firefox).

      • Konkreter Server-Anwendungsprozess, der über mehrere Sockel-Schnittstellen mit verschiedenen Clients kommuniziert.

    • In Schicht 4 wird zwischen Verbindungen (TCP) und Kommunikationen (UDP) unterschieden, nicht zwischen Anwendungen.

  2. Schicht 4 (Transport) - Prozesse und Sockel:

    • Sockel: Technische Schnittstellen, die von Prozessen genutzt werden, um mit anderen Prozessen zu kommunizieren.

    • Prozess-Adressierung: Identität in Schicht 4 bezieht sich auf Sockel (nicht direkt auf die Anwendung). Mehrere Instanzen der gleichen Anwendung können mehrere Sockel gleichzeitig verwenden.

  3. Schicht 4 (Port-Nummern und Demultiplexing):

    • Die Port-Nummer identifiziert den Dienst auf Schicht 5 (Anwendungsprozess).

    • Eindeutige Identifikation einer Verbindung erfolgt durch das 4-Tupel:

      • IP-Adresse des Servers,

      • IP-Adresse des Clients,

      • Port-Nummer des Servers,

      • Port-Nummer des Clients.

  4. Schicht 4 - Transparenz:

    • In Schicht 4 wird keine anwendungsspezifische Information verarbeitet oder verändert (z. B. keine Inhalte der 5-PDU Nachrichten).

Zusammenfassung (einfache Antwort):

  • Anwendung bezeichnet entweder den Anwendungstyp oder den konkreten Anwendungsprozess, der über mehrere Sockel kommunizieren kann.

  • Schicht 4 (Transport) adressiert nicht direkt Anwendungen, sondern Prozesse und deren Sockel, die über Ports und IP-Adressen identifiziert werden.

  • Demultiplexing ermöglicht eine eindeutige Zuordnung der Verbindung über das 4-Tupel (IP-Adressen und Port-Nummern).

  • In Schicht 4 werden keine anwendungsspezifischen Daten verarbeitet.


Was bedeutet Multiplexen und Demultiplexen? Was passiert beim Multiplexen bzw. Demultiplexen? Bei wem (Sender, Empfänger) findet Multiplexen bzw. Demultiplexen statt? Welche Informationen werden bei Multiplexen und Demultiplexen benötigt?

Einprägsame Antwort:

  • Transport- und Vermittlungsschicht im Zusammenspiel:

    • Aufgabe der Transportschicht (Schicht 4):

      • Erweitert die logische Host-zu-Host-Kommunikation der Vermittlungsschicht, sodass mehrere Prozesse auf einem Host adressiert werden können.

      • Multiplexing:

        • Beim Senden:

          • Fügt dem Segment (4-PDU) den Source-Port (zur Identifikation des sendenden Prozesses) und den Destination-Port (zur Identifikation des empfangenden Prozesses) hinzu.

        • Diese Port-Informationen ermöglichen, dass trotz gemeinsamer Host-IP verschiedene Prozesse (bzw. deren Sockel) eindeutig unterschieden werden.

    • Aufgabe der Vermittlungsschicht (Schicht 3):

      • Sorgt für den logischen Datagrammtransport zwischen Hosts.

      • Multiplexing auf Schicht 3:

        • Fügt dem Segment einen Header hinzu, der die Source-Host-IP und Destination-Host-IP enthält.

  • Demultiplexing in der Transportschicht:

    • Empfang eines Segments:

      • Die Transportschicht wertet den Destination-Port aus, um den richtigen Empfangs-Sockel zu identifizieren.

      • Bei TCP kann es zusätzlich nötig sein, auch die Source-IP und den Source-Port zu berücksichtigen – z.B. bei mehreren parallelen Verbindungen vom selben Client.

    • Beispiel-Szenarien:

      • Szenario 1: Zwei Clients von verschiedenen Hosts verwenden zufällig denselben Source-Port → Unterscheidung erfolgt durch die Source-Host-IP.

      • Szenario 2: Zwei Verbindungen desselben Clients (gleiches Quell-Host) werden anhand ihrer unterschiedlichen Source-Ports unterschieden.

    • UDP:

      • Hier reicht oft der Destination-Port, da üblicherweise nur ein Sockel pro Ziel-Port existiert.

  • Kurzfassung:

    • Da die Vermittlungsschicht nur die Kommunikation zwischen Hosts (IP-Adressen) unterstützt, muss die Transportschicht Multiplexing betreiben, um den Nachrichtenstrom den korrekten Prozessen (über ihre Sockel) zuzuordnen – das ist das Demultiplexing.

    • Multiplexing: Fügt kontrollierende Port-Informationen in den 4-PDU-Header ein, bevor die Daten an die Vermittlungsschicht übergeben werden.

    • Demultiplexing: Bei Empfang wird anhand der Port-Nummern (und ggf. IP-Adressen) das Segment dem richtigen Prozess zugeordnet.

Einfache Antwort:

  • Die Transportschicht verwendet Ports, um Daten an den richtigen Prozess zu senden, weil auf Schicht 3 nur ganze Hosts angesprochen werden.

  • Multiplexing: Beim Senden fügt die Transportschicht jedem Segment Quell- und Ziel-Port hinzu.

  • Demultiplexing: Beim Empfangen nutzt die Transportschicht diese Ports (und bei Bedarf auch IP-Adressen), um das Segment an den korrekten Prozess (Sockel) weiterzuleiten.

  • So wird sichergestellt, dass, auch wenn viele Prozesse auf einem Host laufen, jede Nachricht den richtigen Empfänger erreicht.


Welche abstrakten Dienstanforderungen gibt es bezüglich der Transportschicht?

1. Zuverlässigkeit vs. Verlusttoleranz:

  • Zuverlässigkeit:

    • Ziel: Sicherstellen, dass alle Daten zuverlässig übertragen werden, ohne Verluste, Fehler oder Reihenfolgeprobleme.

    • Merkmale:

      • Keine Datenverluste: Alle übertragenen Daten müssen beim Empfänger ankommen.

      • Datenintegrität: Die Daten dürfen nicht verändert werden.

      • Reihenfolge: Daten müssen in der richtigen Reihenfolge ankommen (wichtig für viele Anwendungen wie File-Transfer oder Web-Anfragen).

    • Protokolle: TCP ist ein Beispiel für ein zuverlässiges Protokoll, das diese Eigenschaften garantiert.

  • Verlusttoleranz:

    • Ziel: Die Anwendung ist so gestaltet, dass sie auch bei Datenverlusten oder Fehlern weiter funktioniert. Sie erträgt gewisse Unvollständigkeiten in der Datenübertragung.

    • Merkmale:

      • Fehler können toleriert werden: Verlust oder fehlerhafte Daten haben geringe Auswirkungen auf die Anwendung.

      • Fehlertolerante Mechanismen: Einige Protokolle (z. B. UDP) sind verlusttolerant, da sie keine Bestätigung der gesendeten Daten verlangen.

    • Protokolle: UDP, welches keine Garantie für Lieferung oder Reihenfolge bietet, ist für verlusttolerante Anwendungen geeignet.

2. Bandbreiten-sensitive vs. elastische Anwendungen:

  • Bandbreiten-sensitive Anwendungen:

    • Ziel: Diese Anwendungen benötigen eine konstante und ausreichende Bandbreite für eine korrekte Funktion.

    • Merkmale:

      • Konstante Übertragungsrate: Diese Anwendungen müssen Daten in einem bestimmten Zeitrahmen ohne Verzögerungen oder Schwankungen empfangen.

      • Beispiele: Video-Streaming, VoIP (Sprachanrufe), Online-Gaming.

      • Probleme bei Bandbreitenmangel: Es können Verzögerungen, Pufferungen oder sogar Ausfälle auftreten.

  • Elastische Anwendungen:

    • Ziel: Diese Anwendungen sind weniger empfindlich gegenüber Schwankungen in der Bandbreite und können sich an diese anpassen.

    • Merkmale:

      • Anpassungsfähigkeit: Sie können ihre Anforderungen an die Bandbreite je nach Verfügbarkeit anpassen, ohne die Funktionalität zu beeinträchtigen.

      • Beispiele: Dateiübertragungen (z. B. FTP), E-Mail, Web-Browsing.

      • Flexibilität: Diese Anwendungen können längere Ladezeiten oder Verzögerungen tolerieren.

3. Zeitsensitive Anwendungen:

  • Ziel: Diese Anwendungen müssen Daten innerhalb eines engen Zeitrahmens erhalten und verarbeiten, um ihre Funktion zu erfüllen.

  • Merkmale:

    • Echtzeit: Zeitsensitive Anwendungen benötigen Echtzeit-Kommunikation und können Verzögerungen nicht tolerieren.

    • Beispiele:

      • VoIP (Sprachanrufe), bei denen eine geringe Verzögerung (Latenz) entscheidend ist.

      • Video-Konferenzen, bei denen Latenz und Pufferung das Erlebnis stark beeinträchtigen würden.

      • Industrieautomatisierung, bei der Systeme sofort auf Messdaten reagieren müssen.

    • Probleme bei Verzögerung: Eine zu hohe Verzögerung führt zu Kommunikationsproblemen und beeinträchtigt die Benutzererfahrung.


Wie sieht ein UPD Segment bzw. die UDP-Segmentstruktur aus? Welche Fehler-erkennung bietet UDP? Wie wird die (Internet-)Prüfsumme berechnet?

Der UDP-Header (User Datagram Protocol) ist relativ einfach strukturiert und besteht aus folgenden vier 16-Bit-Feldern:

  1. Quell-Port (Source Port):

    • Größe: 16 Bit

    • Funktion: Gibt den Port des sendenden Prozesses auf dem Quell-Host an.

  2. Ziel-Port (Destination Port):

    • Größe: 16 Bit

    • Funktion: Gibt den Port des Zielprozesses auf dem Ziel-Host an.

  3. Länge (Length):

    • Größe: 16 Bit

    • Funktion: Enthält die Länge des gesamten UDP-Pakets, einschließlich des UDP-Headers und der Anwendungsdaten (Payload).

      • Minimalwert: 8 Bytes (d.h., der Header alleine).

      • Maximalwert: 65535 Bytes, abzüglich der 8 Bytes für den Header und der 20 Bytes für den IPv4-Header.

  4. Prüfziffer (Checksum):

    • Größe: 16 Bit

    • Funktion: Wird verwendet, um die Integrität der Daten zu überprüfen. Sie wird über den gesamten UDP-Header und die Anwendungsdaten berechnet.

    • Berechnung:

      • Die Prüfziffer wird über einen Pseudo-Header berechnet, der auch Teile des IP-Headers (wie Quell- und Ziel-IP-Adressen und Protokolltyp) enthält.

      • Einer-Komplement-Summe: Der Pseudo-Header und die Anwendungsdaten (Payload) werden in 16-Bit-Wörter aufgeteilt und die Einer-Komplement-Summe wird berechnet.

      • Behandlung ungerader Datenlängen: Falls die Anwendungsdaten eine ungerade Anzahl an Bytes haben, wird eine virtuelle Null hinzugefügt, um die Datenlänge auf eine gerade Zahl zu bringen.

Maximale Payload-Größe:

  • Die maximale Größe der Anwendungsdaten (Payload) berechnet sich folgendermaßen: 65535−8 (UDP-Header)−20 (IPv4-Header)=65507 Bytes65535 - 8 \, (\text{UDP-Header}) - 20 \, (\text{IPv4-Header}) = 65507 \, \text{Bytes} Das bedeutet, dass die Anwendungsdaten eines UDP-Pakets bis zu 65507 Bytes umfassen können.

Zusammenfassung des UDP-Headers:

Feld

Größe

Beschreibung

Quell-Port

16 Bit

Port des sendenden Prozesses

Ziel-Port

16 Bit

Port des empfangenden Prozesses

Länge

16 Bit

Gesamtlänge des UDP-Pakets (Header + Payload)

Prüfziffer (Checksum)

16 Bit

Prüfziffer für die Datenintegrität

Die Prüfziffer stellt sicher, dass keine Fehler bei der Datenübertragung auftreten, indem sie eine Integritätsprüfung auf der Empfängerseite durchführt.

 


Warum brauchen wir noch UDP, wenn die Vermittlungsschicht auch einen Dienst mit den Merkmalen wie UDP anbietet?

UDP (User Datagram Protocol) ist aufgrund seiner einfachen Struktur und seines fehlenden Zustandsmanagements eine bevorzugte Wahl für viele Anwendungen, bei denen Geschwindigkeit und geringe Latenz wichtiger sind als die vollständige Gewährleistung von Zuverlässigkeit. Hier ist eine detaillierte Betrachtung der Anwendungen von UDP:

1. Einmalige, zustandslose und kurze Anfragen

  • Beispiel: DNS-Anfragen (Domain Name System)

    • Typische Anwendung: DNS ist ein Protokoll, das IP-Adressen für Domain-Namen auflöst. Diese Anfragen sind in der Regel klein (passen in ein UDP-Segment) und werden ohne weitere Zustandsbehandlung abgewickelt.

    • Funktionsweise: Ein DNS-Client sendet eine Anfrage an den DNS-Server und erwartet sofort eine Antwort. Nach der Beantwortung der Anfrage vergisst der Server die Anfrage und speichert keine Zustände. Dies ist ein Paradebeispiel für die Zustandslosigkeit von UDP, bei der keine komplexen Verbindungen oder Wiederholungsversuche erforderlich sind.

    • Vorteil: Schnelligkeit, da keine Verbindungsaufbau- und Abbauprozeduren wie bei TCP notwendig sind.

2. Schnelligkeit wichtiger als Zuverlässigkeit

  • Beispiel: Audio- und Video-Streaming

    • Typische Anwendung: Dienste wie Video-Streaming (z.B. YouTube, Netflix) oder Audio-Streaming (z.B. Spotify) nutzen häufig UDP, weil die Anwendungslogik darauf ausgelegt ist, Daten mit minimaler Verzögerung zu empfangen und wiederzugeben. Hier wird auf Flusskontrolle, Fehlerkorrektur und Überlaufkontrolle verzichtet, um die Geschwindigkeit der Übertragung zu maximieren.

    • Funktionsweise: Bei Streaming-Anwendungen werden kontinuierlich Datenpakete gesendet, und wenn ein Paket verloren geht oder fehlerhaft ist, kann dies ignoriert werden, solange die Wiedergabe nicht beeinträchtigt wird. Das bedeutet, dass ein Verlust von Datenpaketen keine wesentlichen Auswirkungen auf das Benutzererlebnis hat.

    • Vorteil: Minimierung der Latenz und Vermeidung der Verzögerung durch zusätzliche Fehlerkorrekturen oder Handshake-Prozesse. UDP ermöglicht eine nahezu sofortige Datenübertragung ohne die Notwendigkeit eines Verbindungsaufbaus.

Zusammengefasst:

UDP eignet sich besonders für:

  • Zustandslose Anwendungen, die keine Verbindungsverwaltung benötigen.

  • Echtzeitanwendungen, bei denen die Geschwindigkeit der Übertragung wichtiger ist als die perfekte Übertragung von allen Daten.

  • Anwendungen mit geringer Latenz, wie z.B. DNS oder Streaming-Dienste, bei denen die Daten in Echtzeit verarbeitet und wiedergegeben werden müssen.

Vorteile von UDP:

  • Geringe Latenz: Kein Verbindungsaufbau, keine Flusskontrolle oder Fehlerkorrektur.

  • Effizient: Die einfache Struktur und das Fehlen von Handshakes ermöglichen schnelle Übertragungen.

Nachteile von UDP:

  • Keine Fehlerkorrektur: Es wird keine Garantie für die Zustellung der Daten oder deren Reihenfolge gegeben.

  • Zustandslosigkeit: Der Server muss bei jeder Anfrage einen neuen Prozess starten, da keine Zustandsinformationen gespeichert werden.


Kann man eine ganze Webseite in einem UDP-Datagramm unterbringen? Warum?

Klar! Ich werde die Antwort einmal umformulieren, um sie so einprägsam wie möglich zu machen, und dann eine vereinfachte Version darunter bereitstellen. Dabei achte ich auf klare Struktur und Übersichtlichkeit.

Antwort (einprägsam umgeschrieben):

Anwendungen von UDP

  • Zustandslose Kommunikation

    • Beispiel: DNS-Anfragen

      • Was passiert?: Der Client schickt eine Anfrage, der Server antwortet sofort und vergisst die Anfrage danach.

      • Wieso UDP?: Keine Verbindungsverwaltung, einfach und schnell.

  • Schnelligkeit über Zuverlässigkeit

    • Beispiel: Audio- & Video-Streaming

      • Was passiert?: Daten werden schnell übertragen, verlorene Pakete sind nicht kritisch, weil die Wiedergabe einfach fortgesetzt wird.

      • Wieso UDP?: Minimale Verzögerung, keine Fehlerkorrektur oder Überprüfungen.

Zusammenfassung:

  • UDP ist ideal für schnelle, einfache Kommunikation, bei der Verlust toleriert wird, z.B. bei DNS oder Streaming.

  • Vorteile von UDP: Schnelligkeit und geringe Latenz durch fehlende Verbindungsaufbau- oder Kontrollmechanismen.

  • Nachteile von UDP: Keine Garantie für Zustellung oder Reihenfolge der Daten.

Antwort (vereinfacht):

Anwendungen von UDP

  • DNS-Anfragen: Der Client fragt, der Server antwortet sofort und vergisst es.

  • Streaming: Daten werden schnell übertragen, ohne nach verlorenen Paketen zu suchen.

Zusammenfassung:

  • UDP wird verwendet, wenn Geschwindigkeit wichtiger ist als Zuverlässigkeit.

  • Vorteile: Schnelligkeit, wenig Verzögerung.

  • Nachteile: Keine Garantie für Daten oder Reihenfolge.

 

Was muß ein zuverlässiger Datenübertragungsdienst bzw. ein zuverlässiges Daten-übertragungsprotokoll bei Nutzung eines unterlagerten gestörten Übertragungs-kanals prinzipiell garantieren?

Antwort (einprägsam umgeschrieben):

Zuverlässigkeit der Datenübertragung – Anforderungen

  1. Datenintegrität:

    • Die Daten müssen ohne Bitfehler beim Empfänger ankommen.

  2. Vollständige Lieferung:

    • Alle Daten müssen komplett und ohne Verlust beim Empfängerprozess ankommen.

  3. Reihenfolge der Daten:

    • Die Daten müssen in der richtigen Reihenfolge beim Empfänger ankommen, ohne dass Pakete überholt werden.

  4. Vermeidung von Überflutung:

    • Der Empfänger darf nicht durch zu viele Daten gleichzeitig überlastet werden.

Techniken zur Sicherstellung der Zuverlässigkeit:

  • Kontrollinformationen wie:

    • Prüfziffern, Prüfzummen, ACK/NACK, Quittierungen und Sequenznummern.

    • Timeouts und Hop-Count zur Fehlererkennung.

    • Flusskontrolle (um Überflutung zu vermeiden) und Netzüberlastkontrolle (Congestion Control).

Zusammenfassung:

  • Zuverlässigkeit wird durch Kontrollmechanismen wie Prüfzummen, Bestätigungen und Flusskontrollen gewährleistet, um Bitfehler, Nachrichtenverluste und Reihenfolgenprobleme zu verhindern.

Antwort (vereinfacht):

Zuverlässigkeit der Datenübertragung

  1. Datenintegrität: Keine Bitfehler.

  2. Vollständige Lieferung: Keine Datenverluste.

  3. Reihenfolge: Daten in der richtigen Reihenfolge.

  4. Überflutung vermeiden: Der Empfänger darf nicht überlastet werden.

Techniken:

  • Prüfziffern, ACK/NACK, Sequenznummern, Timeouts.

  • Flusskontrolle und Netzüberlastkontrolle.

Zusammenfassung:

  • Zuverlässigkeit wird durch Kontrollmechanismen wie Bestätigungen und Flusskontrollen sichergestellt.

 

Wie wird ein zuverlässiger Datenübertragungsdienst im Schichtenmodell modelliert?

 

Antwort (einprägsam umgeschrieben):

Zuverlässiger Datentransfer

  1. Übertragung durch unzuverlässiges Netzwerk:

    • Das zuverlässige Datentransferprotokoll nutzt das darunter liegende, unzuverlässige Netzwerkprotokoll (z.B. IP) für die Datenübertragung.

  2. Bilaterale Kommunikation:

    • Zusätzliche Kommunikation zwischen Sender und Empfänger ist notwendig, um sicherzustellen, dass Daten korrekt ankommen und eventuelle Fehler behoben werden.

  3. Fehlerbehebung:

    • Die Fehlerbehebung erfolgt durch den Austausch von Daten und Kontrollinformationen, z.B. durch Bestätigungen (ACKs) oder Wiederholungsanforderungen (NACKs).

  4. Zustandsautomat:

    • Das zuverlässige Datentransferprotokoll kann als Zustandsautomat modelliert werden, der zwischen verschiedenen Zuständen wechselt, abhängig von den empfangenen Bestätigungen oder Fehlern.

  • rdt = Reliable Data Transfer (Zuverlässige Datenübertragung)

  • udt = Unreliable Data Transfer (Unzuverlässige Datenübertragung)

Zusammenfassung:

  • Das zuverlässige Datentransferprotokoll nutzt das unzuverlässige Netzwerk, benötigt jedoch zusätzliche Kommunikation zur Fehlerbehebung und kann als Zustandsautomat dargestellt werden.

Antwort (vereinfacht):

Zuverlässiger Datentransfer

  1. Übertragung durch unzuverlässiges Netzwerk:

    • Das zuverlässige Protokoll verwendet das unzuverlässige Netzwerk für die Übertragung.

  2. Kommunikation:

    • Es gibt eine zusätzliche Kommunikation zwischen Sender und Empfänger, um Fehler zu beheben.

  3. Fehlerbehebung:

    • Fehler werden durch Bestätigungen (ACK) und Wiederholungsanforderungen (NACK) behoben.

  4. Zustandsautomat:

    • Das Protokoll wird als Zustandsautomat modelliert.

  • rdt = zuverlässige Datenübertragung

  • udt = unzuverlässige Datenübertragung

Zusammenfassung:

  • Das zuverlässige Protokoll arbeitet mit einem unzuverlässigen Netzwerk, benötigt aber zusätzliche Kommunikation zur Fehlerbehebung und kann als Zustandsautomat beschrieben werden.


Wie funktionieren Stop-and-Wait-Protokolle?

Antwort (einprägsam umgeschrieben):

Erstes Fehler-Modell: Verlustfreier Übertragungskanal mit garantierter Reihenfolge, aber mit Bitfehlern

1. Möglichkeit der zuverlässigen Datenübertragung:

  • Bitfehlerbehebung durch Redundanz: Ein zusätzliches Fehlererkennungsverfahren, wie z.B. Prüfziffern oder Prüfzummenschwellen, ermöglicht die Erkennung und Behebung von Bitfehlern.

2. Möglichkeit: Stop-and-Wait-Protokoll:

  • Funktionsweise: Der Sender wartet auf eine Bestätigung (ACK) des Empfängers, bevor das nächste Paket gesendet wird.

  • Fehlerproblem: Falls die Bestätigung (ACK) fehlerhaft ist (z.B. NACK wird als ACK erkannt), wird das nächste Paket fälschlicherweise gesendet.

Abhilfe: Stop-and-Wait mit Sequenznummern:

  • Ziel: Der Empfänger soll zwischen wiederholten und neuen Paketen unterscheiden können.

  • Wie: Jedes Paket enthält eine Sequenznummer, sodass der Empfänger weiß, ob es sich um eine Wiederholung handelt oder um das aktuelle Paket. Auch Bestätigungsnachrichten (ACKs oder NACKs) enthalten diese Sequenznummer, um eine fehlerhafte Bestätigung zu erkennen.

ARQ-Protokolle:

  • ARQ steht für „Automatic Repeat reQuest“.

  • Drei wesentliche Fähigkeiten:

    1. Fehlererkennung: Durch Redundanz (z.B. Prüfziffern).

    2. Rückmeldung (ACK/NACK): Vom Empfänger für jedes Paket.

    3. Wiederholung: Bei einem NACK wird das Paket erneut gesendet.

Zusammenfassung:

  • Fehlerbehandlung: Bitfehler durch Prüfziffern, ACK/NACK Rückmeldungen und Wiederholung bei Fehlern.

  • Sequenznummern: Helfen, zwischen Wiederholungen und neuen Paketen zu unterscheiden.

  • ARQ-Protokoll: Grundlage für zuverlässige Datenübertragung unter Berücksichtigung von Bitfehlern.

Antwort (vereinfacht):

Fehler-Modell: Verlustfreier Kanal mit garantierter Reihenfolge, aber Bitfehler

1. Bitfehlerbehebung durch Redundanz:

  • Fehler werden durch zusätzliche Informationen erkannt und korrigiert.

2. Stop-and-Wait-Protokoll:

  • Der Sender wartet auf eine Bestätigung (ACK), bevor er das nächste Paket sendet.

  • Problem: Bei einer fehlerhaften Bestätigung wird das nächste Paket fälschlicherweise gesendet.

Abhilfe: Stop-and-Wait mit Sequenznummern:

  • Jedes Paket hat eine Sequenznummer, die hilft, Wiederholungen zu erkennen.

ARQ-Protokoll:

  • ARQ steht für „Automatische Wiederholung“.

  • Drei Schlüsselmethoden:

    1. Fehlererkennung durch Redundanz.

    2. Bestätigung (ACK/NACK) vom Empfänger.

    3. Wiederholung bei Fehlern.

Zusammenfassung:

  • Fehlerbehebung durch Prüfziffern und Sequenznummern.

  • ARQ-Protokoll sorgt für eine zuverlässige Datenübertragung.


Wie funktionieren Alternating-Bit-Protokolle?

Antwort (einprägsam umgeschrieben):

Zweites Fehler-Modell: Übertragungskanal mit garantierter Reihenfolge, aber Verlust und Bitfehler - Alternating-Bit-Protokoll

1. Behandlung von Paketverlusten:

  • Techniken: Prüfziffern, Sequenznummern und Bestätigungen (ACKs) helfen dabei, Paketverluste zu erkennen und zu behandeln.

  • Wiederholungen: Falls ein Paket verloren geht, wird es erneut gesendet.

2. Erkennung von Paketverlusten:

  • Senderseitig:

    • Countdown-Timer: Beim Senden eines Pakets wird ein Timer gestartet.

    • ACK: Wenn der Sender eine Bestätigung erhält, wird der Timer gestoppt.

    • Timeout: Wenn kein ACK kommt (also der Timer abläuft), wird das Paket erneut gesendet.

    • Fehlerhafte Pakete: Wenn das empfangene Paket fehlerhaft ist, wird es nicht wiederholt.

Problem bei zu kurzem Timeout-Intervall:

  • Falsche Annahme von Paketverlust: Ein zu knapp bemessenes Timeout oder verspätete Telegramme können dazu führen, dass Pakete unnötigerweise erneut gesendet werden.

  • Veraltete ACKs: Der Sender darf nicht aufgrund eines veralteten ACKs eine erneute Übertragung starten, da sonst weitere Bestätigungen fälschlicherweise empfangen und verarbeitet werden.

Zusammenfassung:

  • Behandlung von Paketverlusten: Durch Prüfziffern, Sequenznummern, ACKs und ggf. Wiederholungen.

  • Erkennung von Paketverlusten: Der Sender nutzt einen Timer, um auf Bestätigungen zu warten und bei Timeout Pakete erneut zu senden.

  • Problem mit Timeout: Ein zu kurzes Timeout kann zu unnötigen Wiederholungen führen.

Antwort (vereinfacht):

Fehler-Modell: Übertragungskanal mit garantierter Reihenfolge, aber mit Verlusten und Bitfehlern

1. Behandlung von Paketverlusten:

  • Paketverluste werden mit Prüfziffern, Sequenznummern und Bestätigungen behandelt.

2. Erkennung von Paketverlusten:

  • Countdown-Timer beim Sender: Timer startet beim Senden, wird bei Empfang eines ACKs gestoppt. Bei Timeout wird das Paket erneut gesendet.

  • Fehlerhafte Pakete: Nicht erneut senden.

Problem mit zu kurzem Timeout:

  • Ein zu kurzes Timeout kann dazu führen, dass Pakete unnötig wiederholt werden, was zu falschen Bestätigungen führt.

Zusammenfassung:

  • Paketverlustbehandlung durch Prüfziffern, Sequenznummern und ACKs.

  • Sender verwendet einen Timer, um auf Bestätigungen zu warten und bei Timeout erneut zu senden.




Was ist ein Fenster-Protokoll? Welche Möglichkeiten hat der Empfänger bei der Bestätigung? Was ist der Unterschied zwischen kumulativer und selektiver Bestätigung?

Antwort (einprägsam umgeschrieben):

Fenster-Protokoll

  1. Mehrere Pakete senden:

    • Der Sender kann eine Folge von Paketen senden, ohne auf jede Bestätigung zu warten.

    • Die Fenstergröße bestimmt, wie viele Pakete ohne Rückmeldung gleichzeitig gesendet werden dürfen.

  2. Pufferung und Bestätigung:

    • Der Sender hat einen Puffer (Sendefenster), um Pakete zu speichern, die noch nicht bestätigt oder noch nicht gesendet wurden.

    • Der Empfänger bestätigt nicht jedes Paket einzeln, sondern die kumulative Bestätigung der letzten empfangenen Pakets.

  3. Zeitüberwachung:

    • Der Sender überwacht den Zeitpunkt für jedes Paket oder nur für das „anfänglich“ gesendete Paket.

  4. Empfängerseitige Eingriffe:

    • Zwei Mechanismen zur Fehlerbehebung:

      • Go-back-n: Der Sender muss den Block von n Paketen erneut senden.

      • Selective Reject/Repeat: Nur das fehlerhafte Paket wird erneut angefordert.

  5. Alternating-Bit-Protokoll als Sonderfall:

    • Das Alternating-Bit-Protokoll ist ein Fenster-Protokoll mit einer Fenstergröße von 1.

Antwort (vereinfacht):

Fenster-Protokoll

  • Sender kann mehrere Pakete senden, ohne auf jede Bestätigung zu warten.

  • Fenstergröße: Bestimmt, wie viele Pakete ohne Bestätigung gesendet werden dürfen.

  • Puffer speichert Pakete, die noch nicht bestätigt wurden.

  • Empfänger gibt eine kumulative Bestätigung für die letzte empfangene Nachricht.

  • Fehlerbehebung:

    • Go-back-n: Sender schickt Block von n Paketen erneut.

    • Selective Reject: Nur das fehlerhafte Paket wird erneut gesendet.

  • Alternating-Bit-Protokoll ist ein Fenster-Protokoll mit Fenstergröße 1.


Was ist TCP? Welchen Dienst realisiert TCP? Was bedeutet verbindungsorientierte zuverlässige Kommunikation? Was sagt Ihnen TCP/IP? Welche Dienste hat TCP? Was sind die Merkmale von TCP? Welche Fehler werden verhindert? Welche Fehlerbehandlungen hat TCP?

Antwort (einprägsam umgeschrieben):

Eigenschaften von TCP:

  1. Verbindungsorientiert:

    • TCP stellt eine logische Punkt-zu-Punkt-Verbindung zwischen Sender und Empfänger her. Vollduplex-Kommunikation ermöglicht gleichzeitiges Senden und Empfangen von Daten.

  2. Zuverlässige Datenübertragung:

    • Korrekte Datenübertragung, keine Fehler (Bitfehler).

    • Vollständige Datenübertragung (keine Paketverluste).

    • Richtige Reihenfolge der Daten, wie sie gesendet wurden.

  3. Flusskontrolle:

    • Der Sender wird durch die Flusskontrolle daran gehindert, den Empfängerpuffer zu überfluten.

    • Dynamische Fenstergrößen helfen dabei, die Geschwindigkeit zu regulieren.

  4. Überlastkontrolle:

    • Congestion Control reduziert die Sendegeschwindigkeit bei Netzwerküberlastung, um Staus zu vermeiden.

  5. Bytestrom-Dienst:

    • TCP ist ein Bytestrom-Protokoll: Daten werden byteweise in beide Richtungen gesendet. Nachrichten können im Strom einkodiert werden.

Antwort (vereinfacht):

Eigenschaften von TCP:

  • Verbindung: Logische, zuverlässige Punkt-zu-Punkt-Verbindung.

  • Zuverlässigkeit: Korrekte, vollständige und in der richtigen Reihenfolge ankommende Daten.

  • Flusskontrolle: Verhindert Überflutung des Empfängers.

  • Überlastkontrolle: Reduziert die Sendegeschwindigkeit bei Netzwerküberlastung.

  • Bytestrom: Daten werden byteweise gesendet.

 

Wie wird der Aufbau der Verbindung bei TCP durchgeführt? Welche Informationen werden beim TCP-Verbindungsaufbau ausgetauscht? Warum reicht nicht ein Zwei-Wege-Handschlag bei TCP aus? Warum sind die beiden initialen Sequenznummern beim Aufbau der TCP-Verbindung erforderlich?

TCP Drei-Wege-Handschlag (Connection Establishment):

  1. Client sendet SYN:

    • SYN-Bit wird auf 1 gesetzt.

    • Der Sequenznummer-Feld enthält die initiale Sequenznummer des Clients (client_isn).

    • Das Segment enthält keine Anwendungsdaten.

  2. Server sendet SYN-ACK:

    • SYN-Bit bleibt auf 1.

    • Acknowledgement-Feld zeigt die inkrementierte Sequenznummer des Clients (client_isn + 1).

    • Sequenznummer-Feld enthält die initiale Sequenznummer des Servers (server_isn).

    • Das Segment enthält auch keine Anwendungsdaten.

  3. Client sendet ACK:

    • Der Client bestätigt den Empfang des SYN-ACK-Segments.

    • Die Sequenznummer des Clients wird um 1 erhöht.

    • Damit ist die Verbindung hergestellt.

Warum wird eine Drei-Wege-Handschlag verwendet?

  • Ein Zwei-Wege-Handschlag könnte Duplikate der Client-Nachricht zu mehrfachen Verbindungsaufbauten führen, was zu fehlerhaften Verbindungen und ungewollten Datenübertragungen führen könnte (z.B. doppelte Banküberweisung).

  • Die zufällige Wahl der initialen Sequenznummern hilft, die Wahrscheinlichkeit zu verringern, dass verzögerte Segmente von vorherigen Verbindungen fälschlicherweise der aktuellen Verbindung zugeordnet werden.

TCP Verbindungsabbau:

  1. FIN vom Sender:

    • Das erste FIN-Segment wird vom Sender gesendet, um die Verbindung zu schließen.

  2. ACK vom Empfänger:

    • Das Empfängergerät bestätigt den Empfang des FIN-Segments mit einem ACK.

  3. FIN vom Empfänger:

    • Der Empfänger sendet ein eigenes FIN-Segment, um die Verbindung vollständig zu schließen.

  4. ACK vom Sender:

    • Der Sender bestätigt den Empfang des FIN-Segments und der Verbindungsabbau ist abgeschlossen.

Zusammengefasst:

  • Drei-Wege-Handschlag für eine sichere Verbindung mit zufälligen initialen Sequenznummern zur Vermeidung von Duplikaten und Verwechslungen.

  • Verbindungsabbau erfolgt über FIN-Segmente und die Bestätigung jedes Schrittes durch ACKs.


Welche Informationen stehen im TCP-Header? Wie groß ist der TCP-Header? Wie groß ist die maximale Segmentgröße? Erläutern Sie die TCP-Segmentstruktur! Wie sieht ein TCP-Segment aus? Warum können beliebig viele Segmente mit einer TCP-Verbindung gesendet werden, obwohl die Sequenznummer von TCP-Segmenten begrenzt ist?

Struktur eines TCP-Segments

Ein TCP-Segment besteht aus:

  1. TCP-Header (mindestens 20 Byte):

    • Enthält grundlegende Steuerinformationen wie Sequenznummern, Bestätigungsnummern, Fenstergrößen und Flags.

    • Sequenznummer und Bestätigungsnummer sind jeweils 32 Bit.

    • Fenstergröße (16 Bit) zeigt die Größe des Empfangspuffers an, der beim Empfänger verfügbar ist.

  2. Optionen (optional):

    • Zusätzliche Steuerinformationen, wie z.B. „Maximum Segment Size“ (MSS), „Window Scaling“ oder „Timestamps“.

  3. Anwendungsdaten:

    • Die eigentlichen Nutzdaten des Segments, deren Größe durch die MSS und die MTU der darunterliegenden Schichten begrenzt wird.

TCP-Header Felder:

  • ACK-Bit: Zeigt an, dass die Bestätigungsnummer gültig ist.

  • SYN-Bit: Signalisiert den Beginn eines Verbindungsaufbaus.

  • FIN-Bit: Zeigt an, dass der Sender keine weiteren Daten mehr senden wird.

Maximale Segmentgröße (MSS) und Fragmentierung:

  • MSS (Maximum Segment Size): Die maximal zulässige Größe des TCP-Segments, abhängig von der MTU der darunterliegenden Schicht.

    • Beispiel: Bei Ethernet mit einer MTU von 1500 Byte würde das TCP-Segment eine maximale Größe von 1460 Byte haben (1500 Byte - 20 Byte IPv4-Header - 20 Byte TCP-Header).

  • Fragmentierung: Wenn ein TCP-Segment durch mehrere Netzwerke mit unterschiedlichen MTU-Größen geht, kann es von Routern in kleinere Fragmente aufgeteilt werden. Dies kann die Effizienz der TCP-Verbindung beeinträchtigen und zu Problemen bei der Reihenfolge der Segmente führen.

    • Eine Fragmentierung im IP-Protokoll ist unerwünscht, da sie die Reihenfolge und Integrität der TCP-Segmente beeinträchtigen kann.

Wichtige Faktoren für die Segmentgröße:

  1. Maximale Segmentgröße für IPv4:

    • 65.535 Byte für das IP-Datenfeld.

  2. MTU:

    • Die Maximum Transfer Unit (MTU) ist die maximale Größe eines Pakets, das über ein Netzwerk übertragen werden kann (z.B. 1500 Byte bei Ethernet).

  3. MSS Limitierung:

    • Die Größe des TCP-Segments ist durch die MTU und den IPv4-Header begrenzt. Ein Segment kann also maximal so groß sein wie die MTU minus der Größe des TCP-Headers (20 Byte) und des IPv4-Headers (20 Byte).

    • Beispiel für Ethernet: MSS = 1500 Byte - 20 Byte (TCP) - 20 Byte (IPv4) = 1460 Byte.

Zusammenfassung:

  • Die Größe eines TCP-Segments ist durch die MSS und die MTU der Netzwerke begrenzt.

  • Fragmentierung von TCP-Segmenten im Netzwerk wird vermieden, um die Reihenfolge der Daten und die Effizienz der Verbindung zu gewährleisten.

  • Die Sequenznummern, Bestätigungsnummern, Flags (wie SYN, ACK, FIN) und die Fenstergröße steuern den Fluss und die Zuverlässigkeit der Datenübertragung in TCP.



Wie werden die TCP-Sequenz- und TCP-Bestätigungsnummern verwendet? Wie wird die Sequenznummer eines Segments definiert? Wie funktioniert die Bestätigung bei TCP?

TCP und die Byte-Stromnummerierung

  • Datenstrom und Byte-Stromnummer:

    • TCP realisiert einen Datenstrom von Bytes zwischen Sender und Empfänger. Jedes Byte dieses Stroms wird mit einer Byte-Stromnummer versehen.

    • Die Sequenznummer eines Segments ist die Byte-Stromnummer des ersten Bytes dieses Segments.

Beispiel: Dateiübertragung (10000 Byte)

  1. Dateigröße und Segmentierung:

    • Ein Anwendungsprozess möchte eine Datei von 10.000 Byte an den Empfänger verschicken.

    • Die Maximum Segment Size (MSS) ist auf 1000 Byte Anwendungsdaten pro Segment festgelegt.

    • Der Anwendungsprozess schreibt diese 10.000 Byte in den Socket. TCP teilt die Datei in 10 Segmente, wobei jedes Segment 1000 Byte Anwendungsdaten enthält.

  2. Sequenznummern:

    • Das erste Byte des ersten Segments wird mit i nummeriert (wobei i = client_isn + 1 die Initial Sequence Number des Clients ist).

    • Segment 1 enthält die Bytes i bis i + 999, die Sequenznummer ist i.

    • Segment 2 enthält die Bytes i + 1000 bis i + 1999, die Sequenznummer ist i + 1000.

    • So werden alle 10 Segmente fortlaufend nummeriert.

Bestätigungen und Bestätigungsnummern (ACKs)

  • Bestätigungsnummern (ACKs):

    • Die Bestätigungsnummer gibt an, welches Byte als nächstes erwartet wird.

    • Wenn das Server-TCP die ersten beiden Segmente korrekt empfangen hat, aber das dritte Segment noch nicht, dann gibt das Server-TCP als Bestätigungsnummer die Byte-Stromnummer i + 2000 an, um zu signalisieren, dass das nächste erwartete Byte i + 2000 ist.

Kumulative Bestätigung

  • Kumulative Bestätigung:

    • TCP verwendet eine kumulative Bestätigung, das heißt, dass immer die nächste fehlende Byte-Nummer bestätigt wird.

    • Falls ein Segment verloren geht oder später ankommt, gibt das Server-TCP weiterhin nur die Nummer des nächsten erwarteten Bytes als Bestätigungsnummer an.

Handling von verspäteten oder verlorenen Segmenten

  • Verhalten bei verspäteten oder verlorenen Segmenten:

    • Wenn das Server-TCP Segmente empfängt, die später im Datenstrom liegen (z.B. wenn ein Segment verloren gegangen ist), gibt es immer noch nur die Bestätigungsnummer für das nächste erwartete Byte an, auch wenn es Segmente mit späteren Byte-Stromnummern gibt.

    • Implementierungsabhängige Handhabung:

      • Das Server-TCP kann diese verspäteten Segmente puffern und darauf warten, dass die fehlenden Daten ankommen. Sobald alle Daten bis zu einem bestimmten Punkt empfangen wurden, gibt das Server-TCP eine Bestätigung für die nächste fehlende Byte-Stromnummer aus.

      • Alternativ kann das Server-TCP die verspäteten Daten verwerfen und das Client-TCP zur Wiederholung auffordern.

Zusammenfassung:

  • Byte-Stromnummern und Sequenznummern helfen dabei, den Datenstrom zwischen Sender und Empfänger in TCP zu ordnen.

  • Bestätigungsnummern erlauben es, den aktuellen Fortschritt der Datenübertragung zu verfolgen und festzulegen, welche Daten als nächstes erwartet werden.

  • Kumulative Bestätigung stellt sicher, dass auch bei verloren gegangenen oder verspäteten Segmenten keine fehlerhaften Bestätigungen versendet werden.

  • Implementierungsabhängig kann der Empfänger verspätete Segmente puffern oder diese verwerfen, wenn sie nicht in der richtigen Reihenfolge empfangen werden.


Was ist die Sequenznummer eines Segments?

Sequenznummer und Bestätigungsnummer in TCP

  1. Sequenznummer:

    • Die Sequenznummer eines TCP-Segments entspricht der Byte-Stromnummer des ersten Anwendungsdaten-Bytes in diesem Segment.

    • Die initiale Sequenznummer (ISN) wird zu Beginn der Verbindung festgelegt. Im Beispiel wird die initiale Sequenznummer als 0 angenommen.

    • Die Sequenznummer eines Segments ist die Sequenznummer des vorherigen Segments plus die Anzahl der Datenbytes, die das vorherige Segment enthalten hat.

    Beispiel für drei Segmente:

    • Segment 1:

      • Sequenznummer = 0

      • Enthält z.B. 500 Bytes Anwendungsdaten.

    • Segment 2:

      • Sequenznummer = 500 (500 ist die Anzahl der Bytes im vorherigen Segment)

      • Enthält ebenfalls 500 Bytes Anwendungsdaten.

    • Segment 3:

      • Sequenznummer = 1000 (500 + 500)

      • Enthält 500 Bytes Anwendungsdaten.

  2. Bestätigungsnummer:

    • Die Bestätigungsnummer gibt die Byte-Stromnummer des nächsten zu erwartenden Bytes an.

    • Sie zeigt also das nächste Byte, das der Empfänger vom Sender erwartet.

    • Die Bestätigungsnummer entspricht der Sequenznummer des nächsten Segments, das der Empfänger noch nicht empfangen hat. Das bedeutet, sie gibt an, bis zu welchem Punkt im Datenstrom der Empfänger bereits empfangen hat.

    Beispiel:

    • Wenn das Server-TCP Segment 1 (mit Sequenznummer 0) und Segment 2 (mit Sequenznummer 500) korrekt erhalten hat, aber Segment 3 noch nicht, dann erwartet der Empfänger das nächste Byte mit Sequenznummer 1000.

    • Daher wird im ACK-Segment des Empfängers die Bestätigungsnummer 1000 gesendet, was bedeutet, dass der Empfänger bis Byte 999 korrekt empfangen hat und jetzt auf Byte 1000 wartet.

Zusammenhang zwischen Bestätigungsnummer und Segmentanforderung:

  • Bestätigung eines Segments = Anforderung eines neuen Segments:

    • Wenn der Empfänger eine Bestätigungsnummer sendet, bedeutet dies, dass er die Daten bis zu dieser Byte-Stromnummer erhalten hat und das nächste Segment erwartet.

    • Der Empfänger fordert damit effektiv das nächste Segment an.

Zusammenfassung:

  • Sequenznummer: Die Nummer des ersten Anwendungsdaten-Bytes im Segment, basierend auf der vorherigen Sequenznummer und der Anzahl der Datenbytes.

  • Bestätigungsnummer: Die Byte-Stromnummer des nächsten Bytes, das der Empfänger erwartet.

  • Bestätigung eines Segments durch den Empfänger ist gleichzeitig eine Aufforderung an den Sender, das nächste Segment zu senden.



Was passiert, wenn im Netzwerk noch verspätete Pakete einer mittlerweile schon abgebauten TCP-Verbindung ankommen? Wann könnte das ein Problem sein?

Verspätete Pakete und Verbindungsaufbau in TCP

  1. Verzögerte Datenpakete:

    • Verspätete Pakete, die während einer bestehenden Verbindung eintreffen, aber nicht mehr zu der aktuellen Sitzung gehören, werden verworfen.

    • Das liegt daran, dass sie keiner bestehenden Verbindung zugeordnet werden können.

    • Ein Paket könnte nur dann in eine Verbindung aufgenommen werden, wenn es zu einer neueren Verbindung mit denselben IP-Adressen und Port-Nummern passt und die Bestätigungsnummer im aktuellen Fenster liegt. Das ist jedoch extrem unwahrscheinlich.

  2. Verspätete Verbindungsanforderung:

    • Wenn eine verspätete Verbindungsanforderung (z.B. ein SYN-Paket) mit einer initialen Sequenznummer beim Empfänger eintrifft, wird sie in der Regel wie folgt behandelt:

      • Der Empfänger bestätigt zunächst das Paket mit der gleichen initialen Sequenznummer des Absenders.

      • Zusätzlich gibt er seine eigene initiale Sequenznummer für den Rückweg zurück.

      • Diese scheinbare Verbindung wird jedoch nicht zustande kommen, weil sie in der Regel nicht zu einem aktiven Verbindungsversuch auf der Absenderseite gehört.

  3. Extrem unwahrscheinlicher Fall:

    • In sehr seltenen Fällen kann es passieren, dass eine neue Verbindung mit denselben IP-Adressen, Port-Nummern und der selben initialen Sequenznummer wie der vorherige Verbindungsversuch gleichzeitig aufgebaut wird.

    • In diesem Fall könnte das ACK-Paket die alte Verbindungsanforderung noch bestätigen, was jedoch eine extrem unwahrscheinliche Situation darstellt.

Zusammenfassung:

  • Verspätete Pakete ohne Bezug zu einer bestehenden Verbindung werden verworfen, es sei denn, sie passen zufällig zu einer neuen Verbindung mit denselben Parametern.

  • Verspätete Verbindungsanforderungen werden vom Empfänger mit der initialen Sequenznummer bestätigt, ohne dass eine echte Verbindung zustande kommt, da diese normalerweise keinem Verbindungsversuch zugeordnet werden können.

  • Ein extrem unwahrscheinlicher Fall tritt auf, wenn ein erneuter Verbindungsaufbau mit denselben Parametern stattfindet und die Bestätigung noch aussteht.


Im Abschnitt 3.4.5.5 wird ein vereinfachtes TCP-Senderprogramm gezeigt. Wie wird der zuverlässige Datentransfer hier realisiert?

Klar, ich werde die Antwort in zwei Varianten umschreiben:

  1. Einprägsamere Variante (mit optischen Hilfsmitteln):

Fehlerbehandlung und Wiederholung in TCP

  • Datenübertragung und Timer:

    • Der Sender verpackt Daten und überträgt sie in Segmente an die Vermittlungsschicht.

    • Wenn alle Segmente bestätigt sind, Timer starten.

  • Timerablauf und Wiederholung:

    • Timer läuft ab?: Segment, das noch nicht bestätigt wurde, wird wiederholt.

  • ACK und Bestätigung:

    • Empfangene Segmente werden mit einer Bestätigungsnummer zurückgemeldet.

    • Bestätigungsnummer gibt die nächste erwartete Sequenznummer an.

  • Verhalten des Senders bei ACKs:

    • Wenn N > sendbase:

      • Neue Bestätigung: Sender schiebt sendbase weiter, setzt Timer neu.

    • Wenn N ≤ sendbase:

      • N < sendbase: Duplicate ACK → Sender ignoriert.

      • N = sendbase: Segment vermutlich verloren → Fast Retransmit.

  • Fast Retransmit:

    • Nach 3 Duplicate ACKs wird das verloren gegangene Segment sofort wieder gesendet.

    • Zähler für Duplicate ACKs wird auf 0 gesetzt.

  1. Einfachere Variante (kürzer und klarer):

Fehlerbehandlung in TCP

  • Timer:

    • Wenn ein Segment nicht bestätigt wird, wiederholt der Sender die Übertragung nach Timer-Ablauf.

  • Bestätigung (ACK):

    • Empfangene Segmente werden mit der Bestätigungsnummer zurückgemeldet, die die nächste erwartete Sequenznummer angibt.

  • Duplicate ACK:

    • Wenn die Bestätigungsnummer N ≤ sendbase ist, wird das Segment möglicherweise erneut übertragen, wenn 3 Duplicate ACKs vorliegen (Fast Retransmit).


Warum wiederholt (fast retransmit) der Sender die erneute Übertragung eines Segments erst, wenn er drei ACK-Duplikate dafür erhalten hat? Warum wird für jedes Segment ein Timer gestartet?


Natürlich! Hier ist die Antwort, optisch aufgearbeitet:

  1. Einprägsame und strukturierte Variante:

Fast Retransmit in TCP

  • Was ist Fast Retransmit?

    • Der Sender wiederholt ein Segment:

      • Wenn drei gleiche ACKs (Duplicate ACKs) für dasselbe Segment empfangen werden.

      • Oder vorzeitig, wenn der Retransmit-Timer abläuft.

  • Beispiel:

    1. Angenommene Segmente:

      • Segmente 0 und 330 wurden korrekt empfangen.

      • Segment 250 fehlt beim Empfänger.

    2. Empfänger sendet ACKs:

      • Er bestätigt mehrfach Nummer 250, da dieses Segment noch fehlt.

    3. Was passiert beim Sender?

      • Beim ersten ACK weiß der Sender: „Alles bis Segment 250 - 1 ist angekommen.“

      • Beim zweiten ACK spekuliert der Sender, dass Segment 250 noch ankommt und wartet.

      • Drittes ACK: Der Sender erkennt, dass Segment 250 noch fehlt und sendet es sofort erneut.

  • Warum drei ACKs?

    • Drei ACKs bieten einen Kompromiss zwischen:

      • Schnellem Wiederholen der verlorenen Segmente.

      • Vermeidung von unnötigen Wiederholungen und Belastung des Netzes.

  • Retransmit-Timer:

    • Kann entweder global für alle Segmente oder individuell für jedes Segment ausgelöst werden.

  1. Einfachere Variante:

Fast Retransmit

  • Der Sender wiederholt ein Segment:

    • Wenn er drei gleiche ACKs erhält.

    • Oder wenn der Retransmit-Timer abläuft.

  • Beispiel:

    1. Sender sendet Segment 250, aber es geht verloren.

    2. Der Empfänger sendet drei Mal das ACK für 250.

    3. Der Sender sendet Segment 250 nach dem dritten ACK erneut.

  • Warum drei ACKs?

    • Das stellt sicher, dass der Sender nicht zu oft wiederholt und gleichzeitig schnell reagiert.


Was passiert falls der Senderprozess die Daten schneller sendet, als sie vom Empfängerprozess gelesen werden? Welche Ziele verfolgen die Flusskontrolle und Überlastungskontrolle? Wie funktioniert die Flusskontrolle bei TCP?

Natürlich, hier ist die umstrukturierte und optisch aufbereitete Antwort:

  1. Einprägsame und strukturierte Variante:

Flusskontrolle in TCP (Flow Control)

Ziel der Flusskontrolle:

  • Vermeidung einer Überlastung des Empfängers durch Steuerung der Senderate.

Wie funktioniert es?

  • Empfänger informiert den Sender über den verfügbaren Pufferplatz:

    • Jeder TCP-Prozess hat eine Empfangsfenster-Variable (receive window).

    • Diese zeigt an, wie viel freier Pufferplatz beim Empfänger noch verfügbar ist.

  • Sender passt seine Datenrate an:

    • Der Sender sendet nur so viele Daten, wie noch Platz im Empfangspuffer vorhanden ist.

    • In jedem Segment sendet der Empfänger den freien Pufferplatz im „Fenstergröße“ (WINDOW)-Feld des TCP-Headers.

  • Was passiert, wenn der Puffer voll ist?

    • Wenn kein Platz mehr im Empfangspuffer ist, stoppt der Sender die Datenübertragung.

    • Der Sender wartet, bis er ein Segment erhält, das wieder freien Platz meldet.

  • Leere Segmente:

    • Falls der Empfänger keine Anwendungsdaten hat, sendet er leere Segmente mit der Meldung des freien Puffers.

    • Ohne diese leeren Segmente würde der Sender blockiert und könnte keine Daten mehr senden.

Überlastungskontrolle (Congestion Control)

  • Ziel: Verringerung der Senderate, wenn das Netzwerk überlastet ist.

    • Dies geschieht durch den Congestion Window-Mechanismus, der die Senderate entsprechend anpasst.

    • Vergleich: Der „Sliding Window“-Mechanismus für die Flusskontrolle und das „Congestion Window“ für die Überlastungskontrolle arbeiten in verschiedenen Bereichen.

  1. Einfachere Variante:

Flusskontrolle in TCP

  • Was macht Flusskontrolle?

    • Sie verhindert, dass der Empfänger überlastet wird, indem der Sender nur so viele Daten sendet, wie im Empfangspuffer noch Platz ist.

  • Wie funktioniert das?

    • Der Empfänger gibt dem Sender den freien Platz im Puffer an.

    • Der Sender sendet nur, wenn noch Platz im Empfangspuffer ist. Wenn der Puffer voll ist, stoppt er den Versand.

  • Was passiert, wenn der Puffer voll ist?

    • Der Sender wartet auf leere Segmente vom Empfänger, um den freien Platz zu erfahren.

Überlastungskontrolle

  • Wenn das Netzwerk überlastet ist, verringert der Sender seine Senderate mithilfe des Congestion Windows.


Wofür wird die Segment-Länge im UDP-Header benötigt? Warum gibt es dieses Feld  bei TCP nicht?


  1. Einprägsame und strukturierte Variante:

Segmente und IP-Datagramme: Wie werden sie zusammengefügt?

Aufteilung eines Segments:

  • UDP- oder TCP-Segment wird an die IP-Schicht zur Übertragung übergeben.

  • Wenn die IP-Schicht das Segment in mehrere IP-Datagramme aufteilen muss, kann die empfangende IP-Schicht die Datagramme nicht mehr in der richtigen Reihenfolge zum ursprünglichen Segment zusammenfügen.

Warum?

  • Ein IP-Datagramm garantiert die Reihenfolge der Daten innerhalb des Datagramms, aber nicht über mehrere Datagramme hinweg.

  • Segmente (z. B. von UDP oder TCP) sind atomare Einheiten und müssen vollständig in einem IP-Datagramm transportiert werden.

Wie wird das Segment transportiert?

  • Jedes Segment muss genau in einem IP-Datagramm enthalten sein. Das IP-Datagramm darf dabei jedoch auf mehrere Pakete aufgeteilt werden.

  • Die Länge des IP-Datagramms ermöglicht es, die Länge des enthaltenen Segments (für UDP und TCP) auf Empfängerseite zu berechnen.

Bedeutung des Segment-Längen-Felds:

  • Bei IPv4 ist das Segment-Längen-Feld im Header nicht unbedingt notwendig, da die Länge des Segments auch implizit berechnet werden kann.

  • Das Segment-Längen-Feld wird konzeptionell zur Anwenderschicht hin genutzt, um die Länge zu verifizieren.

Unterschied zwischen UDP und TCP:

  • UDP ist paketbasiert, während TCP stream-basiert ist.

  • Das Segment-Längen-Feld hilft zu verdeutlichen, dass UDP nachrichtenorientiert arbeitet, während TCP einen Datenstrom darstellt.

  1. Einfachere Variante:

Segmente und IP-Datagramme

  • UDP- und TCP-Segmente werden an die IP-Schicht zur Übertragung weitergegeben.

  • IP kann ein Segment in mehrere IP-Datagramme aufteilen, aber die Reihenfolge der Datagramme kann nicht garantiert werden.

Warum?

  • Ein Segment muss immer in einem einzigen IP-Datagramm enthalten sein. Nur dann kann die Reihenfolge beibehalten werden.

Segment-Länge:

  • Die Länge des IP-Datagramms ermöglicht es, die Länge des Segments zu berechnen.

  • Bei IPv4 ist das Segment-Längen-Feld im Header nicht unbedingt nötig, wird aber zur Verifizierung verwendet.

Unterschied zwischen UDP und TCP:

  • UDP ist paketbasiert, während TCP stream-basiert ist.


Wie werden TCP Segmente bestätigt?

  1. Einprägsame und strukturierte Variante:

Kumulative Bestätigung vs. Go-Back-n-Protokoll

Kumulative Bestätigung:

  • Der Empfänger bestätigt den Empfang einer Folge von Segmenten, ohne jedes Segment einzeln bestätigen zu müssen.

  • Beispiel: Der Empfänger erhält Segmente mit den Sequenznummern 0 und 250 und insgesamt 330 Byte korrekt.

    • Der Empfänger sendet dann eine Bestätigungsnummer 330.

    • Ergebnis: Der Sender weiß, dass alle Segmente bis 330 korrekt empfangen wurden, auch wenn das Segment mit 250 nicht explizit bestätigt wurde.

Go-Back-n-Protokoll:

  • Der Empfänger bestätigt nur die lückenlos korrekt empfangenen Segmente.

  • Beispiel: Der Sender schickt Segmente mit den Sequenznummern 0, 250 und 330.

    • Der Empfänger erhält korrekt die Segmente 0 und 330, aber nicht 250.

    • Der Empfänger bestätigt mit Bestätigungsnummer 250.

    • Ergebnis: Der Sender muss alle unbestätigten Segmente (hier 250 und 330) erneut senden, da der Empfänger das Segment mit 330 nicht gespeichert hat.

Unterschied:

  • Bei der kumulativen Bestätigung reicht eine einzige Bestätigung, um alle vorherigen Segmente zu bestätigen.

  • Beim Go-Back-n-Protokoll müssen unbestätigte Segmente wiederholt gesendet werden.

  1. Einfachere Variante:

Kumulative Bestätigung vs. Go-Back-n-Protokoll

Kumulative Bestätigung:

  • Der Empfänger bestätigt alle Segmentfolgen mit einer einzigen Zahl.

    • Beispiel: Der Empfänger erhält Segmente 0 und 250 und bestätigt mit 330, dass alles bis dorthin korrekt angekommen ist.

Go-Back-n-Protokoll:

  • Der Empfänger bestätigt nur korrekt empfangene Segmente.

    • Beispiel: Der Empfänger bekommt Segmente 0 und 330 und bestätigt mit 250. Der Sender muss die ungesendeten Segmente erneut schicken.

Unterschied:

  • Bei der kumulativen Bestätigung reicht eine Bestätigung für alle vorherigen Segmente.

  • Beim Go-Back-n-Protokoll müssen unbestätigte Segmente erneut gesendet werden.


Über was wird die Prüfsumme in einem TCP-Segment gebildet?

  1. Einprägsame und strukturierte Variante:

TCP-Prüfsumme

Warum benötigt TCP eine Prüfsumme?

  • IP-Protokoll garantiert nicht die Zuverlässigkeit der Datenübertragung.

  • TCP fügt eine Prüfsumme hinzu, um die Integrität der übertragenen Daten zu gewährleisten.

Berechnung der Prüfsumme:

  • Das Segment wird ohne das Prüfsummenfeld als 16-Bit-Wörter (2 Byte pro Wort) betrachtet.

  • Alle 16-Bit-Wörter werden mit Einer-Komplement-Arithmetik addiert:

    • Überlauf: Der Übertrag wird niederwertig zur Summe hinzugefügt.

    • Die resultierende Summe wird dann invertiert (Einer-Komplement) → Prüfziffer.

Prüfung der Prüfsumme (Empfänger-Seite):

  • Der Empfänger berechnet selbst die Summe der 16-Bit-Wörter des Segments.

  • Er fügt dann die übertragene Prüfziffer hinzu.

  • Ergebnis: Es sollte 0xFFFF ergeben, wenn keine Fehler aufgetreten sind.

Einschränkung der Prüfsumme:

  • Sie stellt sicher, dass keine einzelnen Bitfehler aufgetreten sind, jedoch nicht, dass die Daten vollständig korrekt sind.

Pseudo-Header:

  • Pseudo-Header enthält Teile des IP-Headers und wird für die Prüfzifferberechnung verwendet, aber nicht übertragen.

  • Einer-Komplement-Fehlerkorrektur: Ein Übertrag wird beim Addieren der Summe durch das hinzufügen von 1 korrigiert.

  1. Einfachere Variante:

TCP-Prüfsumme

Warum Prüfsumme?

  • TCP verwendet eine Prüfsumme, weil IP keine Fehler garantiert.

Wie wird die Prüfsumme berechnet?

  • Die Daten des Segments werden als 16-Bit-Wörter betrachtet.

  • Diese Wörter werden addiert, der Übertrag wird mit dazugezählt.

  • Das Einer-Komplement der Summe ergibt die Prüfziffer.

Empfängerprüfung:

  • Der Empfänger berechnet die gleiche Summe und fügt die Prüfziffer hinzu.

  • Das Ergebnis sollte 0xFFFF sein, wenn keine Fehler da sind.

Einschränkung der Prüfziffer:

  • Sie erkennt Bitfehler, aber nicht alle Fehler.

Pseudo-Header:

  • Der Pseudo-Header enthält Teile des IP-Headers und wird für die Prüfzifferberechnung verwendet, aber nicht übertragen.

  • Korrektur: Falls bei der Berechnung ein Übertrag entsteht, wird dieser durch das Hinzufügen von 1 korrigiert.


Mit welchen Mechanismen wird der TCP-Dienst realisiert? Wie wird mit TCP ein zuverlässiger Datentransfer bewerkstelligt? Wie wird Zuverlässigkeit in TCP erreicht?

  1. Einprägsame und strukturierte Variante:

Mechanismen für die zuverlässige Datenübertragung bei TCP

1. Verbindung aufbauen (Drei-Wege-Handshake)

  • Ziel: Eine zuverlässige Verbindung zwischen Sender und Empfänger wird hergestellt.

  • Eine zufällige initiale Sequenznummer wird vereinbart.

2. Nummerierung der Anwendungsdaten

  • Daten werden byteweise nummeriert, beginnend mit der initialen Sequenznummer + 1.

3. Sicherstellen der richtigen Übertragung

  • Um Daten korrekt und in der richtigen Reihenfolge zu übertragen, nutzt TCP:

    • Prüfsumme: Verifiziert die Korrektheit der Daten.

    • Sequenznummern: Dienen der richtigen Reihenfolge der Daten.

    • Bestätigung (ACK): Bestätigt, dass Daten erfolgreich angekommen sind.

    • Timeout: Sender wartet eine bestimmte Zeit auf Bestätigung. Falls keine kommt, wird das Segment erneut gesendet.

4. Flusskontrolle (Empfänger-Fenstergröße)

  • TCP-Header enthält das Feld Empfänger-Fenstergröße.

  • Dieses Feld zeigt an, wie viel freien Pufferplatz der Empfänger noch zur Aufnahme von Daten hat.

  1. Einfachere Variante:

Wie TCP für zuverlässige Datenübertragung sorgt

1. Drei-Wege-Handshake

  • Der Sender und Empfänger bauen eine Verbindung auf und vereinbaren eine zufällige Sequenznummer.

2. Nummerierung der Daten

  • Jedes Byte wird nummeriert ab der initialen Sequenznummer + 1.

3. Mechanismen für korrekte Übertragung

  • Prüfsumme: Überprüft, ob die Daten richtig angekommen sind.

  • Sequenznummern: Stellt sicher, dass die Daten in der richtigen Reihenfolge sind.

  • Bestätigung (ACK): Zeigt, dass die Daten angekommen sind.

  • Timeout: Wenn keine Bestätigung kommt, wird das Segment erneut gesendet.

4. Flusskontrolle

  • Empfänger-Fenstergröße im TCP-Header zeigt, wie viele Daten der Empfänger noch verarbeiten kann.


Was ist der Unterschied zwischen TCP und UDP? Was heißt TCP bzw. UPD ausgeschrieben? Welche Dienste stellen sie zur Verfügung? Wer kommuniziert über diese Protokolle? Für welche Anwendung benutzt man UDP und TCP? Wenn TCP besser ist als UDP, setzt man dann überhaupt noch UDP ein oder braucht man das nicht mehr? Nennen Sie Protokolle auf der Transportschicht und deren Unterschiede!

Wann sollte welches Protokoll verwendet werden?

UDP (User Datagram Protocol)

  • Eigenschaften:

    • Verbindungslos: Kein Verbindungsaufbau oder -abbau.

    • Einfacher Header (8 Byte): Weniger administrativer Aufwand im Vergleich zu TCP.

    • Keine Flusskontrolle: Es wird so viel gesendet, wie das System und die Netzwerkressourcen zulassen.

    • Unzuverlässig: Es gibt keine Garantie für den Empfang von Nachrichten; Pakete können verloren gehen.

  • Wann verwenden?:

    • Schnelle Übertragung mit akzeptablem Verlust: Wenn es wichtiger ist, Daten schnell zu übertragen und kleine Verluste akzeptabel sind (z.B. bei Streaming und Telefonie).

    • Hohe Anzahl von Verbindungen: UDP benötigt keine Sitzungsinformationen, sodass es mehr Clients bedienen kann.

    • Echtzeitanwendungen: Wie VoIP oder Videostreaming, bei denen der Verlust von Paketen eher eine geringe Auswirkung hat, da die Daten ohnehin in Echtzeit übertragen werden und die Qualität auch bei Verlust noch akzeptabel sein kann.

    • Protokolle mit kurzer Kommunikation: Z.B. DNS, bei dem fehlende Anfragen einfach erneut gestellt werden können.

  • Beispielanwendungen:

    • Streaming Media (Video-Übertragungen)

    • Internet-Telefonie (VoIP)

    • DNS (Domain Name System)

    • Netzwerkmanagement-Protokolle (SNMP)

TCP (Transmission Control Protocol)

  • Eigenschaften:

    • Verbindungorientiert: Initiale Verzögerung durch den 3-Wege-Handshake.

    • Zuverlässig: Daten werden garantiert und in der richtigen Reihenfolge geliefert.

    • Flusskontrolle und Fehlerkorrektur: TCP sorgt für die Kontrolle von Datenflüssen und die Korrektur von Fehlern oder Paketverlusten.

    • Größerer Header (20 Byte): Höherer administrativer Aufwand und mehr Overhead im Vergleich zu UDP.

  • Wann verwenden?:

    • Zuverlässigkeit und Datenintegrität: Wenn es wichtig ist, dass alle Daten korrekt und in der richtigen Reihenfolge ankommen.

    • Anwendungen, die Flusskontrolle und Fehlerbehebung benötigen: Wenn die Datenverbindung stabil sein muss und verlorene oder vertauschte Pakete nicht akzeptabel sind.

    • Längere Kommunikation oder umfangreiche Datenübertragung: Anwendungen, bei denen die Kommunikation über längere Zeiträume stabil bleiben muss.

  • Beispielanwendungen:

    • E-Mail (SMTP)

    • WWW (HTTP, HTTPS)

    • Dateitransfer (FTP)

    • Remote-Terminalzugang (Telnet)

Zusammenfassung

  • UDP ist ideal für Echtzeitanwendungen, die eine schnelle Datenübertragung benötigen, aber mit Paketverlusten leben können (z.B. Video-Streaming, VoIP).

  • TCP wird bevorzugt, wenn Zuverlässigkeit und Datenintegrität erforderlich sind, wie bei Dateiübertragungen oder Webanwendungen, bei denen alle Daten korrekt und in der richtigen Reihenfolge ankommen müssen.


Warum ist UDP besser für Streaming? Was noch macht TCP langsamer?

Ja, genau! Hier eine genauere Erklärung:

UDP - Keine Fluss- und Überlaufkontrolle

  • Flusskontrolle: UDP hat keine eingebaute Flusskontrolle. Das bedeutet, dass der Sender Daten ohne Rücksicht auf die Empfangskapazitäten des Empfängers oder das Netzwerktempo sendet. Dadurch kann UDP theoretisch eine sehr hohe Datenrate erreichen, da es keine Mechanismen zur Vermeidung von Überlastung gibt.

  • Überlaufkontrolle: Da UDP keine Flusskontrolle hat, gibt es auch keine Überlaufkontrolle. Wenn der Empfänger die Daten nicht schnell genug verarbeiten kann (zum Beispiel durch Überlastung seines Puffers), geht die Information verloren, ohne dass der Sender darüber informiert wird.

  • Keine Selbstbremse: Im Gegensatz zu TCP, das den Datenfluss mithilfe von Flusskontrollen und Rückmeldungen anpasst, sendet UDP einfach Daten, ohne die Geschwindigkeit zu drosseln. Das ist vorteilhaft für Anwendungen, die auf eine minimale Latenz angewiesen sind, jedoch zulassen können, dass ein gewisser Prozentsatz der Daten verloren geht.

Kein 3-Wege-Handshake bei UDP

  • Verbindungsaufbau: UDP benötigt keinen Verbindungsaufbau wie TCP, das den 3-Wege-Handshake (SYN, SYN-ACK, ACK) verwendet, um eine Verbindung zwischen Sender und Empfänger zu etablieren. Dies bedeutet, dass UDP-Verbindungen verbindungslos sind und somit ohne zusätzliche Verzögerungen und Initialisierungen auskommen.

  • Vorteil: Das Fehlen des Handshakes führt zu einer schnelleren Übertragung von Daten, da die Kommunikation sofort beginnen kann, ohne dass vorherige Synchronisierungsmaßnahmen erforderlich sind.

Zusammengefasst:

  • UDP garantiert keine zuverlässige Übertragung und kann keine Flusskontrolle oder Überlaufkontrolle durchführen. Es wird nicht automatisch langsamer oder stoppt den Datenversand, was eine konstante Datenrate (wenn auch mit möglichen Verlusten) sicherstellt.

  • Es wird bevorzugt, wenn schnelle Datenübertragung ohne die Notwendigkeit für eine stabile Verbindung erforderlich ist, wie z.B. bei Streaming oder Sprachkommunikation.


Ein Benutzer klickt im Webbrowser auf einen Link. Beschreiben sie, was dabei in den einzelnen Schichten passiert (sowohl seitens Sender, als auch seitens Empfänger)!

Die Beschreibung eines HTTP-Datenverkehrsprozesses ist sehr genau. Hier sind die Schritte nochmal detailliert dargestellt:

1. DNS-Auflösung

  • DNS-Anfrage: Wenn der Webbrowser eine URL wie www.example.com hat, muss diese zunächst in eine IP-Adresse aufgelöst werden. Der Browser verwendet dabei ein DNS (Domain Name System), um die Anfrage an einen DNS-Server zu senden. Der DNS-Server gibt die IP-Adresse des Zielservers zurück, mit der der Browser eine Verbindung herstellen kann.

  • gethostbyname(): Diese Funktion wird in vielen Programmiersprachen verwendet, um die IP-Adresse für einen Hostnamen zu ermitteln.

2. Aufbau der TCP-Verbindung

  • TCP-Stream-Socket: Der Webbrowser öffnet ein TCP/IP-Stream-Socket und gibt dabei die Ziel-IP-Adresse und den Port (normalerweise Port 80 für HTTP oder Port 443 für HTTPS) an.

  • Drei-Wege-Handshake: Der Webbrowser initiiert die TCP-Verbindung, indem er einen Verbindungsaufbau über das Drei-Wege-Handshake-Verfahren durchführt:

    1. SYN: Der Client sendet ein Synchronisierungs-Signal an den Server.

    2. SYN-ACK: Der Server bestätigt den Empfang des Synchronisierungs-Signals und sendet eine Bestätigung zurück.

    3. ACK: Der Client bestätigt wiederum den Empfang der Bestätigung des Servers. Damit ist die Verbindung etabliert.

3. HTTP-Anfrage

  • Aufbau der HTTP-Anfrage: Der Webbrowser baut nun die HTTP-Anfrage (z. B. GET /index.html HTTP/1.1) zusammen, um sie an den Server zu senden. Diese Anfrage wird im TCP-Segment eingebettet und über den offenen Socket an den Server übermittelt.

  • Ziel-Port und IP: Diese Anfrage wird an den Server unter der angegebenen Ziel-IP-Adresse und dem Ziel-Port (meist Port 80 für HTTP oder 443 für HTTPS) gesendet.

4. Bearbeitung der Anfrage auf dem Server

  • Server empfängt die Anfrage: Der Webserver, der auf dem Zielport horcht (z. B. Port 80 oder 443), empfängt das TCP-Segment.

  • Verbindung akzeptieren: Der Server akzeptiert die eingehende TCP-Verbindung und liest die HTTP-Anfrage des Clients.

  • Verarbeitung und Antwort: Der Webserver verarbeitet die Anfrage (z. B. durch das Abrufen einer Datei oder das Ausführen eines Skripts) und generiert eine HTTP-Antwort. Diese Antwort wird zurück an den Client gesendet, ebenfalls eingebettet in TCP-Segmente.

5. Seitenaufbau im Webbrowser

  • Empfang und Anzeige der Seite: Der Client empfängt die HTTP-Antwort und zeigt das angeforderte Objekt (z. B. eine HTML-Seite) im Browser an. Wenn die Antwort Ressourcen wie Bilder oder Skripte enthält, können diese ebenfalls in separaten HTTP-Anfragen geladen werden, die nach dem gleichen Muster verarbeitet werden.

  • Verbindungsschluss: Je nach HTTP-Version und -Konfiguration wird die TCP-Verbindung entweder nach der Übertragung der Antwort geschlossen (bei HTTP/1.0) oder bleibt offen, um mehrere Anfragen zu ermöglichen (bei HTTP/1.1, durch den "Keep-Alive"-Mechanismus).

Zusammenfassung der Schritte:

  1. DNS-Auflösung: URL wird in IP-Adresse umgewandelt.

  2. TCP-Verbindungsaufbau: Drei-Wege-Handshake wird durchgeführt.

  3. HTTP-Anfrage: Der Webbrowser sendet eine HTTP-Anfrage über den offenen TCP-Socket.

  4. Serverantwort: Der Webserver bearbeitet die Anfrage und sendet die Antwort zurück.

  5. Seitenaufbau: Der Client empfängt die Antwort und zeigt die Seite an. Optionale Verbindungsschließung.

Diese Prozesse bilden die Grundlage für die Kommunikation zwischen einem Webbrowser und einem Webserver, um Webseiten im Internet zu laden und anzuzeigen.

Author

Cha R.

Information

Last changed