diff --git a/Writerside/topics/04/Rechnernetze/Teil-2/13_TCP-Ende-zuEnde.md b/Writerside/topics/04/Rechnernetze/Teil-2/13_TCP-Ende-zuEnde.md index 9dd7994..62a303e 100644 --- a/Writerside/topics/04/Rechnernetze/Teil-2/13_TCP-Ende-zuEnde.md +++ b/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 - \ No newline at end of file + +## 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 \ No newline at end of file