---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Grundlagen IT- und Internettechnik (223015c)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
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;
}
section.erklaerung {
  font-size: 1.1rem;
}
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;
}
section.dimmed {
  opacity: 0.2;
}
</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

**Sommersemester 2026**

[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 klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# Glossar: Die Landkarte

Das Web folgt dem **Client-Server-Modell**: Ein Client (Browser) sendet einen **Request**, ein Server liefert eine **Response** – nach den Regeln eines **Protokolls**.

| Begriff       | Was ist das?                                                             |
|---------------|--------------------------------------------------------------------------|
| **Host**      | Ein netzwerkfähiger Rechner (Laptop, Smartphone, Display in S-Bahn etc.) |
| **Client**    | Host bzw. Anwendung mit einer Anfrage (bspw. Browser)                    |
| **Server**    | Host bzw. Anwendung mit der Antwort (bspw. Webserver)                    |
| **Request**   | Die Anfrage des Clients                                                  |
| **Response**  | Die Antwort des Servers                                                  |
| **Protokoll** | Regeln für Kommunikation (z. B. TCP, HTTP)                               |

---

<!-- _class: glossar -->

# Glossar: Adressen & Identitäten

Jedes Gerät im Netz braucht Adressen: eine **IP** für das globale Routing, eine **MAC** für das lokale Netz und einen **Port** für das richtige Programm.

| 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

Daten werden Schicht für Schicht verpackt — jede Schicht fügt einen eigenen **Header** hinzu und erzeugt so eine neue Dateneinheit.

| Begriff     | Was ist das?                                          | Schicht                  |
|-------------|-------------------------------------------------------|--------------------------|
| **Payload** | Die eigentlichen Nutzdaten (bspw. Request, Response)  | Anwendung                |
| **Header**  | Metadaten vor und nach dem Payload                    | Jedes Layer              |
| **Segment** | Payload + TCP-Header (Anwendungsport)                 | Transport (Layer 4)      |
| **Paket**   | Payload + IP-Header (WLAN-Router)                     | Internet (Layer 3)       |
| **Frame**   | Payload + MAC-Header (Netzwerkkarte)                  | Netzzugang (Layer 2)     |
| **Bit**     | Abfolge von Signalen (Licht, Strom, Kabel, Mobilfunk) | Bitübertragung (Layer 1) |


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

---

<!-- _class: glossar -->

# Glossar: Netzwerk-Eigenschaften

**Latenz** und **Bandbreite** bestimmen, wie schnell Daten ankommen — Latenz misst die Verzögerung, Bandbreite die Kapazität.

| Begriff        | Was ist das?                                    | Einheit            |
|----------------|-------------------------------------------------|--------------------|
| **Latenz**     | Verzögerung (hin + zurück)                      | Millisekunden (ms) |
| **Bandbreite** | Datenmenge pro Zeiteinheit                      | Mbit/s             |
| **Hop**        | Ein Sprung zum nächsten Router (im Internet)    | –                  |
| **Round-Trip** | Hin- und Rückweg                                | –                  |
| **Ping**       | Client sendet "ping", bekommt von Server "pong" | 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

Protokolle regeln die Kommunikation auf jeder Schicht — von der Anwendung (HTTP) über den Transport (TCP/UDP) bis zum Routing (IP).

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

<i><small>HTTP(S) = Hypertext Transfer Protocol (Secure)</small> · <small>DNS = Domain Name System</small> · <small>TCP = Transmission Control Protocol</small> · <small>UDP = User Datagram Protocol</small> · <small>IP = Internet Protocol</small>
</i>

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

![bg right:40% fit](./assets/demos/network-chain.png)

Zwischen Klick und fertiger Webseite liegen viele Stationen.

Jede Schicht spricht eine andere Sprache:

- Browser → **HTTP**
- Netzwerkkarte → **Bits und Signale**
- Router → **IP-Pakete**
- Provider → **Routing**

Diese Sprachen müssen zusammenspielen.

<!--
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, teilen sich mehrere Schichten die Aufgaben.

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

---

# Das TCP/IP-Modell

| Schicht | Name | Aufgabe                                  | Protokolle        |
|---------|------|------------------------------------------|-------------------|
| **4** | Anwendung | Dienste steuern, Daten austauschen etc.  | HTTP, DNS, SMTP   |
| **3** | Transport | Zuverlässige Verbindung aufbauen (Ports) | TCP, UDP          |
| **2** | Internet | Routing, global eindeutige Adressen      | IP                |
| **1** | Netzzugang | Lokale Übertragung                       | Ethernet, WLAN    |

Jede Schicht hat genau eine Aufgabe und nutzt nur die Schicht direkt darunter.

<!--
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)
-->

---

<!-- _class: "erklaerung dimmed" -->
<!-- _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

![bg right:52% fit](./assets/demos/encap-layers.png)

**Encapsulation:** Jede Schicht verpackt die Daten der darüberliegenden Schicht.

**Decapsulation:** Beim Empfang packt jede Schicht ihren Teil wieder aus.

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

---

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

Beim Senden wandern Daten von oben nach unten — jede Schicht verpackt die darüberliegende Einheit mit einem eigenen Header.

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

---

<!-- _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.

---

# Vorteile der Schichtung

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

**Mit Schichten:**
Der Browser fordert nur die Seite an. Alles Weitere übernehmen die Schichten darunter.

**Austauschbarkeit:**
Wechselt WLAN zu Ethernet, ändert sich nur Schicht 1.
Löst HTTP/2 die Version HTTP/1 ab, ändert sich nur Schicht 4.

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

---

# OSI vs. TCP/IP

![bg right:48% fit](./assets/demos/osi-tcpip-diagram.png)

OSI (7 Schichten) ist ein theoretisches Referenzmodell — TCP/IP (4 Schichten) beschreibt das reale Internet.

<!--
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 im Zusammenspiel

<!--
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 Ziel-IP und leiten das Paket in die passende Richtung weiter.

<!--
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"**

Sie 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

![bg right:35% fit](./assets/demos/port-highlight.png)

Ein Port identifiziert ein **Programm** auf einem Rechner — wie eine **Wohnungstür im Mehrfamilienhaus**.

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

---

# IP vs. MAC vs. Port

Drei Adresstypen arbeiten zusammen — nur die **MAC-Adresse** ändert sich unterwegs, IP und Port bleiben auf dem gesamten Weg gleich.

| | 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: 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
## Was passiert, wenn ihr `www.hdm-stuttgart.de` aufruft?

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

---

# Das Szenario

Ihr seid im WLAN der HdM und ruft auf:

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

Zwischen Enter und fertiger Seite vergehen rund 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
-->

---

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

# Die Zeitlinie

![h:560 center](./assets/demos/timeline.png)

<!--
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
```

Euer Laptop arbeitet die Quellen der Reihe nach ab:

1. **Browser-Cache** prüfen → kein Eintrag
2. **OS-Cache** prüfen → kein Eintrag
3. **Router/Provider:** DNS-Server anfragen

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

![bg right:45% fit](./assets/demos/dns-tree.png)

**Dezentral:** Niemand kennt alles.

Jede Ebene kennt nur die nächste:

- Root → .de, .com, .org
- .de → alle .de-Domains
- hdm-stuttgart.de → www, mail, …

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

---

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

![bg fit](./assets/demos/dns-lookup.png)

<!--
SPEAKER NOTES:
- Titel: Der DNS-Lookup
- 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 gewöhnliches 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).

Der nächste Schritt ist der Verbindungsaufbau.

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

---

# Zweck des Handshakes

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

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

---

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

![bg fit](./assets/demos/tcp-handshake.png)

<!--
SPEAKER NOTES:
- Titel: Der 3-Way-Handshake
- SYN = Synchronize, ACK = Acknowledge
- 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
-->

---

<!-- _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.

![bg right:42% fit](./assets/demos/client-server-ports.png)

Erst jetzt kann HTTP übertragen 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 euer Browser sendet

```http
GET / HTTP/2.0
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
```

Der Request umfasst rund 200 Bytes Text.

**GET** ruft Daten ab (im Gegensatz zu **POST**, das Daten sendet).
**/** bezeichnet die Startseite.

<!--
SPEAKER NOTES:
- HTTP-Request: lesbar, menschlich verständlich
- GET = "hol mir was" (POST = "hier Daten für euch")
- "/" = Wurzel = Startseite
- HTTP/2.0 = 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**:

![w:900 center](./assets/demos/tcp-segment.png)

**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**:

![w:900 center](./assets/demos/ip-packet.png)

**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**:

![w:900 center](./assets/demos/ethernet-frame.png)

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

---


<!-- _class: dimmed -->

# Router-MAC per ARP ermitteln

**ARP** – Address Resolution Protocol

![w:900 center](./assets/demos/arp-lookup.png)

Das geschieht automatisch. Die Information 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 Schicht 1 erfolgt die Übertragung physikalisch.

<!--
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: Euer Router

**Laptop** → [Frame] → **Router**

Der Router verarbeitet das Frame in drei Schritten:

1. **Layer 1:** Signale werden zu Bits.
2. **Layer 2:** Frame und MAC-Adresse werden geprüft, dann ausgepackt.
3. **Layer 3:** Die Ziel-IP liegt außerhalb des lokalen Netzes.

**Routing-Entscheidung:** Das Paket geht Richtung Internet weiter.

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

![w:900 center](./assets/demos/ethernet-rehop.png)

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

![bg right:35% fit](./assets/demos/hop-chain.png)

Bei jedem Hop laufen drei Schritte ab:

1. Auspacken bis Layer 3 (IP)
2. Routing-Entscheidung
3. Neu verpacken mit nächster MAC

IP bleibt gleich · MAC ändert sich jedes Mal.

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

![bg right:42% fit](./assets/demos/server-decap.png)

Jede Schicht prüft, ob das Paket für sie bestimmt ist, und packt dann die nächste aus.

Am Ende erkennt der Webserver die Anfrage nach der 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/2.0 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 45231

<!DOCTYPE html>
<html lang="de">
<head>
    <title>HdM Stuttgart</title>
...
```

Rund 45 KB HTML müssen nun zu euch übertragen werden.

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

---

# Encapsulation beim Server

Der Server durchläuft dieselben Schritte – nur in umgekehrter Richtung:

![bg right:40% fit](./assets/demos/encap-stack.png)

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

![bg right:38% fit](./assets/demos/response-hops.png)

Der Rückweg funktioniert wie der Hinweg:

- Hop für Hop durchs Internet
- **IP bleibt gleich** (Start/Ziel)
- **MAC ändert sich** bei jedem Router

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

---

# Decapsulation bei euch

![bg right:42% fit](./assets/demos/decap-stack.png)

Der Rückweg ist die umgekehrte Encapsulation.

Jede Schicht prüft, ob das Paket für sie bestimmt ist, und packt dann die nächste aus.

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

---

# TCP vs. UDP

TCP und UDP sind beides Transport-Protokolle — TCP garantiert Vollständigkeit, UDP setzt auf Geschwindigkeit.

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

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _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).

---

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

---

<!-- _class: dimmed -->

# MTU & Fragmentierung

**MTU** = Maximum Transmission Unit

Ein 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

HTTP-Methoden beschreiben, **was** der Client mit einer Ressource tun will.

| Methode | Bedeutung | Beispiel                                      |
|---------|-----------|-----------------------------------------------|
| **GET** | Daten abrufen | Seite laden `GET /index.html HTTP/2.0`        |
| **POST** | Daten senden | Formular absenden `POST /login HTTP/2.0`      |
| **PUT** | Daten ersetzen | Profil aktualisieren `PUT /users/42 HTTP/2.0` |
| **DELETE** | Daten löschen | Account löschen `DELETE /users/42 HTTP/2.0`                               |

<small>CRUD = Create, Read, Update, Delete</small>


<!--
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: erklaerung -->
<!-- _header: '' -->
<!-- _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

Jede HTTP-Response enthält einen dreistelligen Status-Code — die erste Ziffer verrät die Kategorie.

```http
HTTP/2.0 200 OK
HTTP/2.0 404 Not Found
HTTP/2.0 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: erklaerung -->
<!-- _header: '' -->
<!-- _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: dimmed -->

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

---

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

# Netzwerk-Grundlagen – Vertiefung

Die vier Kernkonzepte für Web-Entwickelnde:

**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(S)-Anfrage (HTTP/2.0)
- Keep-Alive: Verbindung bleibt offen für mehrere Requests
- HTTP/2: Multiplexing – viele Requests über eine Verbindung

**3. HTTP(S) 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
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.
-->

---

# CSS im Überblick

![bg right:35%](./assets/demos/css-anatomie.png)

**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** (empfohlen)
```html
<link rel="stylesheet" href="style.css">
```

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

**Option 3: Inline** (vermeiden)
```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

![bg right:35%](./assets/demos/css-selector-element.png)

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

![bg right:35%](./assets/demos/css-selector-class.png)

```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"
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# Selektoren: ID

![bg right:35%](./assets/demos/css-selector-id.png)

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

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

**Raute** vor dem Namen = ID

**Achtung:** 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

![bg right:35%](./assets/demos/css-combinators.png)

```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.
-->

---

# Spezifität von Selektoren

![bg right:35%](./assets/demos/css-specificity.png)

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

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _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

![bg right:42% fit](./assets/demos/box-model-diagram.png)

Jedes HTML-Element ist eine rechteckige **Box**.

**Schichten innen → außen:**

- **content** – Inhalt (Text, Bild)
- **padding** – Innenabstand
- **border** – Rahmen
- **margin** – Außenabstand

<small>Gesamt-Breite = `width + padding + border + margin`. Tipp: `box-sizing: border-box` rechnet padding + border mit ein.</small>

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

![bg right:35%](./assets/demos/css-box-model.png)

```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.
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# Farben

![bg right:35%](./assets/demos/css-colors.png)

CSS kennt fünf Notationen für Farben: **Keyword**, **Hex**, **RGB**, **RGBA** (mit Transparenz) und **HSL**.

```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%);
```

MDN-Referenz: [CSS `<color>`](https://developer.mozilla.org/de/docs/Web/CSS/Reference/Values/color_value)

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

CSS-Einheiten bestimmen, ob Größen **absolut** (px) oder **relativ** zum Kontext (rem, %, vw) berechnet werden.

| 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

![bg right:35%](./assets/demos/css-pseudo-classes.png)

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

![bg right:35%](./assets/demos/css-pseudo-elements.png)

```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.
-->

---


# Responsive Design

![bg right:35%](./assets/demos/css-responsive.png)

```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.
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _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`

**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ächstes Thema:** 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/