Transmission Control Protocol/Überlastungskontrolle

Aus Foxwiki
Version vom 28. Januar 2024, 13:15 Uhr von Dirkwagner (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „=== Überlastungskontrolle === * Bei Paketvermittelten Netzen kann es zu Überlastung kommen * Beim Zielhost * Innerhalb des Netzwerkes * Lösungen Änderung der Fenstergröße * Congestion Windows Size (Größe des Überlastungsfensters) * Die tatsächliche Segmentgröße ist ein Limit aus beiden Werten ==== Slow Start with Congestion Avoidance ==== * Beim Verbindungsaufbau wird das Überlastungfenster auf die Größe eines Segmentes gesetzt * Kommen di…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Überlastungskontrolle

  • Bei Paketvermittelten Netzen kann es zu Überlastung kommen
  • Beim Zielhost
  • Innerhalb des Netzwerkes
  • Lösungen

Änderung der Fenstergröße

  • Congestion Windows Size (Größe des Überlastungsfensters)
  • Die tatsächliche Segmentgröße ist ein Limit aus beiden Werten

Slow Start with Congestion Avoidance

  • Beim Verbindungsaufbau wird das Überlastungfenster auf die Größe eines Segmentes gesetzt
  • Kommen die Quittungen des versandten Segmentes ohne Timeout an, wird die Größe des Überlastungsfensters verdoppelt
  • Dies geschieht bis zum Schwellenwert von 64 KByte
  • Danach pro erfolgreichem Sende- und Empfangszyklus um jeweils eine Segmentgröße
  • Dieser Algorithmus ist für zuverlässige Verbindungen konzipiert und sollte z. B.  bei WLANs deaktiviert werden
  • Dort verringert er stark die effektive Bandbreite

Überlaststeuerung/Staukontrolle (Congestion Control)

  • Wird eine Verbindung stark belastet, werden immer mehr Pakete verworfen
  • Durch die Wiederholung steigt wiederum die Belastung, dies sorgt (ohne Maßnahmen) für einen Datenstau
  • Die Verlustrate wird von einem IP-Netzwerk ständig beobachtet
  • Normalerweise wird eine TCP/IP-Verbindung langsam gestartet (Slow-Start) und die Senderate schrittweise erhöht, bis zum Datenverlust
  • Ein Datenverlust verringert die Senderate, ohne Verlust wird sie wiederum erhöht
Algorithmus zur Überlaststeuerung

Gehen bei einer bestimmten Fenstergröße Pakete verloren, kann das festgestellt werden, wenn der Sender innerhalb einer bestimmten Zeit (Timeout) kein ACK erhält

  • Man muss davon ausgehen, dass das Paket aufgrund zu hoher Netzlast von einem Router im Netz verworfen wurde (Stau im Netz)
  • Um den Stau aufzulösen, müssen alle beteiligten Sender ihre Netzlast reduzieren

Dazu werden im RFC 2581 vier Algorithmen definiert:

  1. slow start
  2. congestion avoidance
  3. fast retransmit
  4. fast recovery
  • slow start und congestion avoidance werden zusammen verwendet
  • fast retransmit und fast recovery werden zusammen verwendet, sind eine Erweiterung von slow start und congestion avoidance
Slow Start Slow Start und Congestion Avoidance
Grafische Darstellung des Slow-Start-Algorithmus
  • Der Slow-Start-Algorithmus dient zur Bestimmung des congestion window
  • Da die momentane Auslastung des Netzes nicht bekannt ist, wird mit kleinen Datenmengen begonnen
  1. Der Algorithmus startet mit einem kleinen Fenster, von einer Maximum Segment Size (MSS), in dem Datenpakete vom Sender zum Empfänger übertragen werden
  2. Der Empfänger sendet ACK an den Sender zurück
  3. Für jedes empfangene ACK wird die Größe des congestion window um eine MSS erhöht
    • Dies führt innerhalb einer Roundtrip-Zeit zu einer Verdopplung des Congestion Windows
  4. Dieses exponentielle Wachstum wird so lange fortgesetzt, bis der Slow-Start Threshold erreicht wird
    • Die Phase des exponentiellen Wachstums wird auch Slow Start Phase genannt
  5. Danach wird das Congestion Window nur noch um eine MSS erhöht, wenn alle Pakete aus dem Fenster erfolgreich übertragen wurden
    • Es wächst pro Roundtrip-Zeit nur noch um eine MSS, also nur noch linear
      • Diese Phase wird als Congestion Avoidance Phase bezeichnet
    • Das Wachstum wird beendet, wenn das vom Empfänger festgelegte Empfangsfenster erreicht worden ist


Kommt es zu einem Timeout, wird das congestion window auf 1 zurückgesetzt, der slow-start threshold wird auf die Hälfte der gesendeten, unquittierten Pakete herabgesetzt (Flight Size)

  • Die Phase des exponentiellen Wachstums wird also verkürzt
  • Das Fenster wächst bei häufigen Paketverlusten nur langsam
Fast-Retransmit und Fast-Recovery
  • Werden eingesetzt, um nach Paketverlust schneller auf die Stau-Situation zu reagieren
  • Empfänger informiert den Sender, wenn Pakete außer der Reihe ankommen und somit dazwischen ein Paketverlust vorliegt
  • Der Empfänger bestätigt das letzte korrekte Paket erneut für jedes weitere ankommende Paket außer der Reihe
  • Man spricht dabei von Dup-Acks (duplicate acknowledgments)
    • Mehrere aufeinanderfolgende Nachrichten, welche dasselbe Datensegment ACKen
  • Der Sender bemerkt die duplizierten ACKS, und nach dem dritten Duplikat sendet er sofort, vor Ablauf des Timers, das verlorene Paket erneut
    • Da nicht auf den Timerablauf gewartet werden muss, heißt das Prinzip Fast Retransmit
  • Dup-Acks: auch Hinweise darauf, dass ein Paketverlust stattfand, dennoch die folgenden Pakete angekommen sind
  • Das Sendefenster wird nach dem Fehler nur halbiert (kein Slow-Start)


Zusätzlich kann das Sendefenster noch um die Anzahl der Dup-Acks erhöht werden

  • Jedes Dup-Ack steht für ein weiteres Paket, welches den Empfänger erreicht hat
  • Dadurch kann nach dem Fehler schneller wieder die volle Sendeleistung erreicht werden
  • Das Prinzip nennt man Fast-Recovery
Verwaltung der TCP-Verbindungen als endlicher Automat
Verwaltung der TCP-Verbindungen als endlicher Automat