Compare commits
6
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
4245ea2567 | ||
|
|
51146d3dfc | ||
|
|
fda4aca4c7 | ||
|
|
aff352fa91 | ||
|
|
ea7e905c61 | ||
|
|
512fbd9d3d |
No files matched your search
@@ -1,7 +1,7 @@
|
|||||||
# HdM Slides - Unified Makefile
|
# HdM Slides - Unified Makefile
|
||||||
# Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
|
# 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
|
# Course configuration
|
||||||
COURSES = 223015b 223015c
|
COURSES = 223015b 223015c
|
||||||
@@ -9,11 +9,11 @@ SLIDES_DIR = slides
|
|||||||
|
|
||||||
# Course-specific settings
|
# Course-specific settings
|
||||||
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
|
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
|
223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
|
||||||
|
|
||||||
223015c_NAME = Internettechnologien
|
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
|
223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
|
||||||
|
|
||||||
DEPLOY_HOST = tengo@tuttle.uberspace.de
|
DEPLOY_HOST = tengo@tuttle.uberspace.de
|
||||||
@@ -85,18 +85,7 @@ build-b: build/.exists
|
|||||||
build-c: build/.exists
|
build-c: build/.exists
|
||||||
$(call build_course,223015c)
|
$(call build_course,223015c)
|
||||||
|
|
||||||
build-klausurfragen: build/.exists
|
build: build-b build-c
|
||||||
@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
|
|
||||||
@echo "All courses built!"
|
@echo "All courses built!"
|
||||||
|
|
||||||
# HTML only builds
|
# HTML only builds
|
||||||
@@ -210,20 +199,13 @@ deploy-b: build-b
|
|||||||
deploy-c: build-c
|
deploy-c: build-c
|
||||||
$(call deploy_course,223015c)
|
$(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
|
deploy-index: build-index
|
||||||
@echo "Deploying root index..."
|
@echo "Deploying root index..."
|
||||||
scp build/index.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/
|
scp build/index.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/
|
||||||
scp build/qr-root.svg $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
|
scp build/qr-root.svg $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
|
||||||
@echo "Root index deployed!"
|
@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!"
|
@echo "All courses deployed!"
|
||||||
|
|
||||||
# Clean
|
# Clean
|
||||||
|
|||||||
File diff suppressed because it is too large.
Load diff
@@ -68,6 +68,38 @@ section.aufgabe {
|
|||||||
section.aufgabe footer {
|
section.aufgabe footer {
|
||||||
display: none;
|
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>
|
</style>
|
||||||
|
|
||||||
<!-- _class: invert -->
|
<!-- _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
|
# Das Problem der Skalierung
|
||||||
|
|
||||||
**Vergrößern:**
|
**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- und Vektorgrafiken
|
||||||
|
|
||||||
| | Raster | Vektor |
|
| | 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: '' -->
|
<!-- _header: '' -->
|
||||||
<!-- _footer: '' -->
|
<!-- _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
|
# JPEG Schritt 2: Chroma Subsampling
|
||||||
|
|
||||||
**Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block):
|
**Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block):
|
||||||
@@ -623,12 +749,36 @@ KLAUSURRELEVANT:
|
|||||||
- Präfix-frei: Kein Code ist Anfang eines anderen
|
- Präfix-frei: Kein Code ist Anfang eines anderen
|
||||||
- Häufigstes Zeichen = kürzester Code
|
- Häufigstes Zeichen = kürzester Code
|
||||||
- Auch in ZIP, PNG, MP3 verwendet
|
- 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 -->
|
<!-- _class: klausur -->
|
||||||
<!-- _header: '' -->
|
<!-- _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
|
# Formatwahl in der Praxis
|
||||||
|
|
||||||
| Anwendung | Format |
|
| 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
|
# Gängige Container
|
||||||
|
|
||||||
| Container | Verwendung |
|
| 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
|
# Das Patent-Problem
|
||||||
|
|
||||||
**H.264 ist nicht frei**
|
**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: '' -->
|
<!-- _header: '' -->
|
||||||
<!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
|
<!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
|
||||||
|
|
||||||
|
|||||||
@@ -68,6 +68,38 @@ section.aufgabe {
|
|||||||
section.aufgabe footer {
|
section.aufgabe footer {
|
||||||
display: none;
|
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>
|
</style>
|
||||||
|
|
||||||
<!-- _class: invert -->
|
<!-- _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 -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Dateisysteme
|
# 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
|
# Backup-Arten
|
||||||
|
|
||||||
**Vollständig (Full):**
|
**Vollständig (Full):**
|
||||||
|
|||||||
@@ -102,6 +102,166 @@ Hochschule der Medien Stuttgart
|
|||||||
<!-- _footer: "" -->
|
<!-- _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
|
# Rastergrafiken
|
||||||
|
|
||||||
**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
|
**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
|
||||||
@@ -243,6 +403,7 @@ KLAUSURRELEVANT:
|
|||||||
- Präfix-frei: Kein Code ist Anfang eines anderen
|
- Präfix-frei: Kein Code ist Anfang eines anderen
|
||||||
- Häufigstes Zeichen = kürzester Code
|
- Häufigstes Zeichen = kürzester Code
|
||||||
- Auch in ZIP, PNG, MP3 verwendet
|
- 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 {
|
section.aufgabe footer {
|
||||||
display: none;
|
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>
|
</style>
|
||||||
|
|
||||||
<!-- _class: invert -->
|
<!-- _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 -->
|
<!-- _class: klausur -->
|
||||||
<!-- _header: '' -->
|
<!-- _header: '' -->
|
||||||
<!-- _footer: '' -->
|
<!-- _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 -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Vom Militär zum Netz
|
# 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-Tags und Attribute
|
||||||
|
|
||||||
```html
|
```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 -->
|
<!-- _class: klausur -->
|
||||||
<!-- _header: '' -->
|
<!-- _header: '' -->
|
||||||
<!-- _footer: '' -->
|
<!-- _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
|
# WCAG: Der Standard
|
||||||
|
|
||||||
**W**eb **C**ontent **A**ccessibility **G**uidelines
|
**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 -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
|||||||
@@ -71,6 +71,38 @@ section.aufgabe footer {
|
|||||||
section.glossar {
|
section.glossar {
|
||||||
font-size: 1.4rem;
|
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>
|
</style>
|
||||||
|
|
||||||
<!-- _class: invert -->
|
<!-- _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
|
# 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?
|
# Warum ist das clever?
|
||||||
|
|
||||||
**Ohne Schichten:**
|
**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 -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Die Reise eines Klicks
|
# 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
|
# Nach dem Handshake
|
||||||
|
|
||||||
**Status:** Die TCP-Verbindung steht.
|
**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?
|
# Warum UDP bei Video-Calls?
|
||||||
|
|
||||||
**Szenario:** Ein Paket geht verloren.
|
**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 -->
|
<!-- _class: klausur -->
|
||||||
<!-- _header: '' -->
|
<!-- _header: '' -->
|
||||||
<!-- _footer: '' -->
|
<!-- _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 -->
|
<!-- _class: klausur -->
|
||||||
<!-- _header: '' -->
|
<!-- _header: '' -->
|
||||||
<!-- _footer: '' -->
|
<!-- _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
|
# Werkzeuge zum Selbst-Erkunden
|
||||||
|
|
||||||
**Im Browser (F12 → Network-Tab):**
|
**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
|
# 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
|
# Zusammenfassung CSS
|
||||||
|
|
||||||
**Selektoren:**
|
**Selektoren:**
|
||||||
|
|||||||
File diff suppressed because it is too large.
Load diff
Reference in new issue
Block a user