update

2025-07-02 11:38:35 +02:00
parent 981742b1e9
commit dd58506ffe
20 changed files with 144 additions and 0 deletions
--- 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,3 +16,147 @@
 | 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         |
+  |---------------------------------|---------------------------------|
+  | ![image_940.png](image_940.png) | ![image_941.png](image_941.png) |
+
+
+## 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                                          | ![image_942.png](image_942.png) |
+| DNS                                         | übersetzt Webseitenname in IP-Adresse                     | ![image_943.png](image_943.png) |
+| HTTP<br/>Hyper Text Transfer Protocol       | Webseiten transferieren                                   | ![image_944.png](image_944.png) |
+| NBNS<br/>NetBIOS Name Service               | übersetzt lokale Hostnamen in IP-Adressen                 | ![image_945.png](image_945.png) |
+| SMTP<br/>Simple Mail Transfer Protocol      | Emails senden                                             | ![image_946.png](image_946.png) |
+| SNMP<br/>Simple Network Management Protocol | Netzwerkgeräte Managen                                    | ![image_947.png](image_947.png) |
+| SNTP<br/>Simple Network Time Protocol       | Gibt Zeit                                                 |                                 |
+| Telnet                                      | Bidirektionale Text-Kommunikation über Terminal-Anwendung | ![image_948.png](image_948.png) |
+| TFTP<br/>Trivial File Transfer Protocol     | Transferiert kleine Datenmengen                           | ![image_949.png](image_949.png) |
+
+## 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
+  - ![image_950.png](image_950.png)
+- Sockets als TC/RX Buffer
+  - ![image_951.png](image_951.png)
+
+## Ports und Sockets in der Praxis
+![image_952.png](image_952.png)
+![image_953.png](image_953.png)
+
+
+## Aufbau einer TCP Verbindung mit Sockets
+### 1. Server erstellt Socket
+![image_954.png](image_954.png)
+- stellt sich danach in den "listening" Modus
+  - wartet auf Client-Request
+
+### 2. Client erstellt Socket und verbindet sich
+![image_955.png](image_955.png)
+
+### 3. Transport Layer überträgt Nachricht zu Server
+![image_956.png](image_956.png)
+
+### 4. Server erstellt Socket und Prozess
+![image_957.png](image_957.png)
+
+### 5. Transport Layer übermittelt Nachrichten
+### 6. Sockets schließen (außer den aus 1)
+![image_958.png](image_958.png)
+
+## 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](#l-sung-nagle) deaktivieren
+    - kleine, verzögerte Pakete leiden
+    - → sofortiges Senden kleiner Pakete
+  - Delayed ACKs abschalten/reduzieren
+