split klausurfragen into per-course files and add erklaerung slides to 223015c
- split slides/klausurfragen.md into course-specific files: - slides/223015b/klausurfragen.md (blocks J-O: dateiformate) - slides/223015c/klausurfragen.md (blocks A-I: it-grundlagen) - add erklaerung slides to 223015c (16 new vertiefung slides) - update erklaerung slides in 223015b with deeper content - update makefile to build klausurfragen per-course - remove global klausurfragen from root index
This commit is contained in:
@@ -68,6 +68,38 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -652,6 +684,28 @@ PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Von-Neumann-Architektur – Vertiefung
|
||||
|
||||
John von Neumann beschrieb 1945 im „First Draft of a Report on the EDVAC" das Prinzip des **Stored Program Computer**: Programme und Daten teilen sich denselben Speicher und sind damit austauschbar, ohne Hardware-Änderungen.
|
||||
|
||||
**Die 5 Komponenten im Detail:**
|
||||
|
||||
| Komponente | Moderne Entsprechung | Funktion |
|
||||
|------------|---------------------|----------|
|
||||
| Rechenwerk (ALU) | CPU-Kern | Addition, Subtraktion, Logik (AND, OR, NOT) |
|
||||
| Steuerwerk | CPU-Kern | Fetch-Decode-Execute-Zyklus |
|
||||
| Speicherwerk | RAM + ROM | Einheitlicher Adressraum für Code + Daten |
|
||||
| Ein-/Ausgabe | I/O-Controller | USB, PCIe, Netzwerk |
|
||||
| Bus-System | Northbridge/Southbridge (heute: SoC) | Adress-, Daten-, Steuerbus |
|
||||
|
||||
**Von-Neumann-Flaschenhals:** CPU und Speicher teilen einen Bus – die Bandbreite begrenzt die Geschwindigkeit. Moderne CPUs umgehen dies durch Caches (L1/L2/L3), die als Harvard-ähnliche Puffer dienen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -689,6 +743,33 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Stored Program Concept – Vertiefung
|
||||
|
||||
Vor Von Neumann mussten Computer für jedes Problem neu verkabelt werden (ENIAC: tagelange Arbeit). Das **Stored Program Concept** machte Programme zu Daten – austauschbar wie Dokumente.
|
||||
|
||||
**Konsequenzen für die Software-Industrie:**
|
||||
- **Betriebssysteme** möglich: Laden verschiedene Programme aus demselben Speicher
|
||||
- **Updates** ohne Hardware-Austausch: Nur Bits ändern, nicht Kabel
|
||||
- **Multitasking**: Mehrere Programme gleichzeitig im Speicher
|
||||
- **Self-Modifying Code**: Programme können sich selbst ändern (Compiler, JIT)
|
||||
|
||||
**Harvard-Architektur (Alternative):**
|
||||
|
||||
| Aspekt | Von Neumann | Harvard |
|
||||
|--------|-------------|---------|
|
||||
| Speicher | Gemeinsam für Code + Daten | Getrennt |
|
||||
| Busse | Ein Bus (Flaschenhals) | Paralleler Zugriff |
|
||||
| Flexibilität | Hoch (Code = Daten) | Geringer |
|
||||
| Einsatz | Desktop, Server, Smartphone | DSP, Mikrocontroller |
|
||||
|
||||
**Modern:** „Modified Harvard" – L1-Cache trennt Code/Daten (Speed), RAM bleibt gemeinsam (Flexibilität).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Vom Militär zum Netz
|
||||
@@ -1117,6 +1198,34 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTML Metadaten – Vertiefung
|
||||
|
||||
Der `<head>`-Bereich enthält Informationen *über* das Dokument, nicht den sichtbaren Inhalt. Diese Metadaten steuern Browser-Verhalten, Suchmaschinen-Indexierung und Social-Media-Vorschauen.
|
||||
|
||||
**Kritische Meta-Tags:**
|
||||
|
||||
| Tag | Funktion | Beispiel |
|
||||
|-----|----------|----------|
|
||||
| `<title>` | Browser-Tab, Suchergebnis-Titel | `<title>HdM Stuttgart</title>` |
|
||||
| `<meta charset>` | Zeichenkodierung (Umlaute!) | `<meta charset="UTF-8">` |
|
||||
| `<meta viewport>` | Mobile Darstellung | `width=device-width, initial-scale=1` |
|
||||
| `<meta description>` | Suchergebnis-Snippet (max 160 Zeichen) | SEO-kritisch |
|
||||
|
||||
**Open Graph Protocol (Facebook, 2010):**
|
||||
```html
|
||||
<meta property="og:title" content="Artikel-Titel">
|
||||
<meta property="og:image" content="https://example.com/preview.jpg">
|
||||
```
|
||||
Steuert die Vorschau beim Teilen auf Facebook, LinkedIn, WhatsApp, Slack.
|
||||
|
||||
**SEO-Relevanz:** Google nutzt `<title>` und `<meta description>` für Ranking und Snippet-Anzeige. Fehlende Metadaten = schlechtere Auffindbarkeit.
|
||||
|
||||
---
|
||||
|
||||
# HTML-Tags und Attribute
|
||||
|
||||
```html
|
||||
@@ -1340,6 +1449,33 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Web-Zugänglichkeit – Vertiefung
|
||||
|
||||
**a11y** = Accessibility (a + 11 Buchstaben + y). Die WHO schätzt, dass 15% der Weltbevölkerung eine Behinderung haben – das sind über 1 Milliarde potenzielle Nutzer.
|
||||
|
||||
**Arten von Einschränkungen:**
|
||||
|
||||
| Typ | Permanent | Temporär | Situativ |
|
||||
|-----|-----------|----------|----------|
|
||||
| Visuell | Blindheit | Nach Augen-OP | Grelle Sonne |
|
||||
| Motorisch | Amputation | Gebrochener Arm | Baby auf dem Arm |
|
||||
| Auditiv | Taubheit | Ohrenentzündung | Laute Umgebung |
|
||||
| Kognitiv | Legasthenie | Müdigkeit | Ablenkung |
|
||||
|
||||
**Assistive Technologien:**
|
||||
- **Screenreader:** NVDA (Windows, kostenlos), VoiceOver (Apple, integriert), JAWS (kommerziell)
|
||||
- **Braillezeilen:** Taktile Ausgabe, ~40–80 Zeichen
|
||||
- **Switch-Geräte:** Ein-Knopf-Steuerung für motorische Einschränkungen
|
||||
- **Eye-Tracking:** Blicksteuerung für Bewegungsunfähige
|
||||
|
||||
Screenreader lesen den DOM sequenziell – semantisches HTML (`<nav>`, `<main>`, `<button>`) ermöglicht Navigation per Tastenkürzel.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1379,6 +1515,35 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Rechtliche Anforderungen – Vertiefung
|
||||
|
||||
Der **European Accessibility Act (EAA)** trat am 28. Juni 2025 in Kraft und betrifft erstmals auch private Unternehmen – nicht nur öffentliche Stellen.
|
||||
|
||||
**Betroffene Sektoren:**
|
||||
- E-Commerce (Online-Shops)
|
||||
- Bankdienstleistungen
|
||||
- Telekommunikation
|
||||
- E-Books und E-Reader
|
||||
- Ticketing und Check-in-Terminals
|
||||
|
||||
**WCAG 2.2 – Konformitätsstufen:**
|
||||
|
||||
| Level | Anforderung | Beispiel |
|
||||
|-------|-------------|----------|
|
||||
| A | Minimum | Alt-Texte für Bilder |
|
||||
| AA | Gesetzlicher Standard | Kontrast 4,5:1, Tastaturnavigation |
|
||||
| AAA | Optimal | Gebärdensprache für Videos |
|
||||
|
||||
**Curb-Cut-Effekt:** Barrierefreiheit hilft allen. Bordsteinabsenkungen für Rollstühle nutzen auch Kinderwagen, Rollkoffer, Fahrräder. Untertitel helfen Gehörlosen, aber auch in lauten Umgebungen oder beim Sprachlernen.
|
||||
|
||||
**Sanktionen:** Bis zu 100.000 € Bußgeld bei Verstößen.
|
||||
|
||||
---
|
||||
|
||||
# WCAG: Der Standard
|
||||
|
||||
**W**eb **C**ontent **A**ccessibility **G**uidelines
|
||||
@@ -1532,6 +1697,38 @@ Echte NutzerInnen einbeziehen = Gold-Standard
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Barrierefreiheit testen – Vertiefung
|
||||
|
||||
Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erfordert manuelles Testen und idealerweise echte Nutzer mit Behinderungen.
|
||||
|
||||
**Tastatur-Test (5 Minuten, jeder kann's):**
|
||||
1. Maus weglegen, nur Tab + Enter + Pfeiltasten nutzen
|
||||
2. Fokus-Indikator immer sichtbar? (kein `outline: none;`!)
|
||||
3. Logische Reihenfolge? (nicht kreuz und quer)
|
||||
4. Alle interaktiven Elemente erreichbar?
|
||||
|
||||
**Automatisierte Tools:**
|
||||
|
||||
| Tool | Typ | Findet |
|
||||
|------|-----|--------|
|
||||
| axe DevTools | Browser-Extension | ~30% der WCAG-Verstöße |
|
||||
| WAVE | Browser-Extension | Struktur-Probleme, Kontrast |
|
||||
| Lighthouse | Chrome DevTools | Performance + Accessibility |
|
||||
| Pa11y | CLI | CI/CD-Integration |
|
||||
|
||||
**Screenreader-Kurztest:**
|
||||
- macOS: `Cmd + F5` (VoiceOver)
|
||||
- Windows: NVDA installieren (kostenlos)
|
||||
- Augen schließen, nur zuhören: Ist die Seite verständlich?
|
||||
|
||||
**Gold-Standard:** Usability-Tests mit Menschen, die Assistive Technologien täglich nutzen.
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
|
||||
@@ -71,6 +71,38 @@ section.aufgabe footer {
|
||||
section.glossar {
|
||||
font-size: 1.4rem;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -402,6 +434,31 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP/IP-Modell – Vertiefung
|
||||
|
||||
Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
|
||||
|
||||
**Schicht-Aufgaben im Detail:**
|
||||
|
||||
| Schicht | Frage | Protokolle | Geräte |
|
||||
|---------|-------|------------|--------|
|
||||
| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
|
||||
| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
|
||||
| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
|
||||
| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
|
||||
|
||||
**OSI vs. TCP/IP:**
|
||||
- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
|
||||
- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
|
||||
|
||||
**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
|
||||
|
||||
---
|
||||
|
||||
# Schichten verpacken Daten
|
||||
|
||||
```
|
||||
@@ -461,6 +518,33 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Dateneinheiten & Encapsulation – Vertiefung
|
||||
|
||||
**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
|
||||
|
||||
**Was jeder Header enthält:**
|
||||
|
||||
| Schicht | Einheit | Header-Inhalte |
|
||||
|---------|---------|----------------|
|
||||
| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
|
||||
| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
|
||||
| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
|
||||
| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
|
||||
|
||||
**Overhead-Rechnung (1 Byte HTTP-Body):**
|
||||
- Ethernet: 14 + 4 Bytes (Header + Trailer)
|
||||
- IP: 20 Bytes (ohne Optionen)
|
||||
- TCP: 20 Bytes (ohne Optionen)
|
||||
- **Minimum: 58 Bytes für 1 Byte Nutzlast**
|
||||
|
||||
**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
|
||||
|
||||
---
|
||||
|
||||
# Warum ist das clever?
|
||||
|
||||
**Ohne Schichten:**
|
||||
@@ -640,6 +724,34 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# IP, MAC, Port – Vertiefung
|
||||
|
||||
Drei Adressebenen lösen drei verschiedene Probleme:
|
||||
|
||||
**IP-Adresse (Schicht 2 – Internet):**
|
||||
- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
|
||||
- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
|
||||
- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
|
||||
|
||||
**MAC-Adresse (Schicht 1 – Netzzugang):**
|
||||
- 48 Bit, vom Hersteller fest vergeben (theoretisch)
|
||||
- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
|
||||
- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
|
||||
- ARP (Address Resolution Protocol) übersetzt IP → MAC
|
||||
|
||||
**Port (Schicht 3 – Transport):**
|
||||
- 16 Bit → 65.535 mögliche Ports
|
||||
- Well-Known Ports (0–1023): HTTP=80, HTTPS=443, SSH=22
|
||||
- Ephemeral Ports (49152–65535): Dynamisch für Client-Verbindungen
|
||||
|
||||
**Warum ändert sich nur MAC?** IP ist das Endziel (Brief-Adresse), MAC ist der aktuelle Bote (wer trägt den Brief gerade?).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Die Reise eines Klicks
|
||||
@@ -922,6 +1034,36 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-Way-Handshake – Vertiefung
|
||||
|
||||
Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
|
||||
|
||||
**Warum zufällige Startwerte (ISN)?**
|
||||
- Sicherheit: Verhindert Session-Hijacking durch Raten
|
||||
- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
|
||||
- ISN = Initial Sequence Number, vom OS zufällig gewählt
|
||||
|
||||
**TCP-Flags im Handshake:**
|
||||
|
||||
| Paket | Flags | Bedeutung |
|
||||
|-------|-------|-----------|
|
||||
| 1 | SYN | Client will Verbindung, sendet seine ISN |
|
||||
| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 |
|
||||
| 3 | ACK | Client bestätigt Server-ISN+1 |
|
||||
|
||||
**Was passiert bei Problemen?**
|
||||
- Kein SYN-ACK → Client wiederholt SYN (Timeout)
|
||||
- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft
|
||||
- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt)
|
||||
|
||||
**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch.
|
||||
|
||||
---
|
||||
|
||||
# Nach dem Handshake
|
||||
|
||||
**Status:** Die TCP-Verbindung steht.
|
||||
@@ -1429,6 +1571,38 @@ SPEAKER NOTES:
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP vs. UDP – Vertiefung
|
||||
|
||||
Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
|
||||
|
||||
**TCP (Transmission Control Protocol):**
|
||||
- Verbindungsorientiert (Handshake vor Daten)
|
||||
- Sequenznummern → Reihenfolge garantiert
|
||||
- ACKs + Retransmission → Kein Datenverlust
|
||||
- Flow Control (Sliding Window) → Empfänger nicht überlasten
|
||||
- Congestion Control → Netzwerk nicht überlasten
|
||||
|
||||
**UDP (User Datagram Protocol):**
|
||||
- Verbindungslos (Fire-and-Forget)
|
||||
- Keine Sequenznummern, keine ACKs
|
||||
- Header nur 8 Bytes (TCP: 20+ Bytes)
|
||||
- Anwendung muss selbst für Zuverlässigkeit sorgen
|
||||
|
||||
| Anwendung | Protokoll | Grund |
|
||||
|-----------|-----------|-------|
|
||||
| HTTP/HTTPS | TCP | Vollständigkeit kritisch |
|
||||
| DNS | UDP | Kleine Pakete, schnelle Antwort |
|
||||
| Video-Streaming | UDP/QUIC | Latenz wichtiger als Perfektion |
|
||||
| Online-Gaming | UDP | Echtzeit, veraltete Daten nutzlos |
|
||||
|
||||
**QUIC:** Googles Protokoll kombiniert UDP-Geschwindigkeit mit TCP-ähnlicher Zuverlässigkeit (HTTP/3).
|
||||
|
||||
---
|
||||
|
||||
# Warum UDP bei Video-Calls?
|
||||
|
||||
**Szenario:** Ein Paket geht verloren.
|
||||
|
||||
| TCP | UDP |
|
||||
|-----|-----|
|
||||
| Warten... neu anfordern... warten... | Ignorieren, nächstes Frame zeigen |
|
||||
| Video friert ein | Kurzes Artefakt |
|
||||
@@ -1508,6 +1682,37 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP-Methoden – Vertiefung
|
||||
|
||||
HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
|
||||
|
||||
**CRUD-Mapping (Create, Read, Update, Delete):**
|
||||
|
||||
| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
|
||||
|---------|------|------------|------|-------------------|
|
||||
| GET | Read | Ja | Ja | Ressource abrufen |
|
||||
| POST | Create | Nein | Nein | Formular, neue Ressource |
|
||||
| PUT | Update | Ja | Nein | Ressource vollständig ersetzen |
|
||||
| PATCH | Update | Nein | Nein | Ressource teilweise ändern |
|
||||
| DELETE | Delete | Ja | Nein | Ressource löschen |
|
||||
|
||||
**Idempotent:** Mehrfaches Ausführen hat denselben Effekt wie einmaliges (GET, PUT, DELETE).
|
||||
**Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
|
||||
|
||||
**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
|
||||
```
|
||||
GET /users/42 → Benutzer 42 abrufen
|
||||
PUT /users/42 → Benutzer 42 vollständig ersetzen
|
||||
DELETE /users/42 → Benutzer 42 löschen
|
||||
POST /users → Neuen Benutzer erstellen
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP Status-Codes
|
||||
|
||||
```http
|
||||
HTTP/1.1 200 OK
|
||||
@@ -1543,6 +1748,31 @@ Status-Codes sagen euch, was passiert ist.
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP Status-Codes – Vertiefung
|
||||
|
||||
Die erste Ziffer kategorisiert die Antwort:
|
||||
|
||||
| Bereich | Kategorie | Häufige Codes |
|
||||
|---------|-----------|---------------|
|
||||
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
|
||||
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
|
||||
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
|
||||
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
|
||||
| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
|
||||
|
||||
**Wichtige Unterscheidungen:**
|
||||
- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
|
||||
- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
|
||||
- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
|
||||
|
||||
**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Zusammenfassung Teil 1
|
||||
|
||||
**Der Ablauf:**
|
||||
1. DNS (UDP:53) → Name zu IP
|
||||
@@ -1579,6 +1809,40 @@ Wie Encapsulation funktioniert.
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Netzwerk-Grundlagen – Vertiefung
|
||||
|
||||
Die vier Kernkonzepte für Web-Entwickler:
|
||||
|
||||
**1. DNS-Auflösung:**
|
||||
- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
|
||||
- Rekursive Abfrage: Root → TLD → Authoritative
|
||||
- Caching auf jeder Ebene (TTL = Time To Live)
|
||||
|
||||
**2. TCP-Verbindungsaufbau:**
|
||||
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
|
||||
- Keep-Alive: Verbindung bleibt offen für mehrere Requests
|
||||
- HTTP/2: Multiplexing – viele Requests über eine Verbindung
|
||||
|
||||
**3. HTTP Request/Response:**
|
||||
```
|
||||
Request: Methode + URL + Header + (Body)
|
||||
Response: Status + Header + Body
|
||||
```
|
||||
|
||||
**4. Schichten & Adressen:**
|
||||
| Was bleibt gleich? | Was ändert sich? |
|
||||
|-------------------|------------------|
|
||||
| Ziel-IP | MAC-Adressen (bei jedem Hop) |
|
||||
| Ports | – |
|
||||
|
||||
**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
|
||||
|
||||
---
|
||||
|
||||
# Werkzeuge zum Selbst-Erkunden
|
||||
|
||||
**Im Browser (F12 → Network-Tab):**
|
||||
- Jeder Request sichtbar
|
||||
- Timing, Headers, Response
|
||||
|
||||
**Im Terminal:**
|
||||
```bash
|
||||
@@ -1870,6 +2134,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
|
||||
<!-- _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
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
│ margin │
|
||||
│ ┌─────────────────────────────┐ │
|
||||
│ │ border │ │
|
||||
│ │ ┌─────────────────────┐ │ │
|
||||
@@ -2117,6 +2408,37 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Responsive Design – Vertiefung
|
||||
|
||||
**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
|
||||
|
||||
**Breakpoints (gängige Werte):**
|
||||
|
||||
| Breakpoint | Gerät | Media Query |
|
||||
|------------|-------|-------------|
|
||||
| < 576px | Smartphone (Portrait) | Basis (kein Query) |
|
||||
| ≥ 576px | Smartphone (Landscape) | `@media (min-width: 576px)` |
|
||||
| ≥ 768px | Tablet | `@media (min-width: 768px)` |
|
||||
| ≥ 992px | Desktop | `@media (min-width: 992px)` |
|
||||
| ≥ 1200px | Large Desktop | `@media (min-width: 1200px)` |
|
||||
|
||||
**Viewport-Meta-Tag (kritisch!):**
|
||||
```html
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
```
|
||||
Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
|
||||
|
||||
**Moderne Alternativen zu Media Queries:**
|
||||
- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
|
||||
- Container Queries: Reagieren auf Container-Größe statt Viewport
|
||||
- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
|
||||
|
||||
---
|
||||
|
||||
# Zusammenfassung CSS
|
||||
|
||||
**Selektoren:**
|
||||
- Element: `p`
|
||||
- Klasse: `.wichtig`
|
||||
- ID: `#header`
|
||||
- Kombinationen: `nav > a`, `h2 + p`
|
||||
|
||||
|
||||
973
slides/223015c/klausurfragen.md
Normal file
973
slides/223015c/klausurfragen.md
Normal file
@@ -0,0 +1,973 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: ""
|
||||
footer: ""
|
||||
title: "Fragenkatalog – IT-Grundlagen (223015c)"
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #d63384;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert {
|
||||
--color-foreground: #fff;
|
||||
}
|
||||
section {
|
||||
font-size: 1.325rem;
|
||||
}
|
||||
h1 {
|
||||
color: #a02060; /* darker raspberry */
|
||||
}
|
||||
section.invert h1 {
|
||||
color: #fff;
|
||||
}
|
||||
h2 {
|
||||
color: #1f2937; /* dark gray, almost black */
|
||||
}
|
||||
pre {
|
||||
background: #0f0f23;
|
||||
border-radius: 8px;
|
||||
}
|
||||
pre code {
|
||||
background: transparent;
|
||||
color: inherit;
|
||||
}
|
||||
a {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
section.disable {
|
||||
opacity: 0.3;
|
||||
}
|
||||
</style>
|
||||
|
||||
|
||||
# Klausurfragen – 223015c
|
||||
**IT-Grundlagen · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 01.02.2026</small>
|
||||
|
||||
---
|
||||
|
||||
> **Legende – Moodle XML-Typen:**
|
||||
> `[MC]` = `multichoice` (einzelne Auswahl)
|
||||
> `[MM]` = `multichoice` + `<single>false</single>` (Mehrfachauswahl)
|
||||
> `[MATCH]` = `matching` (Zuordnung)
|
||||
> `[ORDER]` = `ordering` (Reihenfolge)
|
||||
> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
|
||||
> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
|
||||
> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
|
||||
> `[CLOZE]` = `cloze` (Lückentext, gemischt)`
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK A – Von-Neumann-Architektur
|
||||
|
||||
---
|
||||
|
||||
### A1 – Komponenten zuordnen
|
||||
**Thema:** Von-Neumann Grundstruktur
|
||||
**Punkte:** 3
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.
|
||||
|
||||
| Komponente | Funktion |
|
||||
|---|---|
|
||||
| Rechenwerk (ALU) | Führt arithmetische und logische Operationen durch |
|
||||
| Steuerwerk | Holt, dekodiert und steuert die Ausführung von Befehlen |
|
||||
| Speicherwerk | Enthält sowohl Programme als auch Daten |
|
||||
| Ein-/Ausgabe | Schnittstelle zu externen Geräten (Tastatur, Bildschirm, Netzwerk) |
|
||||
| Bus-System | Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus |
|
||||
|
||||
> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### A2 – Welche Komponente ist das?
|
||||
**Thema:** Von-Neumann – einzelne Komponente identifizieren
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Ein Programm besteht aus einer Folge von Befehlen. Eine Komponente der Von-Neumann-Architektur ist für das Abrufen, Dekodieren und Ausführen dieser Befehle zuständig. Welche?
|
||||
|
||||
- [ ] Rechenwerk (ALU)
|
||||
- [x] **Steuerwerk** ✅
|
||||
- [ ] Speicherwerk
|
||||
- [ ] Ein-/Ausgabe
|
||||
|
||||
> **Feedback:** Das Steuerwerk (Control Unit) orchestriert den Fetch-Decode-Execute-Zyklus – es ist der „Dirigent" der CPU.
|
||||
|
||||
---
|
||||
|
||||
### A3 – Von-Neumann: Was wird ermöglicht?
|
||||
**Thema:** Von-Neumann – Bedeutung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MM]` (Mehrfachauswahl)
|
||||
|
||||
Welche der folgenden Aussagen werden durch die Von-Neumann-Architektur ermöglicht? (Mehrere Antworten möglich)
|
||||
|
||||
- [x] **Betriebssysteme können verschiedene Programme aus dem Speicher laden.** ✅
|
||||
- [x] **Apps können ohne Hardwareänderung installiert werden.** ✅
|
||||
- [ ] Der Computer kann nur ein einziges Programm gleichzeitig ausführen.
|
||||
- [x] **Multitasking wird möglich.** ✅
|
||||
- [ ] Die Hardware muss für jedes neue Programm physisch umgebaut werden.
|
||||
- [x] **Software kann aktualisiert werden, ohne die Hardware zu ändern.** ✅
|
||||
|
||||
> **Feedback:** Kern der Von-Neumann-Architektur: Programme und Daten teilen denselben Speicher → Programme sind austauschbare Daten. Ohne das: kein Betriebssystem, keine Apps, kein Multitasking, keine Updates.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK B – Netzwerk-Grundlagen (TCP/IP)
|
||||
|
||||
---
|
||||
|
||||
### B1 – Protokoll → TCP/IP-Schicht zuordnen
|
||||
**Thema:** TCP/IP-Schichtmodell – Zuordnung
|
||||
**Punkte:** 3
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.
|
||||
|
||||
| Protokoll | Schicht |
|
||||
|----------|---|
|
||||
| HTTP | Anwendung |
|
||||
| DNS | Anwendung |
|
||||
| TCP | Transport |
|
||||
| UDP | Transport |
|
||||
| IP | Internet |
|
||||
| Ethernet | Netzzugang |
|
||||
| WLAN | Netzzugang |
|
||||
|
||||
> **Feedback:** Anwendung: HTTP, DNS, SMTP, FTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
|
||||
|
||||
---
|
||||
|
||||
### B2 – Welche Schicht ist das? (einzeln)
|
||||
**Thema:** TCP/IP – einzelne Schicht identifizieren
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Das Protokoll IP arbeitet auf welcher TCP/IP-Schicht?
|
||||
|
||||
- [ ] Anwendung
|
||||
- [ ] Transport
|
||||
- [x] **Internet** ✅
|
||||
- [ ] Netzzugang
|
||||
|
||||
> **Feedback:** IP (Internet Protocol) arbeitet auf der Internet-Schicht – dort werden Pakete adressiert und geroutet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### B3 – Schicht-Funktion beschreiben
|
||||
**Thema:** TCP/IP – Funktionen der Schichten
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Beschreibe in einem Satz pro Schicht die Hauptfunktion jeder der vier TCP/IP-Schichten (Anwendung, Transport, Internet, Netzzugang).
|
||||
|
||||
> **Musterlösung:** Anwendung: Stellt Protokolle für spezifische Dienste bereit (HTTP für Web, SMTP für Mail). Transport: Sorgt für zuverlässige (TCP) oder schnelle (UDP) Übertragung zwischen zwei Endpunkten. Internet: Adressiert und routet Pakete über Netzwerkgrenzen hinweg mittels IP. Netzzugang: Übertragen von Frames auf einem physischen Übertragungsweg (Ethernet, WLAN).
|
||||
|
||||
---
|
||||
|
||||
### B4 – Was ist eine MAC-Adresse?
|
||||
**Thema:** MAC-Adresse – Konzept
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was identifiziert eine MAC-Adresse?
|
||||
|
||||
- [ ] Den konkreten Dienst (z. B. Webserver) auf einem Computer.
|
||||
- [ ] Den Computer im globalen Internet über Netzwerkgrenzen hinweg.
|
||||
- [x] **Die Netzwerkkarte eines Geräts auf einem lokalen Netzwerksegment.** ✅
|
||||
- [ ] Die Routen, die ein Paket durch das Internet nimmt.
|
||||
|
||||
> **Feedback:** MAC = Media Access Control. Sie ist eine 48-Bit-Adresse, die einer Netzwerkkarte ab Werk zugewiesen wird – lokal, ein Hop.
|
||||
|
||||
---
|
||||
|
||||
### B5 – Was ist eine IP-Adresse?
|
||||
**Thema:** IP-Adresse – Konzept
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was identifiziert eine IP-Adresse?
|
||||
|
||||
- [ ] Die Netzwerkkarte eines Geräts auf einem lokalen Segment.
|
||||
- [x] **Ein Gerät (Host) im globalen Internet – sie ermöglicht das Routing über Netzwerkgrenzen.** ✅
|
||||
- [ ] Den Dienst, der auf einem bestimmten Port läuft.
|
||||
- [ ] Die physische Leitung zwischen zwei Computern.
|
||||
|
||||
> **Feedback:** IP = Internet Protocol. Die IP-Adresse ist der globale „Hausnummer" eines Geräts – routing-tauglich, im Gegensatz zur lokalen MAC-Adresse.
|
||||
|
||||
---
|
||||
|
||||
### B6 – Was ist eine Port-Nummer?
|
||||
**Thema:** Port – Konzept
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wozu dient eine Port-Nummer auf dem Zielrechner?
|
||||
|
||||
- [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
|
||||
- [ ] Sie identifiziert das Gerät im Netzwerk.
|
||||
- [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver auf 80, HTTPS auf 443).** ✅
|
||||
- [ ] Sie zeigt an, ob das Gerät per WLAN oder Kabel verbunden ist.
|
||||
|
||||
> **Feedback:** IP = „Welches Gebäude?", Port = „Welche Tür im Gebäude?" (welcher Dienst soll die Anfrage empfangen).
|
||||
|
||||
---
|
||||
|
||||
### B7 – IP, MAC, Port: Zuordnung
|
||||
**Thema:** Adressierung – Unterschiede auf einen Blick
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Adresse ihre Beschreibung zu.
|
||||
|
||||
| Adresse | Beschreibung |
|
||||
|---|---|
|
||||
| IP-Adresse | Globale Adresse eines Geräts – ermöglicht Routing über Netzwerkgrenzen |
|
||||
| MAC-Adresse | Lokale Adresse einer Netzwerkkarte – nur innerhalb eines Segments gültig |
|
||||
| Port-Nummer | Adressiert einen bestimmten Dienst auf einem Computer |
|
||||
|
||||
> **Feedback:** Drei Ebenen der Adressierung: Gerät global (IP), Gerät lokal (MAC), Dienst auf dem Gerät (Port).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### B8 – MAC ändert sich, IP nicht: Warum?
|
||||
**Thema:** IP vs. MAC beim Routing – Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Ein Paket reist von Ihrem Laptop zu einem Webserver über mehrere Router. Erkläre in 2–3 Sätzen, warum die MAC-Adresse an jedem Router neu gesetzt wird, während die IP-Adresse des Ziel-Servers konstant bleibt.
|
||||
|
||||
> **Musterlösung:** Die IP-Adresse des Ziel-Servers bleibt konstant, weil sie das globale Routingziel identifiziert – jeder Router nutzt sie, um das nächste Hop zu bestimmen. Die MAC-Adresse hingegen gilt nur für ein einzelnes Netzwerksegment (einen „Hop"). An jedem Router wird ein neuer Frame erstellt mit der MAC des nächsten Hops als Ziel – die alte MAC wird verworfen.
|
||||
|
||||
---
|
||||
|
||||
### B9 – Encapsulation: Dateneinheit → Schicht
|
||||
**Thema:** Encapsulation – Zuordnung
|
||||
**Punkte:** 3
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt. Ordne jeder Dateneinheit die zugehörige Schicht und was hinzugefügt wird.
|
||||
|
||||
| Dateneinheit | Schicht + Was wird ergänzt |
|
||||
|---|---|
|
||||
| Daten | Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite) |
|
||||
| Segment | Transportschicht – Daten + Ports und Sequenznummern |
|
||||
| Paket | Internetschicht – Segment + IP-Adressen (Quelle und Ziel) |
|
||||
| Frame | Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme |
|
||||
|
||||
> **Feedback:** D-S-P-F: Daten → Segment → Paket → Frame. Jede Schicht fügt einen Header (und beim Frame auch einen Trailer) hinzu.
|
||||
|
||||
---
|
||||
|
||||
### B10 – Encapsulation: Reihenfolge sortieren
|
||||
**Thema:** Encapsulation – Reihenfolge
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Dateneinheiten in der Reihenfolge, wie sie beim Senden entstehen (von innen nach außen):
|
||||
|
||||
1. Daten
|
||||
2. Segment
|
||||
3. Paket
|
||||
4. Frame
|
||||
|
||||
> **Feedback:** Zwiebelprinzip: Die Anwendung erzeugt Daten → Transport verpackt zu einem Segment → Internet zu einem Paket → Netzzugang zum Frame.
|
||||
|
||||
---
|
||||
|
||||
### B11 – Decapsulation: Umgekehrte Reihenfolge
|
||||
**Thema:** Decapsulation – Empfänger-Seite
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wenn der Server das Signal empfängt, passiert Decapsulation. In welcher Reihenfolge werden die Header entfernt?
|
||||
|
||||
- [ ] Anwendung → Transport → Internet → Netzzugang
|
||||
- [ ] Alle Header werden gleichzeitig entfernt, sobald die Daten im RAM liegen.
|
||||
- [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
|
||||
- [ ] Internet → Netzzugang → Transport → Anwendung
|
||||
|
||||
> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken – der äußerste Header (Frame) wird zuerst entfernt.
|
||||
|
||||
---
|
||||
|
||||
### B12 – Encapsulation: Lückentext
|
||||
**Thema:** Encapsulation – Terminologie
|
||||
**Punkte:** 2
|
||||
**Typ:** `[CLOZE]`
|
||||
|
||||
Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt. Die Transportschicht erzeugt ein [[1:Segment]], die Internetschicht ein [[2:Paket]], und die Netzzugangsschicht einen [[3:Frame]]. Am Empfänger wird dieses in [[4:umgekehrter Reihenfolge]] wieder abgepackt (Decapsulation).
|
||||
|
||||
> **Feedback:** D-S-P-F vorwärts beim Senden, F-P-S-D beim Empfangen. Jeder Name beschreibt die Dateneinheit mit allen bis zu dieser Schicht hinzugefügten Headern.
|
||||
|
||||
---
|
||||
|
||||
### B13 – TCP vs. UDP: Videostreaming
|
||||
**Thema:** TCP vs. UDP – Echtzeit-Szenario
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Ein Videostreaming-Dienst sendet Daten an Ihren Browser. Ein einzelnes Paket geht verloren. Warum wählt der Dienst UDP statt TCP?
|
||||
|
||||
- [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
|
||||
- [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
|
||||
- [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
|
||||
- [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
|
||||
|
||||
> **Feedback:** Der Kern: Bei Echtzeit zählt Latenz, nicht Vollständigkeit. Ein fehlendes Frame ist besser als ein eingefrorenes Video.
|
||||
|
||||
---
|
||||
|
||||
### B14 – TCP vs. UDP: Unterschiede beschreiben
|
||||
**Thema:** TCP vs. UDP – Konzept-Vergleich
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Nenne zwei wesentliche Unterschiede zwischen TCP und UDP und gib für jeden einen konkreten Anwendungsfall an, in dem genau dieses Eigenschaftspaar ausschlaggebend ist.
|
||||
|
||||
> **Musterlösung:** (1) TCP ist verbindungsorientiert und zuverlässig (Handshake, Sequenznummern, ACK) → ideal für Dateiübertragung, wo jedes Byte zählt. (2) UDP ist verbindungslos und schneller, aber ohne Garantie für Lieferung oder Reihenfolge → ideal für Echtzeit-Anwendungen wie Videostreaming oder Online-Gaming, wo Latenz wichtiger als Vollständigkeit ist.
|
||||
|
||||
---
|
||||
|
||||
### B15 – TCP vs. UDP: Richtig oder Falsch?
|
||||
**Thema:** TCP vs. UDP – Aussagen prüfen
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
„UDP garantiert, dass alle Pakete in der richtigen Reihenfolge ankommen."
|
||||
|
||||
Diese Aussage ist …
|
||||
|
||||
- [ ] …korrekt – UDP nutzt Sequenznummern wie TCP.
|
||||
- [x] **…falsch – UDP bietet keine Garantie für Reihenfolge noch für Lieferung.** ✅
|
||||
- [ ] …korrekt – UDP ist sogar zuverlässiger als TCP.
|
||||
- [ ] …falsch – UDP existiert gar nicht mehr in modernen Netzwerken.
|
||||
|
||||
> **Feedback:** UDP = „fire and forget". Keine Verbindung, keine Sequenznummern, keine Bestätigung. Genau deshalb ist es schneller.
|
||||
|
||||
---
|
||||
|
||||
### B16 – TCP 3-Way-Handshake: SYN geht verloren
|
||||
**Thema:** TCP-Verbindungsaufbau – Störfall
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie. Was passiert als nächstes?
|
||||
|
||||
- [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist.
|
||||
- [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client sendet das SYN nach einem Timeout erneut.** ✅
|
||||
- [ ] Der Client sendet direkt ein ACK als Fallback – Verbindung mit zwei Paketen.
|
||||
- [ ] Das verloren gegangene SYN wird vom Netzwerk automatisch rekonstruiert.
|
||||
|
||||
> **Feedback:** Ohne SYN beim Server: kein SYN-ACK, kein Handshake, keine Verbindung. TCP retransmittiert nach Timeout.
|
||||
|
||||
---
|
||||
|
||||
### B17 – TCP 3-Way-Handshake: Ablauf beschreiben
|
||||
**Thema:** TCP-Verbindungsaufbau – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Beschreibe die drei Schritte des TCP 3-Way-Handshakes. Erkläre, warum alle drei Schritte nötig sind, bevor Daten gesendet werden.
|
||||
|
||||
> **Musterlösung:** (1) Client → Server: SYN („Ich will eine Verbindung aufbauen"). (2) Server → Client: SYN-ACK (「Ich bestätige das und will auch eine Verbindung"). (3) Client → Server: ACK ("Bestätigt"). Alle drei Schritte sind nötig, damit beide Seiten wissen, dass die andere die Verbindung akzeptiert hat – erst dann kann zuverlässiger Datenaustausch beginnen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### B18 – TCP Sequenznummern: Wozu?
|
||||
**Thema:** TCP – Sequenznummern
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Welches Problem lösen Sequenznummern im TCP-Header konkret?
|
||||
|
||||
- [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
|
||||
- [x] **Pakete können in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
|
||||
- [ ] Sie zählen, wie viele Benutzende gleichzeitig auf dem Server sind.
|
||||
- [ ] Sie bestimmen die maximale Größe einer Datei.
|
||||
|
||||
> **Feedback:** IP-Pakete können unterschiedliche Routen nehmen → Part 3 kommt vor Part 1. TCP sortiert sie anhand der Sequenznummern wieder.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK C – HTTP
|
||||
|
||||
---
|
||||
|
||||
### C1 – HTTP-Methoden: Zuordnung
|
||||
**Thema:** HTTP-Methoden – Was macht was
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder HTTP-Methode ihre Hauptfunktion zu.
|
||||
|
||||
| Methode | Hauptfunktion |
|
||||
|---|---|
|
||||
| GET | Ruft eine Ressource ab (nur lesen) |
|
||||
| POST | Erstellt eine neue Ressource auf dem Server |
|
||||
| PUT | Ersetzt eine existierende Ressource vollständig |
|
||||
| DELETE | Löscht eine Ressource auf dem Server |
|
||||
|
||||
> **Feedback:** CRUD-Mapping: GET=Read, POST=Create, PUT=Update, DELETE=Delete.
|
||||
|
||||
---
|
||||
|
||||
### C2 – POST vs. PUT: Unterschied
|
||||
**Thema:** HTTP-Methoden – POST vs. PUT
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Person erstellt einen neuen Blog-Eintrag auf einer Webseite. Welche HTTP-Methode wird verwendet?
|
||||
|
||||
- [x] **POST – eine neue Ressource wird erstellt.** ✅
|
||||
- [ ] PUT – PUT wird immer verwendet, wenn Daten gesendet werden.
|
||||
- [ ] GET – GET kann auch Daten senden mit URL-Parametern.
|
||||
- [ ] DELETE – DELETE erstellt und löscht gleichzeitig.
|
||||
|
||||
> **Feedback:** POST = „Erstelle etwas Neues". PUT = „Ersetze etwas Bestehendes". Neuer Blog-Eintrag → POST.
|
||||
|
||||
---
|
||||
|
||||
### C3 – PUT: Profilbild ersetzen
|
||||
**Thema:** HTTP-Methoden – PUT im Szenario
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Person aktualisiert ihr Profilbild – das alte Bild wird durch ein neues ersetzt. Welche HTTP-Methode?
|
||||
|
||||
- [ ] GET – GET kann auch Daten senden.
|
||||
- [x] **PUT – ersetzt eine existierende Ressource.** ✅
|
||||
- [ ] POST – POST ist immer für das Ersetzen zuständig.
|
||||
- [ ] DELETE – DELETE sendet das neue Foto und löscht das alte.
|
||||
|
||||
> **Feedback:** „Ersetzen einer existierenden Ressource" = PUT. POST wäre, wenn ein völlig neues Bild erstellt würde, ohne dass ein vorhandenes überschrieben wird.
|
||||
|
||||
---
|
||||
|
||||
### C4 – DELETE: Wann nutzen?
|
||||
**Thema:** HTTP-Methoden – DELETE im Szenario
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Person löscht einen von ihr erstellten Kommentar auf einer Webseite. Welche HTTP-Methode wird der Browser im Hintergrund verwenden?
|
||||
|
||||
- [ ] GET – GET kann auch Löschvorgänge auslösen.
|
||||
- [ ] POST – POST ist die Standardmethode für alle Änderungen.
|
||||
- [ ] PUT – PUT löscht und ersetzt gleichzeitig.
|
||||
- [x] **DELETE – der Kommentar wird vom Server entfernt.** ✅
|
||||
|
||||
> **Feedback:** DELETE = „Entferne diese Ressource vom Server." Konkret: der Kommentar wird anhand seiner URL/ID identifiziert und gelöscht.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### C5 – GET: Warum nicht für Passwörter?
|
||||
**Thema:** HTTP-Methoden – GET Sicherheit
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Warum sollte man niemals GET verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?
|
||||
|
||||
- [ ] GET ist langsamer als POST – Passwörter müssen schnell übertragen werden.
|
||||
- [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST sind sie im Body versteckt.** ✅
|
||||
- [ ] GET erlaubt nur Zahlen, keine Buchstaben.
|
||||
- [ ] GET wird vom Server nie verschlüsselt, POST immer.
|
||||
|
||||
> **Feedback:** GET-Parameter hängen an der URL (`?pw=123`). Diese ist in History, Logs, Proxies sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL selbst wird an zu vielen Stellen gespeichert.
|
||||
|
||||
---
|
||||
|
||||
### C6 – Status-Codes: Kategorisierung
|
||||
**Thema:** HTTP Status-Codes – Bedeutung der ersten Ziffer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder ersten Ziffer eines HTTP-Status-Codes ihre Bedeutung zu.
|
||||
|
||||
| Erste Ziffer | Bedeutung |
|
||||
|---|---|
|
||||
| 2xx | Erfolg – die Anfrage wurde erfolgreich verarbeitet |
|
||||
| 3xx | Weiterleitung – die Ressource wurde verschoben |
|
||||
| 4xx | Client-Fehler – die Anfrage der Anfragenden war fehlerhaft |
|
||||
| 5xx | Server-Fehler – der Server hat ein Problem |
|
||||
|
||||
> **Feedback:** Die erste Ziffer = Kategorie. 200 OK, 301 Moved, 404 Not Found, 503 Service Unavailable – die Kategorie sagt Ihnen sofort, wo das Problem liegt.
|
||||
|
||||
---
|
||||
|
||||
### C7 – 503: Server-Fehler erkläre
|
||||
**Thema:** HTTP Status-Codes – 5xx Transfer
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie rufen eine Webseite auf und erhalten `HTTP/2 503 Service Unavailable`. Was bedeutet das?
|
||||
|
||||
- [ ] Sie haben die falsche URL eingegeben.
|
||||
- [ ] Der Server hat die Anfrage erfolgreich umgeleitet.
|
||||
- [x] **Der Server ist überlastet oder temporär nicht verfügbar – Verantwortung liegt beim Betreiber.** ✅
|
||||
- [ ] Der Server hat die Seite dauerhaft verschoben.
|
||||
|
||||
> **Feedback:** 5xx = Server-Problem. Sie als Client können nur später erneut versuchen. Der Betreiber muss das lösen.
|
||||
|
||||
---
|
||||
|
||||
### C8 – 404: Wer hat „Schuld"?
|
||||
**Thema:** HTTP Status-Codes – 4xx Transfer
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie erhalten einen 404-Fehler. Wer ist für die Ursache verantwortlich?
|
||||
|
||||
- [ ] Der Server ist abgestürzt.
|
||||
- [ ] Das Internet ist ausgefallen.
|
||||
- [x] **Der Client (Anfragende) – eine URL wurde angefordert, die nicht existiert (Tippfehler oder veralteter Link).** ✅
|
||||
- [ ] Der DNS-Server konnte den Namen nicht auflösen.
|
||||
|
||||
> **Feedback:** 4xx = Client-Fehler. Der Server funktioniert perfekt, er sagt nur: „Das, was Sie anfragen, habe ich nicht."
|
||||
|
||||
---
|
||||
|
||||
### C9 – Status-Codes: Szenarios zuordnen
|
||||
**Thema:** HTTP Status-Codes – Transfer Zuordnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Szenario den passenden HTTP-Status-Code zu.
|
||||
|
||||
| Szenario | Status-Code |
|
||||
|---|---|
|
||||
| Sie rufen eine Seite auf, die seit letztem Jahr auf eine neue URL umgeleitet wurde | 301 Moved Permanently |
|
||||
| Eine Webseite lädt erfolgreich | 200 OK |
|
||||
| Sie geben eine URL ein, die nicht existiert | 404 Not Found |
|
||||
| Der Webserver ist überlastet | 503 Service Unavailable |
|
||||
|
||||
> **Feedback:** 200 = Alles gut. 301 = dauerhaft verschoben. 404 = nicht gefunden (Ihr Fehler). 503 = Server-Problem (Betreiber).
|
||||
|
||||
---
|
||||
|
||||
### C10 – Status-Codes: Freitext
|
||||
**Thema:** HTTP Status-Codes – Konzept zusammenfassen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum HTTP-Status-Codes aus einer dreistelligen Zahl bestehen und was die erste Ziffer konkret bedeutet. Nenne je einen Beispiel-Code für 2xx, 4xx und 5xx.
|
||||
|
||||
> **Musterlösung:** Die erste Ziffer kategorisiert die Antwort: 2xx = Erfolg, 3xx = Weiterleitung, 4xx = Client-Fehler, 5xx = Server-Fehler. Die restlichen zwei Ziffern spezifizieren den genauen Fall. Beispiele: 200 OK (Erfolg), 404 Not Found (Client-Fehler), 500 Internal Server Error (Server-Fehler). Diese Struktur ermöglicht es, allein aus dem Code zu verstehen, ob und wo ein Problem liegt – ohne die Antwort ganz lesen zu müssen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK D – DNS
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D1 – DNS: Was macht es?
|
||||
**Thema:** DNS – Grundfunktion
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist die Hauptfunktion eines DNS-Servers?
|
||||
|
||||
- [ ] Er verschlüsselt die Verbindung zwischen Client und Server.
|
||||
- [x] **Er übersetzt einen Domain-Namen (z. B. `hdm-stuttgart.de`) in eine IP-Adresse.** ✅
|
||||
- [ ] Er routet Pakete durch das Internet.
|
||||
- [ ] Er weist jedem Computer eine MAC-Adresse zu.
|
||||
|
||||
> **Feedback:** DNS = Domain Name System = „Telefonbuch des Internets". Name → IP. Ohne DNS müsste man überall IP-Adressen eintippen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D2 – DNS: Zeitlicher Ablauf
|
||||
**Thema:** DNS – Rolle im Gesamtablauf
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie geben `https://hdm-stuttgart.de` in die Adresszeile ein. Was passiert vor dem TCP-Handshake?
|
||||
|
||||
- [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach benötigt.
|
||||
- [x] **DNS-Auflösung: Der Name wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen.** ✅
|
||||
- [ ] DNS passiert nach dem TCP-Handshake.
|
||||
- [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
|
||||
|
||||
> **Feedback:** DNS vor TCP. Kein Name-to-IP? Kein Handshake möglich. TCP arbeitet auf IP-Adressen, nicht auf Domain-Namen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D3 – DNS: Warum zwingend nötig?
|
||||
**Thema:** DNS – Transfer/Begründung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre in 2–3 Sätzen, warum der DNS-Schritt zwingend vor dem TCP-Handshake stehen muss. Was würde passieren, wenn der Browser den Domain-Namen direkt an den Netzwerk-Stack übergeben würde?
|
||||
|
||||
> **Musterlösung:** TCP arbeitet nur mit IP-Adressen – ein Domain-Name wie `hdm-stuttgart.de` ist für TCP-/IP-Stack sinnlos. Ohne vorherige DNS-Auflösung würde der Browser nicht wissen, an welche IP er das SYN senden soll. Der DNS-Schritt konvertiert den human-readable-Namen in eine maschinenlesbare IP, erst danach kann der Verbindungsaufbau beginnen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D4 – DNS: Lückentext
|
||||
**Thema:** DNS – Terminologie
|
||||
**Punkte:** 1
|
||||
**Typ:** `[CLOZE]`
|
||||
|
||||
Der DNS-Server übersetzt einen [[1:Domain-Namen]] in eine [[2:IP-Adresse]]. Dieser Schritt fällt [[3:vor]] dem TCP-Handshake statt, weil TCP nur zu [[4:IP-Adressen]] Verbindungen aufbauen kann.
|
||||
|
||||
> **Feedback:** Die vier Lücken beschreiben den DNS-Ablauf vollständig: Was wird übersetzt, in was, wann, und warum.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK E – Der Gesamtablauf (Zusammen)
|
||||
|
||||
---
|
||||
|
||||
### E1 – Reihenfolge eines HTTPS-Aufrufs
|
||||
**Thema:** Gesamtablauf – Sortierung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Schritte eines HTTPS-Aufrufs in der richtigen Reihenfolge:
|
||||
|
||||
1. DNS-Auflösung (Name → IP)
|
||||
2. TCP 3-Way-Handshake (Verbindung aufbauen)
|
||||
3. TLS-Handshake (Verschlüsselung vereinbaren)
|
||||
4. HTTP GET (Anfrage senden)
|
||||
5. HTTP 200 OK + HTML (Antwort empfangen)
|
||||
|
||||
> **Feedback:** DNS → TCP → TLS → HTTP Request → HTTP Response. Jeder Schritt ist eine Voraussetzung für den nächsten.
|
||||
|
||||
---
|
||||
|
||||
### E2 – Reihenfolge: Welche Folge ist korrekt?
|
||||
**Thema:** Gesamtablauf – Multiple Choice
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie geben eine URL ein. Welche Reihenfolge ist korrekt?
|
||||
|
||||
- [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
|
||||
- [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
|
||||
- [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
- [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
|
||||
> **Feedback:** DNS immer zuerst. Dann TCP (Verbindung). Dann HTTP (Anfrage/Antwort).
|
||||
|
||||
---
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK F – HTML-Grundlagen
|
||||
|
||||
---
|
||||
|
||||
### F1 – `<head>` vs. `<body>`: Was passiert bei Fehler?
|
||||
**Thema:** HTML-Struktur – head/body
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine studierende Person platziert den `<title>` und `<meta name="description">` im `<body>` statt im `<head>`. Welche zwei Konsequenzen hat das?
|
||||
|
||||
- [ ] Kein Problem – Browser ignorieren die Unterscheidung.
|
||||
- [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO, Screen-Reader können die Seite nicht richtig vorlesen.** ✅
|
||||
- [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
|
||||
- [ ] Nur das Fehlen von `<meta charset>` ist ein Problem.
|
||||
|
||||
> **Feedback:** `<head>` = Metadaten (unsichtbar für die Benutzenden, sichtbar für Browser/Maschinen). `<body>` = sichtbarer Inhalt. Title und description im Body werden nicht als Metadaten interpretiert.
|
||||
|
||||
---
|
||||
|
||||
### F2 – `<head>`: Was gehört wohin?
|
||||
**Thema:** HTML-Struktur – Zuordnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Element zu, ob es in `<head>` oder `<body>` gehört.
|
||||
|
||||
| Element | Wohin? |
|
||||
|---|---|
|
||||
| `<title>` | `<head>` |
|
||||
| `<meta charset="UTF-8">` | `<head>` |
|
||||
| `<meta name="description">` | `<head>` |
|
||||
| `<h1>Willkommen</h1>` | `<body>` |
|
||||
| `<p>Text hier</p>` | `<body>` |
|
||||
| `<link rel="stylesheet">` | `<head>` |
|
||||
|
||||
> **Feedback:** `<head>` = alles, was die Benutzenden nicht direkt sehen (Metadaten, Styles, Titel). `<body>` = alles, was im Browser-Fenster angezeigt wird.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### F3 – Charset: Was passiert ohne `<meta charset>`?
|
||||
**Thema:** HTML – Zeichenkodierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist die konkrete Konsequenz, wenn `<meta charset="UTF-8">` fehlt oder falsch gesetzt ist?
|
||||
|
||||
- [ ] Die Webseite lädt gar nicht.
|
||||
- [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole dargestellt, weil der Browser die falsche Zeichenkodierung rät.** ✅
|
||||
- [ ] Die Seite wird langsamer, da der Browser alle Sprachen durchprobieren muss.
|
||||
- [ ] Das CSS wird nicht geladen.
|
||||
|
||||
> **Feedback:** Ohne charset nutzt der Browser oft einen Standard wie Latin-1. Bei UTF-8-gespeicherten Dateien → Umlaute und Emojis werden falsch dargestellt (Mojibake).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK G – CSS
|
||||
|
||||
---
|
||||
|
||||
### G1 – Spezifität: ID vs. Klasse vs. Element
|
||||
**Thema:** CSS Spezifität – Grundregel
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Gegeben:
|
||||
```
|
||||
p { color: blue; }
|
||||
.highlight { color: green; }
|
||||
#main { color: red; }
|
||||
```
|
||||
Ein Element `<p class="highlight" id="main">` wird angezeigt. Welche Farbe?
|
||||
|
||||
- [ ] Blau – die Element-Regel steht zuerst im Code.
|
||||
- [ ] Grün – Klassen haben immer Vorrang vor IDs.
|
||||
- [x] **Rot – die ID `#main` hat die höchste Spezifität (0,1,0,0).** ✅
|
||||
- [ ] Rot – die letzte Regel im Code gewinnt immer.
|
||||
|
||||
> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Reihenfolge im Code ist nur relevant bei gleicher Spezifität.
|
||||
|
||||
---
|
||||
|
||||
|
||||
### G2 – Responsive Design: Mobile First – Welche Farbe?
|
||||
**Thema:** CSS Media Queries – Mobile First
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
```css
|
||||
.container { background: white; }
|
||||
@media (min-width: 768px) { .container { background: blue; } }
|
||||
@media (min-width: 1024px) { .container { background: green; } }
|
||||
```
|
||||
Welche Farbe bei 900 px Breite?
|
||||
|
||||
- [ ] Weiß – Media-Queries gelten nur ab 1024 px.
|
||||
- [ ] Grün – die letzte Media-Query überschreibt immer.
|
||||
- [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` nicht (900 < 1024).** ✅
|
||||
- [ ] Weiß – keine Media-Query greift zwischen den Breakpoints.
|
||||
|
||||
> **Feedback:** Mobile First: Basis = white. Bei 900px: 768px-Query greift ✓, 1024px-Query greift ✗ → blau.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### G3 – Desktop First: `max-width` erkläre
|
||||
**Thema:** CSS Media Queries – Desktop First
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie würde eine Media Query für „Desktop First" aussehen (Standard ist Desktop, Anpassung für kleine Screens)?
|
||||
|
||||
- [ ] `@media (device-width: small) { ... }`
|
||||
- [ ] `@media (min-width: ...)` – bleibt gleich, nur die Reihenfolge ändert sich.
|
||||
- [x] **`@media (max-width: ...)` – Stile für Bildschirme, die kleiner als eine bestimmte Breite sind.** ✅
|
||||
- [ ] `@media (mobile: true) { ... }`
|
||||
|
||||
> **Feedback:** Desktop First: Basis-CSS für große Schirme. `max-width` = „Wenn der Bildschirm schmäler ist als X, dann…" – Ausnahmen für Tablets/Handys.
|
||||
|
||||
---
|
||||
|
||||
### G4 – Mobile First vs. Desktop First: Vergleich
|
||||
**Thema:** CSS Media Queries – Konzept-Vergleich
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre den Unterschied zwischen „Mobile First" und „Desktop First" beim Responsive Design. Welche Media-Query-Eigenschaft nutzt jeder Ansatz, und warum?
|
||||
|
||||
> **Musterlösung:** Mobile First: Das Basis-CSS ist für kleine Bildschirme (Handy). Mit `min-width` werden schrittweise Anpassungen für größere Bildschirme hinzugefügt („ab dieser Breite"). Desktop First: Das Basis-CSS ist für große Bildschirme. Mit `max-width` werden Ausnahmen für kleinere Geräte definiert (「bis zu dieser Breite"). Mobile First wird bevorzugt, weil die Mehrheit der Benutzenden mobil zugrifft und forced-mobile-first die Grundlage für progressive Enhancement bietet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK H – Barrierefreiheit
|
||||
|
||||
---
|
||||
|
||||
### H1 – Wie nutzen Menschen das Web?
|
||||
**Thema:** Barrierefreiheit – Eingabegeräte
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Eingabegerät seine Nutzungsweise zu.
|
||||
|
||||
| Eingabe | Nutzungsweise |
|
||||
|---|---|
|
||||
| Maus | Klicken, Scrollen |
|
||||
| Tastatur | Tab-Navigation, Enter, Pfeiltasten |
|
||||
| Screenreader | Vorlesen von Inhalten |
|
||||
| Sprachsteuerung | „Klicke auf Anmelden" |
|
||||
| Augensteuerung | Eye-Tracking |
|
||||
| Switch-Geräte | Ein-/Aus-Schalter |
|
||||
|
||||
> **Feedback:** Nicht alle nutzen Maus + Bildschirm. ~15% der Weltbevölkerung haben eine Behinderung (WHO). Assistive Technologien wie Screenreader (NVDA, VoiceOver, JAWS) oder Switch-Geräte ermöglichen Web-Zugang für Menschen mit verschiedenen Einschränkungen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H2 – Einschränkungen: Temporär vs. situativ
|
||||
**Thema:** Barrierefreiheit – Einschränkungstypen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Person kann aktuell nur mit einer Hand ihr Handy bedienen, weil sie das Baby auf dem Arm trägt. Wie klassifiziert man diese Einschränkung?
|
||||
|
||||
- [ ] Permanent – das ist eine bleibende körperliche Behinderung.
|
||||
- [ ] Temporär – die Person ist verletzt und braucht Zeit zum Heilen.
|
||||
- [x] **Situativ – die Einschränkung entsteht durch die aktuelle Umgebung/Situation, nicht durch eine Behinderung.** ✅
|
||||
- [ ] Diese Art von Einschränkung existiert nicht – Barrierefreiheit betrifft nur Menschen mit Behinderung.
|
||||
|
||||
> **Feedback:** Drei Typen: Permanent (z. B. Blindheit), Temporär (z. B. gebrochener Arm, Augen-OP), Situativ (z. B. helle Sonne, laute Umgebung, Baby auf dem Arm). Barrierefreie Gestaltung hilft bei allen drei.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H3 – Curb-Cut-Effekt: Beispiel identifizieren
|
||||
**Thema:** Barrierefreiheit – Curb-Cut-Effekt
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Welches Beispiel demonstriert den Curb-Cut-Effekt?
|
||||
|
||||
- [ ] Barrierefreie Webseiten laden langsamer.
|
||||
- [x] **Untertitel: gedacht für Gehörlose, helfen aber auch in lauter Umgebung oder beim Sprachlernen.** ✅
|
||||
- [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
|
||||
- [ ] Alt-Texte verlängern die Ladezeit einer Webseite.
|
||||
|
||||
> **Feedback:** Curb-Cut-Effekt = eine barrierefreie Lösung nutzt am Ende allen. Untertitel für Gehörlose → helfen auch in lauter Umgebung. Kontrastreiche Farben für Sehbehinderung → besser im Sonnenlicht, für ältere Menschen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H4 – Curb-Cut-Effekt: Erklärung
|
||||
**Thema:** Barrierefreiheit – Curb-Cut-Effekt Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre das Konzept des Curb-Cut-Effekts. Nenne zwei konkrete Web-Beispiele und erkläre jeweils, wer die ursprüngliche Zielgruppe war und wer sonst davon profitiert.
|
||||
|
||||
> **Musterlösung:** Der Curb-Cut-Effekt beschreibt, wie eine Maßnahme für Menschen mit Behinderung am Ende allen zugute kommt – wie die Bordsteinabsenkung, die für Rollstuhlfahrer gedacht war, aber auch Kinderwagen, Rollkoffer und Fahrrädern helfen. Web-Beispiele: (1) Untertitel – primär für Gehörlose, helfen auch in lauter Umgebung oder beim Sprachlernen. (2) Alt-Texte – primär für Screen-Reader-Benutzende, helfen auch Suchmaschinen (SEO).
|
||||
|
||||
---
|
||||
|
||||
### H5 – EAA: Was ist das?
|
||||
**Thema:** Barrierefreiheit – Rechtlicher Rahmen
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der European Accessibility Act (EAA)?
|
||||
|
||||
- [ ] Ein freiwilliges EU-Programm zur Förderung barrierefreier Websites.
|
||||
- [x] **Eine EU-Richtlinie, die seit Juni 2025 in Kraft ist und Barrierefreiheit in bestimmten digitalen Bereichen verpflichtend macht.** ✅
|
||||
- [ ] Ein deutsches Gesetz, das nur öffentliche Behörden betrifft.
|
||||
- [ ] Ein technisches Standard wie HTML oder CSS.
|
||||
|
||||
> **Feedback:** EAA = European Accessibility Act. Seit 28. Juni 2025 in Kraft. Betrifft E-Commerce, Banking, Telekommunikation, Transport, E-Books. In Deutschland umgesetzt durch das BFSG (Barrierefreiheitsstärkungsgesetz). Verstoß: bis 100.000€ Bußgeld möglich.
|
||||
|
||||
---
|
||||
|
||||
### H6 – Barrierefreiheit: Warum auch für „normale" Benutzende?
|
||||
**Thema:** Barrierefreiheit – Business Case
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum barrierefreie Gestaltung nicht nur für Menschen mit Behinderung wichtig ist, sondern auch einen praktischen Nutzen für alle Benutzenden hat. Nenne mindestens zwei konkrete Beispiele.
|
||||
|
||||
> **Musterlösung:** Barrierefreiheit verbessert die UX für alle: (1) SEO – Alt-Texte und semantisches HTML helfen Suchmaschinen, die Seite besser zu verstehen → besseres Ranking. (2) Mobile – viele barrierefreie Prinzipien (z. B. große Tippflächen, guter Kontrast) sind auch für Mobilgeräte im Sonnenlicht wichtig. (3) Ältere Menschen – Sehschwäche, motorische Einschränkungen betreffen einen großen Anteil der Bevölkerung. Der Markt: ~15% Menschen mit Behinderung + ~20% ältere Menschen.
|
||||
|
||||
---
|
||||
|
||||
### H7 – Tastatur-Test: Was prüfen?
|
||||
**Thema:** Barrierefreiheit – Praktischer Test
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie möchten eine Webseite auf Barrierefreiheit testen, ohne assistive Technologie zu installieren. Was machen Sie?
|
||||
|
||||
- [ ] Sie scrollen durch die Seite und schauen, ob sie schön aussieht.
|
||||
- [x] **Sie navigieren nur mit Tab + Enter durch die Seite und prüfen: Erreichen Sie alle Funktionen? Ist der Fokus immer sichtbar? Ist die Tab-Reihenfolge logisch?** ✅
|
||||
- [ ] Sie installieren einen Screenreader und lassen die Seite vorlesen.
|
||||
- [ ] Sie öffnen den Quellcode und zählen die barrierefreien Tags.
|
||||
|
||||
> **Feedback:** Der Tastatur-Test ist der schnellste barrierefreie Selbsttest: Nur Tab + Enter benutzen. Wenn man so eine Funktion nicht erreicht kann, ist sie für Tastatur-Benutzende (und damit auch für Screenreader-Benutzende) nicht zugänglich. Tools wie axe DevTools oder Lighthouse automatisieren ~30% der Checks.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead disable -->
|
||||
|
||||
## BLOCK I – Zusammenfassung-Fragen (Übergreifend)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### I1 – Gesamtablauf: Wahl der richtigen Methode
|
||||
**Thema:** HTTP + TCP + DNS zusammen
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Eine Person klickt auf einen „Neuen Eintrag erstellen"-Button einer Webanwendung. Beschreibe vom Klick bis zur Antwort des Servers, welche Protokolle beteiligt sind und welche HTTP-Methode verwendet wird.
|
||||
|
||||
> **Musterlösung:** (1) Der Browser sendet eine HTTP-Anfrage. Da es sich um eine neue Ressource handelt, nutzt er POST. (2) Vorher: DNS löst den Domain-Namen auf. (3) TCP-Handshake stellt die Verbindung her. (4) POST-Anfrage wird gesendet (Daten im Body). (5) Server verarbeitet, erstellt den Eintrag, antwortet mit 201 Created.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### I2 – Gesamtablauf: Störfall analysieren
|
||||
**Thema:** Netzwerk + HTTP – Transfer/Problemlösung
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Sie rufen eine Webseite auf und erhalten eine Fehlermeldung. Beschreibe drei verschiedene Szenarien, die zu einer Fehlermeldung führen könnten, und erkläre, in welcher „Schicht" des Ablaufs (DNS, TCP, HTTP) das Problem liegt und wie Sie es erkennen.
|
||||
|
||||
> **Musterlösung:** (1) DNS-Fehler: „Der Server wurde nicht gefunden" → DNS konnte den Namen nicht auflösen (z. B. Tippfehler in der URL oder DNS-Server nicht erreichbar). (2) TCP-Fehler: „Die Verbindung wurde verweigert" → Server existiert (IP bekannt), akzeptiert aber keine Verbindung (nicht gestartet, Port blockiert). (3) HTTP-Fehler: 404 → TCP-Verbindung erfolgreich, aber die angeforderte Ressource existiert nicht auf dem Server.
|
||||
Reference in New Issue
Block a user