split klausurfragen into per-course files and add erklaerung slides to 223015c

- split slides/klausurfragen.md into course-specific files: - slides/223015b/klausurfragen.md (blocks J-O: dateiformate) - slides/223015c/klausurfragen.md (blocks A-I: it-grundlagen) - add erklaerung slides to 223015c (16 new vertiefung slides) - update erklaerung slides in 223015b with deeper content - update makefile to build klausurfragen per-course - remove global klausurfragen from root index
2026-02-02 19:06:37 +01:00
parent 512fbd9d3d
commit ea7e905c61
8 changed files with 1789 additions and 1184 deletions
--- a/slides/223015c/02-netzwerke-protokolle-css.md
+++ b/slides/223015c/02-netzwerke-protokolle-css.md
@@ -71,6 +71,38 @@ section.aufgabe footer {
 section.glossar {
  font-size: 1.4rem;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: repeating-linear-gradient(
+    135deg,
+    #fce4ec,
+    #fce4ec 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.erklaerung {
+    background: #fce4ec !important;
+  }
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #a02060;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
 </style>

 <!-- _class: invert -->
@@ -402,6 +434,31 @@ SPEAKER NOTES:

 ---

+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# TCP/IP-Modell – Vertiefung
+
+Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
+
+**Schicht-Aufgaben im Detail:**
+
+| Schicht | Frage | Protokolle | Geräte |
+|---------|-------|------------|--------|
+| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
+| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
+| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
+| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
+
+**OSI vs. TCP/IP:**
+- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
+- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
+
+**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
+
+---
+
 # Schichten verpacken Daten

 ```
@@ -461,6 +518,33 @@ SPEAKER NOTES:

 ---

+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Dateneinheiten & Encapsulation – Vertiefung
+
+**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
+
+**Was jeder Header enthält:**
+
+| Schicht | Einheit | Header-Inhalte |
+|---------|---------|----------------|
+| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
+| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
+| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
+| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
+
+**Overhead-Rechnung (1 Byte HTTP-Body):**
+- Ethernet: 14 + 4 Bytes (Header + Trailer)
+- IP: 20 Bytes (ohne Optionen)
+- TCP: 20 Bytes (ohne Optionen)
+- **Minimum: 58 Bytes für 1 Byte Nutzlast**
+
+**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
+
+---
+
 # Warum ist das clever?

 **Ohne Schichten:**
@@ -640,6 +724,34 @@ SPEAKER NOTES:

 ---

+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# IP, MAC, Port – Vertiefung
+
+Drei Adressebenen lösen drei verschiedene Probleme:
+
+**IP-Adresse (Schicht 2 – Internet):**
+- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
+- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
+- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
+
+**MAC-Adresse (Schicht 1 – Netzzugang):**
+- 48 Bit, vom Hersteller fest vergeben (theoretisch)
+- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
+- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
+- ARP (Address Resolution Protocol) übersetzt IP → MAC
+
+**Port (Schicht 3 – Transport):**
+- 16 Bit → 65.535 mögliche Ports
+- Well-Known Ports (0–1023): HTTP=80, HTTPS=443, SSH=22
+- Ephemeral Ports (49152–65535): Dynamisch für Client-Verbindungen
+
+**Warum ändert sich nur MAC?** IP ist das Endziel (Brief-Adresse), MAC ist der aktuelle Bote (wer trägt den Brief gerade?).
+
+---
+
 <!-- _class: lead -->

 # Die Reise eines Klicks
@@ -922,6 +1034,36 @@ SPEAKER NOTES:

 ---

+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# 3-Way-Handshake – Vertiefung
+
+Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
+
+**Warum zufällige Startwerte (ISN)?**
+- Sicherheit: Verhindert Session-Hijacking durch Raten
+- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
+- ISN = Initial Sequence Number, vom OS zufällig gewählt
+
+**TCP-Flags im Handshake:**
+
+| Paket | Flags | Bedeutung |
+|-------|-------|-----------|
+| 1 | SYN | Client will Verbindung, sendet seine ISN |
+| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 |
+| 3 | ACK | Client bestätigt Server-ISN+1 |
+
+**Was passiert bei Problemen?**
+- Kein SYN-ACK → Client wiederholt SYN (Timeout)
+- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft
+- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt)
+
+**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch.
+
+---
+
 # Nach dem Handshake

 **Status:** Die TCP-Verbindung steht.
@@ -1429,6 +1571,38 @@ SPEAKER NOTES:
 <!-- _footer: '' -->

 # TCP vs. UDP – Vertiefung
+
+Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
+
+**TCP (Transmission Control Protocol):**
+- Verbindungsorientiert (Handshake vor Daten)
+- Sequenznummern → Reihenfolge garantiert
+- ACKs + Retransmission → Kein Datenverlust
+- Flow Control (Sliding Window) → Empfänger nicht überlasten
+- Congestion Control → Netzwerk nicht überlasten
+
+**UDP (User Datagram Protocol):**
+- Verbindungslos (Fire-and-Forget)
+- Keine Sequenznummern, keine ACKs
+- Header nur 8 Bytes (TCP: 20+ Bytes)
+- Anwendung muss selbst für Zuverlässigkeit sorgen
+
+| Anwendung | Protokoll | Grund |
+|-----------|-----------|-------|
+| HTTP/HTTPS | TCP | Vollständigkeit kritisch |
+| DNS | UDP | Kleine Pakete, schnelle Antwort |
+| Video-Streaming | UDP/QUIC | Latenz wichtiger als Perfektion |
+| Online-Gaming | UDP | Echtzeit, veraltete Daten nutzlos |
+
+**QUIC:** Googles Protokoll kombiniert UDP-Geschwindigkeit mit TCP-ähnlicher Zuverlässigkeit (HTTP/3).
+
+---
+
+# Warum UDP bei Video-Calls?
+
+**Szenario:** Ein Paket geht verloren.
+
+| TCP | UDP |
 |-----|-----|
 | Warten... neu anfordern... warten... | Ignorieren, nächstes Frame zeigen |
 | Video friert ein | Kurzes Artefakt |
@@ -1508,6 +1682,37 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
 <!-- _footer: '' -->

 # HTTP-Methoden – Vertiefung
+
+HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
+
+**CRUD-Mapping (Create, Read, Update, Delete):**
+
+| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
+|---------|------|------------|------|-------------------|
+| GET | Read | Ja | Ja | Ressource abrufen |
+| POST | Create | Nein | Nein | Formular, neue Ressource |
+| PUT | Update | Ja | Nein | Ressource vollständig ersetzen |
+| PATCH | Update | Nein | Nein | Ressource teilweise ändern |
+| DELETE | Delete | Ja | Nein | Ressource löschen |
+
+**Idempotent:** Mehrfaches Ausführen hat denselben Effekt wie einmaliges (GET, PUT, DELETE).
+**Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
+
+**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
+```
+GET /users/42        → Benutzer 42 abrufen
+PUT /users/42        → Benutzer 42 vollständig ersetzen
+DELETE /users/42     → Benutzer 42 löschen
+POST /users          → Neuen Benutzer erstellen
+```
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTTP Status-Codes

 ```http
 HTTP/1.1 200 OK
@@ -1543,6 +1748,31 @@ Status-Codes sagen euch, was passiert ist.
 <!-- _footer: '' -->

 # HTTP Status-Codes – Vertiefung
+
+Die erste Ziffer kategorisiert die Antwort:
+
+| Bereich | Kategorie | Häufige Codes |
+|---------|-----------|---------------|
+| 1xx | Informational | 100 Continue, 101 Switching Protocols |
+| 2xx | Success | 200 OK, 201 Created, 204 No Content |
+| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
+| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
+| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
+
+**Wichtige Unterscheidungen:**
+- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
+- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
+- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
+
+**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Zusammenfassung Teil 1

 **Der Ablauf:**
 1. DNS (UDP:53) → Name zu IP
@@ -1579,6 +1809,40 @@ Wie Encapsulation funktioniert.
 <!-- _footer: '' -->

 # Netzwerk-Grundlagen – Vertiefung
+
+Die vier Kernkonzepte für Web-Entwickler:
+
+**1. DNS-Auflösung:**
+- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
+- Rekursive Abfrage: Root → TLD → Authoritative
+- Caching auf jeder Ebene (TTL = Time To Live)
+
+**2. TCP-Verbindungsaufbau:**
+- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
+- Keep-Alive: Verbindung bleibt offen für mehrere Requests
+- HTTP/2: Multiplexing – viele Requests über eine Verbindung
+
+**3. HTTP Request/Response:**
+```
+Request:  Methode + URL + Header + (Body)
+Response: Status + Header + Body
+```
+
+**4. Schichten & Adressen:**
+| Was bleibt gleich? | Was ändert sich? |
+|-------------------|------------------|
+| Ziel-IP | MAC-Adressen (bei jedem Hop) |
+| Ports | – |
+
+**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
+
+---
+
+# Werkzeuge zum Selbst-Erkunden
+
+**Im Browser (F12 → Network-Tab):**
+- Jeder Request sichtbar
+- Timing, Headers, Response

 **Im Terminal:**
 ```bash
@@ -1870,6 +2134,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
 <!-- _footer: '' -->

 # CSS Spezifität – Vertiefung
+
+Spezifität bestimmt, welche CSS-Regel gewinnt, wenn mehrere auf dasselbe Element zutreffen. Sie wird als 4-stellige Zahl berechnet: **(Inline, IDs, Klassen, Elemente)**.
+
+**Berechnung:**
+
+| Selektor | Inline | IDs | Klassen | Elemente | Gesamt |
+|----------|--------|-----|---------|----------|--------|
+| `p` | 0 | 0 | 0 | 1 | 0,0,0,1 |
+| `.info` | 0 | 0 | 1 | 0 | 0,0,1,0 |
+| `p.info` | 0 | 0 | 1 | 1 | 0,0,1,1 |
+| `#header` | 0 | 1 | 0 | 0 | 0,1,0,0 |
+| `#header .nav a` | 0 | 1 | 1 | 1 | 0,1,1,1 |
+
+**Wichtige Regeln:**
+- Eine Klasse (0,0,1,0) schlägt **jede Anzahl** von Elementen (0,0,0,99)
+- Eine ID schlägt jede Anzahl von Klassen
+- `!important` bricht alles → vermeiden, da schwer zu überschreiben
+
+**Best Practice:** Flache Spezifität anstreben. BEM-Methodik (`.block__element--modifier`) hält Spezifität gleichmäßig niedrig.
+
+---
+
+# Box-Modell
+
+```
+┌─────────────────────────────────────┐
+│              margin                 │
 │   ┌─────────────────────────────┐   │
 │   │          border             │   │
 │   │   ┌─────────────────────┐   │   │
@@ -2117,6 +2408,37 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
 <!-- _footer: '' -->

 # Responsive Design – Vertiefung
+
+**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
+
+**Breakpoints (gängige Werte):**
+
+| Breakpoint | Gerät | Media Query |
+|------------|-------|-------------|
+| < 576px | Smartphone (Portrait) | Basis (kein Query) |
+| ≥ 576px | Smartphone (Landscape) | `@media (min-width: 576px)` |
+| ≥ 768px | Tablet | `@media (min-width: 768px)` |
+| ≥ 992px | Desktop | `@media (min-width: 992px)` |
+| ≥ 1200px | Large Desktop | `@media (min-width: 1200px)` |
+
+**Viewport-Meta-Tag (kritisch!):**
+```html
+<meta name="viewport" content="width=device-width, initial-scale=1">
+```
+Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
+
+**Moderne Alternativen zu Media Queries:**
+- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
+- Container Queries: Reagieren auf Container-Größe statt Viewport
+- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
+
+---
+
+# Zusammenfassung CSS
+
+**Selektoren:**
+- Element: `p`
+- Klasse: `.wichtig`
 - ID: `#header`
 - Kombinationen: `nav > a`, `h2 + p`