440 lines
22 KiB
Markdown
440 lines
22 KiB
Markdown
Here is the quiz converted into a clean, readable Markdown format. I have preserved the structure, code snippets, and feedback for each question.
|
||
|
||
---
|
||
|
||
# 223015c – Grundlagen IT- und Internettechnik
|
||
|
||
**WS 2025/26 – Michael Czechowski – HdM Stuttgart**
|
||
**40 Punkte / 40 Minuten**
|
||
|
||
---
|
||
|
||
### Q1 – Von-Neumann: Komponenten zuordnen (3 pt)
|
||
|
||
**Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.**
|
||
|
||
* **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 (Stored Program Concept).
|
||
* **Ein-/Ausgabe:** Schnittstelle zu externen Geräten wie 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).
|
||
|
||
---
|
||
|
||
### Q2 – Von-Neumann vs. Harvard (2 pt)
|
||
|
||
**Ein Arduino-Mikrocontroller nutzt die Harvard-Architektur. Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.**
|
||
|
||
**Warum ist die Harvard-Architektur für Echtzeit-Anwendungen auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn das Smartphone diese Architektur verwenden würde?**
|
||
|
||
* [ ] Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.
|
||
* [x] **Harvard nutzt separate Speicher für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.** ✅
|
||
* [ ] Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.
|
||
* [ ] Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.
|
||
|
||
> **Feedback:** Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.
|
||
|
||
---
|
||
|
||
### Q3 – Stored Program Concept (2 pt)
|
||
|
||
**Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem ENIAC Programme durch Umstecken von Kabeln eingegeben werden.**
|
||
|
||
**Was konkret ermöglicht das Stored Program Concept, was vorher nicht möglich war? Nenne zwei Beispiele.**
|
||
|
||
* [ ] Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.
|
||
* [ ] Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.
|
||
* [x] **Programme werden als Daten im Speicher abgelegt → z. B. Apps können installiert/gelöscht werden und Multitasking (mehrere Programme gleichzeitig) wird möglich.** ✅
|
||
* [ ] Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.
|
||
|
||
> **Feedback:** Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.
|
||
|
||
---
|
||
|
||
### Q4 – HTML: `<head>` vs. `<body>` (2 pt)
|
||
|
||
**Ein Student erstellt eine Webseite und platziert *alles* im `<body>` – auch den `<title>` und die `<meta name="description">`.**
|
||
|
||
**Welche zwei konkreten Konsequenzen hat das?**
|
||
|
||
* [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`.
|
||
* [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO und 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 – title und description funktionieren überall.
|
||
|
||
> **Feedback:** title und meta description gehören in `<head>`. Im `<body>`: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.
|
||
|
||
---
|
||
|
||
### Q5 – Barrierefreiheit: Curb-Cut-Effekt (3 pt)
|
||
|
||
**Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung – ursprünglich für Menschen mit Behinderung – letztendlich *allen* zugute kommt.**
|
||
|
||
**Nenne ein konkretes Web-Beispiel, das diesen Effekt demonstriert, und erkläre, wer davon profitiert.**
|
||
|
||
* [ ] Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.
|
||
* [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
|
||
* [x] **Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.** ✅
|
||
* [ ] **Dark Mode:** Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.
|
||
|
||
> **Feedback:** Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.
|
||
|
||
---
|
||
|
||
### Q6 – European Accessibility Act (2 pt)
|
||
|
||
**Der European Accessibility Act (EAA) ist seit Juni 2025 in Kraft.**
|
||
|
||
**Was bedeutet das konkret für ein deutsches E-Commerce-Unternehmen, das eine Webseite betreibt?**
|
||
|
||
* [ ] Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.
|
||
* [ ] Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.
|
||
* [x] **Die Webseite muss barrierefreiheitstechnisch WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.** ✅
|
||
* [ ] Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.
|
||
|
||
> **Feedback:** EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.
|
||
|
||
---
|
||
|
||
### Q7 – TCP/IP: Protokoll → Schicht (3 pt)
|
||
|
||
**Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.**
|
||
|
||
* **HTTP:** Anwendung
|
||
* **DNS:** Anwendung
|
||
* **TCP:** Transport
|
||
* **UDP:** Transport
|
||
* **IP:** Internet
|
||
* **Ethernet:** Netzzugang
|
||
|
||
> **Feedback:** Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
|
||
|
||
---
|
||
|
||
### Q8 – Encapsulation: Dateneinheit → Schicht (3 pt)
|
||
|
||
**Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige Schicht zu.**
|
||
|
||
* **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:** Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.
|
||
|
||
---
|
||
|
||
### Q9 – IP vs. MAC vs. Port: Transfer-Szenario (3 pt)
|
||
|
||
**Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in einem anderen Land. Das Paket durchläuft mehrere Router.**
|
||
|
||
**Welche der folgenden Aussagen über die Adressen auf dem Weg ist korrekt?**
|
||
|
||
* [ ] Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.
|
||
* [x] **Die IP-Adresse des Servers bleibt konstant, der Port (443) ändert sich nicht – die MAC-Adresse wird an jedem Router neu gesetzt (lokal, ein Hop).** ✅
|
||
* [ ] Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.
|
||
* [ ] IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.
|
||
|
||
> **Feedback:** IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.
|
||
|
||
---
|
||
|
||
### Q10 – TCP 3-Way-Handshake: Was passiert wäre? (3 pt)
|
||
|
||
**Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie.**
|
||
|
||
**Was passiert als nächstes, und warum wird keine Verbindung aufgebaut?**
|
||
|
||
* [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.
|
||
* [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client wird das SYN nach einem Timeout erneut senden.** ✅
|
||
* [ ] Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.
|
||
* [ ] Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.
|
||
|
||
> **Feedback:** Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).
|
||
|
||
---
|
||
|
||
### Q11 – TCP vs. UDP: Videostreaming (2 pt)
|
||
|
||
**Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren.**
|
||
|
||
**Warum wählt der Dienst UDP statt TCP, obwohl ein Paket verloren geht?**
|
||
|
||
* [ ] 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:** Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.
|
||
|
||
---
|
||
|
||
### Q12 – HTTP-Methoden: Szenario (2 pt)
|
||
|
||
**Ein Nutzer aktualisiert sein Profilbild auf einer Webseite. Das Foto wird zum Server gesendet und das *alte Bild ersetzt*.**
|
||
|
||
**Welche HTTP-Methode wird für diese Operation verwendet, und warum nicht GET?**
|
||
|
||
* [ ] **GET** – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.
|
||
* [x] **PUT – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet *keine* Daten zum Server.** ✅
|
||
* [ ] **POST** – POST ist immer für das Ersetzen von Daten zuständig.
|
||
* [ ] **DELETE** – DELETE sendet das neue Foto und löscht gleichzeitig das alte.
|
||
|
||
> **Feedback:** PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.
|
||
|
||
---
|
||
|
||
### Q13 – HTTP Status-Codes: Fehlerdiagnose (2 pt)
|
||
|
||
**Du rufst eine Webseite auf und der Browser zeigt folgende Fehlermeldung an:**
|
||
`HTTP/1.1 503 Service Unavailable`
|
||
|
||
**Was bedeutet dieser Code, und wer ist für die Behebung zuständig – du oder der Betreiber der Webseite?**
|
||
|
||
* [ ] Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.
|
||
* [ ] Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.
|
||
* [x] **Server-Fehler: Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Betreiber – du kannst nur später erneut versuchen.** ✅
|
||
* [ ] Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.
|
||
|
||
> **Feedback:** 503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.
|
||
|
||
---
|
||
|
||
### Q14 – DNS: Rolle im Ablauf (2 pt)
|
||
|
||
**Du gibst `https://hdm-stuttgart.de` in die Adresszeile ein.**
|
||
|
||
**Was passiert *vor* dem TCP-Handshake, und warum ist dieser Schritt zwingend nötig?**
|
||
|
||
* [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.
|
||
* [x] **DNS-Auflösung: Der Name `hdm-stuttgart.de` wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.** ✅
|
||
* [ ] DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.
|
||
* [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
|
||
|
||
> **Feedback:** DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.
|
||
|
||
---
|
||
|
||
### Q15 – CSS Spezifität: Welche Regel gewinnt? (2 pt)
|
||
|
||
**Gegeben folgender CSS-Code:**
|
||
|
||
```css
|
||
p { color: blue; } /* (A) */
|
||
.highlight { color: green; } /* (B) */
|
||
#main { color: red; } /* (C) */
|
||
|
||
```
|
||
|
||
**Ein Element `<p class="highlight" id="main">Text</p>` wird angezeigt.**
|
||
**Welche Farbe zeigt der Text an, und warum?**
|
||
|
||
* [ ] **Blau** – die Element-Regel steht zuerst im Code und hat daher Vorrang.
|
||
* [ ] **Grün** – Klassen-Selektoren haben immer Vorrang vor IDs.
|
||
* [x] **Rot – die ID-Regel `#main` hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).** ✅
|
||
* [ ] **Rot** – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.
|
||
|
||
> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.
|
||
|
||
---
|
||
|
||
### Q16 – Responsive Design: Mobile First (2 pt)
|
||
|
||
**Ein Developer schreibt folgendes CSS:**
|
||
|
||
```css
|
||
.container { background: white; }
|
||
|
||
@media (min-width: 768px) {
|
||
.container { background: blue; }
|
||
}
|
||
|
||
@media (min-width: 1024px) {
|
||
.container { background: green; }
|
||
}
|
||
|
||
```
|
||
|
||
**Welche Farbe hat `.container` bei einem Bildschirm von 900 px Breite, und warum?**
|
||
|
||
* [ ] **Weiß** – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.
|
||
* [ ] **Grün** – die letzte Media-Query überschreibt immer alle vorherigen.
|
||
* [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` greift nicht (900 < 1024).** ✅
|
||
* [ ] **Weiß** – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.
|
||
|
||
> **Feedback:** Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.
|
||
|
||
---
|
||
|
||
### Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs (1 pt)
|
||
|
||
**Du gibst eine URL ein. Welche Reihenfolge der Schritte 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:** Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).
|
||
|
||
---
|
||
|
||
### Q18 – Bonusfrage: Spezifität Edge Case (1 pt)
|
||
|
||
**Es gibt zwei CSS-Regeln für ein `<p>`-Element:**
|
||
|
||
```css
|
||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||
.highlight { color: red; } /* 1× Klasse */
|
||
|
||
```
|
||
|
||
**Das Element hat die Klasse `highlight`. Welche Farbe gewinnt?**
|
||
|
||
* [ ] **Blau** – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.
|
||
* [x] **Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.** ✅
|
||
* [ ] **Blau** – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.
|
||
* [ ] Unentschieden – die Regeln haben exakt gleiche Spezifität.
|
||
|
||
> **Feedback:** Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.
|
||
|
||
---
|
||
|
||
### Q19 – Von-Neumann: Der Flaschenhals (Engpass)
|
||
|
||
**Die Von-Neumann-Architektur hat einen bekannten Nachteil, den sogenannten „Von-Neumann-Flaschenhals“. Was ist damit gemeint?**
|
||
|
||
* [ ] Das Steuerwerk kann Befehle schneller verarbeiten, als das Rechenwerk sie berechnen kann.
|
||
* [x] **Die CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Daten und Befehle denselben Bus nutzen, müssen sie nacheinander geladen werden.** ✅
|
||
* [ ] Der Speicher verliert seine Daten, wenn der Strom abgeschaltet wird, was den Startvorgang verlangsamt.
|
||
* [ ] Die Ein-/Ausgabegeräte blockieren den Prozessor dauerhaft, da sie keinen eigenen Speicher haben.
|
||
|
||
> **Feedback:** Der Flaschenhals entsteht, weil Befehle und Daten sich den gleichen Weg (Bus) teilen müssen und der Speicherzugriff langsamer ist als die CPU-Geschwindigkeit.
|
||
|
||
---
|
||
|
||
### Q20 – HTML: Encoding (Charset)
|
||
|
||
**In Q4 ging es um Metadaten. Ein weiteres wichtiges Tag im `<head>` ist `<meta charset="UTF-8">`. Was ist die konkrete Konsequenz, wenn dieses Tag fehlt oder falsch ist?**
|
||
|
||
* [ ] Die Webseite lädt gar nicht, da der Browser den Binärcode nicht interpretieren kann.
|
||
* [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole („Hieroglyphen“) dargestellt, da der Browser die falsche Zeichenkodierung rät.** ✅
|
||
* [ ] Die Seite wird langsamer, da der Browser erst alle Sprachen der Welt durchprobieren muss.
|
||
* [ ] Das CSS wird nicht geladen, da CSS zwingend UTF-8 voraussetzt.
|
||
|
||
> **Feedback:** Ohne definierte `charset` (Zeichensatz) nutzt der Browser oft einen Standard (z. B. Latin-1), was bei UTF-8-gespeicherten Dateien zu Darstellungsfehlern bei ä, ö, ü oder Emojis führt.
|
||
|
||
---
|
||
|
||
### Q21 – Barrierefreiheit: POUR-Prinzip
|
||
|
||
**Die WCAG basieren auf vier Prinzipien (POUR). Eines davon ist „Bedienbarkeit“ (Operable). Welches Szenario beschreibt eine Verletzung dieses Prinzips?**
|
||
|
||
* [ ] Der Textkontrast ist zu gering (grau auf hellgrau), sodass man ihn kaum lesen kann.
|
||
* [x] **Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar.** ✅
|
||
* [ ] Der Inhalt ist in sehr komplizierter Fachsprache geschrieben, die ein Laie nicht versteht.
|
||
* [ ] Die Webseite stürzt in alten Browsern ab.
|
||
|
||
> **Feedback:** „Bedienbar“ bedeutet, dass die Schnittstelle (Buttons, Links) von jedem genutzt werden kann – also auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar“ (Perceivable).
|
||
|
||
---
|
||
|
||
### Q22 – Encapsulation: Die Empfänger-Seite (Decapsulation)
|
||
|
||
**In Q8 haben wir Daten verpackt. Wenn der Server das Signal empfängt, passiert das Gegenteil (Decapsulation). In welcher Reihenfolge werden die Header *entfernt*?**
|
||
|
||
* [ ] Anwendung (HTTP) → Transport (TCP) → Internet (IP) → Netzzugang (Ethernet)
|
||
* [ ] Es werden alle Header gleichzeitig entfernt, sobald die Daten im RAM liegen.
|
||
* [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
|
||
* [ ] Internet (IP) → Netzzugang (Ethernet) → Transport (TCP) → Anwendung (HTTP)
|
||
|
||
> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken (Zwiebel-Prinzip). Erst wird der Umschlag (Ethernet) geöffnet, dann das Paket (IP), dann das Segment (TCP).
|
||
|
||
---
|
||
|
||
### Q23 – Ports: Wozu genau?
|
||
|
||
**Wir wissen aus Q9, dass IP-Adressen Computer identifizieren. Wozu genau dient dann die Port-Nummer (z. B. 80 oder 443) auf dem Zielrechner?**
|
||
|
||
* [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
|
||
* [ ] Sie dient zur Verschlüsselung der Daten.
|
||
* [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver vs. Mailserver).** ✅
|
||
* [ ] Sie zeigt an, ob der Computer per WLAN oder Kabel verbunden ist.
|
||
|
||
> **Feedback:** Die IP ist wie die Hausnummer (welches Gebäude?), der Port ist wie die Türnummer oder der Name an der Klingel (wer im Haus soll das Paket bekommen? Webserver? Mailserver?).
|
||
|
||
---
|
||
|
||
### Q24 – TCP: Sequenznummern
|
||
|
||
**TCP ist zuverlässig. Ein Mechanismus dafür sind „Sequenznummern“ im Header. Welches Problem lösen diese konkret?**
|
||
|
||
* [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
|
||
* [x] **Pakete können im Internet unterschiedliche Routen nehmen und in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
|
||
* [ ] Sie zählen, wie viele Benutzer gerade gleichzeitig auf dem Server sind.
|
||
* [ ] Sie bestimmen die maximale Größe einer Datei.
|
||
|
||
> **Feedback:** Da IP-Pakete überholen können, kommen Teil 2 und Teil 3 vielleicht vor Teil 1 an. TCP sortiert sie anhand der Nummern wieder richtig. UDP macht das nicht.
|
||
|
||
---
|
||
|
||
### Q25 – HTTP Methoden: Sicherheit
|
||
|
||
**Warum sollte man niemals die GET-Methode verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?**
|
||
|
||
* [ ] GET ist langsamer als POST und 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 stehen sie im Body.** ✅
|
||
* [ ] GET erlaubt nur Zahlen, keine Buchstaben.
|
||
* [ ] GET-Anfragen werden vom Server nicht verschlüsselt, POST-Anfragen immer.
|
||
|
||
> **Feedback:** Parameter bei GET hängen an der URL (`?pw=123`). Das ist in der History und in Logs sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL ist an zu vielen Stellen sichtbar.
|
||
|
||
---
|
||
|
||
### Q26 – HTTP Status: 404 Not Found
|
||
|
||
**Du erhältst einen 404-Fehler. In Q13 (503) lag der Fehler beim Server. Wer hat beim 404-Fehler „Schuld“ bzw. wo liegt die Ursache meistens?**
|
||
|
||
* [ ] Der Server ist abgestürzt.
|
||
* [ ] Das Internet ist ausgefallen.
|
||
* [x] **Der Client (Nutzer). Es wurde eine URL angefordert, die es nicht gibt (Tippfehler oder veralteter Link).** ✅
|
||
* [ ] Der DNS-Server konnte den Namen nicht auflösen.
|
||
|
||
> **Feedback:** 4xx-Codes sind Client-Errors. Der Server funktioniert super, er sagt dir nur: „Das, was du (Client) suchst, habe ich nicht.“
|
||
|
||
---
|
||
|
||
### Q27 – CSS: `!important` vs. ID
|
||
|
||
**In Q15 hat die ID gewonnen. Nun ändern wir den Code:**
|
||
|
||
```css
|
||
#main { color: red; }
|
||
p { color: blue !important; }
|
||
|
||
```
|
||
|
||
**Welche Farbe hat das `<p id="main">` Element nun?**
|
||
|
||
* [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor.
|
||
* [ ] **Lila** – Die Farben mischen sich.
|
||
* [x] **Blau** – `!important` durchbricht die normale Spezifitäts-Kaskade und gewinnt sogar gegen IDs (außer die ID hat auch !important). ✅
|
||
* [ ] **Rot** – `!important` wird von modernen Browsern ignoriert.
|
||
|
||
> **Feedback:** `!important` ist die „Atombombe“ im CSS. Es überschreibt normale Spezifitätsregeln (ID, Klasse, Element). Es sollte daher sehr sparsam eingesetzt werden.
|
||
|
||
---
|
||
|
||
### Q28 – Responsive Design: Desktop First
|
||
|
||
**In Q16 nutzten wir `min-width` (Mobile First). Wie würde die Media Query aussehen, wenn wir „Desktop First“ arbeiten würden (also Standard ist Desktop, Anpassung für kleine Screens)?**
|
||
|
||
* [ ] `@media (device-width: small) { ... }`
|
||
* [ ] `@media (min-width: ...)` – das bleibt gleich, nur die Reihenfolge ändert sich.
|
||
* [x] **`@media (max-width: ...)` – Wir definieren Stile für Bildschirme, die *kleiner* als eine bestimmte Breite sind.** ✅
|
||
* [ ] `@media (mobile: true) { ... }`
|
||
|
||
> **Feedback:** Desktop First bedeutet: Das Basis-CSS ist für große Schirme. Mit `max-width` (maximale Breite) definieren wir Ausnahmen für Geräte, die schmaler sind (Tablets, Handys).
|