2328 lines
52 KiB
Markdown
2328 lines
52 KiB
Markdown
---
|
||
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;
|
||
/**background: repeating-linear-gradient(
|
||
135deg,
|
||
#fce4ec,
|
||
#fce4ec 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;**/
|
||
}
|
||
@media print {
|
||
section.erklaerung {
|
||
background: #fce4ec !important;
|
||
}
|
||
}
|
||
section.erklaerung h1 {
|
||
font-size: 1.5rem;
|
||
color: #a02060;
|
||
margin-bottom: 0.3rem;
|
||
}
|
||
section.erklaerung ul,
|
||
section.erklaerung ol {
|
||
font-size: 1.0rem;
|
||
line-height: 1.4;
|
||
}
|
||
section.erklaerung p {
|
||
font-size: 1.0rem;
|
||
line-height: 1.4;
|
||
}
|
||
section.erklaerung table {
|
||
font-size: 0.9rem;
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: black -->
|
||
|
||
|
||
|
||
# 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: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _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 Ihnen und einer Webseite liegen viele Stationen.
|
||
|
||
Jede Komponente "spricht" anders:
|
||
|
||
- Browser → **HTTP**
|
||
- Netzwerkkarte → **Bits / Signale**
|
||
- Router → **IP-Pakete**
|
||
- Provider → **Routing**
|
||
|
||
Wie zusammenbringen?
|
||
|
||
<!--
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# TCP/IP-Modell – Vertiefung
|
||
|
||
Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
|
||
|
||
**Schicht-Aufgaben im Detail:**
|
||
|
||
| Schicht | Frage | Protokolle | Geräte |
|
||
|---------|-------|------------|--------|
|
||
| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
|
||
| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
|
||
| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
|
||
| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
|
||
|
||
**OSI vs. TCP/IP:**
|
||
- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
|
||
- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
|
||
|
||
**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
|
||
|
||
---
|
||
|
||
# Schichten verpacken Daten
|
||
|
||
|
||
|
||
**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
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Dateneinheiten & Encapsulation – Vertiefung
|
||
|
||
**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
|
||
|
||
**Was jeder Header enthält:**
|
||
|
||
| Schicht | Einheit | Header-Inhalte |
|
||
|---------|---------|----------------|
|
||
| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
|
||
| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
|
||
| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
|
||
| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
|
||
|
||
**Overhead-Rechnung (1 Byte HTTP-Body):**
|
||
- Ethernet: 14 + 4 Bytes (Header + Trailer)
|
||
- IP: 20 Bytes (ohne Optionen)
|
||
- TCP: 20 Bytes (ohne Optionen)
|
||
- **Minimum: 58 Bytes für 1 Byte Nutzlast**
|
||
|
||
**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
|
||
|
||
---
|
||
|
||
# Warum ist das clever?
|
||
|
||
**Ohne Schichten:**
|
||
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 = 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
|
||
|
||
|
||
|
||
- 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
|
||
-->
|
||
|
||
---
|
||
|
||
# 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: 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 Sie `www.hdm-stuttgart.de` aufrufen?
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
- Alle Werkzeuge da: Schichten, Adressen, Protokolle
|
||
- Jetzt anwenden
|
||
- URL → Enter → 200ms → Webseite
|
||
- Was passiert in 200ms?
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Szenario
|
||
|
||
Sie sind im WLAN der HdM und rufen 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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _paginate: false -->
|
||
|
||
# Die Zeitlinie
|
||
|
||
|
||
|
||
<!--
|
||
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
|
||
```
|
||
|
||
Ihr 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
|
||
|
||
|
||
|
||
**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 -->
|
||
|
||
# Der DNS-Lookup
|
||
|
||
|
||
|
||
<!--
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _paginate: false -->
|
||
|
||
# Der 3-Way-Handshake
|
||
|
||
|
||
|
||
**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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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.
|
||
|
||
|
||
|
||
**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 Ihr 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 Sie")
|
||
- "/" = 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**:
|
||
|
||
|
||
|
||
**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**:
|
||
|
||
|
||
|
||
**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**:
|
||
|
||
|
||
|
||
**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 Ihr 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: Ihr 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
|
||
|
||
|
||
|
||
**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
|
||
|
||
|
||
|
||
Bei jedem Hop:
|
||
|
||
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
|
||
|
||
|
||
|
||
Jede Schicht prüft "ist das für mich?" und packt dann die nächste aus.
|
||
|
||
Am Ende versteht der Webserver: "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 Ihnen.
|
||
|
||
<!--
|
||
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:
|
||
|
||
|
||
|
||
<!--
|
||
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
|
||
|
||
|
||
|
||
Gleiches Spiel 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 Ihnen
|
||
|
||
|
||
|
||
Rückweg = Encapsulation umgekehrt.
|
||
|
||
Jede Schicht prüft "ist das für mich?" 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 | 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).
|
||
|
||
---
|
||
|
||
# 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)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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: 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
|
||
```
|
||
|
||
---
|
||
|
||
# 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: 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.
|
||
|
||
---
|
||
|
||
# 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-Entwickler:
|
||
|
||
**1. DNS-Auflösung:**
|
||
- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
|
||
- Rekursive Abfrage: Root → TLD → Authoritative
|
||
- Caching auf jeder Ebene (TTL = Time To Live)
|
||
|
||
**2. TCP-Verbindungsaufbau:**
|
||
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
|
||
- Keep-Alive: Verbindung bleibt offen für mehrere Requests
|
||
- HTTP/2: Multiplexing – viele Requests über eine Verbindung
|
||
|
||
**3. HTTP Request/Response:**
|
||
```
|
||
Request: Methode + URL + Header + (Body)
|
||
Response: Status + Header + Body
|
||
```
|
||
|
||
**4. Schichten & Adressen:**
|
||
| Was bleibt gleich? | Was ändert sich? |
|
||
|-------------------|------------------|
|
||
| Ziel-IP | MAC-Adressen (bei jedem Hop) |
|
||
| Ports | – |
|
||
|
||
**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
|
||
|
||
---
|
||
|
||
# Werkzeuge zum Selbst-Erkunden
|
||
|
||
**Im Browser (F12 → Network-Tab):**
|
||
- Jeder Request sichtbar
|
||
- Timing, Headers, Response
|
||
|
||
**Im Terminal:**
|
||
```bash
|
||
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.
|
||
-->
|
||
|
||
---
|
||
|
||
# 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.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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
|
||
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
```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.
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
# 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.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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ä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/
|