Compare commits

...
Author SHA1 Message Date
libretech 4245ea2567 add essay questions across all blocks in 223015c
- A4: von-neumann komponenten (disabled)
- B7a: IP/MAC/Port vergleichen
- B13a: TCP vs UDP vergleichen
- C9a: status codes 2xx/4xx/5xx erklären
- C9b: HTTP-methoden vergleichen (disabled)
- D5: encapsulation erklären (disabled)
- E3: gesamtablauf DNS/TCP/HTTP
- H2a: einschränkungstypen erklären
2026-02-02 21:12:48 +01:00
libretech 51146d3dfc add more essay questions to 223015b (all disabled)
- J25: redundanz vs irrelevanz
- K12: rasterisierung vs vektorisierung
- L12: warum 8x8 blöcke bei JPEG
- N9: container vs codec transfer
2026-02-02 21:10:47 +01:00
libretech fda4aca4c7 add essay questions across all blocks in 223015b
- J23-J24: distribution comparison, analog vs digital
- K10-K11: image types, color depth (disabled)
- L10-L11: JPEG pipeline, artifacts (L11 disabled)
- M7-M8: image format comparison, GIF alternatives (M8 disabled)
- N7-N8: frame types, video codec comparison (N8 disabled)
- O14-O15: storage tech comparison, backup strategies (O15 disabled)
2026-02-02 20:51:46 +01:00
libretech aff352fa91 add questions for analog/digital media and storage types in 223015b
- J15-J22: analog/digital media, distribution methods, generationsverlust
- O9-O13: storage media categories, cloud, LTO
- some questions disabled for later use
2026-02-02 20:38:48 +01:00
libretech ea7e905c61 split klausurfragen into per-course files and add erklaerung slides to 223015c
- split slides/klausurfragen.md into course-specific files:
  - slides/223015b/klausurfragen.md (blocks J-O: dateiformate)
  - slides/223015c/klausurfragen.md (blocks A-I: it-grundlagen)
- add erklaerung slides to 223015c (16 new vertiefung slides)
- update erklaerung slides in 223015b with deeper content
- update makefile to build klausurfragen per-course
- remove global klausurfragen from root index
2026-02-02 19:06:37 +01:00
libretech 512fbd9d3d add erklaerung slides to 223015b course files
- add erklaerung css class and 6 explanation slides to 01-grundlagen-text-audio.md
- add erklaerung css class and 9 explanation slides to 02-bild-audio-video.md
- add erklaerung css class and 2 explanation slides to 03-speichermedien-schnittstellen.md
- regenerate klausurfolien.md with updated content
2026-02-02 14:25:04 +01:00
9 changed files with 4387 additions and 909 deletions

No files matched your search

+5 -23
View File
@@ -1,7 +1,7 @@
# HdM Slides - Unified Makefile
# Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images klausurfragen build-klausurfragen deploy-klausurfragen
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images
# Course configuration
COURSES = 223015b 223015c
@@ -9,11 +9,11 @@ SLIDES_DIR = slides
# Course-specific settings
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
223015c_NAME = Internettechnologien
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
DEPLOY_HOST = tengo@tuttle.uberspace.de
@@ -85,18 +85,7 @@ build-b: build/.exists
build-c: build/.exists
$(call build_course,223015c)
build-klausurfragen: build/.exists
@echo "Building klausurfragen..."
@mkdir -p build
@if [ -f "$(SLIDES_DIR)/klausurfragen.md" ]; then \
echo " Building klausurfragen.md..."; \
npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" -o build/klausurfragen.html; \
npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" --pdf --allow-local-files -o build/klausurfragen.pdf; \
else \
echo " Skipping: $(SLIDES_DIR)/klausurfragen.md not found"; \
fi
build: build-b build-c build-klausurfragen
build: build-b build-c
@echo "All courses built!"
# HTML only builds
@@ -210,20 +199,13 @@ deploy-b: build-b
deploy-c: build-c
$(call deploy_course,223015c)
# Deploy klausurfragen (root-level page)
deploy-klausurfragen: build-klausurfragen
@echo "Deploying klausurfragen..."
@scp build/klausurfragen.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
@scp build/klausurfragen.pdf $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
@echo "klausurfragen deployed!"
deploy-index: build-index
@echo "Deploying root index..."
scp build/index.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/
scp build/qr-root.svg $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
@echo "Root index deployed!"
deploy: build-index deploy-b deploy-c deploy-klausurfragen deploy-index
deploy: build-index deploy-b deploy-c deploy-index
@echo "All courses deployed!"
# Clean
File diff suppressed because it is too large. Load diff
+249 -1
View File
@@ -68,6 +68,38 @@ section.aufgabe {
section.aufgabe footer {
display: none;
}
section.erklaerung {
font-size: 1.1rem;
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.erklaerung {
background: #e3f2fd !important;
}
}
section.erklaerung h1 {
font-size: 1.5rem;
color: #1e5f8a;
margin-bottom: 0.3rem;
}
section.erklaerung ul,
section.erklaerung ol {
font-size: 1.0rem;
line-height: 1.4;
}
section.erklaerung p {
font-size: 1.0rem;
line-height: 1.4;
}
section.erklaerung table {
font-size: 0.9rem;
}
</style>
<!-- _class: invert -->
@@ -220,6 +252,26 @@ KLAUSURRELEVANT:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Rastergrafik – Vertiefung
Ein Pixel ist die kleinste adressierbare Einheit. Bei 24-Bit-Farbtiefe speichert jeder Pixel drei 8-Bit-Werte (0–255) für Rot, Grün und Blau. Diese additive Farbmischung erzeugt 256³ = 16,7 Millionen mögliche Farbtöne.
**Speicherberechnung:** `Breite × Höhe × Bytes pro Pixel`
| Auflösung | Farbtiefe | Berechnung | Größe |
|-----------|-----------|------------|-------|
| 1920×1080 | 24 Bit (3 B) | 2.073.600 × 3 | 6,2 MB |
| 4K (3840×2160) | 24 Bit | 8.294.400 × 3 | 24,9 MB |
| 4K | 32 Bit (4 B) | 8.294.400 × 4 | 33,2 MB |
Der Alpha-Kanal (32 Bit) speichert Transparenz als Wert von 0 (unsichtbar) bis 255 (vollständig sichtbar). PNG nutzt dies für weiche Kanten; JPEG unterstützt keinen Alpha-Kanal.
---
# Das Problem der Skalierung
**Vergrößern:**
@@ -274,6 +326,30 @@ KLAUSURRELEVANT:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Vektorgrafik – Vertiefung
Vektorgrafiken speichern keine Pixel, sondern mathematische Beschreibungen: Koordinaten, Kurvenparameter (Bézier-Kontrollpunkte), Füllfarben, Strichstärken. Der Renderer berechnet die Pixel erst bei der Ausgabe – daher beliebig skalierbar.
**Bézier-Kurven** (Pierre Bézier, 1962, für Renault-Karosserien entwickelt):
- Definiert durch Ankerpunkte und Kontrollpunkte
- Kubische Bézier: 2 Anker + 2 Kontrollpunkte
- Mathematisch exakt reproduzierbar
| Aspekt | Raster | Vektor |
|--------|--------|--------|
| Skalierung 10× | Pixel sichtbar | Perfekt scharf |
| Foto-Realismus | Gut geeignet | Unpraktikabel |
| Dateigröße Logo | Wächst mit Auflösung | Konstant (~5 KB) |
| Editierbarkeit | Destruktiv | Nicht-destruktiv |
**Rasterisierung:** GPU wandelt Vektordaten in Pixel um. Geschieht bei jeder Darstellung neu – deshalb ist ein 4K-Monitor schärfer als ein 1080p-Monitor bei gleichem SVG.
---
# Raster- und Vektorgrafiken
| | Raster | Vektor |
@@ -338,6 +414,28 @@ KLAUSURRELEVANT:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Psychovisuelle Wahrnehmung – Vertiefung
Die Netzhaut enthält ~120 Mio. Stäbchen (Helligkeitswahrnehmung) aber nur ~6 Mio. Zapfen (Farbwahrnehmung). Dieses 20:1-Verhältnis erklärt, warum JPEG Farbinformationen stärker reduzieren kann als Helligkeitsinformationen.
**Räumliche Frequenz** beschreibt, wie schnell sich die Helligkeit über eine Bildfläche ändert:
- **Niedrig:** Himmel, Wand – große einheitliche Flächen
- **Hoch:** Haare, Texturen, Schrift – schnelle Wechsel
Das Auge ist ein Tiefpassfilter: Hohe Frequenzen (feine Details) werden schwächer wahrgenommen. JPEG verwirft daher zuerst die hohen Frequenzen – der Qualitätsverlust bleibt meist unsichtbar.
| Biologisches Limit | Ausnutzung in JPEG |
|-------------------|-------------------|
| Farbauflösung ~20× geringer | Chroma Subsampling (4:2:0) |
| Hohe Frequenzen unscharf | DCT + Quantisierung |
| Kontrast-Maskierung | Artefakte in Texturen versteckt |
---
<!-- _header: '' -->
<!-- _footer: '' -->
@@ -442,6 +540,34 @@ KLAUSURRELEVANT:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Farbraumkonversion – Vertiefung
RGB→YCbCr nutzt die Biologie des menschlichen Auges: 120 Mio. Stäbchen (Helligkeit) vs. nur 6 Mio. Zapfen (Farbe) – ein 20:1-Verhältnis. Die Transformation erfolgt über eine lineare Matrix:
```
Y = 0.299·R + 0.587·G + 0.114·B
Cb = −0.169·R − 0.331·G + 0.500·B + 128
Cr = 0.500·R − 0.419·G − 0.081·B + 128
```
Die Gewichtung (G dominiert mit 59%) entspricht der spektralen Empfindlichkeit des Auges bei Tageslicht. Y enthält alle Schärfeinformation; Cb/Cr können reduziert werden.
**Chroma Subsampling – Notation J:a:b** (bezogen auf 4×2 Pixel):
| Schema | Farbdaten | Einsatz |
|--------|-----------|---------|
| 4:4:4 | 100% | Postproduktion, Grafik |
| 4:2:2 | 50% | Broadcast, Pro-Video |
| 4:2:0 | 25% | JPEG, H.264, Streaming |
Bei 4:2:0 teilen sich 4 Pixel einen Farbwert, behalten aber individuelle Helligkeit → 50% Dateneinsparung bei kaum sichtbarem Unterschied.
---
# JPEG Schritt 2: Chroma Subsampling
**Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block):
@@ -623,12 +749,36 @@ KLAUSURRELEVANT:
- Präfix-frei: Kein Code ist Anfang eines anderen
- Häufigstes Zeichen = kürzester Code
- Auch in ZIP, PNG, MP3 verwendet
-->
---
-->
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Huffman-Coding – Vertiefung
David Huffman entwickelte 1952 als Student am MIT einen optimalen Algorithmus für präfixfreie Codes – ursprünglich als Hausaufgabe, die zur Veröffentlichung führte.
**Algorithmus (Bottom-Up-Baumkonstruktion):**
1. Alle Symbole nach Häufigkeit sortieren
2. Die zwei seltensten Symbole zu einem Knoten kombinieren
3. Wiederholen bis nur noch die Wurzel übrig ist
4. Codes ablesen: links = 0, rechts = 1
**Präfixfreiheit:** Kein Code ist Anfang eines anderen → sofort dekodierbar ohne Trennzeichen.
| Eigenschaft | Huffman | Arithmetisch |
|-------------|---------|--------------|
| Einheit | Ganze Bits | Fraktionale Bits |
| Optimalität | Optimal für ganze Bits | Näher an Entropie |
| Geschwindigkeit | Schneller | Langsamer |
| JPEG-Einsatz | Standard (Baseline) | Optional (selten) |
JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittswerte), eine für AC-Koeffizienten (Frequenzen). Die Tabellen sind im JPEG-Header gespeichert.
---
<!-- _class: klausur -->
<!-- _header: '' -->
@@ -772,6 +922,28 @@ KLAUSURRELEVANT:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# WebP & AVIF – Vertiefung
**WebP** entstand 2010 aus Googles VP8-Videocodec (On2 Technologies, für $133M gekauft). Statt I-Frames für Video werden sie als Einzelbilder verwendet. WebP nutzt Intra-Frame-Prediction, die benachbarte Blöcke zur Vorhersage verwendet – effizienter als JPEGs blockweise DCT.
**AVIF** basiert auf dem AV1-Videocodec, entwickelt 2015–2018 von der Alliance for Open Media (Google, Apple, Netflix, Amazon, Microsoft, Mozilla). Nach dem Patent-Chaos von H.265/HEVC vereinten sich die Konkurrenten für einen lizenzfreien Standard.
| Aspekt | WebP | AVIF |
|--------|------|------|
| Basis-Codec | VP8/VP9 | AV1 |
| Kompression vs. JPEG | 25–35% besser | 50% besser |
| HDR/Wide Gamut | Nein | Ja (10/12 Bit) |
| Encoding-Geschwindigkeit | Schnell | Sehr langsam |
| Browser-Support 2025 | 97%+ | 93%+ |
**Warum JPEG dominiert:** Kameras, Bildbearbeitungssoftware und Content-Management-Systeme sind auf JPEG optimiert. Der Wechsel erfordert Infrastruktur-Updates über die gesamte Pipeline.
---
# Formatwahl in der Praxis
| Anwendung | Format |
@@ -890,6 +1062,33 @@ KLAUSURRELEVANT:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Container vs. Codec – Vertiefung
**Container** (Multiplexer-Format) organisiert mehrere Datenströme mit Timing-Informationen. Er enthält keine Kompressionslogik, sondern synchronisiert Video, Audio, Untertitel und Metadaten.
**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.
| Container | Entwickler | Typische Codecs | Besonderheit |
|-----------|------------|-----------------|--------------|
| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig |
| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel |
| WebM | Google | VP9, AV1, Opus | HTML5-optimiert, lizenzfrei |
| MOV | Apple | ProRes, H.264 | Professionelle Produktion |
**Metadaten im Container:**
- Timecodes für Frame-genaue Synchronisation
- Kapitelmarken, Thumbnails
- Sprach-Tags für Audio/Untertitel
- HDR-Metadaten (MaxCLL, MaxFALL)
**Praktisches Problem:** Eine `.mp4`-Datei mit AV1-Codec spielt auf älteren Geräten nicht ab, obwohl sie MP4 „unterstützen" – der Hardware-Decoder fehlt für AV1.
---
# Gängige Container
| Container | Verwendung |
@@ -1115,6 +1314,32 @@ KLAUSURRELEVANT:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# H.264/AVC – Vertiefung
H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-ray. Vor H.264 war MPEG-2 Standard – H.264 erreichte bei gleicher Qualität die halbe Bitrate.
**Technische Innovationen:**
- **Variable Blockgrößen:** 16×16 bis 4×4 Macroblocks (MPEG-2: nur 16×16)
- **Intra-Prediction:** Blöcke werden aus Nachbarn vorhergesagt
- **In-Loop Deblocking:** Filter reduziert Blockartefakte vor der Referenzierung
- **CABAC:** Arithmetic Coding ersetzt Huffman (10–15% effizienter)
| Profile | Anwendung | Max. Auflösung |
|---------|-----------|----------------|
| Baseline | Videotelefonie, ältere Geräte | 480p |
| Main | Broadcast, Streaming | 1080p |
| High | Blu-ray, professionell | 4K |
**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.
**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzer-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.
---
# Das Patent-Problem
**H.264 ist nicht frei**
@@ -1221,6 +1446,29 @@ KLAUSURRELEVANT:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# AV1 – Vertiefung
Die **Alliance for Open Media** (2015) vereinte Konkurrenten nach dem Patent-Chaos von H.265/HEVC. Drei separate Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) machten H.265-Lizenzierung unberechenbar – die Industrie wollte einen garantiert lizenzfreien Standard.
**Gründungsmitglieder:** Google, Mozilla, Cisco, Netflix, Amazon, Microsoft. Apple trat 2018 bei – historisch, da Apple sonst eigene Standards bevorzugt.
| Technische Innovation | Beschreibung |
|----------------------|--------------|
| Superblocks | Bis 128×128 Pixel (H.264: max 16×16) |
| Prediction Modes | 56 Intra-Modi (H.264: 9) |
| Transform | 10 verschiedene Transformtypen |
| Film Grain Synthesis | Filmkorn wird als Parameter übertragen |
**Encoding-Performance:** Software-Encoding ist 50–200× langsamer als H.264. Erst Hardware-Encoder (Intel ab Gen 12, NVIDIA RTX 40, Apple M3) machen Echtzeit-Encoding praktikabel.
**Adoption 2025:** YouTube und Netflix nutzen AV1 für 4K/8K-Streams. 2024 gewann AV1 einen Emmy für technische Innovation – offene Standards können Industriestandard werden.
---
<!-- _header: '' -->
<!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
@@ -68,6 +68,38 @@ section.aufgabe {
section.aufgabe footer {
display: none;
}
section.erklaerung {
font-size: 1.1rem;
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.erklaerung {
background: #e3f2fd !important;
}
}
section.erklaerung h1 {
font-size: 1.5rem;
color: #1e5f8a;
margin-bottom: 0.3rem;
}
section.erklaerung ul,
section.erklaerung ol {
font-size: 1.0rem;
line-height: 1.4;
}
section.erklaerung p {
font-size: 1.0rem;
line-height: 1.4;
}
section.erklaerung table {
font-size: 0.9rem;
}
</style>
<!-- _class: invert -->
@@ -235,6 +267,29 @@ Kleine SSD für System + große HDD für Archiv.
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# HDD vs. SSD – Vertiefung
**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
| Aspekt | HDD | SATA SSD | NVMe SSD |
|--------|-----|----------|----------|
| Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
| IOPS (4K random) | 100 | 90.000 | 1.000.000 |
| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
---
<!-- _class: lead -->
# Dateisysteme
@@ -484,6 +539,30 @@ Warum 1 Offsite?
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# 3-2-1-Backup-Regel – Vertiefung
Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
| Bedrohung | Schutz durch | Beispiel |
|-----------|--------------|----------|
| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
**Moderne Erweiterung 3-2-1-1-0:**
- **+1** Air-Gapped (offline, nicht verbunden)
- **+0** Verifizierte Backups (regelmäßig Restore testen)
**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
---
# Backup-Arten
**Vollständig (Full):**
+161
View File
@@ -102,6 +102,166 @@ Hochschule der Medien Stuttgart
<!-- _footer: "" -->
# Verlustfrei vs. Verlustbehaftet
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|---|---|---|
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
| **Reduktion** | 30-50% | 80-99% |
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
**Faustregel:**
- Medien für Endnutzer → Lossy oft akzeptabel
- Quellmaterial, Code, Archive → Lossless nötig
<!--
REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
KLAUSURRELEVANT:
- Verlustfrei = Original 1:1 wiederherstellbar
- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
- Redundanz vs. Irrelevanz ist der Kernunterschied!
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Dateneinheiten
| Einheit | Bytes | Potenz | Beispiel |
|---------|------:|:------:|----------|
| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
<!--
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
1 TB Festplatte = ~931 GiB nutzbar
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Der digitale Wendepunkt
| Jahr | Analog | Digital | Digital-Anteil |
|------|--------|---------|----------------|
| **1986** | 2,6 EB | 0,02 EB | **1%** |
| **2002** | — | — | **50%** (Wendepunkt) |
| **2007** | 18 EB | 277 EB | **94%** |
**Perspektive:**
- 1986: "Petabyte" war ein theoretisches Konzept
- 2025: ~181 Zettabyte jährlich produziert
**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
(AWS Glacier, Film-Archive, Rechenzentren)
<!--
PRÜFUNGSRELEVANT:
- Wendepunkt 2002
- Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
- Magnetband als Archivmedium
QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Analoge Medien
### Distribution: physisch (Kauf, Verleih, Kopie)
- **Text**
- Bücher, Zeitungen, Zeitschriften, Lochkarten
- **Bild**
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
- **Audio:**
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
- **Video:**
- Film (35mm, Super 8), VHS, Betamax
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Digitale Medien
### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
- **Text**
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
- **Bild**
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
- **Audio**
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
- **Video**
- Videodatei (MP4, MKV, AVI, WebM)
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Digitale Speichermedien
- **Optische Speicher**
- CD, DVD, Blu-ray
- **Magnetische Speicher**
- Festplatte (HDD), Magnetband (LTO)
- **Flash-Speicher**
- SSD, USB-Stick, SD-Karte
- **Cloud-Speicher**
- Dropbox, Google Drive, iCloud, AWS S3
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Rastergrafiken
**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
@@ -243,6 +403,7 @@ KLAUSURRELEVANT:
- Präfix-frei: Kein Code ist Anfang eines anderen
- Häufigstes Zeichen = kürzester Code
- Auch in ZIP, PNG, MP3 verwendet
-->
---
File diff suppressed because it is too large. Load diff
@@ -68,6 +68,38 @@ section.aufgabe {
section.aufgabe footer {
display: none;
}
section.erklaerung {
font-size: 1.1rem;
background: repeating-linear-gradient(
135deg,
#fce4ec,
#fce4ec 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.erklaerung {
background: #fce4ec !important;
}
}
section.erklaerung h1 {
font-size: 1.5rem;
color: #a02060;
margin-bottom: 0.3rem;
}
section.erklaerung ul,
section.erklaerung ol {
font-size: 1.0rem;
line-height: 1.4;
}
section.erklaerung p {
font-size: 1.0rem;
line-height: 1.4;
}
section.erklaerung table {
font-size: 0.9rem;
}
</style>
<!-- _class: invert -->
@@ -652,6 +684,28 @@ PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Von-Neumann-Architektur – Vertiefung
John von Neumann beschrieb 1945 im „First Draft of a Report on the EDVAC" das Prinzip des **Stored Program Computer**: Programme und Daten teilen sich denselben Speicher und sind damit austauschbar, ohne Hardware-Änderungen.
**Die 5 Komponenten im Detail:**
| Komponente | Moderne Entsprechung | Funktion |
|------------|---------------------|----------|
| Rechenwerk (ALU) | CPU-Kern | Addition, Subtraktion, Logik (AND, OR, NOT) |
| Steuerwerk | CPU-Kern | Fetch-Decode-Execute-Zyklus |
| Speicherwerk | RAM + ROM | Einheitlicher Adressraum für Code + Daten |
| Ein-/Ausgabe | I/O-Controller | USB, PCIe, Netzwerk |
| Bus-System | Northbridge/Southbridge (heute: SoC) | Adress-, Daten-, Steuerbus |
**Von-Neumann-Flaschenhals:** CPU und Speicher teilen einen Bus – die Bandbreite begrenzt die Geschwindigkeit. Moderne CPUs umgehen dies durch Caches (L1/L2/L3), die als Harvard-ähnliche Puffer dienen.
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
@@ -689,6 +743,33 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Stored Program Concept – Vertiefung
Vor Von Neumann mussten Computer für jedes Problem neu verkabelt werden (ENIAC: tagelange Arbeit). Das **Stored Program Concept** machte Programme zu Daten – austauschbar wie Dokumente.
**Konsequenzen für die Software-Industrie:**
- **Betriebssysteme** möglich: Laden verschiedene Programme aus demselben Speicher
- **Updates** ohne Hardware-Austausch: Nur Bits ändern, nicht Kabel
- **Multitasking**: Mehrere Programme gleichzeitig im Speicher
- **Self-Modifying Code**: Programme können sich selbst ändern (Compiler, JIT)
**Harvard-Architektur (Alternative):**
| Aspekt | Von Neumann | Harvard |
|--------|-------------|---------|
| Speicher | Gemeinsam für Code + Daten | Getrennt |
| Busse | Ein Bus (Flaschenhals) | Paralleler Zugriff |
| Flexibilität | Hoch (Code = Daten) | Geringer |
| Einsatz | Desktop, Server, Smartphone | DSP, Mikrocontroller |
**Modern:** „Modified Harvard" – L1-Cache trennt Code/Daten (Speed), RAM bleibt gemeinsam (Flexibilität).
---
<!-- _class: lead -->
# Vom Militär zum Netz
@@ -1117,6 +1198,34 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# HTML Metadaten – Vertiefung
Der `<head>`-Bereich enthält Informationen *über* das Dokument, nicht den sichtbaren Inhalt. Diese Metadaten steuern Browser-Verhalten, Suchmaschinen-Indexierung und Social-Media-Vorschauen.
**Kritische Meta-Tags:**
| Tag | Funktion | Beispiel |
|-----|----------|----------|
| `<title>` | Browser-Tab, Suchergebnis-Titel | `<title>HdM Stuttgart</title>` |
| `<meta charset>` | Zeichenkodierung (Umlaute!) | `<meta charset="UTF-8">` |
| `<meta viewport>` | Mobile Darstellung | `width=device-width, initial-scale=1` |
| `<meta description>` | Suchergebnis-Snippet (max 160 Zeichen) | SEO-kritisch |
**Open Graph Protocol (Facebook, 2010):**
```html
<meta property="og:title" content="Artikel-Titel">
<meta property="og:image" content="https://example.com/preview.jpg">
```
Steuert die Vorschau beim Teilen auf Facebook, LinkedIn, WhatsApp, Slack.
**SEO-Relevanz:** Google nutzt `<title>` und `<meta description>` für Ranking und Snippet-Anzeige. Fehlende Metadaten = schlechtere Auffindbarkeit.
---
# HTML-Tags und Attribute
```html
@@ -1340,6 +1449,33 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Web-Zugänglichkeit – Vertiefung
**a11y** = Accessibility (a + 11 Buchstaben + y). Die WHO schätzt, dass 15% der Weltbevölkerung eine Behinderung haben – das sind über 1 Milliarde potenzielle Nutzer.
**Arten von Einschränkungen:**
| Typ | Permanent | Temporär | Situativ |
|-----|-----------|----------|----------|
| Visuell | Blindheit | Nach Augen-OP | Grelle Sonne |
| Motorisch | Amputation | Gebrochener Arm | Baby auf dem Arm |
| Auditiv | Taubheit | Ohrenentzündung | Laute Umgebung |
| Kognitiv | Legasthenie | Müdigkeit | Ablenkung |
**Assistive Technologien:**
- **Screenreader:** NVDA (Windows, kostenlos), VoiceOver (Apple, integriert), JAWS (kommerziell)
- **Braillezeilen:** Taktile Ausgabe, ~40–80 Zeichen
- **Switch-Geräte:** Ein-Knopf-Steuerung für motorische Einschränkungen
- **Eye-Tracking:** Blicksteuerung für Bewegungsunfähige
Screenreader lesen den DOM sequenziell – semantisches HTML (`<nav>`, `<main>`, `<button>`) ermöglicht Navigation per Tastenkürzel.
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
@@ -1379,6 +1515,35 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Rechtliche Anforderungen – Vertiefung
Der **European Accessibility Act (EAA)** trat am 28. Juni 2025 in Kraft und betrifft erstmals auch private Unternehmen – nicht nur öffentliche Stellen.
**Betroffene Sektoren:**
- E-Commerce (Online-Shops)
- Bankdienstleistungen
- Telekommunikation
- E-Books und E-Reader
- Ticketing und Check-in-Terminals
**WCAG 2.2 – Konformitätsstufen:**
| Level | Anforderung | Beispiel |
|-------|-------------|----------|
| A | Minimum | Alt-Texte für Bilder |
| AA | Gesetzlicher Standard | Kontrast 4,5:1, Tastaturnavigation |
| AAA | Optimal | Gebärdensprache für Videos |
**Curb-Cut-Effekt:** Barrierefreiheit hilft allen. Bordsteinabsenkungen für Rollstühle nutzen auch Kinderwagen, Rollkoffer, Fahrräder. Untertitel helfen Gehörlosen, aber auch in lauten Umgebungen oder beim Sprachlernen.
**Sanktionen:** Bis zu 100.000 € Bußgeld bei Verstößen.
---
# WCAG: Der Standard
**W**eb **C**ontent **A**ccessibility **G**uidelines
@@ -1532,6 +1697,38 @@ Echte NutzerInnen einbeziehen = Gold-Standard
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Barrierefreiheit testen – Vertiefung
Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erfordert manuelles Testen und idealerweise echte Nutzer mit Behinderungen.
**Tastatur-Test (5 Minuten, jeder kann's):**
1. Maus weglegen, nur Tab + Enter + Pfeiltasten nutzen
2. Fokus-Indikator immer sichtbar? (kein `outline: none;`!)
3. Logische Reihenfolge? (nicht kreuz und quer)
4. Alle interaktiven Elemente erreichbar?
**Automatisierte Tools:**
| Tool | Typ | Findet |
|------|-----|--------|
| axe DevTools | Browser-Extension | ~30% der WCAG-Verstöße |
| WAVE | Browser-Extension | Struktur-Probleme, Kontrast |
| Lighthouse | Chrome DevTools | Performance + Accessibility |
| Pa11y | CLI | CI/CD-Integration |
**Screenreader-Kurztest:**
- macOS: `Cmd + F5` (VoiceOver)
- Windows: NVDA installieren (kostenlos)
- Augen schließen, nur zuhören: Ist die Seite verständlich?
**Gold-Standard:** Usability-Tests mit Menschen, die Assistive Technologien täglich nutzen.
---
<!-- _class: lead -->
@@ -71,6 +71,38 @@ section.aufgabe footer {
section.glossar {
font-size: 1.4rem;
}
section.erklaerung {
font-size: 1.1rem;
background: repeating-linear-gradient(
135deg,
#fce4ec,
#fce4ec 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.erklaerung {
background: #fce4ec !important;
}
}
section.erklaerung h1 {
font-size: 1.5rem;
color: #a02060;
margin-bottom: 0.3rem;
}
section.erklaerung ul,
section.erklaerung ol {
font-size: 1.0rem;
line-height: 1.4;
}
section.erklaerung p {
font-size: 1.0rem;
line-height: 1.4;
}
section.erklaerung table {
font-size: 0.9rem;
}
</style>
<!-- _class: invert -->
@@ -402,6 +434,31 @@ SPEAKER NOTES:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# TCP/IP-Modell – Vertiefung
Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
**Schicht-Aufgaben im Detail:**
| Schicht | Frage | Protokolle | Geräte |
|---------|-------|------------|--------|
| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
**OSI vs. TCP/IP:**
- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
---
# Schichten verpacken Daten
```
@@ -461,6 +518,33 @@ SPEAKER NOTES:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Dateneinheiten & Encapsulation – Vertiefung
**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
**Was jeder Header enthält:**
| Schicht | Einheit | Header-Inhalte |
|---------|---------|----------------|
| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
**Overhead-Rechnung (1 Byte HTTP-Body):**
- Ethernet: 14 + 4 Bytes (Header + Trailer)
- IP: 20 Bytes (ohne Optionen)
- TCP: 20 Bytes (ohne Optionen)
- **Minimum: 58 Bytes für 1 Byte Nutzlast**
**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
---
# Warum ist das clever?
**Ohne Schichten:**
@@ -640,6 +724,34 @@ SPEAKER NOTES:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# IP, MAC, Port – Vertiefung
Drei Adressebenen lösen drei verschiedene Probleme:
**IP-Adresse (Schicht 2 – Internet):**
- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
**MAC-Adresse (Schicht 1 – Netzzugang):**
- 48 Bit, vom Hersteller fest vergeben (theoretisch)
- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
- ARP (Address Resolution Protocol) übersetzt IP → MAC
**Port (Schicht 3 – Transport):**
- 16 Bit → 65.535 mögliche Ports
- Well-Known Ports (0–1023): HTTP=80, HTTPS=443, SSH=22
- Ephemeral Ports (49152–65535): Dynamisch für Client-Verbindungen
**Warum ändert sich nur MAC?** IP ist das Endziel (Brief-Adresse), MAC ist der aktuelle Bote (wer trägt den Brief gerade?).
---
<!-- _class: lead -->
# Die Reise eines Klicks
@@ -922,6 +1034,36 @@ SPEAKER NOTES:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# 3-Way-Handshake – Vertiefung
Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
**Warum zufällige Startwerte (ISN)?**
- Sicherheit: Verhindert Session-Hijacking durch Raten
- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
- ISN = Initial Sequence Number, vom OS zufällig gewählt
**TCP-Flags im Handshake:**
| Paket | Flags | Bedeutung |
|-------|-------|-----------|
| 1 | SYN | Client will Verbindung, sendet seine ISN |
| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 |
| 3 | ACK | Client bestätigt Server-ISN+1 |
**Was passiert bei Problemen?**
- Kein SYN-ACK → Client wiederholt SYN (Timeout)
- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft
- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt)
**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch.
---
# Nach dem Handshake
**Status:** Die TCP-Verbindung steht.
@@ -1429,6 +1571,38 @@ SPEAKER NOTES:
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# TCP vs. UDP – Vertiefung
Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
**TCP (Transmission Control Protocol):**
- Verbindungsorientiert (Handshake vor Daten)
- Sequenznummern → Reihenfolge garantiert
- ACKs + Retransmission → Kein Datenverlust
- Flow Control (Sliding Window) → Empfänger nicht überlasten
- Congestion Control → Netzwerk nicht überlasten
**UDP (User Datagram Protocol):**
- Verbindungslos (Fire-and-Forget)
- Keine Sequenznummern, keine ACKs
- Header nur 8 Bytes (TCP: 20+ Bytes)
- Anwendung muss selbst für Zuverlässigkeit sorgen
| Anwendung | Protokoll | Grund |
|-----------|-----------|-------|
| HTTP/HTTPS | TCP | Vollständigkeit kritisch |
| DNS | UDP | Kleine Pakete, schnelle Antwort |
| Video-Streaming | UDP/QUIC | Latenz wichtiger als Perfektion |
| Online-Gaming | UDP | Echtzeit, veraltete Daten nutzlos |
**QUIC:** Googles Protokoll kombiniert UDP-Geschwindigkeit mit TCP-ähnlicher Zuverlässigkeit (HTTP/3).
---
# Warum UDP bei Video-Calls?
**Szenario:** Ein Paket geht verloren.
@@ -1508,6 +1682,37 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# HTTP-Methoden – Vertiefung
HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
**CRUD-Mapping (Create, Read, Update, Delete):**
| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
|---------|------|------------|------|-------------------|
| GET | Read | Ja | Ja | Ressource abrufen |
| POST | Create | Nein | Nein | Formular, neue Ressource |
| PUT | Update | Ja | Nein | Ressource vollständig ersetzen |
| PATCH | Update | Nein | Nein | Ressource teilweise ändern |
| DELETE | Delete | Ja | Nein | Ressource löschen |
**Idempotent:** Mehrfaches Ausführen hat denselben Effekt wie einmaliges (GET, PUT, DELETE).
**Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
```
GET /users/42 → Benutzer 42 abrufen
PUT /users/42 → Benutzer 42 vollständig ersetzen
DELETE /users/42 → Benutzer 42 löschen
POST /users → Neuen Benutzer erstellen
```
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
@@ -1543,6 +1748,31 @@ Status-Codes sagen euch, was passiert ist.
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# HTTP Status-Codes – Vertiefung
Die erste Ziffer kategorisiert die Antwort:
| Bereich | Kategorie | Häufige Codes |
|---------|-----------|---------------|
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
**Wichtige Unterscheidungen:**
- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
@@ -1579,6 +1809,40 @@ Wie Encapsulation funktioniert.
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Netzwerk-Grundlagen – Vertiefung
Die vier Kernkonzepte für Web-Entwickler:
**1. DNS-Auflösung:**
- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
- Rekursive Abfrage: Root → TLD → Authoritative
- Caching auf jeder Ebene (TTL = Time To Live)
**2. TCP-Verbindungsaufbau:**
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
- Keep-Alive: Verbindung bleibt offen für mehrere Requests
- HTTP/2: Multiplexing – viele Requests über eine Verbindung
**3. HTTP Request/Response:**
```
Request: Methode + URL + Header + (Body)
Response: Status + Header + Body
```
**4. Schichten & Adressen:**
| Was bleibt gleich? | Was ändert sich? |
|-------------------|------------------|
| Ziel-IP | MAC-Adressen (bei jedem Hop) |
| Ports | – |
**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
---
# Werkzeuge zum Selbst-Erkunden
**Im Browser (F12 → Network-Tab):**
@@ -1870,6 +2134,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# CSS Spezifität – Vertiefung
Spezifität bestimmt, welche CSS-Regel gewinnt, wenn mehrere auf dasselbe Element zutreffen. Sie wird als 4-stellige Zahl berechnet: **(Inline, IDs, Klassen, Elemente)**.
**Berechnung:**
| Selektor | Inline | IDs | Klassen | Elemente | Gesamt |
|----------|--------|-----|---------|----------|--------|
| `p` | 0 | 0 | 0 | 1 | 0,0,0,1 |
| `.info` | 0 | 0 | 1 | 0 | 0,0,1,0 |
| `p.info` | 0 | 0 | 1 | 1 | 0,0,1,1 |
| `#header` | 0 | 1 | 0 | 0 | 0,1,0,0 |
| `#header .nav a` | 0 | 1 | 1 | 1 | 0,1,1,1 |
**Wichtige Regeln:**
- Eine Klasse (0,0,1,0) schlägt **jede Anzahl** von Elementen (0,0,0,99)
- Eine ID schlägt jede Anzahl von Klassen
- `!important` bricht alles → vermeiden, da schwer zu überschreiben
**Best Practice:** Flache Spezifität anstreben. BEM-Methodik (`.block__element--modifier`) hält Spezifität gleichmäßig niedrig.
---
# Box-Modell
```
@@ -2117,6 +2408,37 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
---
<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->
# Responsive Design – Vertiefung
**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
**Breakpoints (gängige Werte):**
| Breakpoint | Gerät | Media Query |
|------------|-------|-------------|
| < 576px | Smartphone (Portrait) | Basis (kein Query) |
| ≥ 576px | Smartphone (Landscape) | `@media (min-width: 576px)` |
| ≥ 768px | Tablet | `@media (min-width: 768px)` |
| ≥ 992px | Desktop | `@media (min-width: 992px)` |
| ≥ 1200px | Large Desktop | `@media (min-width: 1200px)` |
**Viewport-Meta-Tag (kritisch!):**
```html
<meta name="viewport" content="width=device-width, initial-scale=1">
```
Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
**Moderne Alternativen zu Media Queries:**
- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
- Container Queries: Reagieren auf Container-Größe statt Viewport
- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
---
# Zusammenfassung CSS
**Selektoren:**
File diff suppressed because it is too large. Load diff