---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Grundlagen IT- und Internettechnik (223015c)"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
title: "Termin 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;
}
</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 -->

# Termin 2 – 10.01.2026
## Netzwerke, Protokolle & CSS

---

# Agenda

**Teil 1: Die Reise eines Klicks**
- Warum ist Netzwerk-Kommunikation kompliziert?
- Was passiert, wenn du eine URL aufrufst?
- DNS → TCP → HTTP → Response

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

---

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

---

<!-- _class: lead -->

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

---

# Das Szenario

Du bist im WLAN der HdM angemeldest und gehst auf:

```
hdm-stuttgart.de
```

**Zwischen Enter und der fertigen Seite:** ~200 Millisekunden.

In dieser Zeit passieren hunderte Operationen.

Bevor wir sie durchgehen: **Warum ist das überhaupt so kompliziert?**

---

<!-- _class: lead -->

# Das Grundproblem
## Warum brauchen wir Schichten, Adressen, Ports?

---

# Was zwischen dir und dem Server liegt

Du willst eine Webseite. Klingt einfach.

Aber dazwischen liegen:
- Deine WLAN-Karte
- Der Router im Flur
- Das Netzwerk der HdM
- Das Internet (dutzende Router)
- Der Webserver in Vaihingen

**Jede Station spricht eine andere "Sprache":**
- Dein Browser spricht HTTP ("Gib mir /index.html")
- Das Kabel versteht nur Strom an/aus

---

# Die Lösung: Aufgabenteilung

Statt dass jedes Programm alles können muss, teilen wir die Arbeit auf:

| Wer | Kümmert sich um |
|-----|-----------------|
| **HTTP** | "Was will ich?" (Webseite, Bild, Video) |
| **TCP** | "Kommt alles an? In der richtigen Reihenfolge?" |
| **IP** | "Wo muss es hin?" (welcher Rechner im Internet) |
| **Ethernet** | "Wie kommt es zum nächsten Gerät?" |
| **Physik** | "Strom oder Licht durch das Kabel" |

Jeder macht seinen Job. Keiner muss wissen, wie die anderen arbeiten.

---

# Warum ist das clever?

**Ohne Schichten:**
Dein Browser müsste wissen, wie man Ethernet-Frames baut, wie WLAN-Frequenzen funktionieren, wie Router Pakete weiterleiten...

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

**Das Prinzip heißt Abstraktion:**
Jede Schicht versteckt ihre Komplexität vor den anderen.

---

<!--

# Schichten reden nur mit Nachbarn

```
HTTP   ──────────→   TCP   ──────────→   IP   ──────────→  Ethernet
       "Schick das"       "Schick das"       "Schick das"
```

**HTTP sagt zu TCP:** "Schick das an den Server."
**TCP sagt zu IP:** "Schick das an 212.132.79.37."
**IP sagt zu Ethernet:** "Schick das an den Router."

**HTTP weiß nicht, dass es Ethernet gibt.**
**Ethernet weiß nicht, dass es HTTP gibt.**

Das ist der Punkt.

---

# Und horizontal?

Auf der anderen Seite (Server) passiert das Gleiche – nur rückwärts:

```
Dein Laptop                              Server

┌─────────┐                           ┌─────────┐
│  HTTP   │ ←── logische Verbindung ──→│  HTTP   │
└────┬────┘                           └────┬────┘
     ↓                                     ↑
┌─────────┐                           ┌─────────┐
│   TCP   │                           │   TCP   │
└────┬────┘                           └────┬────┘
     ↓                                     ↑
┌─────────┐                           ┌─────────┐
│   IP    │                           │   IP    │
└────┬────┘                           └────┬────┘
     ↓                                     ↑
    ⚡ ─────── physische Übertragung ────── ⚡
```

HTTP "redet" mit HTTP. TCP "redet" mit TCP. Aber physisch läuft alles unten durch.

---

-->

<!-- _class: lead -->

# Warum brauchen wir IP-Adressen?

---

# Das Internet ist kein einzelnes Netzwerk

Das Internet besteht aus **tausenden** separaten Netzwerken:

- Netzwerk der HdM
- Netzwerk der Telekom
- Netzwerk von Google
- Netzwerk deines Heimrouters
- ...

Ein Paket muss von Netzwerk zu Netzwerk weitergereicht werden.

**Router** entscheiden bei jedem Hop: "In welches Netzwerk als nächstes?"

---

# IP-Adressen = Globale Adressen

```
141.62.xxx.xxx    ← HdM-Netzwerk
212.132.79.37     ← Ziel-Server
```

Die IP-Adresse sagt dem Router:
1. **In welchem Netzwerk** ist der Rechner?
2. **Welcher Rechner** in diesem Netzwerk?

"141.62... ist nicht bei mir. Ich schicke das Paket Richtung eduroam."

**Die IP-Adresse bleibt auf dem gesamten Weg gleich.**
Sie ist die Empfängeradresse auf dem Brief.

---

# Warum reicht die MAC-Adresse nicht?

Jede Netzwerkkarte hat eine **MAC-Adresse** (z.B. `aa:bb:cc:dd:ee:ff`).

**Problem:** MAC funktioniert nur **lokal**.
- Dein Laptop kennt die MAC deines Routers
- Dein Router kennt die MAC des nächsten Routers
- Aber niemand kennt die MAC des Webservers in Vaihingen

**MAC = "Wer ist mein direkter Nachbar?"**
**IP = "Wo ist das Ziel im gesamten Internet?"**

Deshalb brauchen wir beides.

---

<!-- _class: lead -->

# Warum brauchen wir Ports?

---

# Ein Rechner, viele Programme

Dein Laptop hat **eine** IP-Adresse.

Aber gleichzeitig laufen:
- Browser
- Mail-Programm
- Spotify
- Discord
- System-Updates

Ein Paket kommt an. **Für welches Programm ist es?**

---

# Ports = Türnummern

```
IP-Adresse = Hausnummer      →  "Friedrichstraße 10"
Port       = Wohnungstür     →  "3. Stock links"
```

Jedes Programm "lauscht" auf einem Port:

| Port | Dienst |
|------|--------|
| 80 | HTTP (Webseiten) |
| 443 | HTTPS (Webseiten, verschlüsselt) |
| 25 | SMTP (E-Mail senden) |
| 22 | SSH (Terminal) |

<!--

Wenn ein Paket an `212.132.79.37:443` geht, weiß der Server: "Das ist für den Webserver-Prozess."

-->

---

# Beide Seiten haben Ports

```
Dein Laptop:    141.62.xxx.xxx:52431
                              └─────── Dein Browser lauscht hier

Server:         212.132.79.37:443
                             └─────── Webserver lauscht hier
```

**52431** ist ein zufälliger Port, den dein System für diese Verbindung vergeben hat.

Die Antwort des Servers geht an `141.62.xxx.xxx:52431` – und landet bei deinem Browser, nicht bei Spotify.

---

<!-- _class: lead -->

# Zusammenfassung: Die Bausteine

---

# Was wir jetzt wissen

| Konzept | Löst welches Problem? |
|---------|----------------------|
| **Schichten** | Komplexität aufteilen, Abstraktion |
| **IP-Adresse** | Ziel im globalen Internet finden |
| **MAC-Adresse** | Nächsten Nachbarn im lokalen Netz finden |
| **Port** | Richtiges Programm auf dem Rechner finden |

Mit diesen Bausteinen können wir jetzt die Reise eines Klicks verfolgen.

---

<!-- _class: lead -->

# Die Reise beginnt
## Schritt für Schritt

---

# Die Zeitlinie

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

Jeder dieser Schritte durchläuft alle Schichten – runter und wieder rauf.

---

<!-- _class: lead -->

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

---

# Das Problem

Dein Browser kennt nur den Namen: `www.hdm-stuttgart.de`

Das Internet kennt nur Zahlen: `212.132.79.37`

**Jemand muss übersetzen.**

---

# DNS: Das Telefonbuch des Internets

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

Dein Laptop fragt sich durch eine Hierarchie:

1. **Browser-Cache:** "War ich da kürzlich?" → Nein
2. **Betriebssystem-Cache:** "Kennt Windows/Mac die IP?" → Nein
3. **Router / ISP:** "Frag den DNS-Server deines Providers"

Wenn auch der Provider es nicht weiß, beginnt die **rekursive Suche**.

---

# Die DNS-Hierarchie

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

**Jede Ebene kennt nur die nächste Ebene darunter.**

---

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

---

# DNS ist selbst ein Netzwerk-Request

Die DNS-Anfrage ist nicht magisch. Sie ist selbst ein Paket, das durch alle Schichten muss:

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

Das DNS-Paket macht die gleiche Reise wie später der HTTP-Request – nur zu einem anderen Ziel.

---

# Nach dem DNS-Lookup

**Ergebnis:** Dein Browser weiß jetzt:

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

Diese Information wird gecached.

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

---

<!-- _class: lead -->

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

---

# Warum ein Handshake?

HTTP läuft über **TCP** (Transmission Control Protocol).

TCP ist **verbindungsorientiert**: Bevor Daten fließen, müssen sich beide Seiten einig sein, dass sie miteinander reden wollen.

**Analogie:** Du rufst jemanden an. Das Telefon klingelt. Die Person nimmt ab. Erst dann redest du.

---

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

# Der 3-Way-Handshake

```
Dein Laptop                              HdM-Server
    |                                        |
    |-------- SYN (Seq=1000) --------------->|
    |         "Ich will reden"               |
    |                                        |
    |<--- SYN-ACK (Seq=5000, Ack=1001) ------|
    |     "OK, ich auch"                     |
    |                                        |
    |-------- ACK (Ack=5001) --------------->|
    |         "Gut, dann los"                |
    |                                        |
    |        [ Verbindung steht ]            |
```

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

---

# Warum die Sequenznummern?

**Problem:** Pakete können im Internet:
- Verloren gehen
- Doppelt ankommen
- In falscher Reihenfolge ankommen

**Lösung:** Jedes Byte wird nummeriert.

Der Empfänger weiß genau, welches Byte als nächstes kommen muss – und kann fehlende Pakete erneut anfordern.

---

# Nach dem Handshake

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

```
Dein Laptop ←————————————————→ 212.132.79.37:443
   (Port 52431)                    (Port 443)
```

**Jetzt erst** kann der eigentliche HTTP-Request gesendet werden.

---

<!-- _class: lead -->

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

---

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

Das sind **~200 Bytes** Text.

Aber diese 200 Bytes müssen durch das halbe Internet.

**Wie?**

---

<!-- _class: lead -->

# Die Verpackungsstraße
## Encapsulation: Schicht für Schicht

---

# Jede Schicht verpackt

```
HTTP-Request: "GET / HTTP/1.1..."
    ↓
TCP packt ein:  [ Ports + Seq-Nr ] + HTTP-Request
    = Segment
    ↓
IP packt ein:   [ IP-Adressen ] + Segment
    = Paket
    ↓
Ethernet packt: [ MAC-Adressen ] + Paket + [ Prüfsumme ]
    = Frame
    ↓
Physik:         01001000 01010100 01010100 01010000 ...
    = Bits auf dem Kabel
```

---

# Layer 4: Transport (TCP)

Der HTTP-Request wird zum **Segment**.

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

**Neu hinzugekommen:** Ports (wer sendet? wer empfängt?) und Sequenznummer

---

# Layer 3: Network (IP)

Das Segment wird zum **Paket**.

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

**Neu:** IP-Adressen – woher kommt das Paket, wohin soll es?

---

# Layer 2: Data Link (Ethernet)

Das Paket wird zum **Frame**.

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

**Neu:** MAC-Adressen – aber Achtung: Das ist die MAC des **Routers**, nicht des Servers!

---

# Layer 1: Physical

Der Frame wird zu **Bits** – und die Bits zu physikalischen Signalen.

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

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

Ab hier übernimmt die Physik.

---

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

# MAC vs. IP – nochmal genau

| | IP-Adresse | MAC-Adresse |
|---|-----------|-------------|
| **Frage** | Wer ist das Endziel? | Wer ist der nächste Hop? |
| **Reichweite** | Global (ganzes Internet) | Lokal (bis zum nächsten Router) |
| **Ändert sich?** | Nein, bleibt gleich | Ja, bei jedem Hop |
| **Analogie** | Empfänger auf dem Brief | "Nächstes Postamt: XY" |

**Die MAC-Adresse im ersten Frame ist die MAC des Routers – nicht des Servers!**

---

# Woher kennt dein Laptop die MAC des Routers?

**ARP** – Address Resolution Protocol

```
Dein Laptop (Broadcast an alle):
    "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"
```

Diese Information wird gecached.

---

<!-- _class: lead -->

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

---

# Der erste Hop: Dein Router

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

Der Router empfängt den Frame:

1. **Layer 1:** Signale → Bits
2. **Layer 2:** Prüft Frame. "MAC stimmt, FCS okay" → Auspacken
3. **Layer 3:** Liest IP-Header. "212.132.79.37 – nicht mein Netz"

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

---

# Der Router verpackt NEU

Der Router erstellt einen **neuen Frame** für den nächsten Hop:

```
┌─────────────────────────────────────────────────┐
│ 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                             │
└─────────────────────────────────────────────────┘
```

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

---

# Mehrere Hops

```
Dein Laptop
    ↓ [Frame mit MAC des HdM-Routers]
Router (HdM-Netz)
    ↓ [Frame mit MAC des eduroam-Routers]
Router (BelWü)
    ↓ [Frame mit MAC des nächsten Routers]
...weitere Router...
    ↓ [Frame mit MAC des Ziel-Servers]
Webserver der HdM
```

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

<!--
---

# Das kannst du selbst sehen

```bash
traceroute www.hdm-stuttgart.de   # Mac/Linux
tracert www.hdm-stuttgart.de      # Windows
```

Zeigt jeden Router auf dem Weg mit IP und Antwortzeit.
-->

---

<!-- _class: lead -->

# Die Ankunft
## Decapsulation am Server

---

# Der Server empfängt

Am Webserver passiert alles **rückwärts** (Decapsulation):

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

Der Webserver versteht: "Jemand will die Startseite."

---

<!-- _class: lead -->

# Die Antwort
## Der gleiche Weg zurück

---

# Der Server antwortet

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

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

Diese ~45 KB HTML müssen jetzt zu dir.

---

# Encapsulation beim Server

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

```
HTTP-Response: "HTTP/1.1 200 OK..."
    ↓
TCP packt ein:  [ Ports + Seq-Nr ] + Response
    Dest-Port: 52431 (dein Browser!)
    ↓
IP packt ein:   [ IP-Adressen ]
    Dest-IP: 141.62.xxx.xxx (dein Laptop!)
    ↓
Ethernet packt: [ MAC-Adressen ]
    Dest-MAC: Router des Server-Netzes
    ↓
Bits auf dem Kabel
```

---

# Die Antwort reist zurück

```
Server
    ↓
Router (Ziel-Netz)
    ↓
...weitere Router...
    ↓
Router (HdM-Netz)
    ↓
Dein Laptop
```

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

Bis die Antwort bei dir ankommt – und dein Browser sie auspackt.

---

# Decapsulation bei dir

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

---

<!-- _class: lead -->

# Zusammenfassung
## Das TCP/IP-Modell

---

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

# Die Schichten (TCP/IP)

| Schicht | Name | Dateneinheit | Adressierung |
|---------|------|--------------|--------------|
| 4 | **Anwendung** | Daten | – |
| 3 | **Transport** | Segment | Ports |
| 2 | **Internet** | Paket | IP-Adressen |
| 1 | **Netzzugang** | Frame | MAC-Adressen |

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

---

# OSI vs. TCP/IP

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

OSI ist ein **Referenzmodell**. TCP/IP ist die Realität.

---

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

# Was ihr wissen solltet

**Den Ablauf:**
1. DNS-Lookup (UDP:53) → IP-Adresse
2. TCP-Handshake (SYN → SYN-ACK → ACK)
3. HTTP-Request
4. HTTP-Response

**Die Konzepte:**
- IP bleibt gleich, MAC ändert sich pro Hop
- Ports identifizieren Programme
- Encapsulation/Decapsulation

---

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

# Die Dateneinheiten (PDUs)

| Schicht | Dateneinheit | Was kommt hinzu? |
|---------|--------------|------------------|
| Anwendung | **Daten** | HTTP-Header |
| Transport | **Segment** | Ports, Seq-Nr |
| Internet | **Paket** | IP-Adressen |
| Netzzugang | **Frame** | MAC, Prüfsumme |

**Encapsulation:** Jede Schicht verpackt die Daten der Schicht darüber.
**Decapsulation:** Beim Empfang wird Schicht für Schicht ausgepackt.

---

<!-- _class: lead -->

# Exkurs: MTU & Fragmentierung

---

# Die MTU (Maximum Transmission Unit)

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

```
┌───────────┬──────────────────────────────────────────┬──────────┐
│ Header    │ Payload (max. 1500 Bytes)                │ Trailer  │
│ 14 Bytes  │                                          │ 4 Bytes  │
└───────────┴──────────────────────────────────────────┴──────────┘
```

**Problem:** Ein Foto hat 3.000.000 Bytes.
**Lösung:** TCP zerschneidet die Daten in ~2000 Segmente.

---

# TCP sorgt für Ordnung

Jedes Segment hat eine **Sequenznummer**.

```
Segment 1: Bytes 0-1459      Seq=0
Segment 2: Bytes 1460-2919   Seq=1460
Segment 3: Bytes 2920-4379   Seq=2920
...
```

Der Empfänger setzt die Segmente zusammen – auch wenn sie in falscher Reihenfolge ankommen.

---

<!-- _class: lead -->

# Exkurs: TCP vs. UDP

---

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

# Zwei Transport-Protokolle

| | TCP | UDP |
|---|-----|-----|
| Verbindung | Ja (Handshake) | Nein |
| Reihenfolge garantiert | Ja | Nein |
| Fehlende Pakete | Werden nachgefordert | Gehen verloren |
| Geschwindigkeit | Langsamer | Schneller |

---

# Wann was?

**TCP:**
- Web (HTTP/HTTPS)
- E-Mail
- Dateitransfer
- SSH

→ Wenn **jedes Byte ankommen muss**

**UDP:**
- DNS
- Video-Streaming
- Online-Gaming
- Video-Calls

→ Wenn **Geschwindigkeit wichtiger ist als Vollständigkeit**

---

# Warum UDP bei Video-Calls?

**Szenario:** Ein Paket geht verloren.

**TCP:** Wartet, fordert neu an, wartet... → Video friert ein

**UDP:** Ignoriert es, zeigt nächstes Frame → Kurzes Artefakt

Bei Echtzeit ist ein verlorenes Frame weniger schlimm als Verzögerung.

---

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

# HTTP-Response & Status-Codes

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

<!DOCTYPE html>
```

**Status-Codes:**
- **2xx** Erfolg (200 OK)
- **3xx** Umleitung (301 Moved)
- **4xx** Client-Fehler (404 Not Found)
- **5xx** Server-Fehler (500 Internal Error)

---

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

# HTTP-Methoden

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

---

# Werkzeuge zum Selbst-Erkunden

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

**Im Terminal:**
```bash
ping hdm-stuttgart.de
traceroute hdm-stuttgart.de
nslookup hdm-stuttgart.de
curl -I hdm-stuttgart.de
```

---

<!-- _class: lead -->

# Teil 2: CSS
## Webseiten gestalten

---

# Was ist CSS?

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

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

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

---

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

---

# CSS-Anatomie

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

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

---

# Selektoren: Element

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

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

---

# 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

---

# Selektoren: ID

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

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

**Raute** vor dem Namen = ID

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

---

# Selektoren: Kombinationen

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

/* Direktes Kind */
nav > a { text-decoration: none; }

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

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

---

# 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 */
```

---

# Box-Modell

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

---

# Box-Modell: CSS

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

`box-sizing: border-box` → width inkl. padding + border

---

# Farben

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

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

---

# Einheiten

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

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

---

# Pseudo-Klassen

```css
a:hover { color: red; }
a:visited { color: purple; }
input:focus { border-color: blue; }

li:first-child { font-weight: bold; }
li:nth-child(odd) { background: #eee; }
```

---

# Pseudo-Elemente

```css
.required::before {
    content: "* ";
    color: red;
}

p::first-letter { font-size: 2em; }
```

`:` = Pseudo-Klasse · `::` = Pseudo-Element

---

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

# Responsive Design

```css
/* Mobile First */
.container { padding: 1rem; }

/* Ab 768px (Tablet) */
@media (min-width: 768px) {
    .container { 
        padding: 2rem; 
        max-width: 720px; 
    }
}
```

---

<!-- _class: lead -->

# Fragen & Diskussion

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

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

---

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