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

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