Notizen

TCP

tagskommunikationssysteme
  • Am häufigsten im Internet verwandtes Protokoll
  • Verbindungsorientiert
  • Punkt-Zu-Punkt -> Kein Multicast
  • Full Duplex - Beide Seiten können Senden und Empfangen+
  • Komplett Verlässlich
  • Stream Interface (Arbeiten wie mit Dateien)
  • Verlässlicher Verbindungsaufbau
  • Elegante Verbindungsabschaltung
  • Schützt Router vor Overload

Verbindungsorientierung

  • IP unterscheidet Verbindungen anhand der Sender- und Empfängeradressen und Ports

TCP Header

  • Stream Interface
  • Anwendung kann TCP jederzeit Daten geben
  • TCP entscheidet dann selbst, wann und wie die Daten übermittelt werden
  • Daten werden in Segmente aufgeteilt, jedes mit eigenem Header

TCP Header

  • 16 Bit - Source Port
  • 16 Bit - Destination Bit
  • 32 Bit - Sequence Number - Das wievielte Byte ist das erste Byte in der Nachricht
  • 32 Bit - Acknowledgement Number - Siehe Kapitel Empfang
  • 4 Bit - Header Length - Aus wie vielen Bytes besteht der Header
  • 12 Bit - Reserviert für Flags - Bisher am Anfang noch nicht belegt, dann am Schluss:
    • URG - Urgent Bit - Der Urgent Pointer ist auszuwerten - Nicht relevant
    • ACK - Acknowledge Bit - Siehe Kapitel Empfang
    • PSH - Push Bit - Nicht relevant
    • RST - Reset Bit - Wird gesendet, wenn irgend ein Headerwert überhaupt nicht passt. Dadurch wird die Verbindung abgebrochen
    • SYN - Synchronisation Bit - Anfrage zum Verbindungsaufbau
    • FIN - Finish Bit - Anfrage zum Beenden der Verbindung, ab dann schickt Sender keine Nutzdaten mehr
  • 16 Bit - Window Size - Flusskontrolle, damit der Sender ausgebremst wird, falls der Empfänger zu langsam ist
  • 16 Bit - Checksum - Gebildet aus Header und Nutzdaten
  • 16 Bit - Urgent Pointer - Nicht relevant

Paketverlust und Wiederholte Sendung

  • Wenn Absender Daten sendet, startet es einen Timer
  • Wenn Empfänger Daten empfängt, sendet es eine Bestätigung (ACK)
  • Wenn beim Absender der Timer abläuft bevor die Bestätigung, wird die Verbindung Zurückgesetzt (RET)
  • Mehr als ein Paket können gesendet werden bevor eine Bestätigung empfangen werden muss

Problem: Wie lange soll der Timer sein? Zu lange Timer verzögern die Datenrate bei schnellen Verbindungen, zu kurze Timer machen lange Verbindungen unmöglich

  • TCP “führt Buch” über die vergangene Zeit zwischen Absendung und der Bestätigung
  • Mit Varianzberechnung, bei hoher Varianz auch hoher Sicherheitszuschlag bei den Timerzeiten

Datentransfer

  • Anwendungen geben TCP Daten
  • TCP speichert diese zunächst in einem Sendepuffer, für jede Verbindung einer
  • Beim Senden entscheidet TCP selbst, wie viel Bytes aus dem Sendepuffer pro Segment versendet werden
  • Ebenfalls wird ein Empfangspuffer angelegt
  • Die Bytes werden im Empfangspuffer an die Position der Sequenznummer geschrieben

Acknowledge

  • Sender und Empfänger speichern die Gesamtzahl empfangener Bytes und gesendeter Bytes
  • Wird eine Nachricht erfolgreich empfangen, so muss ein TCP Segment zurückgesendet werden mit
    • Acknowledgenummer=Posittion erstes nicht empfangenes Byte, also Kumulativ, soll heißen, empfängt der Sender ein vorheriges Acknowledgement nicht, ist es nicht schlimm, solange ein höheres Acknowledge wieder Eintrifft
  • Gehen Nutzdaten Verloren, sendet der Sender fröhlich erstmal weiter. Es wird aber kein neues Acknowledge der neuen Daten kommen, denn sie sind ja verloren gegangen, nur nochmal das alte Ack (Duplicate Ack)
  • Dann läuft der Timer ab
  • Der Sender sendet ein Repair Segment
  • Dann ist die Lücke gefüllt und das Acknowledgement kommt (Cumulative Ack)

Flusskontrolle - Window Size

  • Window Size = Anzahl an Bytes, die im Empfangspuffer noch frei sind
  • Mit dem Acknowledge wird die Window Size mitgesendet -> Sender weiß wie viel er noch Senden darf
  • Wird der Puffer gelesen bzw geleert, wird ein neuer Acknowledge gesendet mit der neuen Window Size -> “Advertise Window Nachricht”

Drei-Wege-Handshake: Verbindungsaufbau

  • In der ersten Nachricht wird das SYN-Bit gesetzt, das heißt es wird eine Verbindung angefragt
    • Die initialen Sequenznummern sind Zufällig gewählt
    • Die Zufallszahlen werden gewählt, damit Scheinverbindungen erkannt werden
  • Diese wird akzeptiert, wenn eine Anwendung am angegebenen Port lauscht
  • Das Acknowledge wird gesendet
  • Die dritte Nachricht bestätigt den Acknowledge
  • Jede dieser Nachrichten, die zwar keine Nutzdaten senden, erhöht den Acknowledge Counter um 1

Verbindungsabbau

  • A sendet FIN-Flag, was heißt dass A nichts mehr sendet
  • B empfängt dieses und sendet FIN-Flag, was heißt, dass er nichts mehr sendet und nichts mehr empfangen muss
  • A empfängt FIN-Flag und weiß dass er nichts mehr empfangen muss
  • Verbindung ist beendet

Überlastabwehr - Congestion Control

  • Ein schneller Sender kann nicht nur den Empfänger überlasten, auch Zwischenstationen
  • TCP nutzt den Nachrichtenverlust als Überlastindikator und reduziert dann Datenrate
  • “Slow Start”: Sender sendet erst mal kleine Nachrichten (Max Segment Size = 1kB), werden diese Acknowledged, wird die Nachrichtengröße verdoppelt usw.
  • Kann ein Paket nicht zugestellt werden, wird der Threshold gespeichert (Hälfte der versuchten Größe) und die Größe zurückgesetzt
    • Größter Threshold ist 1/2 Window Size des Empfängers
  • Von da an wieder verdoppeln bis zum Threshold, ab dem dann nur noch linear wachsen

Backlinks