update
This commit is contained in:
BIN
Writerside/images/image_959.png
Normal file
BIN
Writerside/images/image_959.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 87 KiB |
BIN
Writerside/images/image_960.png
Normal file
BIN
Writerside/images/image_960.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 71 KiB |
@ -129,32 +129,6 @@
|
||||
- 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
|
||||
- 
|
||||
- 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
|
||||
- gibt an, wie viele Bytes der Empfänger noch aufnehmen kann
|
||||
|
||||
### Flusskontrolle Beispiel
|
||||

|
||||
|
||||
|
||||
### Datenfluss: Fehlerfreie Übertragung
|
||||

|
||||
|
||||
### Datenfluss: Fehlerhafte Übertragung
|
||||

|
||||
|
||||
## TCP Pipelining, Sliding Window
|
||||
### Pipelining
|
||||
- TCP-Sender kann mehrere Segmente senden, ohne auf die Bestätigung des Empfängers zu warten
|
||||
@ -355,15 +329,86 @@
|
||||
- → sofortiges Senden kleiner Pakete
|
||||
- Delayed ACKs abschalten/reduzieren
|
||||
|
||||
## TCP Flusskontrolle und MSS
|
||||
## 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
|
||||
|
||||
## TCP Sliding Window
|
||||
- rwnd, cwnd, swnd = min(cwnd, rwnd)
|
||||
### 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
|
||||

|
||||
|
||||
## Slow Start (sstresh) und Congestion Avoidance
|
||||
|
||||
## 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!
|
||||
|
||||
## TCP Tahoe und TCP Reno
|
||||

|
||||
|
||||
### 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
|
||||
|
||||

|
Reference in New Issue
Block a user