Verlust, Wiederholung, Zuverlässigkeit

Einführung

Daten in Netzwerken können verloren gehen - Kabel können gestört sein, Router können überlastet sein, Funkverbindungen können unterbrochen werden. In dieser Lektion lernen Sie, wie Netzwerke mit Verlust umgehen und warum nicht jede Übertragung zuverlässig sein muss.

Was passiert bei Paketverlust?

Ursachen für Paketverlust

1. Überlastung (Congestion)

Router-Puffer voll
→ Neue Pakete werden verworfen
→ "Congestion Drop"

2. Fehlerhafte Übertragung

Störungen auf der Leitung
→ Prüfsumme stimmt nicht
→ Paket wird verworfen

3. Defekte Hardware

Defektes Kabel, defekter Port
→ Signale kommen nicht an
→ Pakete verloren

4. Routing-Probleme

TTL läuft ab (zu viele Hops)
→ Router verwirft Paket
→ ICMP "Time Exceeded" zurück

5. Funkstörungen (WLAN)

Interferenzen, Distanz, Hindernisse
→ Signale kommen nicht an
→ Pakete verloren

Typische Verlustraten

Gute Netzwerke:

Kabel (Ethernet):     < 0.01% Verlust
Glasfaser:            < 0.001% Verlust

Problematische Netzwerke:

WLAN (schlecht):      1-5% Verlust
Mobilfunk (3G/4G):    1-10% Verlust
Satellit:             5-20% Verlust

Beispiel:

1000 Pakete gesendet
10 Pakete verloren
→ 1% Paketverlust

Unterschied: Zuverlässige vs. Schnelle Übertragung

Zwei grundlegende Ansätze

Zuverlässig (TCP):

• ✅ Garantiert Zustellung
• ✅ Garantiert Reihenfolge
• ✅ Garantiert Vollständigkeit
• ❌ Langsamer (Overhead)
• ❌ Höhere Latenz (Wartezeit)

Schnell (UDP):

• ✅ Minimaler Overhead
• ✅ Geringe Latenz
• ❌ Keine Garantie für Zustellung
• ❌ Keine Reihenfolge
• ❌ Keine Wiederholung

Wann wird was verwendet?

TCP (zuverlässig) für:

• Webseiten (HTTP/HTTPS)
• Dateiübertragung (FTP, SFTP)
• E-Mail (SMTP, IMAP)
• SSH (Remote-Zugriff)
• Datenbanken

Grund: Daten MÜSSEN vollständig ankommen

UDP (schnell) für:

• DNS-Anfragen
• Streaming (Video, Audio)
• Online-Gaming
• VoIP (Telefonie)
• DHCP

Grund: Geschwindigkeit wichtiger als Vollständigkeit

TCP: Zuverlässige Übertragung

Mechanismen für Zuverlässigkeit

1. Bestätigungen (ACK)

Sender: "Hier ist Paket 1"
Empfänger: "ACK 1 empfangen"

Sender: "Hier ist Paket 2"
Empfänger: "ACK 2 empfangen"

2. Sequence Numbers (Reihenfolge)

Sender sendet: SEQ 1, SEQ 2, SEQ 3
Empfänger empfängt: SEQ 3, SEQ 1, SEQ 2
→ Sortiert: SEQ 1, 2, 3 → Korrekte Reihenfolge

3. Timeouts (Zeitüberschreitung)

Sender: "Hier ist Paket 1"
→ Wartet auf ACK
→ Kein ACK nach 1 Sekunde
→ Sendet Paket 1 erneut

4. Wiederholungen (Retransmission)

Paket verloren
→ Timeout
→ Erneut senden
→ Bis ACK empfangen

Beispiel: TCP-Verbindung

Erfolgreiche Übertragung:

Sender                  Empfänger
  |                         |
  |--- Paket 1 (SEQ 1) ---->|
  |<---- ACK 1 -------------|
  |                         |
  |--- Paket 2 (SEQ 2) ---->|
  |<---- ACK 2 -------------|
  |                         |
  |--- Paket 3 (SEQ 3) ---->|
  |<---- ACK 3 -------------|

Mit Paketverlust:

Sender                  Empfänger
  |                         |
  |--- Paket 1 (SEQ 1) ---->|
  |<---- ACK 1 -------------|
  |                         |
  |--- Paket 2 (SEQ 2) --X  | ← Verloren!
  |                         |
  |  (Timeout - 1 Sek.)     |
  |                         |
  |--- Paket 2 (SEQ 2) ---->| ← Wiederholt
  |<---- ACK 2 -------------|
  |                         |
  |--- Paket 3 (SEQ 3) ---->|
  |<---- ACK 3 -------------|

Sliding Window (Flusskontrolle)

Problem: Warten auf jedes ACK ist ineffizient

Lösung: Mehrere Pakete gleichzeitig senden

Beispiel:

Window Size = 3

Sender sendet:
Paket 1, 2, 3 (gleichzeitig)

Wartet auf ACKs:
ACK 1 empfangen → Sende Paket 4
ACK 2 empfangen → Sende Paket 5
ACK 3 empfangen → Sende Paket 6

Vorteil: Höhere Effizienz, trotzdem zuverlässig

Overhead von TCP

Was TCP "kostet":

- 20 Bytes TCP-Header pro Segment
- ACK-Pakete (zusätzlicher Traffic)
- Timeouts (Wartezeit)
- Verbindungsaufbau (3-Way Handshake)
- Verbindungsabbau (4-Way Teardown)

Beispiel:

1000 Bytes Daten senden:

Ohne TCP (reine Daten):  1000 Bytes
Mit TCP (inkl. Header):  1020 Bytes + ACKs
→ ~5-10% Overhead

UDP: Schnelle Übertragung

Charakteristika

Keine Bestätigungen:

Sender: "Hier ist Paket"
Empfänger: (empfängt oder nicht, keine Antwort)

Keine Wiederholungen:

Paket verloren → bleibt verloren

Keine Reihenfolge:

Pakete können in beliebiger Reihenfolge ankommen
Anwendung muss selbst sortieren (falls nötig)

Minimaler Header:

UDP-Header: nur 8 Bytes
TCP-Header: mindestens 20 Bytes

Warum UDP verwenden?

Grund 1: Geschwindigkeit

TCP: Paket 1 → Warten → ACK → Paket 2 → ...
UDP:  Paket 1, 2, 3, 4, 5 → Fertig

Grund 2: Geringe Latenz

Keine Wartezeiten auf Bestätigungen
Wichtig für Echtzeit-Anwendungen

Grund 3: Simple Anfragen

DNS: "Was ist die IP von google.com?"
→ Eine Frage, eine Antwort
→ Kein Verbindungsaufbau nötig

Grund 4: Verlust akzeptabel

Video-Streaming:
- 1 verlorener Frame von 60 pro Sekunde
- Kaum sichtbar
- Besser als Wartezeit (Buffering)

Beispiele

DNS-Anfrage:

Client: "Was ist die IP von example.com?" (UDP)
Server: "93.184.216.34" (UDP)

→ Schnell (< 10ms)
→ Falls verloren: Client fragt erneut

Video-Streaming:

Frame 1 → Verloren → Übersprungen
Frame 2 → Empfangen → Angezeigt
Frame 3 → Empfangen → Angezeigt

→ Leichtes Ruckeln statt Pause
→ Besser für Benutzererfahrung

Online-Gaming:

Position-Update verloren
→ Spieler "springt" kurz
→ Nächstes Update korrigiert
→ Besser als Wartezeit

Warum nicht jede Kommunikation abgesichert ist

Trade-offs: Zuverlässigkeit vs. Performance

Zuverlässigkeit (TCP) kostet:

- Zeit (Bestätigungen warten)
- Bandbreite (ACK-Pakete)
- Komplexität (Zustandsverwaltung)

Manchmal ist Verlust akzeptabel:

1. Redundante Daten

Video: 60 Frames pro Sekunde
→ 1 Frame verloren = 1/60 Sekunde
→ Kaum wahrnehmbar

2. Alte Daten irrelevant

Online-Gaming: Position vor 1 Sekunde
→ Aktuelle Position wichtiger
→ Alte Position überspringen

3. Einfache Wiederholung durch Anwendung

DNS-Anfrage:
→ Keine Antwort nach 100ms
→ Erneut fragen (einfacher als TCP)

4. Echtzeit wichtiger als Vollständigkeit

VoIP (Telefonie):
→ Kurze Störung akzeptabel
→ Besser als 1 Sekunde Pause

Beispiel-Vergleich: Dateidownload vs. Streaming

Dateidownload (TCP):

Datei: software.zip (500 MB)
→ MUSS zu 100% ankommen
→ Jedes Bit wichtig
→ TCP mit Wiederholungen
→ Dauert länger, aber korrekt

Video-Streaming (UDP):

Film: movie.mp4 (2 GB)
→ 99.9% reicht aus
→ Einzelne Frames unwichtig
→ UDP ohne Wiederholungen
→ Flüssige Wiedergabe

Hybride Ansätze

Anwendungen mit eigener Zuverlässigkeit über UDP

Beispiel: QUIC (HTTP/3)

Basis: UDP (schnell)
+ Eigene Zuverlässigkeit (selektiv)
+ Verschlüsselung
+ Multiplexing
→ Schneller als TCP, aber zuverlässig

Beispiel: WebRTC

Audio: UDP (Verlust akzeptabel)
Video: UDP (Verlust akzeptabel)
Daten: UDP + eigene Wiederholungen

Vorteil:

• Flexibilität
• Nur wichtige Daten wiederholen
• Bessere Performance als TCP

Zusammenfassung

Kernkonzepte

1. Paketverlust ist normal

• Überlastung, Fehler, Störungen
• Typisch 0.01% - 5%
• Muss behandelt werden

2. TCP: Zuverlässig

• Bestätigungen (ACK)
• Wiederholungen (Retransmission)
• Reihenfolge (Sequence Numbers)
• Flusskontrolle (Window)
• Overhead: ~5-10%

3. UDP: Schnell

• Keine Bestätigungen
• Keine Wiederholungen
• Minimaler Overhead (8 Bytes Header)
• Anwendung entscheidet über Zuverlässigkeit

4. Trade-offs

• Zuverlässigkeit ↔ Geschwindigkeit
• Vollständigkeit ↔ Latenz
• Richtige Wahl abhängig von Anwendung

Wann was verwenden?

TCP verwenden für:

• ✅ Daten müssen vollständig ankommen
• ✅ Reihenfolge ist wichtig
• ✅ Fehler inakzeptabel
• Beispiele: Web, E-Mail, Dateien, SSH

UDP verwenden für:

• ✅ Geschwindigkeit wichtiger als Vollständigkeit
• ✅ Echtzeit-Anforderungen
• ✅ Verlust akzeptabel
• Beispiele: DNS, Streaming, Gaming, VoIP

Ausblick

In der nächsten Lektion:

• Zusammenfassung des gesamten Kurses
• Warum dieses Wissen grundlegend ist
• Wie es Ihnen bei ARP, Switching, Routing hilft

---

Merksatz: TCP = zuverlässig aber langsamer, UDP = schnell aber ohne Garantie!