1872 lines
42 KiB
Markdown
1872 lines
42 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #1e5f8a;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert {
|
||
--color-foreground: #fff;
|
||
}
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h1 {
|
||
color: #1e5f8a;
|
||
}
|
||
section.invert h1 {
|
||
color: #fff;
|
||
}
|
||
h2 {
|
||
color: #1f2937;
|
||
}
|
||
pre {
|
||
background: #0f0f23;
|
||
color: #5fb3e4;
|
||
border-radius: 8px;
|
||
border-left: 3px solid #1e5f8a;
|
||
}
|
||
pre code {
|
||
background: transparent;
|
||
color: inherit;
|
||
}
|
||
code {
|
||
background: #0f0f23;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
|
||
}
|
||
section code:not(.hljs) { color: #5fb3e4 !important; }
|
||
section code.hljs { color: #f8f8f8 !important; }
|
||
a {
|
||
color: var(--color-highlight);
|
||
}
|
||
section.klausur {
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.klausur {
|
||
background: #e3f2fd !important;
|
||
}
|
||
}
|
||
section.aufgabe {
|
||
background: #e3f2fd !important;
|
||
}
|
||
section.aufgabe footer {
|
||
display: none;
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
|
||
**223015b** · Modul "Technik 1" · 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
**Sommersemester 2026**
|
||
|
||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Kapitel 4 – 30.01.2026
|
||
## Distribution, APIs & Zukunft
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
LKW voller Festplatten (Symbolbild)
|
||
Sneakernet: Manchmal schneller als Internet!
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Problem: Daten müssen reisen
|
||
|
||
**Szenario:** 100 TB von Berlin nach München
|
||
|
||
**Option 1: Internet-Upload**
|
||
- 1 Gbps Uplink = 125 MB/s
|
||
- Zeit: **9,3 Tage** (non-stop!)
|
||
|
||
**Option 2: Festplatte per Post**
|
||
- 10× 10TB HDDs (~2.000€)
|
||
- Kopieren: ~10 Stunden
|
||
- Versand: 1-2 Tage
|
||
- Gesamt: **~3 Tage**
|
||
|
||
*"Never underestimate the bandwidth of a station wagon full of tapes."* — Andrew Tanenbaum (1981)
|
||
|
||
<!--
|
||
Bandbreite vs. Latenz Trade-off
|
||
Internet: Hohe Latenz (9 Tage), aber sofort startbar
|
||
Post: Niedrige Latenz (3 Tage), aber Setup nötig
|
||
AWS Snowball existiert GENAU deswegen
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
AWS Snowmobile: 45-Fuß-Container auf LKW
|
||
100 Petabyte Kapazität
|
||
-->
|
||
|
||
---
|
||
|
||
# AWS Snowball
|
||
|
||
**AWS Snowball (seit 2015):**
|
||
|
||
**Problem:** Petabytes on-premise → AWS-Cloud
|
||
|
||
**Geräte:**
|
||
- Snowball Edge: 100 TB
|
||
- **Snowmobile:** 100 PB (Container auf LKW!)
|
||
|
||
**Prozess:**
|
||
1. AWS schickt verschlüsseltes Gerät
|
||
2. Kunde kopiert Daten lokal (schnell!)
|
||
3. Gerät zurück an AWS
|
||
4. AWS lädt in S3 hoch
|
||
|
||
**Kosten:** Günstiger als Internet-Transfer bei >10 TB
|
||
|
||
<!--
|
||
Snowball: Ruggedized Storage-Gerät
|
||
Snowmobile: Für Exabyte-Scale (Rechenzentrum-Migration)
|
||
Verschlüsselung: 256-Bit AES
|
||
Physical Security: Tamper-resistant, GPS-Tracking
|
||
Use Case: Rechenzentrum-Umzüge, Film-Archive
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
CD, DVD, Blu-ray nebeneinander
|
||
Evolution der optischen Medien
|
||
-->
|
||
|
||
---
|
||
|
||
# Physische Distribution
|
||
|
||
**CD (1982):** 700 MB
|
||
**DVD (1995):** 4,7 GB / 8,5 GB
|
||
**Blu-ray (2006):** 25 GB / 50 GB / 100 GB
|
||
|
||
**Problem heute:**
|
||
- Games: 50-150 GB (Call of Duty: 200+ GB!)
|
||
- Filme: Streaming überholt Blu-ray
|
||
- Disc = "License Key", Rest wird geladen
|
||
|
||
<!--
|
||
CD: Musik-Alben, Software (90er)
|
||
DVD: Filme, PS2-Games
|
||
Blu-ray: HD-Filme, PS3/PS4/PS5-Games
|
||
PS5: Blu-ray-Laufwerk, aber viele Games passen nicht mehr auf eine Disc
|
||
Disc oft nur Installer, Rest kommt aus Netz (Day-One-Patches)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Server unter Last (symbolisch)
|
||
"Hug of Death" – zu viele Anfragen
|
||
-->
|
||
|
||
---
|
||
|
||
# Zentralisierte Distribution
|
||
|
||
**Klassisches Modell:** Ein Server, viele Clients
|
||
|
||
**Problem:**
|
||
1 Million User wollen 1 GB-Datei
|
||
→ Server braucht **1 PB Bandbreite!**
|
||
→ Server überlastet → **"Hug of Death"**
|
||
|
||
**Lösung:** Content Delivery Networks (CDNs)
|
||
|
||
<!--
|
||
Single Point of Failure
|
||
Keine Skalierbarkeit
|
||
Reddit-Hug-of-Death: Kleine Websites crashen bei Frontpage
|
||
Slashdot-Effekt: Gleiches Problem (2000er)
|
||
CDNs lösen das Problem
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Weltkarte mit CDN-Knoten (Points of Presence)
|
||
Globale Verteilung
|
||
-->
|
||
|
||
---
|
||
|
||
# CDNs: Content Delivery Networks
|
||
|
||
**CDN = Verteiltes Netzwerk weltweit**
|
||
|
||
**Funktionsweise:**
|
||
1. **Origin Server** (Hauptquelle)
|
||
2. **Edge Servers** (geografisch verteilt)
|
||
3. User → nächster Edge Server
|
||
4. Erste Anfrage: Edge holt von Origin, cached
|
||
5. Weitere Anfragen: Direkt vom Edge (schnell!)
|
||
|
||
**Vorteile:**
|
||
✓ Reduzierte Latenz (geografische Nähe)
|
||
✓ Last-Verteilung
|
||
✓ Bandbreitenersparnis
|
||
|
||
<!--
|
||
PoP = Point of Presence (Edge-Standort)
|
||
Caching: Zwischenspeicherung beliebter Inhalte
|
||
TTL = Time To Live (wie lange cached?)
|
||
Große CDN-Anbieter: Cloudflare, Akamai, Amazon CloudFront, Fastly
|
||
-->
|
||
|
||
---
|
||
|
||
# CDN-Strategien
|
||
|
||
**Static Content:**
|
||
- Bilder, CSS, JS, Videos
|
||
- Lange Cache-Zeit (TTL: Tage/Wochen)
|
||
|
||
**Dynamic Content:**
|
||
- User-spezifisch (Profil)
|
||
- Kurze TTL oder nicht cachebar
|
||
|
||
**Cache Invalidation:**
|
||
- Versioning (`style.css` → `style.v2.css`)
|
||
- Cache-Purge (manuell leeren)
|
||
|
||
*"There are only two hard things in Computer Science: cache invalidation and naming things."* — Phil Karlton
|
||
|
||
<!--
|
||
Static: Logo einer Website (1 Jahr gecached)
|
||
Dynamic: Dein Facebook-Feed (immer aktuell)
|
||
Cache Invalidation: Schwer, weil globale Verteilung
|
||
Versioning: Neue Datei = neuer Cache-Eintrag
|
||
Purge: Manuelles Löschen (teuer, dauert Zeit)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Netflix Open Connect Appliance
|
||
Server in ISP-Rechenzentren
|
||
-->
|
||
|
||
---
|
||
|
||
# Netflix: Fallstudie CDN
|
||
|
||
**Netflix Open Connect (eigenes CDN):**
|
||
|
||
**Strategie:**
|
||
- Server IN ISP-Rechenzentren (Telekom, Vodafone...)
|
||
- Popular Content vorgeladen (Predictive Caching)
|
||
- **95%+ Traffic vom lokalen ISP-Server**
|
||
|
||
**Zahlen (2024):**
|
||
- 200M+ Subscriber
|
||
- ~15% des globalen Internet-Traffics!
|
||
- Ohne CDN: Unmöglich
|
||
|
||
<!--
|
||
Open Connect: Kostenlose Appliances für ISPs
|
||
ISPs profitieren: Weniger Backbone-Traffic
|
||
Netflix profitiert: Günstigerer Transit
|
||
Predictive Caching: Neue Season "Stranger Things" → Vorgeladen
|
||
Peering: Direktverbindungen zwischen Netflix & ISPs
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
P2P-Netzwerk-Diagramm
|
||
Dezentral, jeder ist Client & Server
|
||
-->
|
||
|
||
---
|
||
|
||
# P2P: Peer-to-Peer
|
||
|
||
**P2P = Jeder ist Client UND Server**
|
||
|
||
**Philosophie:** Dezentralisierung
|
||
|
||
**Anwendungen:**
|
||
- BitTorrent (File-Sharing)
|
||
- IPFS (InterPlanetary File System)
|
||
- Blockchain (Bitcoin, Ethereum)
|
||
|
||
**Vorteil:** Skalierbar (mehr User = mehr Bandbreite!)
|
||
|
||
**Nachteil:** Langsam bei wenigen Peers, oft für Piraterie missbraucht
|
||
|
||
<!--
|
||
P2P vs. Client-Server: Kein zentraler Server
|
||
Last verteilt sich auf alle Teilnehmer
|
||
Je mehr User, desto schneller (umgekehrt zu Client-Server!)
|
||
Zensur-resistent: Kein Single Point of Failure
|
||
Rechtliche Grauzone: Technologie neutral, aber oft illegal genutzt
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
BitTorrent-Swarm-Visualisierung
|
||
Peers tauschen Chunks untereinander
|
||
-->
|
||
|
||
---
|
||
|
||
# BitTorrent: Wie funktioniert's?
|
||
|
||
**BitTorrent (Bram Cohen, 2001):**
|
||
|
||
**Komponenten:**
|
||
1. **.torrent-Datei:** Metadaten (Hashes, Tracker-URL)
|
||
2. **Tracker:** Vermittelt Peers
|
||
3. **Seeders:** Haben komplette Datei
|
||
4. **Leechers:** Laden noch
|
||
5. **Swarm:** Alle Peers zusammen
|
||
|
||
**Mechanismus:**
|
||
- Datei in Chunks (z.B. 256 KB)
|
||
- Jeder Peer lädt von verschiedenen Peers
|
||
- "Tit-for-tat": Wer uploaded, lädt schneller
|
||
|
||
<!--
|
||
Bram Cohen: Entwickelte BitTorrent 2001 (Python)
|
||
Tracker: Koordiniert Peers, aber speichert keine Daten
|
||
DHT (Distributed Hash Table): Tracker-loses BitTorrent
|
||
Chunks: Datei in kleine Stücke → Paralleler Download
|
||
Tit-for-tat: Fairness-Mechanismus (Upload = Download-Speed)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
The Pirate Bay Logo (historisch)
|
||
BitTorrent-Index, kontroverser aber wichtiger Teil der Geschichte
|
||
-->
|
||
|
||
---
|
||
|
||
# BitTorrent & Piraterie
|
||
|
||
**2000er:** Musik-/Film-Piraterie-Revolution
|
||
|
||
**Napster (1999-2001):** Zentralisiert → Verklagt, Shutdown
|
||
|
||
**BitTorrent (2001+):** Dezentral → Schwerer zu verklagen
|
||
|
||
**The Pirate Bay (2003):** BitTorrent-Index
|
||
- Blockiert, zieht um, neue Domains
|
||
- **Whack-a-Mole-Spiel**
|
||
|
||
**Rechtliche Grauzone:**
|
||
- Protokoll selbst: Legal
|
||
- Inhalte: Oft illegal (Urheberrecht)
|
||
- Legitime Uses: Linux-ISOs, Open-Source, Public Domain
|
||
|
||
<!--
|
||
RIAA verklagte Napster (2001) → Erfolg
|
||
The Pirate Bay: Verklagt, Gründer im Gefängnis, aber Site lebt
|
||
Whack-a-Mole: Domain blocken → neue Domain
|
||
Torrent-Protokoll neutral (wie Messer: Legal, aber Verbrechen möglich)
|
||
Legitime Nutzung: Ubuntu-Download via Torrent (entlastet Server)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
IPFS-Logo
|
||
InterPlanetary File System
|
||
-->
|
||
|
||
---
|
||
|
||
# IPFS: Dezentrales Web?
|
||
|
||
**IPFS = InterPlanetary File System (2015)**
|
||
|
||
**Vision:** Web ohne Server
|
||
|
||
**Funktionsweise:**
|
||
- **Content-Addressable:** Dateien durch Hash identifiziert
|
||
- **CID:** Content Identifier (`QmXyZ123...`)
|
||
- Datei auf vielen Knoten (wie BitTorrent, aber persistent)
|
||
- Abruf: "Gib mir Datei mit Hash X" (egal wo)
|
||
|
||
**Vorteile:** Zensur-resistent, kein Single Point of Failure
|
||
|
||
**Nachteile:** Langsam (noch), keine Verfügbarkeitsgarantie
|
||
|
||
**Anwendung:** NFT-Speicher
|
||
|
||
<!--
|
||
Protocol Labs (Juan Benet, 2014)
|
||
Content-Addressed: URL = Hash (ändert sich bei Änderung → Versionierung automatisch)
|
||
Pinning: Datei dauerhaft verfügbar halten (Knoten müssen hosten)
|
||
Gateway: IPFS über HTTP zugänglich (ipfs.io)
|
||
NFTs: Viele nutzen IPFS (aber nicht alle! Manche nur Links)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Streaming-Pipeline: Encoder → CDN → Player
|
||
HLS/DASH-Segmente
|
||
-->
|
||
|
||
---
|
||
|
||
# Streaming: Real-Time-Distribution
|
||
|
||
**Streaming = Daten während Empfang konsumiert**
|
||
|
||
**Protokolle:**
|
||
- **HLS** (Apple): HTTP-basiert, Segmente
|
||
- **MPEG-DASH:** Standard, ähnlich HLS
|
||
- **WebRTC:** Browser-zu-Browser, niedrige Latenz
|
||
|
||
**Adaptive Bitrate:**
|
||
- Stream in mehreren Qualitäten (240p-4K)
|
||
- Player wechselt dynamisch
|
||
- Segmente: 2-10 Sekunden
|
||
|
||
**Latenz:**
|
||
- Traditional (HLS): 10-30 Sekunden
|
||
- Low-Latency HLS: 2-5 Sekunden
|
||
- WebRTC: <1 Sekunde (Videocalls)
|
||
|
||
<!--
|
||
HLS = HTTP Live Streaming
|
||
DASH = Dynamic Adaptive Streaming over HTTP
|
||
Adaptive Bitrate: Bandbreite schwankt → Qualität anpassen
|
||
Manifest-Datei: Liste aller Qualitäten & Segmente
|
||
Player-Logik: Misst Bandbreite, wählt beste Qualität
|
||
Latenz-Trade-off: Buffering vs. Real-Time
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: Torrent & CDN
|
||
|
||
**Aufgabe (40 Min):**
|
||
|
||
**Teil 1: BitTorrent (20 Min)**
|
||
1. Lade legalen Torrent (Linux-ISO: ubuntu.com)
|
||
2. Tool: qBittorrent oder Transmission
|
||
3. Beobachte: Peers, Seeders, Download-Speed, Upload-Speed
|
||
|
||
**Teil 2: CDN-Analyse (20 Min)**
|
||
1. Öffne populäre Website (z.B. nytimes.com)
|
||
2. Browser DevTools → Network-Tab
|
||
3. Schaue auf Requests: Welche CDN-Domains?
|
||
4. Response-Headers: `X-Cache`, `CF-Ray`, etc.
|
||
|
||
**Tools:** cdn77.com/cdn-check
|
||
|
||
<!--
|
||
Ubuntu-Torrent: Legitim, gut geseeded (schnell)
|
||
qBittorrent: FOSS, keine Ads (im Gegensatz zu uTorrent)
|
||
Swarm beobachten: Peers kommen/gehen
|
||
Upload-Speed: Ihr werdet zum Seeder!
|
||
DevTools: F12, Network-Tab, Seite neu laden
|
||
CDN-Domains: cdn.example.com, cloudfront.net, akamaihd.net
|
||
Headers: Zeigen Cache-Status, CDN-Provider
|
||
-->
|
||
|
||
<!--
|
||
Netflix: Schwer zu analysieren (verschlüsselt), aber CDN sichtbar
|
||
YouTube: Google CDN (googlevideo.com)
|
||
Spotify: Akamai CDN
|
||
Cache-Control Header: max-age, s-maxage, public/private
|
||
-->
|
||
|
||
---
|
||
|
||
# Dateitransfer-Protokolle
|
||
|
||
**FTP (File Transfer Protocol, 1971):**
|
||
- Ältestes Internet-Protokoll für Dateitransfer
|
||
- ⚠️ Unverschlüsselt! (Passwort im Klartext)
|
||
- **SFTP/FTPS:** Sichere Varianten
|
||
|
||
**WebDAV (Web-based Distributed Authoring):**
|
||
- HTTP-basiert → Firewall-freundlich
|
||
- Wird von vielen Cloud-Diensten genutzt
|
||
- Mountbar als Netzlaufwerk
|
||
|
||
**Moderne Alternativen:** rsync, rclone, Cloud-APIs
|
||
|
||
<!--
|
||
FTP: Port 21 (Steuerung), Port 20 (Daten)
|
||
Noch verbreitet für: Webhosting, Legacy-Systeme
|
||
FileZilla: Populärer FTP-Client
|
||
WebDAV: Nextcloud, Box.com nutzen WebDAV
|
||
SMB/NFS: Für lokale Netzwerke besser (schneller)
|
||
rsync: Inkrementelle Übertragung (nur Änderungen)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: APIs
|
||
## Software-Schnittstellen & Protokolle
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
API-Diagramm mit Pfeilen zwischen Apps
|
||
Software-Kommunikation visualisiert
|
||
-->
|
||
|
||
---
|
||
|
||
# Was ist eine API?
|
||
|
||
**API = Application Programming Interface**
|
||
|
||
**Analogie: Restaurant**
|
||
- Du (Client) → Speisekarte (API-Dokumentation)
|
||
- Bestellst (Request)
|
||
- Küche bereitet zu (Backend)
|
||
- Kellner bringt Essen (Response)
|
||
- Du weißt nicht, WIE gekocht wird – nur WAS du kriegst
|
||
|
||
**Typen:** Hardware-APIs, OS-APIs, Web-APIs, Library-APIs
|
||
|
||
<!--
|
||
API = Vertrag zwischen Software-Komponenten
|
||
Abstraktion: Implementierung verborgen, nur Interface sichtbar
|
||
Windows API, POSIX, OpenGL = Betriebssystem/Hardware-APIs
|
||
NumPy, React = Library-APIs
|
||
Web-APIs = Heute Fokus
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
HTTP Request/Response-Zyklus
|
||
Client → Server → Client
|
||
-->
|
||
|
||
---
|
||
|
||
# HTTP: Das Fundament
|
||
|
||
**HTTP = HyperText Transfer Protocol (1991)**
|
||
|
||
**Request-Struktur:**
|
||
- **Method:** GET, POST, PUT, DELETE
|
||
- **URL:** Resource-Identifier
|
||
- **Headers:** Metadaten (Content-Type, Authorization...)
|
||
- **Body:** Optional (bei POST/PUT)
|
||
|
||
**Response-Struktur:**
|
||
- **Status Code:** 200 OK, 404 Not Found, 500 Error
|
||
- **Headers:** Metadaten
|
||
- **Body:** HTML, JSON, XML, Binary...
|
||
|
||
<!--
|
||
HTTP = Tim Berners-Lee (1991, CERN)
|
||
Request-Response-Modell: Client fragt, Server antwortet
|
||
Stateless: Jede Anfrage unabhängig (keine Session am Server)
|
||
HTTPS = HTTP + TLS (Verschlüsselung)
|
||
-->
|
||
|
||
---
|
||
|
||
# HTTP-Methods: CRUD
|
||
|
||
**CRUD = Create, Read, Update, Delete**
|
||
|
||
| Method | CRUD | Beispiel |
|
||
|--------|------|----------|
|
||
| **GET** | Read | `/posts` → Alle Posts |
|
||
| **POST** | Create | `/posts` → Neuer Post |
|
||
| **PUT** | Update | `/posts/42` → Post ersetzen |
|
||
| **PATCH** | Update | `/posts/42` → Teilupdate |
|
||
| **DELETE** | Delete | `/posts/42` → Post löschen |
|
||
|
||
**GET = Idempotent** (mehrfach ausführen = gleiches Ergebnis)
|
||
|
||
<!--
|
||
CRUD: Basis-Operationen für Datenbanken
|
||
RESTful APIs nutzen HTTP-Methods für CRUD
|
||
Idempotenz: GET, PUT, DELETE → mehrfach = gleich
|
||
POST nicht idempotent: 2× POST → 2 neue Einträge
|
||
PATCH: Nur geänderte Felder (effizienter als PUT)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
REST-API-Struktur
|
||
Resources, URLs, HTTP-Methods
|
||
-->
|
||
|
||
---
|
||
|
||
# REST: Representational State Transfer
|
||
|
||
**REST (Roy Fielding, 2000):**
|
||
|
||
**Prinzipien:**
|
||
1. **Stateless:** Jede Anfrage eigenständig
|
||
2. **Resource-Based:** URLs = Ressourcen (`/users/123`)
|
||
3. **HTTP-Methods:** CRUD-Operationen
|
||
4. **Hypermedia:** Links zu verwandten Ressourcen
|
||
|
||
**Beispiel: Twitter-API**
|
||
```
|
||
GET /tweets/123 → Tweet mit ID 123
|
||
POST /tweets → Neuen Tweet erstellen
|
||
DELETE /tweets/123 → Tweet löschen
|
||
GET /users/alice/tweets → Tweets von Alice
|
||
```
|
||
|
||
<!--
|
||
Roy Fielding: Dissertation 2000 (definierte REST)
|
||
REST = Architektur-Stil,nicht Protokoll
|
||
Stateless: Server speichert keine Session (skalierbar!)
|
||
HATEOAS = Hypermedia as the Engine of Application State (selten implementiert)
|
||
REST-Vorteile: Einfach, cacheable, sprachunabhängig
|
||
REST-Nachteile: Over-/Under-Fetching
|
||
-->
|
||
|
||
---
|
||
|
||
# REST-Probleme
|
||
|
||
**Problem 1: Over-Fetching**
|
||
```
|
||
GET /users/123
|
||
→ Gibt zurück: Name, Email, Bio, Avatar,
|
||
Follower-Count, Posts, Friends...
|
||
```
|
||
Du willst nur Name → Kriegst 90% zu viel
|
||
|
||
**Problem 2: Under-Fetching**
|
||
```
|
||
GET /users/123 → User-Daten
|
||
GET /users/123/posts → Alle Posts
|
||
```
|
||
2 Requests statt einem
|
||
|
||
**Lösung:** GraphQL
|
||
|
||
<!--
|
||
Over-Fetching: Bandbreite-Verschwendung (Mobile!)
|
||
Under-Fetching: Latenz (2 Round-Trips statt 1)
|
||
REST-Workarounds: Query-Parameter (?fields=name,email)
|
||
Aber: Nicht standardisiert, jede API anders
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
GraphQL-Logo
|
||
Facebook-Technologie
|
||
-->
|
||
|
||
---
|
||
|
||
# GraphQL: Die REST-Alternative
|
||
|
||
**GraphQL (Facebook, 2015):**
|
||
|
||
**Idee:** Client fragt EXAKT, was er braucht
|
||
|
||
**Query-Beispiel:**
|
||
```graphql
|
||
{
|
||
user(id: 123) {
|
||
name
|
||
email
|
||
posts(limit: 5) {
|
||
title
|
||
createdAt
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
**Vorteile:**
|
||
✓ Kein Over-/Under-Fetching
|
||
✓ Ein Endpoint (`/graphql`)
|
||
✓ Strongly Typed (Schema!)
|
||
|
||
<!--
|
||
Facebook entwickelte GraphQL für Mobile (2012)
|
||
Open-Source 2015
|
||
Schema = Typdefinitionen (wie TypeScript für APIs)
|
||
Introspection: Client kann Schema abfragen (selbst-dokumentierend)
|
||
Nachteile: Komplexer als REST, Caching schwieriger
|
||
-->
|
||
|
||
---
|
||
|
||
# GraphQL Schema
|
||
```graphql
|
||
type User {
|
||
id: ID!
|
||
name: String!
|
||
email: String
|
||
posts: [Post!]!
|
||
}
|
||
|
||
type Post {
|
||
id: ID!
|
||
title: String!
|
||
content: String!
|
||
author: User!
|
||
}
|
||
|
||
type Query {
|
||
user(id: ID!): User
|
||
posts: [Post!]!
|
||
}
|
||
|
||
type Mutation {
|
||
createPost(title: String!, content: String!): Post!
|
||
}
|
||
```
|
||
|
||
**`!` = Required (non-nullable)**
|
||
|
||
<!--
|
||
Schema-First-Design: Schema definieren, dann implementieren
|
||
Query: Daten lesen (wie GET)
|
||
Mutation: Daten ändern (wie POST/PUT/DELETE)
|
||
Subscription: Real-Time-Updates (WebSocket-basiert)
|
||
GraphQL Playground: Interactive API Explorer
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
WebSocket-Verbindung: Bidirektional, persistent
|
||
Im Gegensatz zu HTTP Request-Response
|
||
-->
|
||
|
||
---
|
||
|
||
# WebSockets: Real-Time
|
||
|
||
**Problem mit HTTP:**
|
||
- Request-Response-Zyklus
|
||
- Server kann nicht "pushen"
|
||
- Polling ineffizient
|
||
|
||
**WebSocket (2011):**
|
||
- **Bidirektionale Verbindung**
|
||
- Bleibt offen (Persistent)
|
||
- Server kann jederzeit senden
|
||
|
||
**Anwendungen:**
|
||
Chat (Discord), Live-Updates (Aktienkurse), Multiplayer-Games
|
||
|
||
<!--
|
||
HTTP: Server antwortet nur auf Anfrage
|
||
Polling: Client fragt jede Sekunde (ineffizient!)
|
||
Long-Polling: Besser, aber Workaround
|
||
WebSocket: Echte bidirektionale Verbindung
|
||
Handshake: HTTP-Upgrade-Request → WebSocket
|
||
-->
|
||
|
||
---
|
||
|
||
# WebSocket: Chat-Beispiel
|
||
|
||
**Flow:**
|
||
1. Alice öffnet Chat → WebSocket-Connection
|
||
2. Bob öffnet Chat → Eigene Connection
|
||
3. Alice tippt: "Hi Bob!"
|
||
4. Client sendet: `{"type": "message", "text": "Hi Bob!", "to": "bob"}`
|
||
5. Server leitet an Bobs Connection weiter
|
||
6. Bob empfängt, zeigt an
|
||
|
||
**Kein Polling! Instant!**
|
||
|
||
<!--
|
||
WebSocket-Frames: Text (JSON) oder Binary
|
||
Ping/Pong: Keepalive-Mechanismus
|
||
Protokoll: ws:// (unverschlüsselt), wss:// (verschlüsselt, wie HTTPS)
|
||
Socket.io: JavaScript-Library (vereinfacht WebSocket)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
gRPC-Logo
|
||
Google-Technologie
|
||
-->
|
||
|
||
---
|
||
|
||
# gRPC: Google's Approach
|
||
|
||
**gRPC = Google Remote Procedure Call (2015)**
|
||
|
||
**Idee:** Funktion auf Remote-Server aufrufen, als wäre es lokal
|
||
|
||
**Eigenschaften:**
|
||
- **Protocol Buffers (Protobuf):** Binär, kompakt (statt JSON)
|
||
- **HTTP/2:** Multiplexing, Bidirektional
|
||
- **Strongly Typed**
|
||
- **Code-Generierung** (Client/Server aus `.proto`-Datei)
|
||
|
||
**Vorteile:** Performance, Streaming
|
||
**Nachteile:** Nicht Browser-kompatibel, Debugging schwieriger
|
||
|
||
<!--
|
||
RPC = Remote Procedure Call (wie Funktionsaufruf über Netzwerk)
|
||
Protobuf: Google's Serialisierungsformat (wie JSON, aber binär)
|
||
HTTP/2: Multiplexing = mehrere Requests über eine Connection
|
||
Streaming: Server/Client/Bidirectional möglich
|
||
Use Case: Microservices (interne Kommunikation)
|
||
Browser: gRPC-Web als Workaround (Proxy nötig)
|
||
-->
|
||
|
||
---
|
||
|
||
# gRPC Beispiel
|
||
|
||
**`.proto`-Datei:**
|
||
```protobuf
|
||
service UserService {
|
||
rpc GetUser (UserRequest) returns (UserResponse);
|
||
rpc ListPosts (Empty) returns (stream Post);
|
||
}
|
||
|
||
message UserRequest {
|
||
int32 id = 1;
|
||
}
|
||
|
||
message UserResponse {
|
||
string name = 1;
|
||
string email = 2;
|
||
}
|
||
```
|
||
|
||
**Code-Generierung:** Client/Server-Code automatisch generiert
|
||
|
||
<!--
|
||
.proto = Protocol Buffer Definition
|
||
rpc = Remote Procedure Call (Funktionsdefinition)
|
||
stream = Server-seitige Streaming (Datenstrom)
|
||
Code-Gen: protoc-Compiler generiert Code für Go, Python, Java, C++, etc.
|
||
Type-Safety: Compiler prüft Typen
|
||
-->
|
||
|
||
---
|
||
|
||
# JSON: Das Standard-Format
|
||
|
||
**JSON = JavaScript Object Notation**
|
||
|
||
**Eigenschaften:**
|
||
- Textbasiert, menschenlesbar
|
||
- Schlüssel-Wert-Paare
|
||
- Unterstützt: Objekte, Arrays, Strings, Numbers, Booleans, null
|
||
|
||
**Beispiel:**
|
||
```json
|
||
{
|
||
"name": "Alice",
|
||
"age": 28,
|
||
"posts": [
|
||
{"title": "Hello", "views": 42},
|
||
{"title": "World", "views": 123}
|
||
]
|
||
}
|
||
```
|
||
|
||
<!--
|
||
JSON = Subset von JavaScript (aber sprachunabhängig)
|
||
Überall unterstützt: Jede Programmiersprache
|
||
UTF-8 Encoding (Emojis möglich!)
|
||
Kein Kommentar-Support (Kritikpunkt)
|
||
Alternativen: XML (verbose), YAML (menschenfreundlicher), Protobuf (binär)
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: API abfragen
|
||
|
||
**Aufgabe (40 Min):**
|
||
|
||
**Teil 1: REST-API (20 Min)**
|
||
1. Öffentliche API: `jsonplaceholder.typicode.com`
|
||
2. Tool: curl (Terminal) oder Postman (GUI)
|
||
3. Beispiele:
|
||
```bash
|
||
curl https://jsonplaceholder.typicode.com/posts/1
|
||
curl -X POST https://jsonplaceholder.typicode.com/posts \
|
||
-H "Content-Type: application/json" \
|
||
-d '{"title":"Test","body":"Hello","userId":1}'
|
||
```
|
||
4. Analysiere: Status-Code, Headers, Body
|
||
|
||
**Teil 2: WebSocket (20 Min)**
|
||
1. Öffne: `websocket.org/echo.html`
|
||
2. Verbinde, sende Nachrichten
|
||
3. Beobachte: Instant Response
|
||
|
||
<!--
|
||
JSONPlaceholder: Fake REST API für Testing
|
||
curl: Command-Line HTTP-Tool (Linux/macOS/Windows)
|
||
Postman: GUI-Alternative (einfacher)
|
||
-X POST: HTTP-Method
|
||
-H: Header setzen
|
||
-d: Data (Body)
|
||
WebSocket Echo: Server echot zurück (Test-Server)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 3: Metadaten
|
||
## Daten über Daten & Interoperabilität
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Foto mit eingeblendeten GPS-Koordinaten
|
||
EXIF-Daten visualisiert
|
||
Privacy-Albtraum
|
||
-->
|
||
|
||
---
|
||
|
||
# Was sind Metadaten?
|
||
|
||
**Metadaten = Daten über Daten**
|
||
|
||
**Beispiele:**
|
||
- **Foto:** Kamera, Datum, GPS, Belichtung
|
||
- **MP3:** Künstler, Album, Jahr, Genre, Cover
|
||
- **PDF:** Autor, Datum, Software
|
||
- **E-Mail:** Absender, Empfänger, Zeitstempel
|
||
|
||
**Warum wichtig?**
|
||
✓ Organisation, Suche
|
||
✓ Kontext (Wann/Wo/Wie?)
|
||
|
||
**Aber auch:**
|
||
❌ Privacy-Risiko, Forensische Spuren
|
||
|
||
<!--
|
||
"Data about data" = Standard-Definition
|
||
Metadaten oft wichtiger als Daten selbst (NSA: "We kill people based on metadata")
|
||
Jede Datei hat Metadaten (implizit oder explizit)
|
||
Header in Dateien: Erste Bytes oft Metadaten
|
||
-->
|
||
|
||
---
|
||
|
||
# EXIF: Exchangeable Image File Format
|
||
|
||
**EXIF (1995, Kamera-Hersteller):**
|
||
|
||
**Typische Daten:**
|
||
- Kamera-Modell (z.B. "iPhone 15 Pro")
|
||
- Datum & Uhrzeit
|
||
- Belichtung (Blende, Verschlusszeit, ISO)
|
||
- **GPS-Koordinaten** (Latitude, Longitude, Altitude)
|
||
- Software (z.B. "Photoshop 2024")
|
||
|
||
**Speicherort:** JPEG-Header (Binärformat)
|
||
|
||
**Tools:** exiftool, ExifPurge, metapicz.com
|
||
|
||
<!--
|
||
JEITA = Japan Electronic & Information Technology Industries Association
|
||
EXIF in JPEG, TIFF, WAV, etc.
|
||
GPS: Automatisch von Smartphones hinzugefügt (wenn Location-Services an)
|
||
Software: Zeigt, ob Bild bearbeitet wurde
|
||
Orientation: Landscape/Portrait (für Auto-Rotation)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
John McAfee Guatemala-Story (2012)
|
||
Vice Magazine veröffentlichte Foto mit GPS-EXIF
|
||
Aufenthaltsort verraten
|
||
-->
|
||
|
||
---
|
||
|
||
# EXIF: Privacy-Albtraum
|
||
|
||
**Szenario 1: Stalking**
|
||
- Foto auf Twitter: "Zuhause entspannen 🏡"
|
||
- EXIF: GPS 52.5200° N, 13.4050° E
|
||
- → Stalker weiß, wo du wohnst
|
||
|
||
**Szenario 2: Whistleblowing**
|
||
- Anonyme Quelle schickt PDF
|
||
- Metadaten: "Erstellt von: John Doe, Firma XY"
|
||
- → Quelle identifiziert
|
||
|
||
**Berühmter Fall:**
|
||
John McAfee (2012): Vice-Magazine vergaß EXIF zu entfernen
|
||
→ GPS verriet Aufenthaltsort in Guatemala
|
||
|
||
<!--
|
||
EXIF standardmäßig AN (die meisten wissen's nicht)
|
||
Jedes Handy-Foto = potentieller Fingerabdruck
|
||
Whistleblower: Reality Winner (2017) – NSA-Dokument mit Druckerspuren
|
||
Druckerspuren: Gelbe Punkte (Machine Identification Code)
|
||
-->
|
||
|
||
---
|
||
|
||
# Social Media & EXIF-Stripping
|
||
|
||
**Welche Plattformen entfernen EXIF?**
|
||
|
||
✓ **Twitter/X:** Ja (seit 2015)
|
||
✓ **Facebook/Instagram:** Ja (GPS entfernt)
|
||
✓ **Reddit:** Ja
|
||
❌ **WhatsApp:** Nein (privat, aber Metadaten bleiben)
|
||
❌ **E-Mail-Anhänge:** Nein
|
||
❌ **Cloud (Dropbox, Google Drive):** Nein
|
||
|
||
**Best Practice:** EXIF manuell entfernen vor Upload
|
||
```bash
|
||
exiftool -all= foto.jpg # Entfernt ALLE Metadaten
|
||
```
|
||
|
||
<!--
|
||
Twitter-Kritik 2015: Journalisten-Fotos verrieten Standorte
|
||
Facebook: GPS entfernt, aber Kamera-Modell bleibt
|
||
Signal: Entfernt EXIF automatisch
|
||
Telegram: Nicht immer (unsicher!)
|
||
Cloud: Originaldatei bleibt unverändert (gut für Backup, schlecht für Privacy)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
ID3-Tag-Editor (Screenshot)
|
||
MP3-Metadaten bearbeiten
|
||
-->
|
||
|
||
---
|
||
|
||
# ID3-Tags: Musik-Metadaten
|
||
|
||
**ID3 = Identification 3 (1996)**
|
||
|
||
**Versionen:**
|
||
- **ID3v1:** 128 Bytes am Ende (limitiert!)
|
||
- Titel (30 Zeichen), Artist, Album, Jahr
|
||
- **ID3v2:** Am Anfang, variable Länge
|
||
- Unbegrenzte Textfelder, Cover-Art, Lyrics, BPM
|
||
|
||
**Tools:**
|
||
- Kid3 (GUI, Multi-Platform)
|
||
- MusicBrainz Picard (Auto-Tagging!)
|
||
- mp3tag (Windows)
|
||
|
||
<!--
|
||
ID3v1: Ursprünglich (1996), sehr limitiert
|
||
Genre: Fixe Liste (0-255), nicht erweiterbar
|
||
ID3v2: Seit 1998, viel flexibler
|
||
Cover-Art: JPEG embedded in MP3 (APIC-Frame)
|
||
BPM: Beats per Minute (für DJs)
|
||
Composer: Unterschied zu Artist (klassische Musik)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
MusicBrainz-Logo
|
||
Wikipedia für Musik-Metadaten
|
||
-->
|
||
|
||
---
|
||
|
||
# MusicBrainz: Offene Musik-Datenbank
|
||
|
||
**MusicBrainz (2000):**
|
||
|
||
**Idee:** Wikipedia für Musik-Metadaten
|
||
|
||
**Community-gepflegt:**
|
||
- Künstler, Alben, Tracks
|
||
- Relationships (Band-Mitglieder, Label...)
|
||
- Releases (verschiedene Editionen, Länder)
|
||
|
||
**MusicBrainz Picard:**
|
||
- Audio-Fingerprinting (AcoustID)
|
||
- Analysiert Waveform, matched mit Datenbank
|
||
- Auto-Tagging (auch bei falsch benannten Dateien!)
|
||
|
||
**Philosophie:** Open Data (gegen proprietäre Gracenote/CDDB)
|
||
|
||
<!--
|
||
MusicBrainz: Non-Profit, Community-driven
|
||
Gracenote: Sony-Tochter, proprietär, teuer
|
||
CDDB: Ursprünglich frei, dann kommerzialisiert (1998)
|
||
AcoustID: Akustischer Fingerabdruck (wie Shazam)
|
||
Picard: Python-basiert, FOSS
|
||
API: Frei nutzbar (Rate-Limited)
|
||
-->
|
||
|
||
---
|
||
|
||
# Dublin Core: Universelle Metadaten
|
||
|
||
**Dublin Core (1995, Dublin, Ohio):**
|
||
|
||
**15 Kern-Elemente:**
|
||
1. Title, 2. Creator, 3. Subject, 4. Description
|
||
5. Publisher, 6. Contributor, 7. Date, 8. Type
|
||
9. Format, 10. Identifier (ISBN, DOI)
|
||
11. Source, 12. Language, 13. Relation
|
||
14. Coverage, 15. Rights
|
||
|
||
**Anwendung:** Bibliotheken, Archive, Webseiten (HTML `<meta>`)
|
||
|
||
<!--
|
||
Dublin Core Metadata Initiative (DCMI)
|
||
Standard für Ressourcen-Beschreibung (nicht nur Dateien)
|
||
Einfach, aber universell
|
||
HTML: <meta name="DC.title" content="...">
|
||
Erweitert: Qualified Dublin Core (mehr Felder)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
PDF-Metadaten-Analyse (Screenshot)
|
||
Versteckte Informationen sichtbar
|
||
-->
|
||
|
||
---
|
||
|
||
# PDF-Metadaten: Hidden Dangers
|
||
|
||
**PDF-Metadaten (XMP):**
|
||
|
||
**Gespeichert:**
|
||
- Titel, Autor, Betreff, Keywords
|
||
- Erstellungsdatum, Änderungsdatum
|
||
- Software, **Company** (aus Office-Lizenz!)
|
||
|
||
**Versteckte Daten:**
|
||
- Änderungshistorie (Track Changes)
|
||
- Kommentare (vermeintlich gelöscht)
|
||
- Ebenen (InDesign, Illustrator)
|
||
|
||
**Berühmter Fall:**
|
||
Tony Blair Dossier (2003, Irak-Krieg)
|
||
→ PDF-Metadaten zeigten Manipulation
|
||
|
||
<!--
|
||
XMP = Extensible Metadata Platform (Adobe)
|
||
Company: Windows Office speichert Firmennamen aus Lizenz
|
||
Track Changes: Word → PDF kann History enthalten
|
||
Tony Blair: "Dodgy Dossier" – Copy-Paste aus Student-Arbeit nachgewiesen
|
||
PDF-Redaktion: Adobe Acrobat Pro "Sanitize Document"
|
||
Dangerzone: FOSS-Tool (Freedom of Press Foundation)
|
||
-->
|
||
|
||
---
|
||
|
||
# Interoperabilität: Offene vs. Proprietäre
|
||
|
||
**Offene Formate:**
|
||
✓ Spezifikation öffentlich
|
||
✓ Keine Lizenzgebühren
|
||
✓ Viele Programme unterstützen1
|
||
**Beispiele:** PNG, OGG, MKV, Markdown, SVG
|
||
|
||
**Proprietäre Formate:**
|
||
❌ Spezifikation geheim
|
||
❌ Oft nur in einer Software voll nutzbar
|
||
❌ **Lock-in-Effekt**
|
||
**Beispiele:** PSD (Photoshop), INDD (InDesign), DWG (AutoCAD), .pages
|
||
|
||
<!--
|
||
Interoperabilität = Zusammenarbeit verschiedener Systeme
|
||
Lock-in: "Gefangene Daten" (nur in Software X öffenbar)
|
||
Firma geht pleite → Format stirbt (WordPerfect-Beispiel)
|
||
Offene Standards: Überlebensfähiger (Community kann implementieren)
|
||
-->
|
||
111
|
||
---
|
||
|
||
# Vendor Lock-in: Beispiele
|
||
|
||
**Fall 1: Microsoft Office (.docx)**
|
||
- Historisch: .doc undokumentiert
|
||
- LibreOffice konnte nicht perfekt konvertieren
|
||
- "Formatierung kaputt" → Zurück zu MS Office
|
||
|
||
**Fall 2: Adobe Creative Suite**
|
||
- PSD: Layer, Blend-Modes → Nur in Photoshop voll editierbar
|
||
- GIMP kann öffnen, aber Features fehlen
|
||
|
||
**Fall 3: Apple Ecosystem**
|
||
- .pages, .numbers, .key → Nur auf Apple native Bearbeitung
|
||
|
||
<!--
|
||
.docx: Heute Open XML (standardisiert), aber viele proprietäre Extensions
|
||
OOXML vs. ODF: Zwei konkurrierende Standards (beide ISO)
|
||
PSD: 30+ Jahre alt, extrem komplex
|
||
GIMP: Free, aber nicht Feature-Parität
|
||
Apple: Export zu Office-Formaten verliert Features
|
||
Lock-in = Business-Strategie
|
||
-->
|
||
|
||
---
|
||
|
||
# Datenmigration & Langzeitarchivierung
|
||
|
||
**Beispiele toter Formate:**
|
||
- WordPerfect (.wpd) – 1980-90er dominant, heute kaum lesbar
|
||
- Lotus 1-2-3 (.wks) – Spreadsheet, verschwunden
|
||
- Flash (.swf) – Millionen Websites/Games, seit 2020 tot
|
||
|
||
**Archivierungs-Strategien:**
|
||
1. **Migration:** Regelmäßig in aktuelle Formate konvertieren
|
||
2. **Emulation:** Alte Software in VM
|
||
3. **Offene Standards:** PDF/A, TIFF, Plain Text
|
||
|
||
<!--
|
||
Format-Tod: Unvermeidlich (30+ Jahre Lebensdauer selten)
|
||
WordPerfect: Marktführer 1980er, heute Museum
|
||
Flash: Adobe kündigte 2020 Support-Ende an
|
||
PDF/A: Archiv-PDF (Subset, keine interaktiven Features)
|
||
TIFF: Unkomprimiert, für Langzeitarchivierung
|
||
Plain Text: Überlebt alles (ASCII/UTF-8)
|
||
Migration alle 5-10 Jahre nötig
|
||
-->
|
||
|
||
---
|
||
|
||
# Metadaten für Accessibility
|
||
|
||
**Alt-Text (Alternative Text):**
|
||
```html
|
||
<img src="cat.jpg" alt="Orange tabby cat sleeping on windowsill">
|
||
```
|
||
|
||
**Warum?**
|
||
✓ Screen-Reader (Blinde/Sehbehinderte)
|
||
✓ SEO (Suchmaschinen)
|
||
✓ Fallback (Bild lädt nicht)
|
||
|
||
**PDF-Tags:** Strukturierte PDFs (Überschriften, Listen)
|
||
→ Screen-Reader kann navigieren
|
||
|
||
**Video:** Closed Captions (CC), Audio Descriptions
|
||
|
||
<!--
|
||
Alt-Text: Beschreibt Bild für Blinde (Screen-Reader liest vor)
|
||
Schlechter Alt-Text: "Bild123.jpg" (nutzlos!)
|
||
Guter Alt-Text: Beschreibend, kontextbezogen
|
||
PDF-Tags: "Tagged PDF" vs. "Untagged PDF"
|
||
Untagged: Für Screen-Reader oft unbrauchbar (nur Textstrom)
|
||
WCAG = Web Content Accessibility Guidelines (W3C)
|
||
ADA = Americans with Disabilities Act (USA, rechtlich)
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: Metadaten analysieren & entfernen
|
||
|
||
**Aufgabe (40 Min):**
|
||
|
||
**Teil 1: EXIF (20 Min)**
|
||
1. Nimm Foto (oder nutze altes)
|
||
2. Analysiere: `exiftool foto.jpg` oder metapicz.com
|
||
3. Notiere: GPS? Kamera-Modell? Software?
|
||
4. Entferne: `exiftool -all= foto.jpg`
|
||
5. Vergleiche Dateigrößen
|
||
|
||
**Teil 2: ID3 (20 Min)**
|
||
1. Nimm MP3-Datei
|
||
2. Analysiere: Kid3, mp3tag, oder exiftool
|
||
3. Ändere Tags (z.B. falscher Artist)
|
||
4. Optional: MusicBrainz Picard (Auto-Tagging)
|
||
|
||
<!--
|
||
exiftool: Command-Line, mächtig (alle Metadaten-Formate)
|
||
metapicz.com: Online, einfach
|
||
Dateigröße: EXIF-Daten können 10-50 KB sein
|
||
GPS-Schock: Viele wissen nicht, dass GPS gespeichert wird
|
||
Kid3: GUI, Cross-Platform
|
||
MusicBrainz Picard: Audio-Fingerprinting in Aktion
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 4: Zukunft
|
||
## Trends & Ausblick
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Futuristisches Rechenzentrum
|
||
DNA-Helix überlagert
|
||
-->
|
||
|
||
---
|
||
|
||
# AI-basierte Kompression
|
||
|
||
**Problem:** JPEG/H.264 basieren auf 90er-Jahre-Modellen
|
||
|
||
**Neue Ansätze:**
|
||
|
||
1. **Neuronale Bild-Kompression:**
|
||
- Deep Learning lernt Kompression/Dekompression
|
||
- Google's "Learned Image Compression" (2018)
|
||
- Outperforms JPEG bei gleicher Größe
|
||
|
||
2. **Generative Kompression:**
|
||
- Encoder extrahiert semantische Features
|
||
- Decoder generiert Bild neu (wie DALL-E)
|
||
- **99%+ Kompression**, aber nicht bit-genau!
|
||
|
||
**Problem:** Hoher Rechenaufwand, keine Standardisierung
|
||
|
||
<!--
|
||
AI-Kompression: Neuronale Netze statt handcrafted Algorithmen
|
||
Google: Variational Autoencoders (VAEs) für Kompression
|
||
Generative: "Ein Golden Retriever im Wald" → Neu generiert
|
||
Nicht bit-genau: Akzeptabel für Streaming, nicht für Archivierung
|
||
GPU/NPU nötig: Noch nicht Consumer-ready
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
JPEG XL Logo
|
||
Moderner JPEG-Nachfolger
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG XL: Der moderne JPEG
|
||
|
||
**JPEG XL (2021, ISO-Standard):**
|
||
|
||
**Ziele:**
|
||
✓ 60% besser als JPEG
|
||
✓ Besser als WebP/AVIF (manchmal)
|
||
✓ Lossless UND Lossy
|
||
✓ Progressive Decoding (wie klassisches JPEG)
|
||
✓ Rückwärtskompatibel (JPEG → JPEG XL "Wrapper")
|
||
|
||
**Features:** HDR, Animation (wie GIF, aber besser)
|
||
|
||
**Status 2025:** Browser-Support langsam (Safari ja, Chrome on-off)
|
||
|
||
**Problem:** Google favorisiert WebP/AVIF → politischer Kampf
|
||
|
||
<!--
|
||
JPEG XL = JXL
|
||
Cloudinary, Facebook testeten JXL (positive Ergebnisse)
|
||
Chrome entfernte Support 2022, Re-Add-Diskussion 2024
|
||
Safari (WebKit): Support seit 2022
|
||
Technisch überlegen, aber Standards sterben an Politik
|
||
-->
|
||
|
||
---
|
||
|
||
# AV1 & VVC: Codec-Krieg
|
||
|
||
**AV1 (Alliance for Open Media):**
|
||
✓ Etabliert sich (YouTube 4K, Netflix)
|
||
✓ Hardware-Decoder in neuen GPUs/Smartphones
|
||
|
||
**VVC (H.266, 2020):**
|
||
- 50% besser als H.265
|
||
- **Aber:** Patent-Problem (mehrere Pools, unklare Kosten)
|
||
- Adoption gering
|
||
|
||
**LCEVC:** Add-on für existierende Codecs
|
||
|
||
**Zukunft:**
|
||
- AV2 (Nachfolger AV1) in Entwicklung
|
||
- ML integriert?
|
||
|
||
<!--
|
||
AV1: YouTube forciert (8K nur AV1)
|
||
VVC: Technisch brilliant, juristisch Albtraum (wie H.265)
|
||
LCEVC = Low Complexity Enhancement Video Coding
|
||
AV2: Alliance for Open Media arbeitet dran
|
||
ML: Neural Codecs (Google's "Neural Video Coding")
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
DNA-Storage-Konzept
|
||
Futuristisch, aber real
|
||
-->
|
||
|
||
---
|
||
|
||
# DNA-Storage
|
||
|
||
**Konzept:** Daten in DNA-Sequenzen
|
||
|
||
**Eigenschaften:**
|
||
- Speicherdichte: **215 Petabyte/Gramm**
|
||
- Haltbarkeit: Tausende Jahre
|
||
- Kosten: Aktuell $3.500/MB (sinkend)
|
||
|
||
**Beispiele:**
|
||
- Microsoft + Twist Bioscience
|
||
- Netflix "Biohackers"-Episode (2021)
|
||
- Harvard: Wikipedia (11 GB) in DNA (2017)
|
||
|
||
**Problem:** Synthese & Sequenzierung extrem langsam/teuer
|
||
|
||
**Anwendung:** Langzeitarchivierung (nicht Live-Daten)
|
||
|
||
<!--
|
||
DNA = A, T, G, C (4 Basen)
|
||
Kodierung: Binär → DNA (00=A, 01=T, 10=G, 11=C)
|
||
215 PB/g: Gesamte Internet-Daten in Schuhkarton
|
||
Haltbarkeit: Mammut-DNA 10.000+ Jahre alt, lesbar
|
||
Kosten: 2010 = $12.000/MB, 2021 = $3.500/MB (Exponentialfall)
|
||
Twist Bioscience: Kommerzielle DNA-Synthese
|
||
-->
|
||
|
||
---
|
||
|
||
# Holografischer Speicher
|
||
|
||
**Holographic Data Storage:**
|
||
|
||
**Prinzip:**
|
||
- Laser schreibt in 3D-Kristall (statt 2D-Oberfläche)
|
||
- Interferenzmuster speichert Bits
|
||
- Paralleler Zugriff (schnell!)
|
||
|
||
**Vorteile:**
|
||
✓ Hohe Dichte (Terabytes pro Disc)
|
||
✓ Schnelle Lesegeschwindigkeit
|
||
✓ Langlebig (50+ Jahre)
|
||
|
||
**Stand 2025:** Prototypen (Sony, InPhase †), Kommerzialisierung gescheitert
|
||
|
||
**Problem:** Teuer, Konkurrenz durch SSDs
|
||
|
||
<!--
|
||
Hologramm: 3D-Information in 2D-Medium
|
||
InPhase Technologies: Bankrott 2010 (zu früh)
|
||
Sony: Forschung läuft weiter
|
||
Terabyte-Discs: Waren Ziel (nie erreicht)
|
||
Konkurrenz: SSDs wurden billiger, schneller
|
||
-->
|
||
|
||
---
|
||
|
||
# Quantum Storage?
|
||
|
||
**Quantenspeicher:**
|
||
|
||
**Konzept:**
|
||
- Qubits statt klassische Bits
|
||
- Superposition: 0 UND 1 gleichzeitig
|
||
- Verschränkung: Qubits korreliert über Distanz
|
||
|
||
**Anwendung:**
|
||
- Nicht für klassische Daten (Qubits instabil)
|
||
- Quantum Key Distribution (QKD) für Kommunikation
|
||
- Zukunft: Quanten-RAM für Quantencomputer
|
||
|
||
**Stand 2025:** Experimentell, Speicherzeit Millisekunden
|
||
|
||
<!--
|
||
Qubits: Quantenbits (z.B. Photon-Polarisation, Elektron-Spin)
|
||
Superposition: Kollabiert bei Messung
|
||
Quantencomputer: IBM, Google, D-Wave
|
||
Speicherproblem: Dekohärenz (Qubits verlieren Zustand)
|
||
QKD: Abhör-sichere Kommunikation (Quantenmechanik garantiert)
|
||
"Immer 20 Jahre entfernt" (wie Fusion)
|
||
-->
|
||
|
||
---
|
||
|
||
# Web3 & Dezentraler Speicher
|
||
|
||
**IPFS, Filecoin, Arweave, Storj:**
|
||
|
||
**Idee:** Speicher ohne zentrale Server
|
||
|
||
**Filecoin (2017):**
|
||
- Blockchain-basiert
|
||
- User vermieten Festplatten-Platz
|
||
- Bezahlung in FIL (Kryptowährung)
|
||
|
||
**Arweave (2018):**
|
||
- "Permanent Storage"
|
||
- Einmalige Zahlung → Daten für immer (theoretisch)
|
||
|
||
**Kritik:**
|
||
❌ Langsam vs. AWS S3
|
||
❌ Teurer (oft)
|
||
❌ Keine Garantie (Nodes offline)
|
||
|
||
<!--
|
||
IPFS: Besprochen in Woche 7
|
||
Filecoin: Incentive-Layer für IPFS (Storage Market)
|
||
Arweave: Endowment-Modell (Zinsen finanzieren Storage)
|
||
Storj: S3-Äquivalent, verschlüsselt & verteilt
|
||
Hype vs. Reality: Viele gescheiterte Projekte
|
||
Legitime Use-Cases: NFT-Storage, Zensur-resistente Archivierung
|
||
-->
|
||
|
||
---
|
||
|
||
# Streaming-Zukunft
|
||
|
||
**Trends:**
|
||
|
||
**8K-Streaming:**
|
||
- 7680×4320 = 33 Megapixel/Frame
|
||
- Braucht 100+ Mbps (selbst mit AV1)
|
||
- Problem: Kaum Content, kaum TVs
|
||
|
||
**VR/AR-Streaming:**
|
||
- 2× 4K (pro Auge), 90-120 fps
|
||
- Latenz <20ms kritisch
|
||
- 5G + Edge Computing nötig
|
||
|
||
**Cloud Gaming:**
|
||
- Spiel im Rechenzentrum, Stream zu User
|
||
- Input-Lag = Todfeind (<50ms)
|
||
|
||
**Problem:** Physik (Lichtgeschwindigkeit!)
|
||
|
||
<!--
|
||
8K: YouTube unterstützt, aber wer hat 8K-Monitor?
|
||
VR: Meta Quest, Apple Vision Pro
|
||
Latenz: Lichtgeschwindigkeit ~300.000 km/s, aber Routing + Processing addiert sich
|
||
Edge Computing: Server näher an User (5G-Masten)
|
||
Cloud Gaming: Stadia gescheitert (2023 †), GeForce Now, Xbox Cloud
|
||
Input-Lag: Fiber ~5ms/1000km, aber Server-Processing + Encoding + Decoding
|
||
-->
|
||
|
||
---
|
||
|
||
# Nachhaltigkeit
|
||
|
||
**Digitalisierung ≠ Umweltfreundlich**
|
||
|
||
**Rechenzentren:**
|
||
- 2024: 1-2% globaler Stromverbrauch (steigend!)
|
||
- Kühlung, Server, Netzwerk
|
||
|
||
**Streaming:**
|
||
- 1h Netflix (HD): ~3 GB, ~0,1 kWh
|
||
- × Milliarden Stunden = massiver CO₂
|
||
|
||
**E-Waste:**
|
||
- Smartphones: 2-3 Jahre Lebensdauer
|
||
- SSDs, HDDs: Nicht ewig
|
||
|
||
**Lösungen:**
|
||
- Effizientere Codecs (weniger Bandbreite)
|
||
- Renewable Energy für Rechenzentren
|
||
- Längere Hardware-Lebensdauer (Right to Repair!)
|
||
|
||
<!--
|
||
Stromverbrauch: AI-Training + Crypto-Mining steigend
|
||
Netflix: 2019 Studie (umstritten, aber Größenordnung)
|
||
E-Waste: 53,6 Mio. Tonnen/Jahr (2019, UN)
|
||
Right to Repair: EU-Gesetze, Apple-Widerstand
|
||
Effizienz: AV1 spart 30% Bandbreite vs. H.264
|
||
Green Data Centers: Island (Geothermie), Nordics (Wasserkraft)
|
||
-->
|
||
|
||
---
|
||
|
||
# Regulierung & Standardisierung
|
||
|
||
**Wer entscheidet?**
|
||
|
||
**Standards-Organisationen:**
|
||
- ISO/IEC (International)
|
||
- IETF (Internet-Protokolle)
|
||
- W3C (Web-Standards)
|
||
- IEEE (Hardware)
|
||
|
||
**Problem:** Industrie-Dominanz
|
||
- MPEG-LA (Patent-Pools)
|
||
- USB-IF (Intel-dominiert)
|
||
- HDMI Forum (Consumer-Electronics)
|
||
|
||
**EU-Regulierung:**
|
||
- USB-C-Pflicht (ab 2024)
|
||
- DMA (Digital Markets Act): Interoperabilität
|
||
- GDPR: Datenschutz (betrifft Metadaten!)
|
||
|
||
**Zukunft:** Mehr Open Standards? Oder Fragmentierung?
|
||
|
||
<!--
|
||
ISO/IEC: Internationale Standards (JPEG, MPEG, etc.)
|
||
IETF: RFCs (HTTP, TLS, etc.)
|
||
W3C: HTML, CSS, Web-APIs
|
||
IEEE: Ethernet, Wi-Fi
|
||
Patent-Pools: Kartelle? Oder notwendige Koordination?
|
||
USB-C-Pflicht: EU zwang Apple (iPhone 15)
|
||
DMA: Zwingt Big Tech zu Interoperabilität (Messenger)
|
||
GDPR: Privacy by Design
|
||
-->
|
||
|
||
---
|
||
|
||
# Fallstudie: Gruppenarbeit
|
||
|
||
**Aufgabe (90 Min, ca. 5 Personen):**
|
||
|
||
**Szenario:** Mittelständisches Medienunternehmen produziert Videos
|
||
|
||
**Erarbeitet Konzept für:**
|
||
1. Speichermedien (intern/extern, kurz-/langfristig)
|
||
2. Dateiformate (Produktion, Distribution, Archivierung)
|
||
3. Dateisysteme (welche für was?)
|
||
4. Schnittstellen (SATA, USB, PCIe, Netzwerk)
|
||
5. Distributionswege (NAS, Cloud, FTP)
|
||
6. Backup-Strategie (3-2-1-Regel!)
|
||
|
||
**Ergebnis:** Konzeptpapier (Mindmap, Tabelle, Poster)
|
||
**Präsentation:** 5 Min pro Gruppe
|
||
|
||
<!--
|
||
Praxisnahe Anwendung aller Themen
|
||
Gruppenarbeit: Peer-Learning
|
||
Szenarien vorgeben (Vorgänger-Skript hatte 6)
|
||
Alternativen: Stadtarchiv, Agentur, Hochschul-Mediathek, Fotografin, Reporterteam
|
||
Bewertung: Technische Korrektheit, Begründung, Kreativität
|
||
-->
|
||
|
||
---
|
||
|
||
# Alternative Szenarien (Auswahl)
|
||
|
||
1. **Mittelständisches Medienunternehmen** (Videos, Streaming)
|
||
2. **Kommunales Stadtarchiv** (Digitalisierung historischer Bestände)
|
||
3. **Agentur für digitale Kommunikation** (internationale Kampagne)
|
||
4. **Digitale Hochschul-Mediathek** (Lehrvideos, Podcasts)
|
||
5. **Freiberufliche Fotografin** (Tausende RAW-Fotos/Jahr)
|
||
6. **Internationales Reporterteam** (investigative Recherche, sensibel)
|
||
|
||
**Jede Gruppe wählt ein Szenario**
|
||
|
||
<!--
|
||
Verschiedene Complexity-Level
|
||
Stadtarchiv: Langzeitarchivierung-Fokus
|
||
Agentur: Collaboration-Fokus
|
||
Fotografin: Solo-Workflow
|
||
Reporterteam: Security-Fokus (Verschlüsselung!)
|
||
Gruppen wählen selbst (Interesse)
|
||
-->
|
||
|
||
---
|
||
|
||
# Was wir insgesamt gelernt haben
|
||
|
||
✓ **Bits → Formate:** Encoding, Kompression (MP3, JPEG, H.264)
|
||
✓ **Speicher:** HDD, SSD, Dateisysteme, Backup, Archivierung
|
||
✓ **Schnittstellen:** USB-C, HDMI, DisplayPort, Ethernet
|
||
✓ **Distribution:** CDN, P2P, Streaming, APIs
|
||
✓ **Metadaten:** EXIF, ID3, Privacy, Interoperabilität
|
||
✓ **Zukunft:** AI-Kompression, DNA-Storage, Nachhaltigkeit
|
||
|
||
**Kernbotschaft:**
|
||
Digitale Medien sind das Ergebnis von Standards, Politik, Kompromissen & Innovation.
|
||
|
||
Ihr habt jetzt die Werkzeuge, um die digitale Welt kritisch zu verstehen.
|
||
|
||
<!--
|
||
5 Termine = Intensive Journey
|
||
Von Grundlagen zu Zukunft
|
||
Technologie ist nicht neutral (Patent-Kriege, Vendor Lock-in)
|
||
Kritisches Denken: Wer profitiert? Wer wird ausgeschlossen?
|
||
Hands-On: Praktische Fähigkeiten (Hex-Editor, FFmpeg, exiftool)
|
||
-->
|
||
|
||
---
|
||
|
||
# Weiterführende Ressourcen
|
||
|
||
**Bücher:**
|
||
- "Code" – Charles Petzold (Basics)
|
||
- "Understanding Digital Signal Processing" – Richard Lyons
|
||
|
||
**Websites:**
|
||
- IETF RFCs (ietf.org)
|
||
- FFmpeg Documentation (ffmpeg.org)
|
||
- Protocol Labs (IPFS, Filecoin)
|
||
|
||
**YouTube:**
|
||
- Computerphile (Kompression, Encoding)
|
||
- Branch Education (Hardware-Visualisierungen)
|
||
|
||
**Podcasts:**
|
||
- Command Line Heroes (Red Hat)
|
||
|
||
**Tools:** MediaInfo, exiftool, FFmpeg, Wireshark
|
||
|
||
<!--
|
||
Petzold "Code": Beste Einführung in Computer-Grundlagen
|
||
Lyons: Für Audio/Video-Kompression (mathematisch)
|
||
IETF RFCs: Primärquellen (HTTP, TLS, etc.)
|
||
Computerphile: Tom Scott, Mike Pound (hervorragend!)
|
||
Branch Education: 3D-Animationen (SSD, CPU...)
|
||
Command Line Heroes: Tech-Geschichte (Spotify, Apple Podcasts)
|
||
-->
|
||
|
||
---
|
||
|
||
# Abschluss & Dank
|
||
|
||
**Ihr habt gelernt:**
|
||
- Dateien zu lesen (Hex, Metadaten)
|
||
- Formate zu vergleichen (JPEG vs. PNG, H.264 vs. AV1)
|
||
- Infrastruktur zu verstehen (CDN, P2P, APIs)
|
||
- Kritisch zu denken (Open Standards, Lock-in, Nachhaltigkeit)
|
||
|
||
**Nächste Schritte:**
|
||
- Fallstudie (falls Prüfungsleistung)
|
||
- Feedback willkommen (E-Mail)
|
||
- Weiterlernen mit Ressourcen
|
||
|
||
**Vielen Dank für eure Aufmerksamkeit!**
|
||
|
||
<!--
|
||
5 Termine gemeinsame Reise
|
||
Von "Was sind Bits?" zu "DNA-Storage"
|
||
Hands-On jedes Mal (Hex-Editor, FFmpeg, exiftool, APIs)
|
||
Narrative statt Faktenlisten (Suzanne Vega, John McAfee, Tony Blair)
|
||
Kritische Perspektive (Patent-Kriege, Vendor Lock-in)
|
||
Evaluation: Feedback ernst nehmen, Kurs verbessern
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
||
|
||
---
|
||
|
||
# Lizenz & Attribution
|
||
|
||
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
|
||
|
||
- Erlaubt Teilen & Anpassen mit Namensnennung
|
||
- Adaptionen müssen unter gleicher Lizenz geteilt werden
|
||
|
||
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
|
||
|