This commit is contained in:
David Schirrmeister
2025-07-02 11:38:35 +02:00
parent 981742b1e9
commit dd58506ffe
20 changed files with 144 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 153 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 168 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 76 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 211 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 207 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 89 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 69 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 78 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 237 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 221 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 244 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 295 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 148 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 146 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 326 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 358 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 178 KiB

View File

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