2. Page Load Times

🧠 1. Was ist `cwnd`?¶

cwnd (Congestion Window) ist ein interner Wert beim Sender von TCP-Daten (z. B. Webserver)
Er regelt, wie viele Bytes (bzw. Segmente) TCP auf einmal ins Netzwerk senden darf, ohne auf Bestätigungen (ACKs) zu warten.

Warum gibt es `cwnd`?¶

Damit der Sender nicht zu viele Daten auf einmal losschickt und dadurch das Netzwerk überlastet.

TCP weiß nicht, wo im Netz es gerade klemmt (Router, Leitungen, etc.)
Aber es merkt:
- 📉 Wenn ACKs langsam oder gar nicht zurückkommen → ⚠️ Stau → cwnd wird kleiner
- 📈 Wenn ACKs schnell und vollständig zurückkommen → 🟢 alles gut → cwnd wird größer

cwnd wächst bei:¶

ACKs, die zurückkommen
Je mehr ACKs, desto größer cwnd → erlaubt mehr gleichzeitige Sendungen

cwnd schrumpft bei:¶

Paketverlust oder Timeout
TCP wird vorsichtiger → reduziert cwnd

🔢 2. Was ist `IW` (Initial Window)?¶

Das ist der Startwert von cwnd, wenn eine neue Verbindung aufgebaut wird.
Beispiel: IW = 2 MSS → TCP darf direkt zu Beginn 2 Segmente senden (z. B. 1600 Bytes bei MSS = 800 Bytes)

🔁 3. Was ist RTT (Round-Trip Time)?¶

Die Zeit, die vergeht, bis ein gesendetes Paket beantwortet wird.
Also:
- 📤 Ein Paket geht raus
- 📥 Eine Antwort (z. B. ACK oder Daten) kommt zurück
  → Das ist eine RTT

Beispiel:

Client schickt HTTP-Request an Server
Server schickt erste Antwort (z. B. ein Segment)
→ Das Ganze zählt als 1 RTT

📬 4. Was sind ACKs?¶

Das sind kleine Nachrichten vom Empfänger an den Sender, die sagen: > „Ich habe dein Paket bekommen.“

TCP wartet auf diese ACKs, um:

zu wissen, was angekommen ist
zu entscheiden, ob cwnd erhöht werden darf

Ohne ACKs → kein Wachstum von cwnd.

🌍 5. Beobachtet `cwnd` nur das lokale Netz?¶

Nein.
cwnd bezieht sich auf den gesamten Pfad zwischen Client und Server (Ende-zu-Ende).

Es „fühlt“ Staus im Netz nur über die Rückmeldungen (ACKs)
Es kennt keine Router oder Leitungen direkt
Es reagiert aber auf Verluste, Verzögerungen und Doppelte ACKs als Zeichen: „Irgendwo ist es zu voll“

🌐 6. Unterschied HTTP mit und ohne Pipelining¶

Feature	Ohne Pipelining	Mit Pipelining
Anfragen	Eine nach der anderen	Alle auf einmal
Antworten	Erst Antwort 1, dann 2, dann 3	Auch in Reihenfolge – aber alle Anfragen schon vorher raus
Vorteil	Einfach, gut steuerbar	Schnellere Anfragen
Nachteil	Viele RTTs nötig	Head-of-Line-Blocking: Wenn eine Antwort hängt, hängen alle

📦 7. Beispiel: Bild wird übertragen (mit TCP)¶

Client fragt: „Gib mir Bild 5“
Server schaut auf sein cwnd – z. B. 2 MSS → schickt 2 Segmente
Client bekommt sie → schickt 2 ACKs
Server empfängt ACKs → erhöht cwnd → darf z. B. 4 Segmente schicken
Das geht so weiter, bis das Bild komplett da ist
Wenn alles ankam → keine neuen ACKs → Ruhe

💥 Merksätze zum Mitnehmen¶

cwnd lebt beim Sender
cwnd = Vertrauenslevel, wie viel man schicken darf
ACKs sind die Währung für Vertrauen
RTT = Anfrage + Antwort
Bei ACKs wächst cwnd (Slow Start)
Bei RTT wächst cwnd (Congestion Avoidance)
Kein explizites „cwnd ist jetzt größer“-Paket – es passiert intern
HTTP mit Pipelining = schneller, aber riskanter bei Problemen

💥 Kleine Übungsaufgabe¶

Objekt	Request Bytes	Request Segmente	Response Bytes	Response Segmente
HTML Code	1200	2	2000	3
Bild 1	1600	2	3200	4
Bild 2	3200	4	800	1
Bild 3	4800	6	8000	10
Bild 4	800	2	30000	38
Bild 5	1200	2	11600	15
Bild 6 – 14	800	1	8000	10
Bild 15	800	1	52000	65
Bild 16	800	1	11200	14
Bild 17 – 27	800	1	3200	4

Parameter	Wert
MSS	800 Bytes
IW	2 MSS

📝 Legende für folgende Beispiele:¶

MOReq[...] = HTML Request
IO1Req[...] = Bild-Request 1
MO:Sx–Sy = Server-Antwort für HTML
IOx:Sx–Sy = Server-Antwort für Bild x
ACK = Quittung für empfangenes Segment
cwnd = Congestion Window

🔷 Persistent HTTP ohne Pipelining¶

🔹 Regel 1: Kein Pipelining (HTTP-Verhalten)¶

Der Client darf nur einen Request gleichzeitig senden.
Erst nachdem die vollständige Antwort empfangen wurde, sendet er den nächsten Request.
Es gibt keine Überschneidung zwischen Request–Response–Zyklen.

🔹 Regel 2: TCP mit Slow Start¶

Server startet mit cwnd = IW = 2 MSS
Bei jedem ACK, das der Server bekommt, erhöht sich cwnd um 1 MSS
Wenn mehrere Segmente gesendet wurden, können mehrere ACKs ankommen → schnelleres Wachstum

RTT	Tx Client	cwnd Client	Client (Browser)	Server	cwnd Server	Tx Server
1	2 Segmente	2 MSS	`MOReq[1200]`	Empfängt Req, sendet ACK	2 MSS	1x ACK, 2 Segmente (HTML 0–1599)
2	2x ACK	4 MSS	ACK für HTML-Segmente	Erhöht cwnd, sendet rest HTML	4 MSS	1 Segment (HTML 1600–1999)
3	1x ACK + 2 Segmente	5 MSS	ACK + `IO1Req[1600]`	Empfängt Req, sendet ACK	5 MSS	1x ACK, 4 Segmente (Bild 1)
4	4x ACK + 4 Segmente	11 MSS	ACK + `IO2Req[3200]`	Empfängt Req, sendet ACK	9 MSS	1x ACK, 1 Segment (Bild 2)
5	1x ACK	12 MSS	ACK für Bild 2	Erhöht cwnd	10 MSS	–
Zur Legende

🔷 Persistent HTTP mit Pipelining¶

🔹 Regel 1: Pipelining erlaubt (HTTP-Verhalten)¶

Der Client kann mehrere Requests hintereinander senden, ohne auf Antworten zu warten.
Die Reihenfolge der Antworten muss vom Server korrekt eingehalten werden.
Effizienter, weil mehr RTTs parallel genutzt werden können.

🔹 Regel 2: TCP mit Slow Start (gleich wie oben)¶

cwnd beginnt mit 2 MSS
Bei jedem ACK wächst cwnd um 1 MSS (solange keine Verluste auftreten)(Slow Start)
Server nutzt cwnd, um mehrere Segmente gleichzeitig zu senden

RTT	Tx Client	cwnd Client	Client (Browser)	Server	cwnd Server	Tx Server
1	2 Segmente	2 MSS	`MOReq[1200]`	Empfängt Req, sendet ACK	2 MSS	1x ACK, 2 Segmente (HTML)
2	2x ACK + 8 Segmente	4 MSS	ACK + `IO1–IO3Req`	Empfängt Req, sendet 3x ACK	4 MSS	3x ACK, 3 Segmente (HTML Ende + Bild 1)
3	–	4 MSS	–	Erhöht cwnd, sendet rest Bild 1	5 MSS	1 Segment (Bild 1)
4	4x ACK	8 MSS	ACK für Bild 1	Erhöht cwnd, sendet Bild 2	9 MSS	1 Segment (Bild 2)
5	1x ACK	9 MSS	ACK für Bild 2	Erhöht cwnd, sendet Bild 3	10 MSS	10 Segmente (Bild 3)
Zur Legende

🔶 Was passiert bei Paketverlust? (gilt für beide Fälle)¶

📉 Regel 3: Verlusterkennung & Reaktion¶

Wenn ein Segment verloren geht, merkt der Client das daran, dass er mehrmals denselben ACK sendet
Der Server erkennt den Verlust bei:
- 3 doppelten ACKs → Fast Retransmit: Er sendet das verlorene Segment sofort nochmal
- Dann: Reduktion des cwnd
  - z. B. cwnd = cwnd / 2
  - Wechsel in den Congestion Avoidance-Modus
Beispiel: Stell dir vor, der Server sendet:
```
Segment 0 (Bytes 0–799) ✅
Segment 1 (Bytes 800–1599) ✅
Segment 2 (Bytes 1600–2399) ❌ ← dieses geht verloren
Segment 3 (Bytes 2400–3199) ✅
```

Der Client bekommt: - Segment 0 → sendet ACK 800 - Segment 1 → sendet ACK 1600 - ❌ Segment 2 fehlt → Client wartet auf 1600–2399 - Dann kommt Segment 3 (Bytes 2400–3199), aber Segment 2 fehlt noch!

📣 Jetzt passiert's:¶

Der Client kann Segment 3 nicht verwenden, solange Segment 2 fehlt.
→ Also schickt er nochmal einen ACK für 1600
→ und nochmal...
→ und nochmal...

📌 Diese doppelten ACKs für denselben Bytewert nennt man Duplicate ACKs.

🚨 Wann reagiert der Server?¶

Wenn der Server drei Duplicate ACKs für denselben Wert sieht (z. B. 3× ACK 1600), dann: - erkennt er, dass Segment 2 fehlt - → Fast Retransmit: er sendet Segment 2 sofort erneut - → Reduziert sein cwnd (häufig auf die Hälfte)

Bild 5
- Request: 1200 Bytes → 2 Segmente
- Response: 11600 Bytes → 15 Segmente
MSS = 800 Bytes
Wir nehmen an: Segment 7 (Bytes 5600–6399) geht verloren

📦 Beispiel: Paketverlust bei Bild 5 (Segment 7 fehlt)¶

RTT	Tx Client	cwnd Client	Client (Browser)	Server	cwnd Server	Tx Server
1	`IO5Req[1200]` (2 Segmente)	z. B. 20 MSS	sendet Bild-Request	empfängt Request, sendet ACK	z. B. 50 MSS	1x ACK, sendet 15 Segmente (Bild 5)
...				❌ Segment 7 (Byte 5600–6399) fehlt
2	1x DUP ACK (für Segment 6)	20 MSS	empfängt Segment 6	–	50 MSS	–
3	1x DUP-ACK (für Segment 6)	20 MSS	empfängt Segment 6	–	50 MSS	–
4	1x DUP-ACK (für Segment 6)	20 MSS	empfängt Segment 2	🔁 Fast Retransmit wird ausgelöst	50 MSS	Retransmit Segment 7
5	1x ACK	21 MSS	empfängt fehlendes Segment → komplett	erhöht cwnd	51 MSS	–

Zur Legende