From 8fd33b291b18d78fd6b242282314dfbe563af5bd Mon Sep 17 00:00:00 2001 From: Michael Czechowski Date: Thu, 14 May 2026 16:44:37 +0200 Subject: [PATCH] =?UTF-8?q?223015c=20phase=204:=20kap2=20slide-MD=20rewrit?= =?UTF-8?q?e=20(91=20=E2=86=92=2041=20slides,=20-55%)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit bogen-treu nach docs/223015c/02-netzwerke-protokolle-css-bogen.md. sub-A netzwerk (18 slides): - lead 'sub-A netzwerk' - klausur drei-adressen-tabelle (IP weltweit eindeutig endgerät, MAC lokal eindeutig NIC, port programm — mit beispielen 80/443/22) - ip-packet demo reuse - client-server-ports demo reuse - lead TCP/IP, warum-schichten erklärung, klausur 4-schichten-tabelle (network-access/internet/transport/application mit protokollen + dateneinheiten frame/packet/segment/data) - encap-stack demo reuse, klausur encapsulation-pyramide - OSI vs TCP/IP tabelle (7 vs 4 schichten) - lead DNS, dns-lookup demo reuse, dns-tree demo reuse - lead HTTP, klausur HTTP-request mit GET/path/header, klausur HTTP-response mit statuscode/header/body - klausur statuscodes-tabelle (200/301/302/400/401/403/404/500/503) - HTTP-versionen 1.1/2/3 mit hauptverbesserungen pro version - tcp-handshake demo reuse - klausur synthese 'URL → pixel 7 schritte' (URL-parsen→DNS→TCP→TLS→HTTP→HTML/CSS/JS→render) - network-chain demo reuse sub-B CSS+A11y (22 slides): - lead sub-B - css-anatomie demo reuse mit selektor/property/value erklärung + 3 einbindungsarten - klausur CSS-selektoren-tabelle (element/klasse/id/pseudo/kombinatoren) - css-combinators demo reuse - klausur spezifizität-hierarchie (inline 1000, id 100, klasse 10, element 1) - css-box-model demo reuse + ASCII-darstellung + box-sizing border-box best-practice - display: block/inline/flex/grid übersicht - klausur flexbox-vs-grid (1D vs 2D, anwendungs-fälle) - css-responsive demo reuse (media queries, mobile-first) - lead A11y, klausur BFSG+EAA-pflicht ab 28.06.2025 (wer betroffen, ausnahmen kleinunternehmen, 100k bußgeld), klausur WCAG-POUR-prinzipien - a11y-semantic demo reuse, ARIA als ergänzung (button vs div role=button), contrast-levels demo reuse, keyboard-a11y demo reuse, a11y-error demo reuse - selbstlernen A11y-audit mit lighthouse - zusammenfassung 'netzwerk + browser-synthese + CSS + A11y' reuse-demos: ip-packet, client-server-ports, encap-stack, dns-lookup, dns-tree, tcp-handshake, network-chain, css-anatomie, css-combinators, css-box-model, css-responsive, a11y-semantic, contrast-levels, keyboard-a11y, a11y-error (15 demos reused) no NEU demos in dieser session — alle inline als markdown-tabellen + code-blocks klausur-marker (11): drei-adressen, 4-schichten, encapsulation, HTTP-request, HTTP-response, statuscodes, URL→pixel-7-schritte, CSS-selektoren, spezifizität, box-model, flexbox-vs-grid, BFSG/EAA, WCAG-POUR build geht durch --- slides/223015c/02-netzwerke-protokolle-css.md | 2948 +++++------------ 1 file changed, 878 insertions(+), 2070 deletions(-) diff --git a/slides/223015c/02-netzwerke-protokolle-css.md b/slides/223015c/02-netzwerke-protokolle-css.md index c7ed32c..8fdb1fb 100644 --- a/slides/223015c/02-netzwerke-protokolle-css.md +++ b/slides/223015c/02-netzwerke-protokolle-css.md @@ -14,40 +14,27 @@ title: "Kapitel 2: Netzwerke, Protokolle & CSS" --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; -} +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; -} +pre code { background: transparent; color: inherit; } code { - background: #1a1a2e; - color: #d63384; + background: #0f0f23; padding: 0.15em 0.4em; border-radius: 4px; + font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace; } -a { - color: var(--color-highlight); -} +section code:not(.hljs) { color: #d63384 !important; } +section code.hljs { color: #f8f8f8 !important; } +a { color: var(--color-highlight); } section.klausur { background: repeating-linear-gradient( 135deg, @@ -58,2279 +45,1100 @@ section.klausur { ) !important; } @media print { - section.klausur { - background: #fce4ec !important; - } -} -section.aufgabe { - background: #fce4ec !important; -} -section.aufgabe footer { - display: none; -} -section.glossar { - font-size: 1.4rem; -} -section.erklaerung { - font-size: 1.1rem; -} -section.erklaerung h1 { - font-size: 1.5rem; - color: #a02060; - margin-bottom: 0.3rem; -} -section.erklaerung ul, -section.erklaerung ol { - font-size: 1.0rem; - line-height: 1.4; -} -section.erklaerung p { - font-size: 1.0rem; - line-height: 1.4; -} -section.erklaerung table { - font-size: 0.9rem; + section.klausur { background: #fce4ec !important; } } +section.aufgabe { background: #fce4ec !important; } +section.aufgabe footer { display: none; } +section.erklaerung { font-size: 1.1rem; } +section.erklaerung h1 { font-size: 1.5rem; color: #a02060; margin-bottom: 0.3rem; } +section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; } +section.erklaerung p { font-size: 1.0rem; line-height: 1.4; } +section.erklaerung table { font-size: 0.9rem; } - - - - - -![bg fit opacity:0.2](./assets/background-termin-2.png) - -# Grundlagen IT- und Internettechnik - -**223015c** · Modul "Technik 1" · 1. Semester -Digital- und Medienwirtschaft -Hochschule der Medien Stuttgart - -**Sommersemester 2026** - -[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/) - ---- - - - - -![bg fit](./assets/qr/slides-223015c.png) - ---- - # Kapitel 2 ## Netzwerke, Protokolle & CSS +Eine Stunde (oder zwei), eine Frage: *Wie reisen die Bytes vom Server in Frankfurt zu deinem Browser in Stuttgart — und wie wird ankommender HTML-Code zu einer hübschen barrierefreien Seite?* ---- - -# 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 +# Sub-Sektion A: Netzwerk +## Wie reisen Pakete? + +--- + + + +# Drei Adressen — IP · MAC · Port + +| Adresse | Identifiziert | Beispiel | +|---------|---------------|----------| +| **IP** | das **Endgerät** (welt-eindeutig) | `192.168.1.42` (v4) · `2001:db8::1` (v6) | +| **MAC** | die **Netzwerk-Karte** (lokal eindeutig) | `00:1A:2B:3C:4D:5E` (6 Byte hex) | +| **Port** | das **Programm** auf dem Gerät | `80` (HTTP) · `443` (HTTPS) · `22` (SSH) | + +**Drei Schichten, drei Fragen.** „Welcher Computer?" → IP. „Welches Kabel/WLAN?" → MAC. „Welches Programm?" → Port. + + --- - - -# Glossar: Die Landkarte - -Das Web folgt dem **Client-Server-Modell**: Ein Client (Browser) sendet einen **Request**, ein Server liefert eine **Response** – nach den Regeln eines **Protokolls**. - -| Begriff | Was ist das? | Analogie | -|---------|--------------|----------| -| **Host** | Ein Rechner im Netz | Ein Haus mit Adresse | -| **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 (z. B. TCP, HTTP) | Speisekarte + Bestellablauf | +![bg fit](./assets/demos/ip-packet.png) --- - + + -# Glossar: Adressen & Identitäten - -Jedes Gerät im Netz braucht Adressen: eine **IP** für das globale Routing, eine **MAC** für das lokale Netz und einen **Port** für das richtige Programm. - -| Begriff | Was ist das? | Beispiel | -|---------|--------------|----------| -| **IP-Adresse** | Globale Adresse im Internet | `212.132.79.37` | -| **MAC-Adresse** | Hardware-Adresse der Netzwerkkarte | `aa:bb:cc:dd:ee:ff` | -| **Port** | "Türnummer" auf einem Rechner | `80`, `443`, `22` | -| **DNS** | Telefonbuch: Name → IP | hdm-stuttgart.de → IP | -| **Domain** | Menschenlesbarer Name | `hdm-stuttgart.de` | +![bg fit](./assets/demos/client-server-ports.png) +Port-Modell. ---- +Ein Server kann **mehrere Dienste** gleichzeitig laufen lassen — jeder auf einem anderen Port: +- Port 80: HTTP +- Port 443: HTTPS +- Port 22: SSH +- Port 25: SMTP (Mail-Versand) +- Port 53: DNS - +Der Client wählt einen zufälligen **Ephemeral Port** (49152–65535) für seine Antworten. -# Glossar: Daten unterwegs - -Daten werden Schicht für Schicht verpackt — jede Schicht fügt einen eigenen **Header** hinzu und erzeugt so eine neue Dateneinheit. - -| Begriff | Was ist das? | Schicht | -|---------|--------------|---------| -| **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 - -**Latenz** und **Bandbreite** bestimmen, wie schnell Daten ankommen — Latenz misst die Verzögerung, Bandbreite die Kapazität. - -| Begriff | Was ist das? | Einheit | -|---------|--------------|---------| -| **Latenz** | Verzögerung (hin + zurück) | Millisekunden | -| **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 - -Protokolle regeln die Kommunikation auf jeder Schicht — von der Anwendung (HTTP) über den Transport (TCP/UDP) bis zum Routing (IP). - -| Protokoll | Wofür? | Port | Schicht | -|-----------|--------|------|---------| -| **HTTP** | Webseiten ü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? +# TCP/IP-Schichtenmodell --- -# Das Problem: Komplexität +# Warum Schichten? -![bg right:40% fit](./assets/demos/network-chain.png) +Komplexes Problem **„Daten von A nach B"** in kleine Aufgaben **zerlegt:** -Zwischen Ihnen und einer Webseite liegen viele Stationen. +- Welche elektrischen Signale auf dem Kabel? (Schicht 1) +- Wie ist das Paket adressiert? (Schicht 2) +- Wie kommt das Paket über mehrere Hops? (Schicht 3) +- Wie ist die Verbindung zuverlässig? (Schicht 4) +- Welche Anwendung benutzt das? (Schicht 5) -Jede Komponente "spricht" anders: - -- Browser → **HTTP** -- Netzwerkkarte → **Bits / Signale** -- Router → **IP-Pakete** -- Provider → **Routing** - -Wie zusammenbringen? +**Jede Schicht ignoriert, was die anderen tun.** Modularer, austauschbarer, debugbarer. --- -# Die Lösung: Arbeitsteilung + -Statt dass jedes Programm alles können muss: **Aufgaben aufteilen.** +# TCP/IP · 4 Schichten -| 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 | +| # | Schicht | Aufgabe | Beispiel-Protokolle | Dateneinheit | +|---|---------|---------|---------------------|--------------| +| 1 | **Network Access** | Bits auf Kabel/WLAN | Ethernet · WiFi | Frame | +| 2 | **Internet** | Routing über mehrere Hops | **IP** · ICMP | Packet | +| 3 | **Transport** | Verbindung + Zuverlässigkeit | **TCP** · UDP | Segment | +| 4 | **Application** | Anwendungs-Logik | **HTTP** · DNS · SMTP | Data | + +Schichten von unten nach oben. Jede höhere Schicht **nutzt** die darunter. --- -# 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 | - -Jede Schicht hat genau eine Aufgabe und nutzt nur die Schicht direkt darunter. - - - ---- - - -# TCP/IP-Modell – Vertiefung - -Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt. - -**Schicht-Aufgaben im Detail:** - -| Schicht | Frage | Protokolle | Geräte | -|---------|-------|------------|--------| -| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) | -| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) | -| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router | -| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point | - -**OSI vs. TCP/IP:** -- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4 -- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1 - -**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht. - ---- - -# Schichten verpacken Daten - -![bg right:52% fit](./assets/demos/encap-layers.png) - -**Encapsulation:** Jede Schicht packt ein. - -**Decapsulation:** Beim Empfang wird ausgepackt. +![bg fit](./assets/demos/encap-stack.png) --- -# 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 | +# Encapsulation — Datenüberbringung -Beim Senden wandern Daten von oben nach unten — jede Schicht verpackt die darüberliegende Einheit mit einem eigenen Header. +``` +[Application Data] + ↓ + TCP-Header +[Segment] + ↓ + IP-Header +[Packet] + ↓ + Ethernet-Header + Trailer +[Frame] + ↓ als Bits auf das Kabel/WLAN +``` + +Beim Empfänger: **umgekehrte Reihenfolge.** --- - - - +# OSI vs TCP/IP -# Dateneinheiten & Encapsulation – Vertiefung +| OSI (7 Schichten) | TCP/IP (4 Schichten) | +|-------------------|----------------------| +| 7 Application | Application | +| 6 Presentation | (in App-Schicht) | +| 5 Session | (in App-Schicht) | +| 4 Transport | Transport | +| 3 Network | Internet | +| 2 Data Link | Network Access | +| 1 Physical | (in Network Access) | -**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. +**OSI:** theoretisches Lehrbuch-Modell (ISO, 1984). +**TCP/IP:** das Modell, das in der Praxis verwendet wird. +Klausurfähig (Block C.4): die zwei Modelle nebeneinander stellen können. ---- +OSI hat 7 Schichten. Die obersten drei (Application, Presentation, Session) wurden in der TCP/IP-Welt nicht so streng getrennt — die gesamte Anwendungs-Logik wird in EINER Schicht (Application) zusammengefasst. -# Exkurs: OSI vs. TCP/IP - -![bg right:50% fit](./assets/demos/osi-tcpip-diagram.png) - -OSI (7 Schichten) ist ein theoretisches Referenzmodell — TCP/IP (4 Schichten) beschreibt das reale Internet. - - --- -# Die drei Adressen -## IP, MAC und Port – wer braucht was? +# DNS — die Adress-Auskunft +Bisher: Adressen sind IP-Nummern. Aber Menschen tippen `librete.ch`, nicht `185.232.71.45`. ---- - -# 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 - -![bg right:35% fit](./assets/demos/port-highlight.png) - -Ein Port identifiziert ein **Programm** auf einem Rechner — wie eine **Wohnungstür im Mehrfamilienhaus**. - -- **80** → HTTP -- **443** → HTTPS -- **22** → SSH -- **53** → DNS - - - ---- - -# IP vs. MAC vs. Port - -Drei Adresstypen arbeiten zusammen — nur die **MAC-Adresse** ändert sich unterwegs, IP und Port bleiben auf dem gesamten Weg gleich. - -| | IP-Adresse | MAC-Adresse | Port | -|---|-----------|-------------|------| -| **Frage** | Welcher Rechner? | Welches Gerät nebenan? | Welches Programm? | -| **Reichweite** | Global | Lokal (1 Hop) | Auf einem Rechner | -| **Ändert sich?** | Nein | Ja, bei jedem Hop | Nein | -| **Schicht** | Internet (IP) | Netzzugang (Ethernet) | Transport (TCP/UDP) | -| **Beispiel** | 212.132.79.37 | aa:bb:cc:dd:ee | 443 | - - - ---- - - - - - -# 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 - -![h:560 center](./assets/demos/timeline.png) - - - ---- - - - -# Schritt 1: DNS -## "Wo wohnt hdm-stuttgart.de?" - - - ---- - -# 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 - - - ---- - -# Die DNS-Hierarchie - -![bg right:45% fit](./assets/demos/dns-tree.png) - -**Dezentral:** Niemand kennt alles. - -Jede Ebene kennt nur die nächste: - -- Root → .de, .com, .org -- .de → alle .de-Domains -- hdm-stuttgart.de → www, mail, … - - - ---- - - - - ![bg fit](./assets/demos/dns-lookup.png) +Ein DNS-Lookup hat mehrere Schritte: ---- +1. Browser fragt den **DNS-Resolver** (meist beim ISP konfiguriert, z.B. 1.1.1.1 von Cloudflare) +2. Resolver fragt einen der **Root-Server** (13 weltweit, .root) +3. Root antwortet: „kenne ich nicht, frag den .ch-TLD-Server" +4. Resolver fragt den **TLD-Server** für .ch +5. TLD antwortet: „kenne ich nicht, frag den autoritativen Server für librete.ch" +6. Resolver fragt den **autoritativen Nameserver** (oft beim Hoster) +7. Authoritative antwortet: „librete.ch ist 185.232.71.45" +8. Resolver liefert die IP zurück an den Browser -# 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. - - + +--- + + + + +![bg fit](./assets/demos/dns-tree.png) + + + +--- + + + +# HTTP — die Sprache des Webs + + + +--- + + + +# HTTP-Request — was geschickt wird + +```http +GET /index.html HTTP/1.1 +Host: librete.ch +User-Agent: Mozilla/5.0 (Macintosh; …) +Accept: text/html,application/xhtml+xml +Accept-Language: de-DE,en-US;q=0.9 +Connection: keep-alive +``` + +| Bestandteil | Was | +|-------------|-----| +| `GET` | **Method** — was tun wir | +| `/index.html` | **Path** — was wollen wir | +| `HTTP/1.1` | **Version** | +| `Host: …` | **Header** (mehrere möglich) | + + + +--- + + + +# HTTP-Response — was zurückkommt + +```http +HTTP/1.1 200 OK +Content-Type: text/html; charset=utf-8 +Content-Length: 1234 +Cache-Control: max-age=3600 +Server: nginx/1.24 + + +... +``` + +| Bestandteil | Was | +|-------------|-----| +| `200 OK` | **Statuscode + Message** | +| `Content-Type: …` | **Header** mit Meta-Information | +| (leere Zeile) | trennt Header von Body | +| ` + +--- + + + +# Statuscodes — die wichtigsten + +| Code | Name | Bedeutung | +|------|------|-----------| +| **200** | OK | alles gut, hier dein Inhalt | +| **301** | Moved Permanently | Seite ist umgezogen, hier neue URL | +| **302** | Found | temporäre Weiterleitung | +| **400** | Bad Request | deine Anfrage war kaputt | +| **401** | Unauthorized | du musst dich einloggen | +| **403** | Forbidden | eingeloggt aber nicht berechtigt | +| **404** | Not Found | gibt's nicht | +| **500** | Internal Server Error | Server hat Bug | +| **503** | Service Unavailable | Server überlastet / down | + + + +--- + +# HTTP/1.1 → HTTP/2 → HTTP/3 + +| Version | Jahr | Hauptverbesserung | +|---------|------|-------------------| +| HTTP/1.0 | 1996 | erste Spec | +| **HTTP/1.1** | 1997 | persistent connections (1 TCP für viele Requests) | +| **HTTP/2** | 2015 | multiplexing (parallele Streams im selben TCP) + Header-Komprimierung | +| **HTTP/3** | 2022 | basiert auf **QUIC** (UDP statt TCP), schnellere Handshakes | + +Heute: HTTP/2 dominant. HTTP/3 wächst stark, besonders bei Google, Cloudflare. + + --- - ![bg fit](./assets/demos/tcp-handshake.png) + +--- + + + +# Block F · URL → Pixel in 7 Schritten + +1. **URL parsen** — Schema, Host, Port, Path extrahieren +2. **DNS-Lookup** — Host-Name → IP-Adresse +3. **TCP-Handshake** mit Server-IP auf Port 443 +4. **TLS-Handshake** für https (Zertifikat prüfen) +5. **HTTP-Request** senden +6. Server antwortet mit **HTML, CSS, JS** (als Body) +7. Browser **parsed + rendert** — HTML-Baum + CSS-Regeln + JS-Ausführung → Pixel + + --- - -# 3-Way-Handshake – Vertiefung - -Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit. - -**Warum zufällige Startwerte (ISN)?** -- Sicherheit: Verhindert Session-Hijacking durch Raten -- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen -- ISN = Initial Sequence Number, vom OS zufällig gewählt - -**TCP-Flags im Handshake:** - -| Paket | Flags | Bedeutung | -|-------|-------|-----------| -| 1 | SYN | Client will Verbindung, sendet seine ISN | -| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 | -| 3 | ACK | Client bestätigt Server-ISN+1 | - -**Was passiert bei Problemen?** -- Kein SYN-ACK → Client wiederholt SYN (Timeout) -- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft -- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt) - -**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch. - ---- - -# Nach dem Handshake - -**Status:** Die TCP-Verbindung steht. - -![bg right:42% fit](./assets/demos/client-server-ports.png) - -**Jetzt erst** kann HTTP gesprochen werden. +![bg fit](./assets/demos/network-chain.png) --- -# Schritt 3: HTTP-Request -## "Gib mir die Startseite" +# Sub-Sektion B: CSS + A11y +## Wie wird HTML hübsch + barrierefrei? --- -# 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" - - - ---- - - - -# Encapsulation in Aktion -## Der Request wird verpackt - - - ---- - -# Layer 4: Transport (TCP) - -HTTP-Request wird zum **Segment**: - -![w:900 center](./assets/demos/tcp-segment.png) - -**Neu:** Ports + Sequenznummer - - - ---- - -# Layer 3: Network (IP) - -Segment wird zum **Paket**: - -![w:900 center](./assets/demos/ip-packet.png) - -**Neu:** IP-Adressen - - - ---- - -# Layer 2: Data Link (Ethernet) - -Paket wird zum **Frame**: - -![w:900 center](./assets/demos/ethernet-frame.png) - -**Wichtig:** Destination MAC = **Router**, nicht Server! - - - ---- - -# Woher kennt Ihr Laptop die Router-MAC? - -**ARP** – Address Resolution Protocol - -![w:900 center](./assets/demos/arp-lookup.png) - -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: - -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." - - - ---- - -# Der Router verpackt NEU - -![w:900 center](./assets/demos/ethernet-rehop.png) - -**IP bleibt gleich. MAC ändert sich.** - - - ---- - -# Mehrere Hops - -![bg right:35% fit](./assets/demos/hop-chain.png) - -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. - - - ---- - - - -# Die Ankunft -## Der Server empfängt und antwortet - - - ---- - -# Decapsulation am Server - -![bg right:42% fit](./assets/demos/server-decap.png) - -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 -HTTP/1.1 200 OK -Content-Type: text/html; charset=UTF-8 -Content-Length: 45231 - - - - - HdM Stuttgart -... -``` - -~45 KB HTML müssen jetzt zu Ihnen. - - - ---- - -# Encapsulation beim Server - -Der Server macht **dasselbe** – nur in die andere Richtung: - -![bg right:40% fit](./assets/demos/encap-stack.png) - - - ---- - -# Die Antwort reist zurück - -![bg right:38% fit](./assets/demos/response-hops.png) - -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 - -![bg right:42% fit](./assets/demos/decap-stack.png) - -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 und UDP sind beides Transport-Protokolle — TCP garantiert Vollständigkeit, UDP setzt auf Geschwindigkeit. - -| | TCP | UDP | -|---|-----|-----| -| **Verbindung** | Ja (Handshake) | Nein | -| **Reihenfolge** | Garantiert | Nicht garantiert | -| **Verlorene Pakete** | Werden nachgefordert | Gehen verloren | -| **Overhead** | Höher | Niedriger | -| **Use Cases** | Web, Email, Downloads | Video-Calls, Gaming, DNS | - - - ---- - - -# 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. +![bg fit](./assets/demos/css-anatomie.png) - ---- - -# 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 - -HTTP-Methoden beschreiben, **was** der Client mit einer Ressource tun will. - -| 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 -``` - - - ---- - - - - - -# 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 - -Jede HTTP-Response enthält einen dreistelligen Status-Code — die erste Ziffer verrät die Kategorie. - -```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) | - - - ---- - - - - - -# 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 - - - ---- - - - - - -# 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:** -```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 -``` - - - ---- - - - -# Teil 2: CSS -## Webseiten gestalten - - - ---- - -# Was ist CSS? - -![bg right:35%](./assets/demos/css-anatomie.png) - -**C**ascading **S**tyle **S**heets - -```css -p { - color: blue; - font-size: 16px; -} -``` - -- Trennt **Inhalt** (HTML) von **Darstellung** (CSS) -- "Cascading" = Regeln können überschrieben werden -- Eine CSS-Datei kann viele HTML-Seiten stylen - - - ---- - -# CSS einbinden - -**Option 1: Externe Datei** ✓ -```html - -``` - -**Option 2: Style-Tag** -```html - -``` - -**Option 3: Inline** ✗ -```html -

...

-``` - - - ---- - -# CSS-Anatomie +CSS-Anatomie: ```css selector { - property: value; + property: value; } ``` -**Beispiel:** +Beispiel: ```css -h1 { - color: #333333; - font-size: 2rem; - margin-bottom: 1rem; +button { + background-color: hotpink; + padding: 10px 20px; } ``` -Selektor → was wird gestylt -Property → welche Eigenschaft -Value → welcher Wert +`button` = Selektor (welche Elemente betroffen) +`background-color`, `padding` = Properties (welche Eigenschaft) +`hotpink`, `10px 20px` = Values (welcher Wert) - - ---- - -# Selektoren: Element - -![bg right:35%](./assets/demos/css-selector-element.png) - -```css -/* Alle

-Elemente */ -p { - color: gray; -} - -/* Mehrere Elemente gleichzeitig */ -h1, h2, h3 { - font-family: sans-serif; -} -``` - -Element-Selektoren sind die einfachsten. - - - ---- - -# Selektoren: Klasse - -![bg right:35%](./assets/demos/css-selector-class.png) - -```html -

Dieser Text ist wichtig.

-

Dieser nicht.

-``` - -```css -.wichtig { - color: red; - font-weight: bold; -} -``` - -**Punkt** vor dem Namen = Klasse - - --- - - - -# Selektoren: ID +# CSS-Selektoren -![bg right:35%](./assets/demos/css-selector-id.png) - -```html - -``` - -```css -#hauptnavigation { - background: #333; - padding: 1rem; -} -``` - -**Raute** vor dem Namen = ID - -⚠️ IDs sollten **einmalig** pro Seite sein. +| Selektor | Was | +|----------|-----| +| `p` | alle `

`-Elemente | +| `.btn` | alle Elemente mit `class="btn"` | +| `#header` | das Element mit `id="header"` (nur EINS pro Seite) | +| `*` | alle Elemente | +| `button:hover` | Button beim Hover | +| `button:focus` | Button mit Tastatur-Fokus | +| `input:disabled` | deaktivierte Inputs | +| `nav > a` | alle `` direkt unter `