public/uni

Files

Michael Czechowski fb361a2854 add css demos for 223015c chapter 2: selectors, specificity, box-model, colors, pseudo, responsive

2026-04-20 10:53:11 +02:00

61 KiB

Raw Blame History

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 dir und einer Webseite liegen:

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

Jede Komponente "spricht" anders.

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

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

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

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 (7 Schichten)              TCP/IP (4 Schichten)
┌─────────────────────┐        ┌─────────────────────┐
│  7. Anwendung       │        │                     │
├─────────────────────┤        │      Anwendung      │
│  6. Darstellung     │        │                     │
├─────────────────────┤        │                     │
│  5. Sitzung         │        │                     │
├─────────────────────┤        ├─────────────────────┤
│  4. Transport       │        │      Transport      │
├─────────────────────┤        ├─────────────────────┤
│  3. Vermittlung     │        │      Internet       │
├─────────────────────┤        ├─────────────────────┤
│  2. Sicherung       │        │                     │
├─────────────────────┤        │     Netzzugang      │
│  1. Bitübertragung  │        │                     │
└─────────────────────┘        └─────────────────────┘

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

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

212.132.79.37:443
              └─── Port 443 = HTTPS

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

Port	Dienst
80	HTTP
443	HTTPS
22	SSH
53	DNS

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 du `www.hdm-stuttgart.de` aufrufst?

Das Szenario

Du bist im WLAN der HdM und rufst auf:

https://www.hdm-stuttgart.de

Zwischen Enter und fertiger Seite: ~200 Millisekunden.

In dieser Zeit passieren hunderte Operationen.

Die Zeitlinie

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

Schritt 1: DNS

"Wo wohnt hdm-stuttgart.de?"

DNS: Das Telefonbuch des Internets

Domain Name System

www.hdm-stuttgart.de  →  212.132.79.37

Dein 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

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

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

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

Der 3-Way-Handshake

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

SYN = Synchronize · ACK = Acknowledge

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.

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

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

Jetzt erst kann HTTP gesprochen werden.

Schritt 3: HTTP-Request

"Gib mir die Startseite"

Was dein 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:

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

Neu: Ports + Sequenznummer

Layer 3: Network (IP)

Segment wird zum Paket:

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

Neu: IP-Adressen

Layer 2: Data Link (Ethernet)

Paket wird zum Frame:

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

Wichtig: Destination MAC = Router, nicht Server!

Woher kennt dein Laptop die Router-MAC?

ARP – Address Resolution Protocol

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

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

Das passiert automatisch. Die Info wird gecached.

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

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

IP bleibt gleich. MAC ändert sich.

Mehrere Hops

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

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

Die Ankunft

Der Server empfängt und antwortet

Decapsulation am Server

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

Der Webserver versteht: "Jemand will die Startseite."

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

Encapsulation beim Server

Der Server macht dasselbe – nur in die andere Richtung:

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

Die Antwort reist zurück

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

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

Decapsulation bei dir

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

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

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	IDs	Klassen	Elemente	Gesamt
`p`	0	0	1	0,0,0,1
`.info`	0	1	0	0,0,1,0
`p.info`	0	1	1	0,0,1,1
`#header`	1	0	0	0,1,0,0
`#header .nav a`	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

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

Jedes Element ist eine Box.

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/

61 KiB Raw Blame History Unescape Escape