update

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

@@ -16,6 +16,201 @@
 | 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
+![image_866.png](image_866.png)
+
+- 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
+![image_867.png](image_867.png)
+
+#### Neuübertragung aufgrund einer verlorenen ACK
+![image_868.png](image_868.png)
+
+#### keine Neuübertragung, weil Bestätigung vor Timeout ankommt
+![image_869.png](image_869.png)
+
+#### Keine Neuübertragung, weil kumulative Bestätigung ankommt (Summenquittung)
+![image_870.png](image_870.png)
+
+## 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)
+- ![image_871.png](image_871.png)
+
+### Verbindungsaufbau Übung
+![image_872.png](image_872.png)
+
+## 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
+  - ![image_873.png](image_873.png)
+
+### Verbindungsabbau Übung
+![image_874.png](image_874.png)
+
+## TCP Verbindungsmanagement
+![image_875.png](image_875.png)
+- 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
+![image_876.png](image_876.png)
+
+### TCP Server Lifecycle
+![image_877.png](image_877.png)
+
+## TCP Zuverlässigkeit sicherstellen
+- Quittungen
+  - positive ACKs
+  - kumulative Summenquittungen
+- Zeitüberwachung
+  - Retransmission Timer
+  - Timeout (RTO)
+- Sequenznummern
+
+## TCP Flusskontrolle
+### Senden
+- TCP-Sender sendet Daten, solange der Sendepuffer nicht voll ist
+  - enthält die gesendeten, aber noch nicht bestätigten Daten
+- ![image_878.png](image_878.png)
+- 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
+- ![image_879.png](image_879.png)
+
+- Empfangsfenster ist dynamisch
+  - wird vom Empfänger in jedem ACK aktualisiert
+  - gibt an, wie viele Bytes der Empfänger noch aufnehmen kann
+
+### Flusskontrolle Beispiel
+![image_880.png](image_880.png)
+
+
+### Datenfluss: Fehlerfreie Übertragung
+![image_883.png](image_883.png)
+
+### Datenfluss: Fehlerhafte Übertragung
+![image_884.png](image_884.png)
+
+## 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
+![image_881.png](image_881.png)
+- 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
+![image_882.png](image_882.png)
+- **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
@@ -159,4 +354,16 @@
     - kleine, verzögerte Pakete leiden
     - → sofortiges Senden kleiner Pakete
   - Delayed ACKs abschalten/reduzieren
-  
+
+## TCP Flusskontrolle und MSS
+
+## TCP Sliding Window
+- rwnd, cwnd, swnd = min(cwnd, rwnd)
+
+## Slow Start (sstresh) und Congestion Avoidance
+
+## TCP Timeout und RTO-Berechnung
+
+## TCP Fast Retransmit und Fast Recovery
+
+## TCP Tahoe und TCP Reno