- Nutzer/User -> Nutzende - Endnutzer -> Endnutzende - Teilnehmer -> Teilnehmende - Programmierer/Entwickler -> Programmierende/Entwickelnde - Web-Entwickler -> Web-Entwickelnde - Tastatur-Nutzer -> Tastatur-Nutzende - Benutzer -> Nutzende - Konsumenten -> KonsumentInnen - Künstler -> KünstlerInnen - Autor -> AutorIn - Fotografen -> FotografInnen - Kunde -> KundIn ausgenommen: code-identifiers (User, type User, /users/), Sender/Empfänger (network protocol), Sawyer (konkrete person), Hersteller/Betreiber (organisations-rolle).
52 KiB
marp, theme, paginate, backgroundColor, header, footer, title
| marp | theme | paginate | backgroundColor | header | footer | title |
|---|---|---|---|---|---|---|
| true | gaia | true | Grundlagen IT- und Internettechnik (223015c) | Michael Czechowski – HdM Stuttgart – SoSe 2026 | Kapitel 2: Netzwerke, Protokolle & CSS |
Grundlagen IT- und Internettechnik
223015c · Modul "Technik 1" · 1. Semester Digital- und Medienwirtschaft Hochschule der Medien Stuttgart
Sommersemester 2026
https://librete.ch/hdm/223015c/
Kapitel 2
Netzwerke, Protokolle & CSS
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
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/
Teil 1: Netzwerke & Protokolle
Die Infrastruktur des Webs
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 |
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 |
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 |
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 |
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 |
Das Schichtenmodell
Warum ist Netzwerk-Kommunikation in Schichten organisiert?
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?
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 |
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.
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.
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: Daten → Segment → Paket → Frame („Der Sache Praktischer Folgen")
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.
Exkurs: OSI vs. TCP/IP
OSI = Theorie. TCP/IP = Realität.
Die drei Adressen
IP, MAC und Port – wer braucht was?
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?"
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.
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 |
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 |
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?).
Die Reise eines Klicks
Was passiert, wenn Sie www.hdm-stuttgart.de aufrufen?
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.
Die Zeitlinie
Schritt 1: DNS
"Wo wohnt hdm-stuttgart.de?"
DNS: Das Telefonbuch des Internets
Domain Name System
www.hdm-stuttgart.de → 212.132.79.37
Ihr Laptop fragt sich durch:
- Browser-Cache: "War ich da kürzlich?" → Nein
- OS-Cache: "Kennt das Betriebssystem die IP?" → Nein
- Router/Provider: DNS-Server wird gefragt
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, …
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.
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.
Schritt 2: TCP-Handshake
"Hallo Server, bist du da?"
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.
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.
Schritt 3: HTTP-Request
"Gib mir die Startseite"
Was Ihr Browser sendet
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"
Encapsulation in Aktion
Der Request wird verpackt
Layer 4: Transport (TCP)
HTTP-Request wird zum Segment:
Neu: Ports + Sequenznummer
Layer 3: Network (IP)
Segment wird zum Paket:
Neu: IP-Adressen
Layer 2: Data Link (Ethernet)
Paket wird zum Frame:
Wichtig: Destination MAC = Router, nicht Server!
Woher kennt Ihr Laptop die Router-MAC?
ARP – Address Resolution Protocol
Das passiert automatisch. Die Info wird gecached.
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.
Die Reise durch das Netz
Hop für Hop
Der erste Hop: Ihr Router
Laptop → [Frame] → Router
Der Router empfängt:
- Layer 1: Signale → Bits
- Layer 2: Frame prüfen. MAC okay? → Auspacken
- Layer 3: IP lesen. "212.132.79.37 – nicht mein Netz"
Routing-Entscheidung: "Ich schicke es Richtung Internet."
Der Router verpackt NEU
IP bleibt gleich. MAC ändert sich.
Mehrere Hops
Bei jedem Hop:
- Auspacken bis Layer 3 (IP)
- Routing-Entscheidung
- Neu verpacken mit nächster MAC
IP bleibt gleich · MAC ändert sich jedes Mal.
Die Ankunft
Der Server empfängt und antwortet
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."
Der Server antwortet
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>
...
~45 KB HTML müssen jetzt zu Ihnen.
Encapsulation beim Server
Der Server macht dasselbe – nur in die andere Richtung:
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
Decapsulation bei Ihnen
Rückweg = Encapsulation umgekehrt.
Jede Schicht prüft "ist das für mich?" und packt dann die nächste aus.
Exkurse
TCP vs. UDP, MTU, HTTP-Methoden
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 |
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.
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.
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 |
GET /index.html HTTP/1.1
POST /login HTTP/1.1
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/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) |
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:
- DNS (UDP:53) → Name zu IP
- TCP-Handshake (SYN → SYN-ACK → ACK)
- HTTP-Request (GET /...)
- 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
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-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:
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
Teil 2: CSS
Webseiten gestalten
Was ist CSS?
Cascading Style Sheets
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
CSS einbinden
Option 1: Externe Datei ✓
<link rel="stylesheet" href="style.css">
Option 2: Style-Tag
<style>p { color: blue; }</style>
Option 3: Inline ✗
<p style="color: blue;">...</p>
CSS-Anatomie
selector {
property: value;
}
Beispiel:
h1 {
color: #333333;
font-size: 2rem;
margin-bottom: 1rem;
}
Selektor → was wird gestylt Property → welche Eigenschaft Value → welcher Wert
Selektoren: Element
/* Alle <p>-Elemente */
p {
color: gray;
}
/* Mehrere Elemente gleichzeitig */
h1, h2, h3 {
font-family: sans-serif;
}
Element-Selektoren sind die einfachsten.
Selektoren: Klasse
<p class="wichtig">Dieser Text ist wichtig.</p>
<p>Dieser nicht.</p>
.wichtig {
color: red;
font-weight: bold;
}
Punkt vor dem Namen = Klasse
Selektoren: ID
<nav id="hauptnavigation">...</nav>
#hauptnavigation {
background: #333;
padding: 1rem;
}
Raute vor dem Namen = ID
⚠️ IDs sollten einmalig pro Seite sein.
Selektoren: Kombinationen
/* 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; }
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 |
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 */
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
!importantbricht 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
Gesamt-Breite = width + padding + border + margin. Tipp: box-sizing: border-box rechnet padding + border mit ein.
Box-Modell: CSS
.box {
width: 200px;
height: 100px;
padding: 20px;
border: 2px solid black;
margin: 10px;
}
Wichtig:
box-sizing: border-box;
→ width/height inkludiert padding + border
Farben
/* 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%);
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
Pseudo-Klassen
/* 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
Pseudo-Elemente
/* 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)
Responsive Design
/* 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;
}
}
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!):
<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
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/
































