uni/slides/223015c/02-netzwerke-protokolle-css.md

---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Grundlagen IT- und Internettechnik (223015c)"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
title: "Kapitel 2: Netzwerke, Protokolle & CSS"
---

<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #d63384;
  --color-dimmed: #4a4a6a;
}
section.invert {
  --color-foreground: #fff;
}
section {
  font-size: 1.7rem;
}
h1 {
  color: #a02060;
}
section.invert h1 {
  color: #fff;
}
h2 {
  color: #1f2937;
}
pre {
  background: #0f0f23;
  color: #d63384;
  border-radius: 8px;
  border-left: 3px solid #d63384;
}
pre code {
  background: transparent;
  color: inherit;
}
code {
  background: #1a1a2e;
  color: #d63384;
  padding: 0.15em 0.4em;
  border-radius: 4px;
}
a {
  color: var(--color-highlight);
}
section.klausur {
  background: repeating-linear-gradient(
    135deg,
    #fce4ec,
    #fce4ec 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.klausur {
    background: #fce4ec !important;
  }
}
section.aufgabe {
  background: #fce4ec !important;
}
section.aufgabe footer {
  display: none;
}
section.glossar {
  font-size: 1.4rem;
}
</style>

<!-- _class: invert -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: black -->

![bg fit opacity:0.2](./assets/background-termin-2.png)

# Grundlagen IT- und Internettechnik

**223015c** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart

**Wintersemester 2025/26**

[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/qr/slides-223015c.png)

---

<!-- _class: lead -->

# Kapitel 2
## Netzwerke, Protokolle & CSS

<!--
SPEAKER NOTES:
- Zwei Themen: Netzwerke + CSS
- Netzwerke = Fundament. Warum lädt was langsam? Warum Fehler?
- Viele neue Begriffe heute – ist normal
- Glossar gleich = Landkarte, füllt sich mit Bedeutung
-->

---

# Agenda

**Teil 1: Netzwerke & Protokolle**
- Glossar: Die wichtigsten Begriffe
- Das Schichtenmodell: Wie das Internet organisiert ist
- Die Reise eines Klicks: Was passiert bei einem Seitenaufruf?

**Teil 2: CSS**
- Grundlagen, Selektoren, Spezifität
- Box-Modell, Farben, Einheiten

<!--
SPEAKER NOTES:
- Struktur: Glossar → Schichtenmodell → Reise eines Klicks
- Glossar = Landkarte
- Schichtenmodell = "Betriebssystem" des Internets
- Reise = praktische Anwendung
- CSS nach Pause
-->

---

# Ressourcen zum Selbstlernen

* **CODE CRISPIES: https://codecrispi.es/**
* Online Code-Editor: https://codepen.io/pen/
* MDN (Mozilla Developer Network): https://developer.mozilla.org/de/
* Flexbox-Spiel: https://flexboxfroggy.com/
* Grid-Spiel: https://cssgridgarden.com/

<!--
SPEAKER NOTES:
- Code Crispies = unser Material
- Codepen = sofort CSS ausprobieren
- MDN = DIE Referenz schlechthin
- Spiele für Flexbox/Grid – später relevant
-->

---

<!-- _class: lead -->

# Teil 1: Netzwerke & Protokolle
## Die Infrastruktur des Webs

<!--
SPEAKER NOTES:
- Fundament: Ohne Netzwerk kein Internet, kein Web, keine Apps
- Jetzt: Begriffe-Bombardement – ist okay
- Nächste Folie = Referenz zum Zurückblättern
-->

---

<!-- _class: glossar -->

# Glossar: Die Landkarte

| Begriff | Was ist das? | Analogie |
|---------|--------------|----------|
| **Client** | Der, der fragt (Browser) | Gast im Restaurant |
| **Server** | Der, der antwortet | Küche im Restaurant |
| **Request** | Die Anfrage | Bestellung |
| **Response** | Die Antwort | Das Essen |
| **Protokoll** | Regeln für Kommunikation | Speisekarte + Bestellablauf |
| **Host** | Ein Rechner im Netz | Ein Haus mit Adresse |

<!--
SPEAKER NOTES:
- 6 Grundbegriffe – tauchen überall auf
- Client/Server = Grundstruktur des Webs
  - Browser = Client
  - Google/HdM/Netflix = Server
- Request/Response = Kommunikationsmuster
- Protokoll = Regelwerk
  - Analogie: Restaurant in Japan ohne Regeln zu kennen
- Host = Rechner mit Adresse im Netz
-->

---

<!-- _class: glossar -->

# Glossar: Adressen & Identitäten

| Begriff | Was ist das? | Beispiel |
|---------|--------------|----------|
| **IP-Adresse** | Globale Adresse im Internet | `212.132.79.37` |
| **MAC-Adresse** | Hardware-Adresse der Netzwerkkarte | `aa:bb:cc:dd:ee:ff` |
| **Port** | "Türnummer" auf einem Rechner | `80`, `443`, `22` |
| **DNS** | Telefonbuch: Name → IP | hdm-stuttgart.de → IP |
| **Domain** | Menschenlesbarer Name | `hdm-stuttgart.de` |

<!--
SPEAKER NOTES:
- Alles im Internet läuft über Adressen
- IP = Postanschrift, global eindeutig
- MAC = Hardware-Adresse, ab Werk eingebrannt, nur lokal
- Port = welches Programm auf dem Rechner
  - 80 = Web, 443 = HTTPS
  - Sichtbar in URLs: example.com:8080
- DNS = Telefonbuch: Name → Nummer
-->

---

<!-- _class: glossar -->

# Glossar: Daten unterwegs

| Begriff | Was ist das? | Schicht |
|---------|--------------|---------|
| **Paket** | Daten + IP-Header | Internet (Layer 3) |
| **Segment** | Daten + TCP-Header | Transport (Layer 4) |
| **Frame** | Daten + MAC-Header | Netzzugang (Layer 2) |
| **Header** | Metadaten am Anfang | Jede Schicht |
| **Payload** | Die eigentlichen Nutzdaten | Der Inhalt |

<!--
SPEAKER NOTES:
- Abstrakt, aber wichtig
- Payload = der eigentliche Inhalt (Text, Bild, HTML)
- Header = Metadaten (wer, wohin, wie groß)
- Paket/Segment/Frame = gleiche Daten, verschiedene Verpackung
  - Wie Matroschka: Schicht packt Schicht ein
- Wird klarer beim Schichtenmodell gleich
-->

---

<!-- _class: glossar -->

# Glossar: Netzwerk-Eigenschaften

| Begriff | Was ist das? | Einheit |
|---------|--------------|---------|
| **Latenz** | Verzögerung (hin + zurück) | Millisekunden |
| **Bandbreite** | Datenmenge pro Zeiteinheit | Mbit/s |
| **Hop** | Ein Sprung zum nächsten Router | – |
| **Round-Trip** | Hin- und Rückweg | – |
| **Ping** | "Bist du da?" + Antwort | ms |

<!--
SPEAKER NOTES:
- Performance-Begriffe
- Latenz = Verzögerung
  - Gaming: niedrig wichtig
  - Download: egal
- Bandbreite = Straßenbreite
  - Streaming: hoch wichtig
- Hop = Sprung Router→Router (typisch 10-20)
- Ping: Selbst testen!
  - Terminal: `ping google.de`
  - Zahl = Latenz in ms
-->

---

<!-- _class: glossar -->

# Glossar: Protokolle

| Protokoll | Wofür? | Port | Schicht |
|-----------|--------|------|---------|
| **HTTP** | Webseiten übertragen | 80 | Anwendung |
| **HTTPS** | HTTP + Verschlüsselung | 443 | Anwendung |
| **TCP** | Zuverlässige Übertragung | – | Transport |
| **UDP** | Schnelle Übertragung | – | Transport |
| **IP** | Routing durchs Internet | – | Internet |
| **DNS** | Namen → IP-Adressen | 53 | Anwendung |

<!--
SPEAKER NOTES:
- Die wichtigsten Protokolle
- HTTP/HTTPS = Webseiten (S = verschlüsselt)
- TCP = zuverlässig (alles kommt an)
- UDP = schnell (Pakete können verloren gehen)
- IP = Routing durchs Internet
- DNS = Namensauflösung
- Schicht-Spalte: HTTP baut auf TCP, TCP auf IP
  - Das SIND die Schichten
-->

---

<!-- _class: lead -->

# Das Schichtenmodell
## Warum ist Netzwerk-Kommunikation in Schichten organisiert?

<!--
SPEAKER NOTES:
- Wichtigster Teil heute
- Wenn das sitzt → alles andere ordnet sich ein
- Einstiegsfrage: Warum so kompliziert?
-->

---

# Das Problem: Komplexität

Zwischen dir und einer Webseite liegen:

```
Dein Browser
    ↓
Deine Netzwerkkarte (WLAN oder Ethernet)
    ↓
Router im Flur / zu Hause
    ↓
Netzwerk der HdM / deines Providers
    ↓
Das Internet (dutzende Router)
    ↓
Netzwerk des Ziel-Servers
    ↓
Der Webserver
```

Jede Komponente "spricht" anders.

<!--
SPEAKER NOTES:
- Browser→Server: min. 7-8 Stationen
- Jede Station: andere Aufgabe
- Browser versteht HTTP
- Netzwerkkarte versteht nur Bits (Strom an/aus)
- Router versteht IP
- Wie zusammenbringen?
-->

---

# Die Lösung: Arbeitsteilung

Statt dass jedes Programm alles können muss: **Aufgaben aufteilen.**

| Wer? | Aufgabe | Typische Geräte |
|------|---------|-----------------|
| **Browser/App** | Was will ich? | Laptop, Handy, Server |
| **TCP/UDP** | Kommt alles an? | – (Software) |
| **IP** | Welcher Rechner? | Router, Firewall |
| **Ethernet/WLAN** | Nächstes Gerät? | Switch, Access Point |
| **Physik** | Signale übertragen | Kabel, Glasfaser, Antenne |

<!--
SPEAKER NOTES:
- Grundprinzip: Arbeitsteilung
- Jede Schicht = eine Aufgabe, kennt nur Nachbarn
- Browser sagt "will Webseite" – weiß nichts von Ethernet
- TCP weiß nichts von WLAN vs. Glasfaser
- → Abstraktion: Komplexität verstecken
- Geräte-Spalte: Wo "lebt" diese Schicht?
  - Router = Layer 3, liest IP
  - Switch = Layer 2, liest MAC
  - Access Point = Layer 1-2
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Das TCP/IP-Modell

| Schicht | Name | Aufgabe | Protokolle |
|---------|------|---------|------------|
| **4** | Anwendung | Was? Welcher Dienst? | HTTP, DNS, SMTP |
| **3** | Transport | Zuverlässigkeit, Ports | TCP, UDP |
| **2** | Internet | Routing, globale Adressen | IP |
| **1** | Netzzugang | Lokale Übertragung | Ethernet, WLAN |

**4 Schichten. Das reicht, um das Internet zu verstehen.**

<!--
SPEAKER NOTES:
- TCP/IP = das echte Internet
- 4 Schichten:
  - Anwendung: Was will ich? (HTTP, DNS, Mail)
  - Transport: Kommt an? Welches Programm? (TCP, UDP)
  - Internet: Wie zum Zielrechner? (IP)
  - Netzzugang: Wie zum nächsten Gerät? (Ethernet, WLAN)
- KLAUSUR: Welches Protokoll → welche Schicht
-->

---

# Schichten verpacken Daten

```
Anwendung:  [ HTTP-Request: "GET /index.html" ]
                 ↓ verpackt in
Transport:  [ TCP-Header | HTTP-Request ]
                 ↓ verpackt in
Internet:   [ IP-Header | TCP-Header | HTTP-Request ]
                 ↓ verpackt in
Netzzugang: [ Eth-Header | IP-Header | TCP | HTTP | Eth-Trailer ]
                 ↓
Physik:     01001000 01010100 01010100...
```

**Encapsulation:** Jede Schicht packt ein.
**Decapsulation:** Beim Empfang wird ausgepackt.

<!--
SPEAKER NOTES:
- Encapsulation = Verpackung
- Anwendung hat Daten (z.B. HTTP-Request)
- TCP: eigener Header dazu (Ports, Seq-Nr) → weiter
- IP: eigener Header dazu (IPs) → weiter
- Ethernet: Header + Trailer (MACs, Prüfsumme)
- Am Ende: Bits → elektrische Signale / Funk
- Empfang: Rückwärts auspacken
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Dateneinheiten pro Schicht

| Schicht | Name | Dateneinheit | Was kommt hinzu? |
|---------|------|--------------|------------------|
| Anwendung | HTTP, DNS | **Daten** | – |
| Transport | TCP, UDP | **Segment** | Ports, Sequenznummern |
| Internet | IP | **Paket** | IP-Adressen |
| Netzzugang | Ethernet | **Frame** | MAC-Adressen, Prüfsumme |

Merkhilfe: **D**aten → **S**egment → **P**aket → **F**rame
(„**D**er **S**ache **P**raktischer **F**olgen")

<!--
SPEAKER NOTES:
- Glossar-Begriffe jetzt eingeordnet:
  - Anwendung: Daten/Message
  - Transport: Segment
  - Internet: Paket
  - Netzzugang: Frame
- Merkhilfe: D-S-P-F (eigene erfinden!)
- KLAUSUR: Begriff → Schicht
-->

---

# Warum ist das clever?

**Ohne Schichten:**
Jede App müsste wissen, wie Ethernet-Frames gebaut werden, wie WLAN funktioniert, wie Router Pakete weiterleiten...

**Mit Schichten:**
Der Browser sagt: "Ich will diese Seite."
Alles andere übernehmen die Schichten darunter.

**Austauschbarkeit:**
WLAN statt Ethernet? Nur Schicht 1 ändert sich.
HTTP/2 statt HTTP/1? Nur Schicht 4 ändert sich.

<!--
SPEAKER NOTES:
- Der Witz: Unabhängigkeit
- WLAN→Ethernet: Browser merkt nichts, HTTP gleich, TCP gleich
- Neues Protokoll HTTP/3: Untere Schichten egal
- = Lose Kopplung
- Jede Schicht separat weiterentwickelbar
-->

---

# Exkurs: OSI vs. TCP/IP

```
    OSI (7 Schichten)              TCP/IP (4 Schichten)
┌─────────────────────┐        ┌─────────────────────┐
│  7. Anwendung       │        │                     │
├─────────────────────┤        │      Anwendung      │
│  6. Darstellung     │        │                     │
├─────────────────────┤        │                     │
│  5. Sitzung         │        │                     │
├─────────────────────┤        ├─────────────────────┤
│  4. Transport       │        │      Transport      │
├─────────────────────┤        ├─────────────────────┤
│  3. Vermittlung     │        │      Internet       │
├─────────────────────┤        ├─────────────────────┤
│  2. Sicherung       │        │                     │
├─────────────────────┤        │     Netzzugang      │
│  1. Bitübertragung  │        │                     │
└─────────────────────┘        └─────────────────────┘
```

OSI = Theorie. TCP/IP = Realität.

<!--
SPEAKER NOTES:
- OSI = 7 Schichten, theoretisches Referenzmodell
- TCP/IP = 4 Schichten, so gebaut das Internet
- OSI eleganter aufgeteilt, aber nicht real
- Für uns: TCP/IP reicht
- OSI in anderen Kursen → jetzt wisst ihr Zusammenhang
-->

---

<!-- _class: lead -->

# Die drei Adressen
## IP, MAC und Port – wer braucht was?

<!--
SPEAKER NOTES:
- Drei Adresstypen verstehen = häufige Fehlerquelle vermeiden
- Warum drei? Reicht nicht eine?
-->

---

# IP-Adresse: Das Endziel

```
212.132.79.37
```

- **Global eindeutig** (im gesamten Internet)
- Identifiziert einen **Rechner**
- **Bleibt gleich** auf dem gesamten Weg
- Analogie: **Empfänger auf einem Brief**

Router lesen die IP und entscheiden:
"Ist das für mich? Nein → in welche Richtung weiterleiten?"

<!--
SPEAKER NOTES:
- IP = Adresse auf Brief
- Global eindeutig (vereinfacht, IPv4/v6 ignoriert)
- WICHTIG: Ändert sich NICHT auf dem Weg
  - Egal wie viele Router → Ziel-IP bleibt gleich
-->

---

# MAC-Adresse: Der nächste Schritt

```
aa:bb:cc:dd:ee:ff
```

- **Lokal eindeutig** (nur im lokalen Netzwerk relevant)
- Identifiziert eine **Netzwerkkarte**
- **Ändert sich bei jedem Hop**
- Analogie: **"Nächstes Postamt: XY"**

Funktioniert nur innerhalb eines Netzwerksegments.

<!--
SPEAKER NOTES:
- MAC = ganz anders als IP
- Identifiziert Hardware (Netzwerkkarte)
- NUR lokal relevant
  - Laptop kennt MAC des Routers
  - Kennt NICHT MAC des Webservers
- ÄNDERT sich bei jedem Hop
  - Laptop→Router: andere MACs als Router→nächster Router
-->

---

# Port: Das richtige Programm

```
212.132.79.37:443
              └─── Port 443 = HTTPS
```

- Identifiziert ein **Programm** auf einem Rechner
- Ein Rechner, viele Dienste
- Analogie: **Wohnungstür im Mehrfamilienhaus**

| Port | Dienst |
|------|--------|
| 80 | HTTP |
| 443 | HTTPS |
| 22 | SSH |
| 53 | DNS |

<!--
SPEAKER NOTES:
- Dritte Ebene: Port
- Ein Server, viele Programme (Web, Mail, SSH...)
- Port = welches Programm kriegt's
- Standards:
  - 80 = HTTP (unverschlüsselt)
  - 443 = HTTPS (verschlüsselt)
  - 22 = SSH
  - 53 = DNS
- In URLs sichtbar: example.com:8080
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# IP vs. MAC vs. Port

| | IP-Adresse | MAC-Adresse | Port |
|---|-----------|-------------|------|
| **Frage** | Welcher Rechner? | Welches Gerät nebenan? | Welches Programm? |
| **Reichweite** | Global | Lokal (1 Hop) | Auf einem Rechner |
| **Ändert sich?** | Nein | Ja, bei jedem Hop | Nein |
| **Schicht** | Internet (IP) | Netzzugang (Ethernet) | Transport (TCP/UDP) |
| **Beispiel** | 212.132.79.37 | aa:bb:cc:dd:ee | 443 |

<!--
SPEAKER NOTES:
- KLAUSUR: Diese Tabelle
- IP: Welcher Rechner? Global. Bleibt gleich.
- MAC: Welcher Nachbar? Lokal. Ändert sich.
- Port: Welches Programm? Bleibt gleich.
- Merken: NUR MAC ändert sich unterwegs
-->

---

<!-- _class: lead -->

# Die Reise eines Klicks
## Was passiert, wenn du `www.hdm-stuttgart.de` aufrufst?

<!--
SPEAKER NOTES:
- Alle Werkzeuge da: Schichten, Adressen, Protokolle
- Jetzt anwenden
- URL → Enter → 200ms → Webseite
- Was passiert in 200ms?
-->

---

# Das Szenario

Du bist im WLAN der HdM und rufst auf:

```
https://www.hdm-stuttgart.de
```

**Zwischen Enter und fertiger Seite:** ~200 Millisekunden.

In dieser Zeit passieren hunderte Operationen.

<!--
SPEAKER NOTES:
- 200ms = 1/5 Sekunde, gefühlt instant
- In dieser Zeit:
  - DNS, TCP-Aufbau, HTTP-Request/Response
  - HTML parsen, CSS laden, Bilder, JS
- Fokus: Netzwerk-Seite bis HTML ankommt
-->

---

# Die Zeitlinie

```
[0 ms]     DNS: "Welche IP hat www.hdm-stuttgart.de?"
              ↓
[~20 ms]   DNS-Antwort: "212.132.79.37"
              ↓
[~25 ms]   TCP-Handshake beginnt
              ↓
[~50 ms]   TCP-Verbindung steht
              ↓
[~55 ms]   HTTP-Request: "GET /index.html"
              ↓
[~150 ms]  HTTP-Response: HTML kommt zurück
              ↓
[~200 ms]  Browser rendert die Seite
```

<!--
SPEAKER NOTES:
- Grober Ablauf
- Jeder Schritt: Alle Schichten durchlaufen
  - Runter beim Senden
  - Rauf beim Empfangen
- Los mit DNS
-->

---

<!-- _class: lead -->

# Schritt 1: DNS
## "Wo wohnt hdm-stuttgart.de?"

<!--
SPEAKER NOTES:
- Browser kennt: www.hdm-stuttgart.de
- Internet braucht: 212.132.79.37
- Jemand muss übersetzen → DNS
-->

---

# DNS: Das Telefonbuch des Internets

**D**omain **N**ame **S**ystem

```
www.hdm-stuttgart.de  →  212.132.79.37
```

Dein Laptop fragt sich durch:

1. **Browser-Cache:** "War ich da kürzlich?" → Nein
2. **OS-Cache:** "Kennt das Betriebssystem die IP?" → Nein
3. **Router/Provider:** DNS-Server wird gefragt

<!--
SPEAKER NOTES:
- DNS = Telefonbuch (Name → Nummer)
- Erst lokal schauen:
  - Browser-Cache (kürzlich besucht?)
  - OS-Cache
- Sonst: DNS-Server fragen (Provider/Router)
-->

---

# Die DNS-Hierarchie

```
                    . (Root)
                   /|\
                  / | \
               .de .com .org ...
               /
        hdm-stuttgart
             |
            www
```

**Dezentral:** Niemand kennt alles.
Jede Ebene kennt nur die nächste.

<!--
SPEAKER NOTES:
- Hierarchisch wie Baum
- Root-Server → kennen .de, .com, .org Server
- .de-Server → kennen alle .de-Domains
- HdM-Server → kennt www, mail, etc.
- Niemand muss alle Milliarden kennen
-->

---

# Der DNS-Lookup

```
Dein Laptop → Resolver:    "Wo ist www.hdm-stuttgart.de?"

Resolver → Root (.):       "Wer verwaltet .de?"
                           ← "Frag 194.0.0.53"

Resolver → .de-Server:     "Wer verwaltet hdm-stuttgart.de?"
                           ← "Frag den Nameserver der HdM"

Resolver → HdM-NS:         "Welche IP hat www?"
                           ← "212.132.79.37"

Resolver → Dein Laptop:    "Die IP ist 212.132.79.37"
```

<!--
SPEAKER NOTES:
- Kompletter Ablauf (wenn nichts gecached)
- Resolver = typisch beim Provider, macht Arbeit
- Root → .de-Server → HdM-NS → IP
- Klingt aufwändig → ist es
- Deshalb: Caching wie verrückt
  - Meiste Anfragen lokal beantwortet
-->

---

# DNS ist selbst Netzwerk

Die DNS-Anfrage ist ein ganz normales Paket:

| Eigenschaft | Wert |
|-------------|------|
| **Protokoll** | UDP (meistens) |
| **Port** | 53 |
| **Inhalt** | "A-Record für www.hdm-stuttgart.de?" |

DNS durchläuft alle Schichten – genau wie später HTTP.

<!--
SPEAKER NOTES:
- Wichtig: DNS ≠ Magie
- DNS = normales Netzwerk-Protokoll
- Nutzt UDP (schneller, kleine Anfragen)
- Port 53
- Wird auch verpackt: UDP→IP→Ethernet→Bits
-->

---

# Nach dem DNS-Lookup

**Ergebnis:**

```
www.hdm-stuttgart.de = 212.132.79.37
```

Diese Information wird gecached (für Minuten bis Stunden).

**Nächster Schritt:** Verbindung aufbauen.

<!--
SPEAKER NOTES:
- IP bekannt → Browser weiß Ziel
- Info wird gecached (Min-Std)
- Nächster Schritt: TCP-Verbindung
-->

---

<!-- _class: lead -->

# Schritt 2: TCP-Handshake
## "Hallo Server, bist du da?"

<!--
SPEAKER NOTES:
- HTTP läuft über TCP
- TCP = verbindungsorientiert
- Vor Daten: Beide Seiten müssen bereit sein
- Handshake = Händeschütteln vor Gespräch
- Analogie: Telefon klingeln → abheben → "Hallo?" → reden
-->

---

# Warum ein Handshake?

TCP ist **verbindungsorientiert**:

- Beide Seiten müssen bereit sein
- Beide kennen die Sequenznummern des anderen
- Verlorene Pakete können erkannt und neu angefordert werden

**Analogie:**
Telefonat: Klingeln → Abheben → "Hallo?" → Gespräch beginnt

Nicht: Einfach losreden und hoffen, dass jemand zuhört.

<!--
SPEAKER NOTES:
- Warum Aufwand?
- Internet: Pakete können verloren, doppelt, falsche Reihenfolge
- TCP löst das:
  - Verbindung aufbauen
  - Jedes Byte nummeriert
  - Fehlendes → nachfordern
- Handshake: Sequenznummern synchronisieren
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Der 3-Way-Handshake

```
Client (dein Laptop)                      Server
    |                                        |
    |-------- SYN (Seq=1000) --------------->|
    |         "Ich will reden"               |
    |                                        |
    |<--- SYN-ACK (Seq=5000, Ack=1001) ------|
    |     "OK, ich auch. Ich starte bei 5000"|
    |                                        |
    |-------- ACK (Ack=5001) --------------->|
    |         "Verstanden, los geht's"       |
    |                                        |
    |        [ Verbindung steht ]            |
```

**SYN** = Synchronize · **ACK** = Acknowledge

<!--
SPEAKER NOTES:
- 3 Pakete → Verbindung steht
- 1. Client SYN: "Will Verbindung, starte bei 1000"
- 2. Server SYN-ACK: "OK, ich starte bei 5000, erwarte 1001"
- 3. Client ACK: "Verstanden, erwarte 5001"
- Seq-Nr wichtig: Beide wissen nächstes erwartetes Byte
-->

---

# Nach dem Handshake

**Status:** Die TCP-Verbindung steht.

```
Client:    141.62.xxx.xxx:52431
                         └─── Zufälliger Port für diese Verbindung

Server:    212.132.79.37:443
                        └─── HTTPS-Port
```

**Jetzt erst** kann HTTP gesprochen werden.

<!--
SPEAKER NOTES:
- Verbindung steht
- Client: zufälliger Port vom OS (hier 52431) = Rückkanal
- Server: Port 443 = HTTPS-Standard
- JETZT können Daten fließen
-->

---

<!-- _class: lead -->

# Schritt 3: HTTP-Request
## "Gib mir die Startseite"

<!--
SPEAKER NOTES:
- Jetzt konkret: Browser schickt Request
- Die eigentliche Anfrage nach der Webseite
-->

---

# Was dein Browser sendet

```http
GET / HTTP/1.1
Host: www.hdm-stuttgart.de
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html
Accept-Language: de-DE
Connection: keep-alive
```

~200 Bytes Text.

**GET** = "Gib mir" (im Gegensatz zu POST = "Nimm das")
**/** = "Die Startseite"

<!--
SPEAKER NOTES:
- HTTP-Request: lesbar, menschlich verständlich
- GET = "hol mir was" (POST = "hier Daten für dich")
- "/" = Wurzel = Startseite
- HTTP/1.1 = Protokollversion
- Header: Kontext (Host, Browser, Sprache)
- ~200 Bytes Text → müssen durchs Internet
-->

---

<!-- _class: lead -->

# Encapsulation in Aktion
## Der Request wird verpackt

<!--
SPEAKER NOTES:
- 200 Bytes Request → was passiert damit?
- Schicht für Schicht verpacken
-->

---

# Layer 4: Transport (TCP)

HTTP-Request wird zum **Segment**:

```
┌─────────────────────────────────────────────────┐
│ TCP-Header                                      │
│ ┌─────────────┬─────────────┬─────────────────┐ │
│ │ Source Port │ Dest Port   │ Sequence Number │ │
│ │ 52431       │ 443         │ 1001            │ │
│ └─────────────┴─────────────┴─────────────────┘ │
├─────────────────────────────────────────────────┤
│ Payload: "GET / HTTP/1.1..."                    │
└─────────────────────────────────────────────────┘
```

**Neu:** Ports + Sequenznummer

<!--
SPEAKER NOTES:
- Erste Verpackung: TCP
- TCP-Header VOR die Daten
  - Source Port (52431 → Antwort-Ziel)
  - Dest Port (443 → HTTPS)
  - Sequenznummer
- Payload (HTTP-Request) unverändert
- = Segment
-->

---

# Layer 3: Network (IP)

Segment wird zum **Paket**:

```
┌─────────────────────────────────────────────────┐
│ IP-Header                                       │
│ ┌─────────────────┬─────────────────┐           │
│ │ Source IP       │ Destination IP  │           │
│ │ 141.62.xxx.xxx  │ 212.132.79.37   │           │
│ └─────────────────┴─────────────────┘           │
├─────────────────────────────────────────────────┤
│ TCP-Segment (unverändert)                       │
└─────────────────────────────────────────────────┘
```

**Neu:** IP-Adressen

<!--
SPEAKER NOTES:
- Nächste Schicht: IP
- IP-Header VOR das TCP-Segment
  - Source IP (Laptop)
  - Dest IP (Server)
- TCP-Segment = jetzt Payload des IP-Pakets
- = Paket
-->

---

# Layer 2: Data Link (Ethernet)

Paket wird zum **Frame**:

```
┌─────────────────────────────────────────────────┐
│ Ethernet-Header                                 │
│ ┌─────────────────┬─────────────────┐           │
│ │ Source MAC      │ Destination MAC │           │
│ │ aa:bb:cc:dd:ee  │ 11:22:33:44:55  │           │
│ └─────────────────┴─────────────────┘           │
├─────────────────────────────────────────────────┤
│ IP-Paket (unverändert)                          │
├─────────────────────────────────────────────────┤
│ FCS (Frame Check Sequence / Prüfsumme)          │
└─────────────────────────────────────────────────┘
```

**Wichtig:** Destination MAC = **Router**, nicht Server!

<!--
SPEAKER NOTES:
- Letzte Verpackung: Ethernet
- Header vorne, Prüfsumme hinten
- WICHTIG: MACs hier!
  - Source = Laptop
  - Dest = ROUTER, nicht Server!
- Warum? Laptop kann Server nicht direkt erreichen
  - Erst zum Router → der entscheidet weiter
-->

---

# Woher kennt dein Laptop die Router-MAC?

**ARP** – Address Resolution Protocol

```
Laptop (Broadcast):
    "Wer hat die IP 192.168.1.1? Sag mir deine MAC!"

Router:
    "Das bin ich! Meine MAC ist 11:22:33:44:55:66"
```

Das passiert automatisch. Die Info wird gecached.

<!--
SPEAKER NOTES:
- Woher MAC des Routers?
- ARP = Address Resolution Protocol
- Broadcast: "Wer hat IP X? Sag MAC!"
- Router antwortet → Laptop merkt sich
- Automatisch im Hintergrund
-->

---

# Layer 1: Physical

Frame wird zu **Bits** – Bits werden zu Signalen:

| Medium | Signal |
|--------|--------|
| Kupferkabel | Spannung: High/Low |
| Glasfaser | Licht: An/Aus |
| WLAN | Funkwellen |

```
01001000 01010100 01010100 01010000 ...
```

Ab hier übernimmt die Physik.

<!--
SPEAKER NOTES:
- Ganz unten: Physik
- Frame → Bits → Signale
- Je nach Medium:
  - Kupfer: Spannung High/Low
  - Glasfaser: Licht an/aus
  - WLAN: modulierte Funkwellen
- Laptop sendet → Router empfängt
-->

---

<!-- _class: lead -->

# Die Reise durch das Netz
## Hop für Hop

<!--
SPEAKER NOTES:
- Paket unterwegs
- Was passiert bei jedem Router?
-->

---

# Der erste Hop: Dein Router

```
Laptop → [Frame] → Router
```

Der Router empfängt:

1. **Layer 1:** Signale → Bits
2. **Layer 2:** Frame prüfen. MAC okay? → Auspacken
3. **Layer 3:** IP lesen. "212.132.79.37 – nicht mein Netz"

**Routing-Entscheidung:** "Ich schicke es Richtung Internet."

<!--
SPEAKER NOTES:
- Router empfängt Frame
- Physik: Signale → Bits
- Ethernet: MAC okay? Prüfsumme okay? → auspacken
- IP: Ziel-IP lesen → 212.132.79.37 → nicht mein Netz
- Routing-Tabelle: In welche Richtung?
-->

---

# Der Router verpackt NEU

```
┌─────────────────────────────────────────────────┐
│ Ethernet-Header (NEU!)                          │
│ ┌─────────────────┬─────────────────┐           │
│ │ Source MAC      │ Destination MAC │           │
│ │ Router-MAC      │ Nächster-Router │           │
│ └─────────────────┴─────────────────┘           │
├─────────────────────────────────────────────────┤
│ IP-Paket (UNVERÄNDERT)                          │
│ Source: 141.62.xxx.xxx                          │
│ Dest: 212.132.79.37                             │
└─────────────────────────────────────────────────┘
```

**IP bleibt gleich. MAC ändert sich.**

<!--
SPEAKER NOTES:
- Router: neuer Frame, neue MACs
  - Source: jetzt Router
  - Dest: nächster Router
- ABER: IP-Paket unverändert!
  - IP-Adressen bleiben gleich
- Kern: Router packt nur äußerste Schicht aus/ein
  - Innere Schichten unberührt
-->

---

# Mehrere Hops

```
Dein Laptop
    ↓ [Frame an Router 1]
Router HdM-Netz
    ↓ [Frame an Router 2]
Router BelWü
    ↓ [Frame an Router 3]
...
    ↓ [Frame an Server]
Webserver der HdM
```

Bei jedem Hop: Auspacken bis Layer 3, Routing, neu verpacken.

<!--
SPEAKER NOTES:
- Wiederholt sich bei jedem Hop
- Typisch: 10-20 Hops bis Ziel
- Jeder Router: auspacken → routing → einpacken → weiter
- IP immer gleich
- MAC ändert bei jedem Sprung
-->

---

<!-- _class: lead -->

# Die Ankunft
## Der Server empfängt und antwortet

<!--
SPEAKER NOTES:
- Paket angekommen
- Jetzt alles rückwärts: Decapsulation
-->

---

# Decapsulation am Server

```
Bits empfangen (Layer 1)
    ↓
Frame prüfen: MAC okay? FCS okay? → Auspacken (Layer 2)
    ↓
IP lesen: Ziel-IP = meine IP? Ja! → Auspacken (Layer 3)
    ↓
TCP lesen: Port 443, Seq-Nr passt → Auspacken (Layer 4)
    ↓
HTTP lesen: "GET / HTTP/1.1" (Layer 7)
```

Der Webserver versteht: "Jemand will die Startseite."

<!--
SPEAKER NOTES:
- Schicht für Schicht auspacken:
  - Physik → Bits
  - Ethernet → Frame prüfen → auspacken
  - IP → Ziel-IP = meine? Ja → auspacken
  - TCP → Port 443 = Webserver-Prozess → auspacken
  - HTTP → "GET /" = Startseite
- Server bearbeitet, erstellt Antwort
-->

---

# Der Server antwortet

```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 45231

```

~45 KB HTML müssen jetzt zu dir.

<!--
SPEAKER NOTES:
- Antwort: 200 OK = alles gut
- Content-Type: HTML
- Content-Length: 45231 Bytes
- Dann: eigentlicher HTML-Code
-->

---

# Encapsulation beim Server

Der Server macht **dasselbe** – nur in die andere Richtung:

```
HTTP-Response: "HTTP/1.1 200 OK..."
    ↓
TCP: Dest-Port: 52431 (dein Browser!)
    ↓
IP: Dest-IP: 141.62.xxx.xxx (dein Laptop!)
    ↓
Ethernet: Dest-MAC: Router des Server-Netzes
    ↓
Bits
```

<!--
SPEAKER NOTES:
- Gleiches Spiel, andere Richtung
- TCP: Ziel-Port 52431 (Browser!)
- IP: Ziel-IP = Laptop
- Ethernet: Dest-MAC = nächster Router
- Ab geht's – ganzer Weg zurück
-->

---

# Die Antwort reist zurück

```
Server
    ↓
Router → Router → Router → ...
    ↓
Router HdM
    ↓
Dein Laptop
```

Gleiches Spiel: Hop für Hop, IP bleibt gleich, MAC ändert sich.

<!--
SPEAKER NOTES:
- Rückweg: gleiche Mechanik, andere Richtung
- Jeder Router: auspacken → routing → einpacken
- Bis Paket bei euch ankommt
-->

---

# Decapsulation bei dir

```
Bits empfangen
    ↓
Frame: MAC = meine MAC? → Auspacken
    ↓
IP: Ziel-IP = meine IP? → Auspacken
    ↓
TCP: Port 52431 = mein Browser → Auspacken
    ↓
HTTP: "HTTP/1.1 200 OK..."
    ↓
Browser rendert die Seite
```

<!--
SPEAKER NOTES:
- Laptop empfängt, auspackt: Frame → IP → TCP
- TCP: Port 52431 = Browser-Prozess
- Browser bekommt HTTP-Response
- Beginnt mit Rendern
- 200ms vorbei → Webseite sichtbar
-->

---

<!-- _class: lead -->

# Exkurse
## TCP vs. UDP, MTU, HTTP-Methoden

<!--
SPEAKER NOTES:
- Ergänzende Themen für Gesamtverständnis
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# TCP vs. UDP

| | TCP | UDP |
|---|-----|-----|
| **Verbindung** | Ja (Handshake) | Nein |
| **Reihenfolge** | Garantiert | Nicht garantiert |
| **Verlorene Pakete** | Werden nachgefordert | Gehen verloren |
| **Overhead** | Höher | Niedriger |
| **Use Cases** | Web, Email, Downloads | Video-Calls, Gaming, DNS |

<!--
SPEAKER NOTES:
- Zwei Transport-Protokolle
- TCP: zuverlässig
  - Handshake, Seq-Nr, Bestätigungen, Neuübertragung
  - Perfekt für Web, Downloads (nichts darf fehlen)
- UDP: schneller
  - Kein Handshake, keine Bestätigungen
  - Verloren = weg
  - Perfekt für Video-Calls (Verzögerung schlimmer als Verlust)
-->

---

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

Bei **Echtzeit** ist Verzögerung schlimmer als Verlust.

<!--
SPEAKER NOTES:
- Video-Call, Paket verloren:
  - TCP: warten → neu anfordern → warten → Bild friert
  - UDP: ignorieren → nächstes Frame → kurzer Glitch
- Echtzeit: UDP besser
-->

---

# MTU & Fragmentierung

**MTU** = Maximum Transmission Unit

Ethernet-Frame kann maximal **1500 Bytes** Nutzdaten transportieren.

**Problem:** Ein Foto hat 3.000.000 Bytes.

**Lösung:** TCP zerschneidet die Daten in ~2000 Segmente.
Jedes Segment hat eine Sequenznummer.
Der Empfänger setzt sie zusammen.

<!--
SPEAKER NOTES:
- MTU = physikalisches Limit
- Ethernet-Frame: max 1500 Bytes Nutzdaten
- Webseite 100KB, Video Gigabytes?
- TCP zerschneidet in passende Stücke
  - Jedes mit Sequenznummer
  - Empfänger setzt zusammen (auch bei falscher Reihenfolge)
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# HTTP-Methoden

| Methode | Bedeutung | Beispiel |
|---------|-----------|----------|
| **GET** | Daten abrufen | Seite laden |
| **POST** | Daten senden | Formular absenden |
| **PUT** | Daten ersetzen | Profil aktualisieren |
| **DELETE** | Daten löschen | Account löschen |

```http
GET /index.html HTTP/1.1
POST /login HTTP/1.1
```

<!--
SPEAKER NOTES:

Zum Schluss noch HTTP-Methoden.

GET ist das häufigste – "gib mir was". Wenn ihr eine URL aufruft, ist das ein GET.

POST schickt Daten zum Server – wenn ihr ein Formular abschickt.

PUT und DELETE sind für APIs – ersetzen oder löschen von Ressourcen.

Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# HTTP Status-Codes

```http
HTTP/1.1 200 OK
HTTP/1.1 404 Not Found
HTTP/1.1 500 Internal Server Error
```

| Code-Bereich | Bedeutung |
|--------------|-----------|
| **2xx** | Erfolg (200 OK, 201 Created) |
| **3xx** | Umleitung (301 Moved, 304 Not Modified) |
| **4xx** | Client-Fehler (400 Bad Request, 404 Not Found) |
| **5xx** | Server-Fehler (500 Internal Error, 503 Unavailable) |

<!--
SPEAKER NOTES:

Status-Codes sagen euch, was passiert ist.

2xx heißt: Alles gut. 200 OK ist der Normalfall.

3xx heißt: Umleitung. Die Seite ist woanders.

4xx heißt: Ihr habt was falsch gemacht. 404 kennt ihr – Seite nicht gefunden. 403 heißt: Zugriff verweigert.

5xx heißt: Der Server hat ein Problem. 500 ist ein generischer Fehler, 503 heißt: Server überlastet.
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Zusammenfassung Teil 1

**Der Ablauf:**
1. DNS (UDP:53) → Name zu IP
2. TCP-Handshake (SYN → SYN-ACK → ACK)
3. HTTP-Request (GET /...)
4. HTTP-Response (200 OK + HTML)

**Die Konzepte:**
- 4 Schichten: Anwendung → Transport → Internet → Netzzugang
- IP bleibt gleich, MAC ändert sich pro Hop
- Ports identifizieren Programme
- Encapsulation: Jede Schicht verpackt die darüberliegende

<!--
SPEAKER NOTES:

Das ist die Zusammenfassung für Teil 1. Das solltet ihr können:

Den Ablauf: DNS, TCP-Handshake, HTTP-Request, HTTP-Response.

Die Schichten und ihre Protokolle.

Den Unterschied zwischen IP und MAC – was bleibt gleich, was ändert sich.

Was Ports tun.

Wie Encapsulation funktioniert.
-->

---

# Werkzeuge zum Selbst-Erkunden

**Im Browser (F12 → Network-Tab):**
- Jeder Request sichtbar
- Timing, Headers, Response

**Im Terminal:**
```bash
ping hdm-stuttgart.de          # Latenz messen
traceroute hdm-stuttgart.de    # Route anzeigen (Mac/Linux)
tracert hdm-stuttgart.de       # Route anzeigen (Windows)
nslookup hdm-stuttgart.de      # DNS abfragen
curl -I hdm-stuttgart.de       # HTTP-Header abrufen
```

<!--
SPEAKER NOTES:

Probiert das aus!

Im Browser: F12, dann Network-Tab. Ladet eine Seite und schaut, welche Requests passieren. Klickt auf einen Request und schaut euch die Header an.

Im Terminal: ping zeigt euch die Latenz. traceroute zeigt jeden Hop auf dem Weg. nslookup macht eine DNS-Abfrage. curl holt HTTP-Header.

Das sind die Werkzeuge, mit denen Profis Netzwerk-Probleme debuggen.
-->

---

<!-- _class: lead -->

# Teil 2: CSS
## Webseiten gestalten

<!--
SPEAKER NOTES:

Teil 2: CSS. Cascading Style Sheets.

HTML definiert die Struktur – was ist auf der Seite. CSS definiert das Aussehen – wie sieht es aus.
-->

---

# Was ist CSS?

**C**ascading **S**tyle **S**heets

```css
p {
    color: blue;
    font-size: 16px;
}
```

- Trennt **Inhalt** (HTML) von **Darstellung** (CSS)
- "Cascading" = Regeln können überschrieben werden
- Eine CSS-Datei kann viele HTML-Seiten stylen

<!--
SPEAKER NOTES:

CSS steht für Cascading Style Sheets.

Die Trennung von Inhalt und Darstellung ist ein fundamentales Prinzip. HTML sagt "das ist ein Absatz". CSS sagt "Absätze sind blau und 16 Pixel groß".

Vorteil: Ihr könnt das Design der ganzen Website ändern, indem ihr eine Datei ändert.

"Cascading" bedeutet: Regeln fließen nach unten. Eine spezifischere Regel überschreibt eine allgemeine.
-->

---

# CSS einbinden

**Option 1: Externe Datei** ✓
```html
<link rel="stylesheet" href="style.css">
```

**Option 2: Style-Tag**
```html
<style>p { color: blue; }</style>
```

**Option 3: Inline** ✗
```html
<p style="color: blue;">...</p>
```

<!--
SPEAKER NOTES:

Drei Wege, CSS einzubinden.

Externe Datei ist der Standard. Eine CSS-Datei für die ganze Website. Sauber getrennt, gut cachebar.

Style-Tag im HTML-Head: Funktioniert, aber mischt HTML und CSS. Manchmal nützlich für kritisches CSS.

Inline-Styles: Vermeiden. Schwer zu warten, keine Wiederverwendung.
-->

---

# CSS-Anatomie

```css
selector {
    property: value;
}
```

**Beispiel:**
```css
h1 {
    color: #333333;
    font-size: 2rem;
    margin-bottom: 1rem;
}
```

Selektor → was wird gestylt
Property → welche Eigenschaft
Value → welcher Wert

<!--
SPEAKER NOTES:

Die Grundstruktur von CSS.

Selektor sagt: "Diese Elemente". Hier: alle h1-Überschriften.

In den geschweiften Klammern: Property-Value-Paare. color: dunkelgrau. font-size: 2rem. margin-bottom: 1rem.

Semikolon nach jedem Paar. Doppelpunkt zwischen Property und Value.
-->

---

# Selektoren: Element

```css
/* Alle <p>-Elemente */
p {
    color: gray;
}

/* Mehrere Elemente gleichzeitig */
h1, h2, h3 {
    font-family: sans-serif;
}
```

Element-Selektoren sind die einfachsten.

<!--
SPEAKER NOTES:

Element-Selektoren wählen alle Elemente eines Typs.

"p" trifft alle Absätze. "h1, h2, h3" trifft alle Überschriften erster bis dritter Ordnung.

Komma bedeutet "oder" – h1 oder h2 oder h3.
-->

---

# Selektoren: Klasse

```html
<p class="wichtig">Dieser Text ist wichtig.</p>
<p>Dieser nicht.</p>
```

```css
.wichtig {
    color: red;
    font-weight: bold;
}
```

**Punkt** vor dem Namen = Klasse

<!--
SPEAKER NOTES:

Klassen-Selektoren sind flexibler. Ihr definiert eine Klasse im CSS, und weist sie Elementen im HTML zu.

Punkt vor dem Namen: .wichtig

Eine Klasse kann auf beliebig viele Elemente angewendet werden. Ein Element kann mehrere Klassen haben: class="wichtig highlight"
-->

---

# Selektoren: ID

```html
<nav id="hauptnavigation">...</nav>
```

```css
#hauptnavigation {
    background: #333;
    padding: 1rem;
}
```

**Raute** vor dem Namen = ID

⚠️ IDs sollten **einmalig** pro Seite sein.

<!--
SPEAKER NOTES:

ID-Selektoren sind noch spezifischer. Raute vor dem Namen.

IDs sollten auf einer Seite nur einmal vorkommen. Für Navigation, Header, Footer, Main – einmalige Elemente.

In der Praxis: Klassen sind meist besser. IDs haben hohe Spezifität und sind unflexibel.
-->

---

# Selektoren: Kombinationen

```css
/* Nachfahre (beliebig tief verschachtelt) */
article p { line-height: 1.6; }

/* Direktes Kind (nur eine Ebene) */
nav > a { text-decoration: none; }

/* Nächstes Geschwister */
h2 + p { font-size: 1.2rem; }

/* Element mit Klasse */
p.wichtig { color: red; }
```

<!--
SPEAKER NOTES:

Kombinationen erlauben präzisere Auswahl.

Leerzeichen: Nachfahre. "article p" heißt: alle p-Elemente irgendwo innerhalb eines article.

Größer-als: Direktes Kind. "nav > a" heißt: nur Links, die direkt in nav liegen, nicht tiefer verschachtelt.

Plus: Nächstes Geschwister. "h2 + p" heißt: der Absatz direkt nach einer h2.

Element.Klasse: Das Element muss beides sein. "p.wichtig" heißt: nur p-Elemente mit Klasse wichtig.
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Spezifität: Welche Regel gewinnt?

| Selektor | Spezifität |
|----------|------------|
| Element (`p`) | 0,0,0,1 |
| Klasse (`.wichtig`) | 0,0,1,0 |
| ID (`#header`) | 0,1,0,0 |
| Inline (`style="..."`) | 1,0,0,0 |

```css
p { color: blue; }           /* 0,0,0,1 */
.text { color: green; }      /* 0,0,1,0 → gewinnt */
#intro { color: red; }       /* 0,1,0,0 → gewinnt über beide */
```

<!--
SPEAKER NOTES:

Wenn mehrere Regeln auf ein Element zutreffen, gewinnt die spezifischere.

Spezifität wird in vier Zahlen gemessen. Von links nach rechts: Inline, IDs, Klassen, Elemente.

Ein Element-Selektor hat 0,0,0,1. Eine Klasse hat 0,0,1,0. Eine ID hat 0,1,0,0.

0,0,1,0 schlägt 0,0,0,99 – auch hundert Element-Selektoren schlagen keine Klasse.

Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
-->

---

# Box-Modell

```
┌─────────────────────────────────────┐
│              margin                 │
│   ┌─────────────────────────────┐   │
│   │          border             │   │
│   │   ┌─────────────────────┐   │   │
│   │   │       padding       │   │   │
│   │   │   ┌─────────────┐   │   │   │
│   │   │   │   content   │   │   │   │
│   │   │   └─────────────┘   │   │   │
│   │   └─────────────────────┘   │   │
│   └─────────────────────────────┘   │
└─────────────────────────────────────┘
```

Jedes Element ist eine Box.

<!--
SPEAKER NOTES:

Das Box-Modell ist fundamental.

Jedes Element ist eine Box. Von innen nach außen:

Content: Der eigentliche Inhalt. Text, Bild, was auch immer.

Padding: Innenabstand. Zwischen Content und Border.

Border: Der Rahmen.

Margin: Außenabstand. Zwischen diesem Element und anderen.
-->

---

# Box-Modell: CSS

```css
.box {
    width: 200px;
    height: 100px;
    padding: 20px;
    border: 2px solid black;
    margin: 10px;
}
```

**Wichtig:**
```css
box-sizing: border-box;
```
→ width/height inkludiert padding + border

<!--
SPEAKER NOTES:

So setzt ihr die Box-Eigenschaften.

Standardmäßig ist width nur der Content. Padding und Border kommen oben drauf. Das ist verwirrend.

box-sizing: border-box ändert das. Dann ist width die Gesamtbreite inklusive Padding und Border. Viel intuitiver.

Best Practice: Setzt das global für alle Elemente.
-->

---

# Farben

```css
/* Keyword */
color: red;
color: rebeccapurple;

/* Hex */
color: #FF0000;
color: #F00;

/* RGB / RGBA */
color: rgb(255, 0, 0);
color: rgba(255, 0, 0, 0.5);

/* HSL */
color: hsl(0, 100%, 50%);
```

<!--
SPEAKER NOTES:

Farben können auf verschiedene Arten angegeben werden.

Keywords: red, blue, rebeccapurple. Begrenzte Auswahl, aber lesbar.

Hex: Sechs Zeichen, je zwei für Rot, Grün, Blau. #FF0000 ist reines Rot.

RGB: Gleiche Idee, aber dezimal. rgb(255, 0, 0).

RGBA: Mit Alpha-Kanal für Transparenz. 0 ist unsichtbar, 1 ist voll sichtbar.

HSL: Hue, Saturation, Lightness. Manchmal intuitiver für Farbanpassungen.
-->

---

# Einheiten

| Einheit | Bedeutung |
|---------|-----------|
| `px` | Pixel (absolut) |
| `%` | Prozent vom Elternelement |
| `em` | Relativ zur Schriftgröße des Elements |
| `rem` | Relativ zur Schriftgröße des Root-Elements |
| `vw` / `vh` | Prozent der Viewport-Breite/-Höhe |

**Empfehlung:**
`rem` für Schrift, `%` oder `vw/vh` für Layout

<!--
SPEAKER NOTES:

Einheiten – wichtig für responsive Design.

px ist absolut. 16px ist 16px, egal was.

% ist relativ zum Elternelement. width: 50% heißt: halb so breit wie der Container.

em ist relativ zur Schriftgröße des aktuellen Elements. Kompliziert bei Verschachtelung.

rem ist relativ zur Root-Schriftgröße (meist 16px). Einfacher zu handhaben.

vw und vh sind Prozent des Viewports. 100vw ist die volle Bildschirmbreite.
-->

---

# Pseudo-Klassen

```css
/* Hover – Maus drüber */
a:hover { color: red; }

/* Besuchter Link */
a:visited { color: purple; }

/* Fokussiertes Element */
input:focus { border-color: blue; }

/* Erstes/n-tes Kind */
li:first-child { font-weight: bold; }
li:nth-child(odd) { background: #eee; }
```

`:` vor dem Namen = Pseudo-Klasse

<!--
SPEAKER NOTES:

Pseudo-Klassen wählen Elemente in bestimmten Zuständen.

:hover ist der häufigste – wenn die Maus drüber ist.

:focus ist wichtig für Accessibility – wenn ein Element den Tastatur-Fokus hat.

:first-child, :nth-child und ähnliche wählen basierend auf Position.

Wichtig für interaktive Elemente und Zebra-Streifen in Tabellen.
-->

---

# Pseudo-Elemente

```css
/* Vor dem Inhalt einfügen */
.required::before {
    content: "* ";
    color: red;
}

/* Erster Buchstabe */
p::first-letter {
    font-size: 2em;
}
```

`::` = Pseudo-Element (erzeugt "virtuelles" Element)
`:` = Pseudo-Klasse (wählt existierendes Element im Zustand)

<!--
SPEAKER NOTES:

Pseudo-Elemente erzeugen virtuelle Elemente, die nicht im HTML stehen.

::before und ::after fügen Inhalt vor oder nach dem Element ein. Oft für Icons oder Dekorationen.

::first-letter und ::first-line für typografische Effekte.

Doppelpunkt zur Unterscheidung von Pseudo-Klassen – aber einfacher Doppelpunkt funktioniert auch aus Kompatibilitätsgründen.
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Responsive Design

```css
/* Mobile First: Basis-Styles */
.container {
    padding: 1rem;
    background: white;
}

/* Ab 768px (Tablet): Anpassungen */
@media (min-width: 768px) {
    .container {
        padding: 2rem;
        background: red;
    }
}

/* Ab 1024px (Desktop): Weitere Anpassungen */
@media (min-width: 1024px) {
    .container {
        background: green;
    }
}
```

<!--
SPEAKER NOTES:

Responsive Design: Die Seite passt sich der Bildschirmgröße an.

Mobile First: Ihr schreibt zuerst die Styles für kleine Screens. Dann fügt ihr mit @media-Queries Anpassungen für größere Screens hinzu.

min-width heißt: "ab dieser Breite". Also: Basis gilt für alle. Ab 768px gelten zusätzliche Regeln. Ab 1024px noch mehr.

Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute Standard.
-->

---

# Zusammenfassung CSS

**Selektoren:**
- Element: `p`
- Klasse: `.wichtig`
- ID: `#header`
- Kombinationen: `nav > a`, `h2 + p`

**Box-Modell:** content → padding → border → margin

**Spezifität:** Inline > ID > Klasse > Element

**Einheiten:** rem für Text, %, vw/vh für Layout

<!--
SPEAKER NOTES:

Zusammenfassung CSS.

Selektoren: Element, Klasse, ID, Kombinationen. Klassen sind am flexibelsten.

Box-Modell: Alles ist eine Box. Von innen nach außen: content, padding, border, margin.

Spezifität: Die spezifischere Regel gewinnt.

Einheiten: rem für Schrift, relative Einheiten für Layout.
-->

---

<!-- _class: lead -->

# Fragen & Diskussion

**Nächster Termin:** 24.01.2026 – JavaScript

**Kontakt:** lb-czechowski@hdm-stuttgart.de

<!--
SPEAKER NOTES:

Das war's für heute.

Nächstes Mal: JavaScript. Da wird's interaktiv.

Fragen jetzt oder per Email.

Übt das – vor allem CSS könnt ihr sofort ausprobieren. Codepen auf, loslegen.
-->

---

# Lizenz

Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**

Basiert auf Material von:
- Markus Thamm / Wolfgang Gruel (HdM Stuttgart)
- Michael Czechowski

Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/