zusammenfassungen/Writerside/topics/04/Rechnernetze/Teil-2/13_TCP-Ende-zuEnde.md

TCP

TCP vs. UDP

TCP	UDP
Garantierte Übertragung	keine Garantie
Verbindungsorientiert	keine Verbindung
Langsam	Schnell
Sicher (SSL/TLS)	nicht sicher
Paket-Sortier-Mechanismus	keiner
ACKs	keine ACKs
Erweitertes Error-Checking	nur Checksumme
Flow Control	keine
SlowStart & CongestionAvoidance	keine
20-Byte Header	8-Byte Header
3-Wege-Handshake SYN SYN-ACK ACK	keiner
Genutzt von kritischen Anwendungen	genutzt von Real-Time Anwendungen
HTTP, HTTPS, FTP, DNS, SMTP, Telnet	DHCP, DNS, VoIP, RIP, TFTP

TCP

Zuverlässiger Byte-Strom mit integrierter Flusskontrolle

Ausgangslage für eine (virtuelle) TCP-Verbindung

• MSS (Maximum Segment Size)
  • maximale Größe eines TCP-Segments (NUR Daten, ohne Header)
  • wird bei Verbindungsaufbau ausgehandelt
  • abhängig von der MTU (Maximum Transmission Unit) des darunterliegenden Netzwerks
• Retransmission Timer (Timeout = RTO)
  • Nach Ablauf des Timers werden unbestätigte Datenpakete erneut gesendet

TCP Sequenznummern

• Sequenznummer eines TCP-Segments
  • Bytestromnummer des ersten Bytes im Segment
  • wird bei Verbindungsaufbau ausgehandelt

TCP Bestätigungsnummern

• Bestätigungsnummer eines TCP-Segments
  • Bytestromnummer des nächsten erwarteten Bytes
  • Als Quittungsnummer wird gesetzt:
    • ACK-Nummer (von Host B) = fehlerfrei empfangene Squenznummer + Größe der Nutzdaten in Byte
• i.d.R poitiv
  • stellen Summenquittungen dar
    • d.h. alle Bytes bis zur ACK-Nummer wurden fehlerfrei empfangen
• werden zusammen mit den restlichen Daten die von B nach A gesendet werden, in einem TCP-Segment übertragen
  • "Huckepack"

TCP Telnet Fallstudie

Neuübertragung aufgrund einer verlorenen ACK

keine Neuübertragung, weil Bestätigung vor Timeout ankommt

Keine Neuübertragung, weil kumulative Bestätigung ankommt (Summenquittung)

TCP Verbindungsaufbau

TCP-Verbindung ist Full-Duplex

Beide Verbindungen (Hin und Rück) müssen separat aufgebaut werden

SYN-Flag = 1 dient zum Aufbau (Synchronisation)

ACK-Flag = 1 dient zur Bestätigung (Quittung)

Sequenz- und Quittungsnummern beziehen sich auf Bytes

• TCP-Verbindung wird mit einem 3-Wege-Handshake aufgebaut
  • Verbindungsanfrage (SYN) von A an B
    • SYN = 1
    • SEQ = x (Startsequenznummer)
  • Verbindungsbestätigung (SYN, ACK) von B an A
    • SYN = 1
    • ACK = x + 1 (Bestätigungsnummer)
    • SEQ = y (Startsequenznummer von B)
  • Bestätigung (ACK) von A an B
    • SYN = 0
    • ACK = y + 1 (Bestätigungsnummer)
    • SEQ = x + 1 (Fortsetzung der Sequenznummer von A)
• 

Verbindungsaufbau Übung

TCP Verbindungsabbau

TCP-Verbindung ist Full-Duplex → Jede Richtung muss separat abgebaut werden

Falls nur eine Verbindung abgebaut wird (und die andere noch aktiv ist), dann wird die Verbindung in den Zustand "Half-Close" versetzt. bspw. Wenn der Client nur noch empfangen möchte, aber nicht mehr senden.

• Schematisch
  • Schließung TCP-Verbindung mit anschließender Wartezeit von 30 Sekunden
  • 

Verbindungsabbau Übung

TCP Verbindungsmanagement

• TCP-Verbindungen werden in einem Verbindungsmanagement verwaltet
• Zustände:
  • CLOSED: Verbindung ist geschlossen
  • LISTEN: Verbindung wartet auf Verbindungsanfrage
  • SYN-SENT: Verbindungsanfrage wurde gesendet, aber noch keine Antwort erhalten
  • SYN-RECEIVED: Verbindungsanfrage wurde empfangen, aber noch keine Bestätigung gesendet
  • ESTABLISHED: Verbindung ist aufgebaut und kann Daten übertragen
  • FIN-WAIT-1: Die Anwendung möchte Übertragung beenden
  • FIN-WAIT-2: Andere Seite ist einverstanden die Verbindung zu beenden
  • TIME-WAIT: Verbindung ist geschlossen, aber wartet auf mögliche ausstehende Pakete
  • CLOSING: Beide Seiten haben gleichzeitig versucht, die Verbindung zu schließen
  • CLOSE-WAIT: Gegenseite hat Verbindungsfreigabe eingeleitet
  • LAST-ACK: Warten, bis keine TCP-Segmente mehr kommen

TCP Client Lifecycle

TCP Server Lifecycle

TCP Zuverlässigkeit sicherstellen

• Quittungen
  • positive ACKs
  • kumulative Summenquittungen
• Zeitüberwachung
  • Retransmission Timer
  • Timeout (RTO)
• Sequenznummern

TCP Pipelining, Sliding Window

Pipelining

• TCP-Sender kann mehrere Segmente senden, ohne auf die Bestätigung des Empfängers zu warten
• Erlaubt eine höhere Auslastung der Verbindung
• Sender sendet mehrere Segmente in einem Rutsch
  • z.B. 3 Segmente mit jeweils 1000 Bytes
• Konsequenzen:
  • Sender und Empfänger benötigen einen Puffer für mehrere Segmente
    • Minimum: Sender muss alle gesendeten, aber noch nicht bestätigten Segmente puffern
  • Bereich der Sequenz- und Bestätigungsnummern wird größer

Sliding Window

• Sliding Window ist eine Erweiterung des Pipelining
• Gewährleistet:
  • Zuverlässige Übertragung in einem Bytestrom
  • Übertragung der Daten in richtiger Reihenfolge
  • Flusskontrolle zwischen Sender und Empfänger
• Integrierte Flusskontrolle
  • keine feste Sliding Window Größe
    • wird Sender vom Empfänger mitgeteilt ("Advertised Window")
      • auf Grundlage des Speicherplatzes, der der Verbindung zugewiesen ist

Sliding Window Beispiel

• Senderseite (a)
  • LastByteAcked ≤ LastByteSent
  • LastByteSent ≤ LastByteWritten
  • Bytes zwischen LastByteAcked und LastByteSent puffern
• Empfängerseite (b)
  • LastByteRead ≤ LastByteExpected
  • LastByteExpected ≤ LastByteReceived + 1
  • Bytes zwischen LastByteRead und LastByteReceived puffern

TCP Fehlerbehandlung

• Erfolgt durch Go-Back-N
  • Sender sendet Datenpakete, bis er eine Bestätigung erhält
  • Bei Verlust eines Pakets wird es erneut gesendet
• Arbeitet mit positiven ACKs
  • Empfänger sendet ACKs für empfangene Pakete (ggf. kumulative ACKs)
  • Ab dem ersten, nicht quittierten Paket, werden alle folgenden Pakete erneut gesendet

TCP Überlastungskontrolle

• Funktion der Netzwerkschicht zur Regelung des Datenflusses
• Begrenzung der Übertragungsrate
• Lösungsansatz:
  • TCP-Slow-Start
    • Startet mit einer niedrigen Übertragungsrate
    • Erhöht die Rate (cwnd) exponentiell, bis ein Paket verloren geht
      • maximal Windowsize
  • TCP-Überlastungskontrolle
    • Reduziert die Übertragungsrate, wenn Pakete verloren gehen

Silly Window

Sender/Empfänger senden/empfangen nur sehr kleine Datenmengen → Fragmentierung in viele Segmente, welche aber immer noch den TCP/IP-Header haben und damit Netzwerknutzung ineffizient wird

Empfängerseitig (Window Shrinking)

• Empfänger bestätigt sehr kleines Empfangsfenster
  • bspw. 1 Byte
  • weil er nur wenig internen Speicher hat
• Sender darf nur 1 Byte schicken → viele Pakete

Lösung (Clark)

• Empfänger schickt keine ACKs (inkl. Fensteraktualisierungen), außer:
  • Er kann ein volles Segment (MSS) empfangen
  • order Empfangspuffer ist mind. halb leer
• → Sender schickt nicht andauernd

Senderseitig

• Sender generiert kleien Datenmengen und sendet immer sofort
  • bspw. durch interaktiven Dienst, bei jedem Tastendruck wird gesendet

Lösung (Nagle)

• Sender darf nur Segment schicken, wenn
  • alle bisherigen Daten bestätigt (ACK)
  • oder ein vollständiges MSS-Paket vorliegt
• → kleine Datenmengen werden gepuffert, weniger Pakete

Abschätzung von TCP Timeout (Jacobson/Karels)

Timeout = EstimatedRTT + (4 * Abweichung)

TCP Fast Open

• Verwendet einen TFO-Cookie
  • Server gibt Client beim ersten Verbindungsaufbau
  • spätere Verbindungen können so authentifiziert werden

• Erste Verbindungen	Zukünftige Verbindungen

Relevante Fallstudien

Download einer Webseite aus dem Internet

• Step (1): Enter website in browser
• Step (2): DNS Client creates a message
• Step (3): Transport Layer creates an UDP datagram
• Step (4): Network Layer creates an IP packet
• Step (5): ARP determine Destination MAC address
• Step (6): Link Layer creates and transmit a frame
• Step (7): NAT entry and forward frame to ISP Router
• Step (8): ISP Router forwards frame to DNS Server
• Step (9): DNS Server receives frame
• Step (10): DNS translate and generate reply
• Step (11): ISP Router forwards frame to local router
• Step (12): NAT translation in local router
• Step (13): Local Router forwards frame to PC
• Step (14): DNS Client delivers IP address to HTTP
• Step (15): HTTP Client creates Request message
• (Step (16): PC receives website from HTTP Server)

Anwendungsprotokolle

Anwendung	Beschreibung	Bild
DHCP	gibt IP-Adressen
DNS	übersetzt Webseitenname in IP-Adresse
HTTP Hyper Text Transfer Protocol	Webseiten transferieren
NBNS NetBIOS Name Service	übersetzt lokale Hostnamen in IP-Adressen
SMTP Simple Mail Transfer Protocol	Emails senden
SNMP Simple Network Management Protocol	Netzwerkgeräte Managen
SNTP Simple Network Time Protocol	Gibt Zeit
Telnet	Bidirektionale Text-Kommunikation über Terminal-Anwendung
TFTP Trivial File Transfer Protocol	Transferiert kleine Datenmengen

Port Handling

• Ports werden genutzt um laufende Prozesse in den Anwendungen zu identifizieren
• Clientseitige Ports werden dynamisch vom Transport Layer erzeugt
  • zwischen 1024 und 65535

Well Known Ports

Über	Anwendung	Port
UDP	DHCP	67
UDP	NBNS	137
UDP	DNS	53
UDP	SNTP	123
UDP	SNMP	161
TCP	Telnet	23
TCP	SMTP	25
TCP	HTTP	80
TCP	FTP	21

Socket Handling

• Ermöglichen Anwendungen sich mit TCP/IP-Netzwerken zu verbinden
• Virtuelle TCP/UDP Kommunikationskanäle
  • 
• Sockets als TC/RX Buffer
  • 

Ports und Sockets in der Praxis

Aufbau einer TCP Verbindung mit Sockets

1. Server erstellt Socket

• stellt sich danach in den "listening" Modus
  • wartet auf Client-Request

2. Client erstellt Socket und verbindet sich

3. Transport Layer überträgt Nachricht zu Server

4. Server erstellt Socket und Prozess

5. Transport Layer übermittelt Nachrichten

6. Sockets schließen (außer den aus 1)

TCP Tuning für HTTP/1.1 und HTTP/2

• nicht standardisiert, nur Best-Practise
• Ziel
  • Transportverhalten von TCP anpassen, damit HTTP effizienter läuft
    • besonders bei kurzen, parallelen, latenzsensiblen Verbindungen
  • Vermeidung von Verzögerungen bei kleinen Paketen
  • Verbesserung Durchsatz bei parallelen Streams

Große Puffer, schnelle ACKs und kleine Latenzen lassen HTTP über TCP glänzen

Nagle aus, ACKs schnell, Puffer groß - so wird TCP zum HTTP-Turbo.

• Ablauf:
  • TCP-Sendepuffer
    • größer dimensionieren
    • am besten dynamisch (je nach RTT * Bandbreite)
  • TCP-Empfangspuffer
    • groß genug um alle Daten ohne Drop zu puffern
  • Nagle-Algorithmus deaktivieren
    • kleine, verzögerte Pakete leiden
    • → sofortiges Senden kleiner Pakete
  • Delayed ACKs abschalten/reduzieren

TCP Flusskontrolle

Senden

• TCP-Sender sendet Daten, solange der Sendepuffer nicht voll ist
  • enthält die gesendeten, aber noch nicht bestätigten Daten
• 
• Sendefenster wird dazu benutzt, um die Anzahl von Bytes anzugeben, die der Empfänger bereit ist anzunehmen
  • bildet absolute obere Grenze, die vom Sender nicht überschritten werden darf

Empfangen

• TCP-Empfänger sendet ACKs, solange der Empfangspuffer nicht voll ist

• 

• Empfangsfenster ist dynamisch

  • wird vom Empfänger in jedem ACK aktualisiert
    • rwnd = rcvBuffer - (LastByteRcvd - LastByteRead)
  • gibt an, wie viele Bytes der Empfänger noch aufnehmen kann
    • wenn rwnd = 0, warten auf WindowUpdate und keine Daten mehr senden

Flusskontrolle Beispiel

Datenfluss: Fehlerfreie Übertragung

Datenfluss: Fehlerhafte Übertragung

TCP Timeout und RTO-Berechnung

• nach jeder RTT Messung, um zuverlässig aber nicht zu früh neu zu senden

1. Startwert: RTO = 1 Sekunde
2. Initialisierung nach erster RTT Messung
   • SRTT (Smoothed RTT) = RTT_neu
   • RTTVAR (RTT Varianz) = RTT_neu / 2
   • RTO = SRTT + max(G, 4 x RTTVAR
3. Aktualisierung
   • SRTT = (1- 1/8) x SRTT + (1/8) x RTT_neu
   • RTTVAR = (1- 1/4) x RTTVAR + (1/4) x |SRTT - RTT_neu|
   • RTO = SRTT + max(G, 4 x RTTVAR)
4. Sicherheitsmechanismen
   • RTO ≥ 1 Sekunde
   • Exponentielles Backoff
     • RTO = 2x vorheriges RTO
     • RTT wird nur für Original-Segmente gemessen
       • nicht bei Retransmissions

TCP Fast Retransmit und Fast Recovery

Fast Retransmit

• Ziel: Frühzeitige Erkennung von Paketverlusten
  • Schnelle Wiederherstellung Übertragung
  • Reduktion unnötiger Timeouts
• Ablauf
  • Segment geht verloren, nachfolgende kommen an
  • Empfänger bestätigt nur letztes empfangenes Byte
    • Duplicate ACKs
  • Sobald Sender 3 DupACKs für gleiches Segment empfängt → Verlust
  • Segment direkt neu senden (KEIN RTO)

3x gemeldet → sofort gesendet!

Fast Recovery

• Greift direkt nach Fast Retransmit
• Ziel: TCP soll nicht in Slow-Start-Phase zurückfallen
• Sender reduziert cwnd nur moderat

TCP Tahoe

• Implementierung von Staukontrolle
  • SlowStart, Congestion Avoidance, Fast Retransmit

TCP Tahoe startet neu mit dem SlowStart bei jedem Verlust - Sicherheit geht vor Geschwindigkeit

TCP Reno

• Weiterentwicklung von TCP Tahoe
  • Fast Retransmit UND Fast Recovery

TCP Reno erkennt Verluste früh, sendet schnell neu und erholt sich klug