add erklaerung slides after klausur slides in 223015c

- add section.erklaerung CSS class with pink theme styling - add 6 explanation slides to 01-geschichte-grundlagen-html.md - add 10 explanation slides to 02-netzwerke-protokolle-css.md - each slide includes definition, key points, and mnemonics
add archive directory with old klausurfragen files
2026-02-02 14:03:54 +01:00 · 2026-02-02 13:42:12 +01:00 · 2026-02-02 13:42:11 +01:00 · 2026-02-02 13:42:02 +01:00 · 2026-02-02 13:41:58 +01:00 · 2026-02-02 13:41:52 +01:00
15 changed files with 8496 additions and 3656 deletions
@@ -0,0 +1,469 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <quiz>
 <!-- ============================================================
     223015c – Grundlagen IT- und Internettechnik
     40 Punkte / 40 Minuten
     Michael Czechowski – HdM Stuttgart – WS 2025/26
     ============================================================ -->
 <!-- ─── 3 pt – Von-Neumann: 5 Komponenten ─── -->
 <question type="matching">
  <n><text>Q1 – Von-Neumann: Komponenten zuordnen</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Ordne jeder Komponente der Von-Neumann-Architektur ihre
      Funktion zu.</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).</text></generalfeedback>
  <defaultgrade>3</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <shuffleanswers>true</shuffleanswers>
  <answer fraction="100"><text>Rechenwerk (ALU)</text><match>Führt arithmetische und logische Operationen durch.</match></answer>
  <answer fraction="100"><text>Steuerwerk</text><match>Holt, dekodiert und steuert die Ausführung von Befehlen.</match></answer>
  <answer fraction="100"><text>Speicherwerk</text><match>Enthält sowohl Programme als auch Daten (Stored Program Concept).</match></answer>
  <answer fraction="100"><text>Ein-/Ausgabe</text><match>Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.</match></answer>
  <answer fraction="100"><text>Bus-System</text><match>Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.</match></answer>
 </question>
 <!-- ─── 2 pt – Von-Neumann vs Harvard: Transfer ─── -->
 <question type="multichoice">
  <n><text>Q2 – Von-Neumann vs. Harvard</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Ein Arduino-Mikrocontroller nutzt die <strong>Harvard-Architektur</strong>.
      Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.</p>
      <p><strong>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?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>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.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – Speed vs. Flexibilität.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, was getrennte Speicher für Code und Daten bedeuten.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[Harvard nutzt <strong>separate Speicher</strong> für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.]]></text></answer>
 </question>
 <!-- ─── 2 pt – Stored Program Concept Transfer ─── -->
 <question type="multichoice">
  <n><text>Q3 – Stored Program Concept</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem
      ENIAC Programme durch <strong>Umstecken von Kabeln</strong> eingegeben
      werden.</p>
      <p><strong>Was konkret ermöglicht das Stored Program Concept, was
      vorher nicht möglich war? Nenne zwei Beispiele.</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – Programme als Daten im Speicher = Flexibilität.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – der Kern liegt darin, dass Programme im Speicher als Daten residieren.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[Programme werden als <strong>Daten im Speicher</strong> abgelegt → z. B. Apps können installiert/gelöscht werden und <strong>Multitasking</strong> (mehrere Programme gleichzeitig) wird möglich.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.]]></text></answer>
 </question>
 <!-- ─── 2 pt – HTML Metadaten: Transfer ─── -->
 <question type="multichoice">
  <n><text>Q4 – HTML: &lt;head&gt; vs. &lt;body&gt;</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Ein Student erstellt eine Webseite und platziert <em>alles</em>
      im <code>&lt;body&gt;</code> – auch den <code>&lt;title&gt;</code>
      und die <code>&lt;meta name="description"&gt;</code>.</p>
      <p><strong>Welche zwei konkreten Konsequenzen hat das?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>title und meta description gehören in &lt;head&gt;. Im &lt;body&gt;: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – Metadaten im Body werden nicht als solche interpretiert.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – &lt;head&gt; und &lt;body&gt; haben spezifische Funktionen.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[(1) Der Browser-Tab zeigt <strong>keinen Titel</strong> an. (2) Suchmaschinen haben <strong>keine Beschreibung</strong> für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Kein Problem – Browser ignorieren die Unterscheidung zwischen <code>&lt;head&gt;</code> und <code>&lt;body&gt;</code>.]]></text></answer>
  <answer fraction="0"><text><![CDATA[(1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Nur das Fehlen von <code>&lt;meta charset&gt;</code> ist ein Problem – title und description funktionieren überall.]]></text></answer>
 </question>
 <!-- ─── 3 pt – Accessibility Transfer ─── -->
 <question type="multichoice">
  <n><text>Q5 – Barrierefreiheit: Curb-Cut-Effekt</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Der <strong>Curb-Cut-Effekt</strong> beschreibt, wie eine
      barrierefreie Lösung – ursprünglich für Menschen mit Behinderung –
      letztendlich <em>allen</em> zugute kommt.</p>
      <p><strong>Nenne ein konkretes Web-Beispiel, das diesen Effekt
      demonstriert, und erkläre, wer davon profitiert.</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>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.</text></generalfeedback>
  <defaultgrade>3</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – Barrierefreiheit hilft allen.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, welche barrierefreien Maßnahmen auch Menschen ohne Behinderung nutzen.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[<strong>Untertitel:</strong> Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Dark Mode:</strong> Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.]]></text></answer>
 </question>
 <!-- ─── 2 pt – EAA / WCAG ─── -->
 <question type="multichoice">
  <n><text>Q6 – European Accessibility Act</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Der <strong>European Accessibility Act (EAA)</strong> ist seit
      Juni 2025 in Kraft.</p>
      <p><strong>Was bedeutet das konkret für ein deutsches
      E-Commerce-Unternehmen, das eine Webseite betreibt?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>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.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – rechtliche Pflicht zur Barrierefreiheit.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – der EAA erstellt eine rechtliche Verpflichtung für bestimmte Sektoren.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[Die Webseite <strong>muss barrierefreiheitstechnisch</strong> WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.]]></text></answer>
 </question>
 <!-- ─── 3 pt – TCP/IP Schichten: Protokoll → Schicht ─── -->
 <question type="matching">
  <n><text>Q7 – TCP/IP: Protokoll → Schicht</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.</text></generalfeedback>
  <defaultgrade>3</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <shuffleanswers>true</shuffleanswers>
  <answer fraction="100"><text>HTTP</text><match>Anwendung</match></answer>
  <answer fraction="100"><text>TCP</text><match>Transport</match></answer>
  <answer fraction="100"><text>IP</text><match>Internet</match></answer>
  <answer fraction="100"><text>Ethernet</text><match>Netzzugang</match></answer>
  <answer fraction="100"><text>DNS</text><match>Anwendung</match></answer>
  <answer fraction="100"><text>UDP</text><match>Transport</match></answer>
 </question>
 <!-- ─── 3 pt – Encapsulation: D-S-P-F ─── -->
 <question type="matching">
  <n><text>Q8 – Encapsulation: Dateneinheit → Schicht</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Bei der Übertragung wird eine Nachricht von Schicht zu Schicht
      verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige
      Schicht zu.</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.</text></generalfeedback>
  <defaultgrade>3</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <shuffleanswers>true</shuffleanswers>
  <answer fraction="100"><text>Daten</text><match>Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).</match></answer>
  <answer fraction="100"><text>Segment</text><match>Transportschicht – Daten + Ports und Sequenznummern.</match></answer>
  <answer fraction="100"><text>Paket</text><match>Internetschicht – Segment + IP-Adressen (Quelle und Ziel).</match></answer>
  <answer fraction="100"><text>Frame</text><match>Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.</match></answer>
 </question>
 <!-- ─── 3 pt – IP vs MAC vs Port Transfer ─── -->
 <question type="multichoice">
  <n><text>Q9 – IP vs. MAC vs. Port: Transfer-Szenario</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in
      einem anderen Land. Das Paket durchläuft mehrere Router.</p>
      <p><strong>Welche der folgenden Aussagen über die Adressen auf dem
      Weg ist korrekt?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.</text></generalfeedback>
  <defaultgrade>3</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – nur MAC ändert sich unterwegs.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, welche Adresse bei jedem Hop neu gesetzt wird.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[Die <strong>IP-Adresse</strong> des Servers bleibt konstant, der <strong>Port</strong> (443) ändert sich nicht – die <strong>MAC-Adresse</strong> wird an jedem Router neu gesetzt (lokal, ein Hop).]]></text></answer>
  <answer fraction="0"><text><![CDATA[Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.]]></text></answer>
  <answer fraction="0"><text><![CDATA[IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.]]></text></answer>
 </question>
 <!-- ─── 3 pt – 3-Way Handshake: Transfer ─── -->
 <question type="multichoice">
  <n><text>Q10 – TCP 3-Way-Handshake: Was passiert wäre?</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Der Client sendet ein <strong>SYN</strong> zum Server.
      Das SYN-Paket geht verloren – es erreicht den Server nie.</p>
      <p><strong>Was passiert als nächstes, und warum wird keine
      Verbindung aufgebaut?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>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).</text></generalfeedback>
  <defaultgrade>3</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – ohne SYN beim Server: kein SYN-ACK, kein Handshake.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, was der Server ohne SYN tun kann.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[Der Server kennt die Anfrage nicht → sendet <strong>kein SYN-ACK</strong> → der Client erhält keine Antwort → <strong>keine Verbindung</strong>. Der Client wird das SYN nach einem Timeout erneut senden.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.]]></text></answer>
 </question>
 <!-- ─── 2 pt – TCP vs UDP Transfer ─── -->
 <question type="multichoice">
  <n><text>Q11 – TCP vs. UDP: Videostreaming</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Ein Videostreaming-Dienst sendet Daten an deinen Browser.
      Ein einzelnes Paket geht verloren.</p>
      <p><strong>Warum wählt der Dienst <strong>UDP</strong> statt TCP,
      obwohl ein Paket verloren geht?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>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.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – bei Echtzeit ist Verzögerung ärger als Verlust.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, was TCP bei einem verlorenen Paket tun würde.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[Bei <strong>Echtzeit</strong> ist Verzögerung schlimmer als Verlust. TCP würde das Paket <strong>erneut anfordern</strong> → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.]]></text></answer>
  <answer fraction="0"><text><![CDATA[UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.]]></text></answer>
  <answer fraction="0"><text><![CDATA[TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.]]></text></answer>
  <answer fraction="0"><text><![CDATA[UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.]]></text></answer>
 </question>
 <!-- ─── 2 pt – HTTP Methoden: Transfer ─── -->
 <question type="multichoice">
  <n><text>Q12 – HTTP-Methoden: Szenario</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Ein Nutzer aktualisiert sein Profilbild auf einer Webseite.
      Das Foto wird zum Server gesendet und das <strong>alte Bild
      ersetzt</strong>.</p>
      <p><strong>Welche HTTP-Methode wird für diese Operation verwendet,
      und warum nicht GET?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – PUT für das Ersetzen einer Ressource.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, was „ersetzen" in HTTP bedeutet.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[<strong>PUT</strong> – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet <em>keine</em> Daten zum Server.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>GET</strong> – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>POST</strong> – POST ist immer für das Ersetzen von Daten zuständig.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>DELETE</strong> – DELETE sendet das neue Foto und löscht gleichzeitig das alte.]]></text></answer>
 </question>
 <!-- ─── 2 pt – HTTP Status-Codes Transfer ─── -->
 <question type="multichoice">
  <n><text>Q13 – HTTP Status-Codes: Fehlerdiagnose</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Du rufst eine Webseite auf und der Browser zeigt folgende
      Fehlermeldung an:</p>
      <pre>HTTP/1.1 503 Service Unavailable</pre>
      <p><strong>Was bedeutet dieser Code, und wer ist für die Behebung
      zuständig – du oder der Betreiber der Webseite?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – 5xx = Server-Problem, nicht dein Fehler.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, was die Ziffer „5" im Code bedeutet.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[<strong>Server-Fehler:</strong> Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim <strong>Betreiber</strong> – du kannst nur später erneut versuchen.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.]]></text></answer>
 </question>
 <!-- ─── 2 pt – DNS Ablauf Transfer ─── -->
 <question type="multichoice">
  <n><text>Q14 – DNS: Rolle im Ablauf</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Du gibst <code>https://hdm-stuttgart.de</code> in die
      Adresszeile ein.</p>
      <p><strong>Was passiert <em>vor</em> dem TCP-Handshake, und warum
      ist dieser Schritt zwingend nötig?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>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.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – DNS vor TCP, Name → IP.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, was TCP als Zieladresse braucht.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[<strong>DNS-Auflösung:</strong> Der Name <code>hdm-stuttgart.de</code> wird in eine <strong>IP-Adresse</strong> umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.]]></text></answer>
  <answer fraction="0"><text><![CDATA[DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.]]></text></answer>
  <answer fraction="0"><text><![CDATA[DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.]]></text></answer>
 </question>
 <!-- ─── 2 pt – CSS Spezifität Transfer ─── -->
 <question type="multichoice">
  <n><text>Q15 – CSS Spezifität: Welche Regel gewinnt?</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Gegeben folgender CSS-Code:</p>
      <pre>
 p           { color: blue; }      /* (A) */
 .highlight  { color: green; }     /* (B) */
 #main       { color: red; }       /* (C) */
      </pre>
      <p>Ein Element <code>&lt;p class="highlight" id="main"&gt;Text&lt;/p&gt;</code>
      wird angezeigt.<br>
      <strong>Welche Farbe zeigt der Text an, und warum?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>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.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – ID gewinnt durch höchste Spezifität.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege die Spezifitätswerte: ID > Klasse > Element.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[<strong>Rot</strong> – die ID-Regel <code>#main</code> hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die Element-Regel steht zuerst im Code und hat daher Vorrang.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Grün</strong> – Klassen-Selektoren haben immer Vorrang vor IDs.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Rot</strong> – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.]]></text></answer>
 </question>
 <!-- ─── 2 pt – Responsive Design Transfer ─── -->
 <question type="multichoice">
  <n><text>Q16 – Responsive Design: Mobile First</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Ein Developer schreibt folgendes CSS:</p>
      <pre>
 .container { background: white; }
@media (min-width: 768px) {
    .container { background: blue; }
 }
@media (min-width: 1024px) {
    .container { background: green; }
 }
      </pre>
      <p><strong>Welche Farbe hat <code>.container</code> bei einem
      Bildschirm von 900 px Breite, und warum?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 &lt; 1024). Ergebnis: blau.</text></generalfeedback>
  <defaultgrade>2</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – 768px greift, 1024px nicht.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – überlege, welche min-width-Bedingungen bei 900px erfüllt sind.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[<strong>Blau</strong> – bei 900 px greift <code>min-width: 768px</code> (900 ≥ 768), aber <code>min-width: 1024px</code> greift nicht (900 &lt; 1024).]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Grün</strong> – die letzte Media-Query überschreibt immer alle vorherigen.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.]]></text></answer>
 </question>
 <!-- ─── 1 pt – Zusammen: Der Ablauf eines Klicks ─── -->
 <question type="multichoice">
  <n><text>Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Du gibst eine URL ein. <strong>Welche Reihenfolge der Schritte
      ist korrekt?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).</text></generalfeedback>
  <defaultgrade>1</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – DNS → TCP → HTTP Request → HTTP Response.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – an erster Stelle steht immer die DNS-Auflösung.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
  <answer fraction="0"><text><![CDATA[(1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
  <answer fraction="0"><text><![CDATA[(1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
  <answer fraction="0"><text><![CDATA[(1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
 </question>
 <!-- ─── 1 pt – Bonusfrage: Spezifität Edge Case ─── -->
 <question type="multichoice">
  <n><text>Q18 – CSS: 100 Element-Selektoren vs. 1 Klasse</text></n>
  <questiontext type="html">
    <text><![CDATA[
      <p>Es gibt zwei CSS-Regeln für ein <code>&lt;p&gt;</code>-Element:</p>
      <pre>
 p p p p p p p p p p  { color: blue; }   /* 100× Element-Selektor */
 .highlight           { color: red; }    /* 1× Klasse */
      </pre>
      <p>Das Element hat die Klasse <code>highlight</code>.
      <strong>Welche Farbe gewinnt?</p>
    ]]></text>
  </questiontext>
  <generalfeedback type="html"><text>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.</text></generalfeedback>
  <defaultgrade>1</defaultgrade>
  <penalty>0.25</penalty>
  <hidden>0</hidden>
  <single>true</single>
  <shuffleanswers>true</shuffleanswers>
  <correctfeedback type="html"><text>Genau – eine Klasse gewinnt immer gegen beliebig viele Elemente.</text></correctfeedback>
  <incorrectfeedback type="html"><text>Nein – Spezifität funktioniert nicht durch Addition innerhalb einer Stelle.</text></incorrectfeedback>
  <answer fraction="100"><text><![CDATA[<strong>Rot</strong> – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Blau</strong> – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.]]></text></answer>
  <answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.]]></text></answer>
  <answer fraction="0"><text><![CDATA[Unentschieden – die Regeln haben exakt gleiche Spezifität.]]></text></answer>
 </question>
 </quiz>
@@ -0,0 +1,439 @@
 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).
@@ -41,6 +41,7 @@ TOPIC_MAP["vertiefung-offene-fragen"]="Vertiefung & Offene Fragen"
 TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
 TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
 TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
 TOPIC_MAP["klausurfragen"]="Klausurfragen"
 # Configure which topics should appear disabled per course
 # Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
@@ -0,0 +1,187 @@
 #!/usr/bin/env bash
 # Generate root index.html for /hdm/
 # Lists all courses (klausurfragen are now per-course)
 BUILD_DIR="build"
 cat > "$BUILD_DIR/index.html" << 'HEADER'
 <!DOCTYPE html>
 <html lang="de">
 <head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>HdM Vorlesungen</title>
  <style>
    * { box-sizing: border-box; margin: 0; padding: 0; }
    body {
      font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif;
      max-width: 720px;
      margin: 0 auto;
      padding: 3rem 1.5rem;
      background: #fafafa;
      color: #1d1d1f;
      line-height: 1.5;
    }
    h1 {
      font-size: 2rem;
      font-weight: 600;
      letter-spacing: -0.02em;
      margin-bottom: 0.5rem;
    }
    .subtitle { color: #86868b; font-size: 1rem; }
    .courses {
      margin-top: 2rem;
      display: flex;
      flex-direction: column;
      gap: 0.75rem;
    }
    .course-card {
      position: relative;
      background: #fff;
      border-radius: 12px;
      box-shadow: 0 1px 3px rgba(0,0,0,0.08);
      transition: all 0.2s ease;
      display: grid;
      grid-template-columns: 1fr auto auto;
      align-items: center;
      gap: 1rem;
    }
    .course-card:hover {
      transform: translateY(-2px);
      box-shadow: 0 4px 12px rgba(0,0,0,0.12);
    }
    .course-link {
      display: block;
      padding: 1.25rem 1.5rem;
      text-decoration: none;
      color: inherit;
      grid-column: 1;
    }
    .course-link::after {
      content: '';
      position: absolute;
      inset: 0;
      border-radius: 12px;
    }
    .course-label {
      font-size: 0.7rem;
      font-weight: 600;
      text-transform: uppercase;
      letter-spacing: 0.05em;
    }
    .course-b .course-label { color: #1e5f8a; }
    .course-c .course-label { color: #d63384; }
    .course-title {
      font-size: 1.15rem;
      font-weight: 500;
      color: #1d1d1f;
      margin: 0.25rem 0;
    }
    .course-info { font-size: 0.85rem; color: #86868b; }
    .btn {
      display: inline-flex;
      align-items: center;
      justify-content: center;
      padding: 0.5rem 1rem;
      border-radius: 8px;
      text-decoration: none;
      font-size: 0.8rem;
      font-weight: 500;
      transition: all 0.2s;
      white-space: nowrap;
      position: relative;
      z-index: 1;
      margin-right: 0.5rem;
    }
    .btn-slides {
      background: #6c757d;
      color: #fff;
    }
    .btn-slides:hover { filter: brightness(1.1); }
    .btn-pdf {
      background: #f5f5f7;
      color: #1d1d1f;
    }
    .btn-pdf:hover { background: #e8e8ed; }
    .section-title {
      font-size: 1rem;
      font-weight: 600;
      color: #86868b;
      margin-top: 2.5rem;
      margin-bottom: 0.75rem;
    }
    .references {
      display: flex;
      flex-direction: column;
      gap: 0.75rem;
    }
    footer {
      margin-top: 2.5rem;
      padding-top: 1.5rem;
      border-top: 1px solid #e5e5e7;
      color: #86868b;
      font-size: 0.85rem;
    }
    footer a { color: #1d1d1f; text-decoration: none; }
    footer a:hover { text-decoration: underline; }
    .qr-section {
      margin-top: 2.5rem;
      padding: 1.5rem;
      background: #fff;
      border-radius: 12px;
      box-shadow: 0 1px 3px rgba(0,0,0,0.08);
      text-align: center;
    }
    .qr-code { width: 100%; height: auto; }
    .qr-url { margin-top: 0.75rem; font-size: 0.85rem; color: #86868b; }
    @media (max-width: 600px) {
      .course-card { grid-template-columns: 1fr; }
      .course-link { padding-bottom: 0.75rem; }
      .btn { margin: 0 1rem 1rem 1.5rem; }
    }
  </style>
 </head>
 <body>
  <h1>HdM Vorlesungen</h1>
  <p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p>
  <div class="courses">
    <div class="course-card course-b">
      <a href="223015b/" class="course-link">
        <span class="course-label">223015b</span>
        <div class="course-title">Dateiformate, Schnittstellen, Speichermedien &amp; Distributionswege</div>
        <span class="course-info">6 Kapitel · Modul "Technik 1"</span>
      </a>
    </div>
    <div class="course-card course-c">
      <a href="223015c/" class="course-link">
        <span class="course-label">223015c</span>
        <div class="course-title">Grundlagen IT- und Internettechnik</div>
        <span class="course-info">3 Kapitel · Modul "Technik 1"</span>
      </a>
    </div>
 HEADER
 cat >> "$BUILD_DIR/index.html" << 'FOOTER'
  </div>
  <h2 class="section-title">Referenzen</h2>
  <div class="references">
    <div class="course-card">
      <a href="https://codecrispi.es/" class="course-link">
        <span class="course-label">Plattform</span>
        <div class="course-title">Code Crispies</div>
        <span class="course-info">Selbstlernplattform</span>
      </a>
    </div>
  </div>
  <div class="qr-section">
    <img src="qr-root.svg" alt="QR Code" class="qr-code">
    <p class="qr-url">https://librete.ch/hdm/</p>
  </div>
  <footer>
    <a href="mailto:mail@librete.ch">Kontakt</a>
  </footer>
 </body>
 </html>
 FOOTER
 echo "Generated $BUILD_DIR/index.html"
@@ -68,38 +68,6 @@ section.aufgabe {
 section.aufgabe footer {
  display: none;
 }
 section.erklaerung {
  font-size: 1.1rem;
  background: repeating-linear-gradient(
    135deg,
    #e3f2fd,
    #e3f2fd 40px,
    #fff 40px,
    #fff 80px
  ) !important;
 }
@media print {
  section.erklaerung {
    background: #e3f2fd !important;
  }
 }
 section.erklaerung h1 {
  font-size: 1.5rem;
  color: #1e5f8a;
  margin-bottom: 0.3rem;
 }
 section.erklaerung ul,
 section.erklaerung ol {
  font-size: 1.0rem;
  line-height: 1.4;
 }
 section.erklaerung p {
  font-size: 1.0rem;
  line-height: 1.4;
 }
 section.erklaerung table {
  font-size: 0.9rem;
 }
 </style>
 <!-- _class: invert -->
@@ -267,29 +235,6 @@ Kleine SSD für System + große HDD für Archiv.
 ---
 <!-- _class: erklaerung -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
 # HDD vs. SSD – Vertiefung
 **HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
 **SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
 | Aspekt | HDD | SATA SSD | NVMe SSD |
 |--------|-----|----------|----------|
 | Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
 | Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
 | IOPS (4K random) | 100 | 90.000 | 1.000.000 |
 | TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
 **Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
 **Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
 ---
 <!-- _class: lead -->
 # Dateisysteme
@@ -539,30 +484,6 @@ Warum 1 Offsite?
 ---
 <!-- _class: erklaerung -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
 # 3-2-1-Backup-Regel – Vertiefung
 Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
 | Bedrohung | Schutz durch | Beispiel |
 |-----------|--------------|----------|
 | Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
 | Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
 | Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
 **Moderne Erweiterung 3-2-1-1-0:**
 - **+1** Air-Gapped (offline, nicht verbunden)
 - **+0** Verifizierte Backups (regelmäßig Restore testen)
 **Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
 **Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
 ---
 # Backup-Arten
 **Vollständig (Full):**
@@ -102,166 +102,6 @@ Hochschule der Medien Stuttgart
 <!-- _footer: "" -->
 # Verlustfrei vs. Verlustbehaftet
 | | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
 |---|---|---|
 | **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
 | **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
 | **Reduktion** | 30-50% | 80-99% |
 | **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
 **Faustregel:**
 - Medien für Endnutzer → Lossy oft akzeptabel
 - Quellmaterial, Code, Archive → Lossless nötig
 <!--
 REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
 IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
 KLAUSURRELEVANT:
 - Verlustfrei = Original 1:1 wiederherstellbar
 - Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
 - Redundanz vs. Irrelevanz ist der Kernunterschied!
 -->
 ---
 <!-- _header: "" -->
 <!-- _footer: "" -->
 # Dateneinheiten
 | Einheit | Bytes | Potenz | Beispiel |
 |---------|------:|:------:|----------|
 | **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
 | **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
 | **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
 | **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
 | **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
 | **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
 | **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
 | **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
 <!--
 SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
 Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
 Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
 1 TB Festplatte = ~931 GiB nutzbar
 Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
 → "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
 -->
 ---
 <!-- _header: "" -->
 <!-- _footer: "" -->
 # Der digitale Wendepunkt
 | Jahr | Analog | Digital | Digital-Anteil |
 |------|--------|---------|----------------|
 | **1986** | 2,6 EB | 0,02 EB | **1%** |
 | **2002** | — | — | **50%** (Wendepunkt) |
 | **2007** | 18 EB | 277 EB | **94%** |
 **Perspektive:**
 - 1986: "Petabyte" war ein theoretisches Konzept
 - 2025: ~181 Zettabyte jährlich produziert
 **Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
 (AWS Glacier, Film-Archive, Rechenzentren)
 <!--
 PRÜFUNGSRELEVANT:
 - Wendepunkt 2002
 - Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
 - Magnetband als Archivmedium
 QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
 METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
 WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
 ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
 DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
 HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
 VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
 -->
 ---
 <!-- _header: "" -->
 <!-- _footer: "" -->
 # Analoge Medien
 ### Distribution: physisch (Kauf, Verleih, Kopie)
 - **Text**
    - Bücher, Zeitungen, Zeitschriften, Lochkarten
 - **Bild**
    - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
 - **Audio:**
    - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
 - **Video:**
    - Film (35mm, Super 8), VHS, Betamax
 ---
 <!-- _header: "" -->
 <!-- _footer: "" -->
 # Digitale Medien
 ### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
 - **Text**
    - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
 - **Bild**
    - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
 - **Audio**
    - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
 - **Video**
    - Videodatei (MP4, MKV, AVI, WebM)
 ---
 <!-- _header: "" -->
 <!-- _footer: "" -->
 # Digitale Speichermedien
 - **Optische Speicher**
    - CD, DVD, Blu-ray
 - **Magnetische Speicher**
    - Festplatte (HDD), Magnetband (LTO)
 - **Flash-Speicher**
    - SSD, USB-Stick, SD-Karte
 - **Cloud-Speicher**
    - Dropbox, Google Drive, iCloud, AWS S3
 ---
 <!-- _header: "" -->
 <!-- _footer: "" -->
 # Rastergrafiken
 **Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
@@ -403,7 +243,6 @@ KLAUSURRELEVANT:
 - Präfix-frei: Kein Code ist Anfang eines anderen
 - Häufigstes Zeichen = kürzester Code
 - Auch in ZIP, PNG, MP3 verwendet
 -->
 ---
@@ -3,9 +3,9 @@ marp: true
 theme: gaia
 paginate: true
 backgroundColor: #fff
-header: ""
+header: "Klausurfragen – 223015b"
-footer: ""
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
-title: "Fragenkatalog – Dateiformate (223015b)"
+title: "Klausurfragen – Dateiformate, Schnittstellen, Speichermedien"
 ---
 <style>
 :root {
@@ -13,42 +13,21 @@ title: "Fragenkatalog – Dateiformate (223015b)"
  --color-highlight: #1e5f8a;
  --color-dimmed: #4a4a6a;
 }
-section.invert {
+section.invert { --color-foreground: #fff; }
-  --color-foreground: #fff;
+section { font-size: 1.325rem; }
-}
+h1 { color: #1e5f8a; }
-section {
+section.invert h1 { color: #fff; }
-  font-size: 1.325rem;
+h2 { color: #1f2937; }
-}
+pre { background: #0f0f23; border-radius: 8px; }
-h1 {
+pre code { background: transparent; color: inherit; }
-  color: #1e5f8a;
+a { color: var(--color-highlight); }
-}
+section.disable { opacity: 0.3; }
 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 – 223015b
 **Dateiformate, Schnittstellen, Speichermedien · HdM Stuttgart · M. Czechowski**
-<small>Stand: 01.02.2026</small>
+<small>Stand: 02.02.2026</small>
 ---
@@ -60,7 +39,7 @@ section.disable {
 > `[ESSAY]` = `essay` (Freitext, manuell bewertet)
 > `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
 > `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
-> `[CLOZE]` = `cloze` (Lückentext, gemischt)`
+> `[CLOZE]` = `cloze` (Lückentext, gemischt)
 ---
@@ -70,8 +49,6 @@ section.disable {
 ---
 <!-- _class: disable -->
 ### J1 – Was bedeutet „komprimieren"?
 **Thema:** Grundbegriffe – Kompression
 **Punkte:** 1
@@ -119,8 +96,6 @@ Erkläre den Unterschied zwischen verlustfreier und verlustbehafteter Kompressio
 ---
 <!-- _class: disable -->
 ### J4 – Was bedeutet „skalieren"?
 **Thema:** Grundbegriffe – Skalierung
 **Punkte:** 1
@@ -137,8 +112,6 @@ Was passiert, wenn ein Rasterbild vergrößert wird?
 ---
 <!-- _class: disable -->
 ### J5 – Was bedeutet „konvertieren"?
 **Thema:** Grundbegriffe – Konvertierung
 **Punkte:** 1
@@ -155,8 +128,6 @@ Was bedeutet es, eine Datei zu konvertieren?
 ---
 <!-- _class: disable -->
 ### J6 – Was bedeutet „codieren" und „decodieren"?
 **Thema:** Grundbegriffe – Codec-Konzept
 **Punkte:** 2
@@ -201,8 +172,6 @@ Ordne zu: Container oder Codec?
 ---
 <!-- _class: disable -->
 ### J9 – Redundanz vs. Irrelevanz
 **Thema:** Grundbegriffe – Kompressionsprinzipien
 **Punkte:** 2
@@ -237,8 +206,6 @@ Sortiere die Dateneinheiten von kleinster zu größter:
 ---
 <!-- _class: disable -->
 ### J11 – Bit und Byte: Umrechnung
 **Thema:** Grundbegriffe – Bit/Byte-Verhältnis
 **Punkte:** 1
@@ -252,8 +219,6 @@ Ein Bit ist die kleinste Informationseinheit. Ein Byte besteht aus wie vielen Bi
 ---
 <!-- _class: disable -->
 ### J12 – 7-Bit ASCII: Wie viele Zeichen?
 **Thema:** Grundbegriffe – ASCII-Zeichenkodierung
 **Punkte:** 1
@@ -267,8 +232,6 @@ Der ASCII-Standard verwendet 7 Bit pro Zeichen. Wie viele verschiedene Zeichen k
 ---
 <!-- _class: disable -->
 ### J13 – Hexadezimalzahlen: Zwei 4-Bit-Werte
 **Thema:** Grundbegriffe – Hexadezimal
 **Punkte:** 2
@@ -282,8 +245,6 @@ Zwei Hexadezimalzahlen werden jeweils durch 4 Bit dargestellt. Wie viele verschi
 ---
 <!-- _class: disable -->
 ### J14 – Ein Pixel, drei Kanäle, 8 Bit
 **Thema:** Grundbegriffe – Speicherbedarf eines Pixels
 **Punkte:** 1
@@ -415,8 +376,6 @@ Erkläre, warum ein Rasterbild beim Vergrößern unscharf wird, während ein Vek
 ---
 <!-- _class: disable -->
 ### K8 – Vektor → Raster: Wie heißt das?
 **Thema:** Raster vs. Vektor – Konvertierung
 **Punkte:** 1
@@ -459,8 +418,6 @@ Ordne jedem Interpolationsverfahren seine Eigenschaft zu.
 ---
 <!-- _class: disable -->
 ### L1 – JPEG: Verlustfrei oder verlustbehaftet?
 **Thema:** JPEG – Grundeigenschaft
 **Punkte:** 1
@@ -509,8 +466,6 @@ Warum wird bei JPEG von RGB in YCbCr konvertiert?
 ---
 <!-- _class: disable -->
 ### L4 – Chroma Subsampling: Was ist 4:2:0?
 **Thema:** JPEG Schritt 2 – Subsampling
 **Punkte:** 2
@@ -527,8 +482,6 @@ Was bedeutet das Subsampling-Schema 4:2:0?
 ---
 <!-- _class: disable -->
 ### L5 – JPEG-Schritte: Richtige Reihenfolge
 **Thema:** JPEG – Kompressionsablauf
 **Punkte:** 2
@@ -547,8 +500,6 @@ Sortiere die Schritte der JPEG-Kompression in der richtigen Reihenfolge:
 ---
 <!-- _class: disable -->
 ### L6 – Welcher Schritt ist verlustbehaftet?
 **Thema:** JPEG – Verlust lokalisieren
 **Punkte:** 1
@@ -624,8 +575,6 @@ Ordne jedem JPEG-Artefakt seine Beschreibung zu.
 ---
 <!-- _class: disable -->
 ### M1 – PNG: Verlustfrei oder verlustbehaftet?
 **Thema:** PNG – Grundeigenschaft
 **Punkte:** 1
@@ -642,8 +591,6 @@ Wie komprimiert PNG?
 ---
 <!-- _class: disable -->
 ### M2 – PNG vs. JPEG: Wann was?
 **Thema:** Bildformate – Formatwahl
 **Punkte:** 2
@@ -655,8 +602,6 @@ Erklären Sie, wann Sie PNG und wann JPEG wählen würden. Nenne je zwei konkret
 ---
 <!-- _class: disable -->
 ### M3 – GIF: Wie viele Farben?
 **Thema:** GIF – Eigenschaften
 **Punkte:** 1
@@ -673,6 +618,8 @@ Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
 ---
 <!-- _class: disable -->
 ### M4 – WebP vs. JPEG: Vorteil?
 **Thema:** Bildformate – WebP
 **Punkte:** 1
@@ -689,8 +636,6 @@ Was ist der hauptsächliche Vorteil von WebP gegenüber JPEG?
 ---
 <!-- _class: disable -->
 ### M5 – SVG: Was ist es?
 **Thema:** SVG – Grundbegriff
 **Punkte:** 1
@@ -707,8 +652,6 @@ Was ist SVG?
 ---
 <!-- _class: disable -->
 ### M6 – Formatwahl: Szenario zuordnen
 **Thema:** Bildformate – Formatwahl Transfer
 **Punkte:** 2
@@ -855,6 +798,8 @@ Eine Festplatte wird als „1 TB" vermarktet, aber Windows zeigt nur ~931 GB an.
 ---
 <!-- _class: disable -->
 ### O2 – HDD vs. SSD: Kern-Unterschied
 **Thema:** Speichermedien – HDD vs. SSD
 **Punkte:** 1
@@ -871,6 +816,8 @@ Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
 ---
 <!-- _class: disable -->
 ### O3 – HDD vs. SSD: Eigenschaften zuordnen
 **Thema:** Speichermedien – Vergleich
 **Punkte:** 2
@@ -70,23 +70,18 @@ section.aufgabe footer {
 }
 section.erklaerung {
  font-size: 1.1rem;
-  background: repeating-linear-gradient(
+  background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
-    135deg,
+  border-left: 6px solid #a02060;
    #fce4ec,
    #fce4ec 40px,
    #fff 40px,
    #fff 80px
  ) !important;
 }
@media print {
  section.erklaerung {
    background: #fce4ec !important;
  }
 }
 section.erklaerung h1 {
-  font-size: 1.5rem;
+  font-size: 1.6rem;
  color: #a02060;
-  margin-bottom: 0.3rem;
+  margin-bottom: 0.5rem;
 }
 section.erklaerung h2 {
  font-size: 1.3rem;
  color: #1f2937;
  margin-top: 0;
 }
 section.erklaerung ul,
 section.erklaerung ol {
@@ -94,11 +89,11 @@ section.erklaerung ol {
  line-height: 1.4;
 }
 section.erklaerung p {
-  font-size: 1.0rem;
+  font-size: 1.05rem;
-  line-height: 1.4;
+  line-height: 1.5;
 }
 section.erklaerung table {
-  font-size: 0.9rem;
+  font-size: 0.95rem;
 }
 </style>
@@ -688,21 +683,19 @@ PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# Von-Neumann-Architektur – Vertiefung
+# Die 5 Komponenten: Erklaerung
-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.
+**Definition:** Die Von-Neumann-Architektur beschreibt den grundlegenden Aufbau moderner Computer in fuenf Funktionseinheiten.
-**Die 5 Komponenten im Detail:**
+| Komponente | Aufgabe | Beispiel |
 |------------|---------|----------|
 | **Rechenwerk (ALU)** | Arithmetische & logische Operationen | +, -, ×, ÷, Vergleiche |
 | **Steuerwerk** | Holt, dekodiert und steuert Befehle | Fetch-Decode-Execute-Zyklus |
 | **Speicherwerk** | Speichert Programme UND Daten | RAM, ROM |
 | **Ein-/Ausgabe** | Kommunikation mit Aussenwelt | Tastatur, Monitor, USB |
 | **Bus-System** | Verbindet alle Komponenten | Adress-, Daten-, Steuerbus |
-| Komponente | Moderne Entsprechung | Funktion |
+**Merkhilfe:** "**R**echnen, **S**teuern, **S**peichern, **E**in/**A**us, **B**us" (RSSEAB)
 |------------|---------------------|----------|
 | 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.
 ---
@@ -747,26 +740,20 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# Stored Program Concept – Vertiefung
+# Von-Neumann-Architektur: Erklaerung
-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.
+**Definition:** Das revolutionaere Prinzip, dass Programme und Daten im selben Speicher liegen und Programme somit wie Daten behandelt werden koennen.
-**Konsequenzen für die Software-Industrie:**
+**Kernpunkte:**
- **Betriebssysteme** möglich: Laden verschiedene Programme aus demselben Speicher
+- **Stored Program Concept:** Programme sind austauschbare Daten
- **Updates** ohne Hardware-Austausch: Nur Bits ändern, nicht Kabel
+- **Universalrechner:** Gleiche Hardware fuer beliebige Aufgaben
- **Multitasking**: Mehrere Programme gleichzeitig im Speicher
+- **Software-Flexibilitaet:** Programme koennen geladen, geaendert und geloescht werden
 - **Self-Modifying Code**: Programme können sich selbst ändern (Compiler, JIT)
-**Harvard-Architektur (Alternative):**
+**Vorher (ENIAC):** Programmierung durch Umstecken von Kabeln → Tage fuer jedes neue Programm
-| Aspekt | Von Neumann | Harvard |
+**Nachher:** Software als austauschbare Datei → Betriebssysteme, Apps, Updates moeglich
 |--------|-------------|---------|
 | 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).
+**Harvard-Architektur (Alternative):** Getrennter Speicher fuer Code und Daten → schneller, aber weniger flexibel (Arduino, DSPs)
 ---
@@ -1202,27 +1189,23 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# HTML Metadaten – Vertiefung
+# HTML Metadaten: Erklaerung
-Der `<head>`-Bereich enthält Informationen *über* das Dokument, nicht den sichtbaren Inhalt. Diese Metadaten steuern Browser-Verhalten, Suchmaschinen-Indexierung und Social-Media-Vorschauen.
+**Definition:** Der `<head>`-Bereich enthaelt Informationen ueber das Dokument, die nicht direkt im Browser angezeigt werden.
-**Kritische Meta-Tags:**
+| Meta-Tag | Zweck | Beispiel |
 |----------|-------|----------|
 | `<title>` | Browser-Tab, Lesezeichen, SEO | "Meine Website" |
 | `<meta charset>` | Zeichenkodierung | UTF-8 fuer Umlaute |
 | `<meta description>` | Suchmaschinen-Snippet | Max. 160 Zeichen |
 | `<meta viewport>` | Mobile Darstellung | width=device-width |
 | `<meta og:image>` | Social Media Vorschau | Bild beim Teilen |
-| Tag | Funktion | Beispiel |
+**Wichtige Unterscheidung:**
-|-----|----------|----------|
+- `<head>`: Metadaten (fuer Browser, Suchmaschinen, Social Media)
-| `<title>` | Browser-Tab, Suchergebnis-Titel | `<title>HdM Stuttgart</title>` |
+- `<body>`: Sichtbarer Inhalt (fuer Menschen)
 | `<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):**
+**Merkhilfe:** "Head = Gehirn (unsichtbar), Body = Koerper (sichtbar)"
 ```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.
 ---
@@ -1453,26 +1436,22 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# Web-Zugänglichkeit – Vertiefung
+# Web-Nutzung: Erklaerung
-**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.
+**Definition:** Menschen nutzen das Web auf sehr unterschiedliche Weisen - nicht nur mit Maus und Bildschirm.
-**Arten von Einschränkungen:**
+**Eingabemethoden:**
 - **Maus/Trackpad:** Klicken, Scrollen, Hover
 - **Tastatur:** Tab-Navigation, Shortcuts, Pfeiltasten
 - **Screenreader:** Vorlesen von Inhalten (NVDA, VoiceOver, JAWS)
 - **Sprache/Augen:** Sprachbefehle, Eye-Tracking, Switch-Geraete
-| Typ | Permanent | Temporär | Situativ |
+**Arten von Einschraenkungen:**
-|-----|-----------|----------|----------|
+- **Permanent:** Blindheit, Taubheit, motorische Einschraenkungen
-| Visuell | Blindheit | Nach Augen-OP | Grelle Sonne |
+- **Temporaer:** Gebrochener Arm, Augen-OP
-| Motorisch | Amputation | Gebrochener Arm | Baby auf dem Arm |
+- **Situativ:** Sonnenlicht, laute Umgebung, Baby auf Arm
 | Auditiv | Taubheit | Ohrenentzündung | Laute Umgebung |
 | Kognitiv | Legasthenie | Müdigkeit | Ablenkung |
-**Assistive Technologien:**
+**Merkhilfe:** "a11y" = a + 11 Buchstaben + y = "accessibility"
 - **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.
 ---
@@ -1519,28 +1498,21 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# Rechtliche Anforderungen – Vertiefung
+# Barrierefreiheit: Erklaerung
-Der **European Accessibility Act (EAA)** trat am 28. Juni 2025 in Kraft und betrifft erstmals auch private Unternehmen – nicht nur öffentliche Stellen.
+**Definition:** Barrierefreiheit (Accessibility) bedeutet, dass digitale Inhalte fuer alle Menschen zugaenglich sind - unabhaengig von koerperlichen oder technischen Einschraenkungen.
-**Betroffene Sektoren:**
+**Rechtlicher Rahmen:**
- E-Commerce (Online-Shops)
+- **European Accessibility Act (EAA):** Seit Juni 2025 EU-weit verpflichtend
- Bankdienstleistungen
+- **BITV 2.0:** Deutsche Verordnung fuer oeffentliche Stellen
- Telekommunikation
+- **Strafen:** Bis zu 100.000 EUR Bussgeld moeglich
 - E-Books und E-Reader
 - Ticketing und Check-in-Terminals
-**WCAG 2.2 – Konformitätsstufen:**
+**Curb-Cut-Effekt:** Massnahmen fuer Menschen mit Behinderung helfen allen:
 - Untertitel → laute Umgebung, Sprachlernen
 - Kontrast → Sonnenlicht, aeltere Menschen
 - Tastatur-Navigation → Power-User, RSI-Betroffene
-| Level | Anforderung | Beispiel |
+**Business Case:** ~15% Menschen mit Behinderung + ~20% Aeltere = 35% potenzielle Zielgruppe
 |-------|-------------|----------|
 | 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.
 ---
@@ -1701,31 +1673,25 @@ Echte NutzerInnen einbeziehen = Gold-Standard
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# Barrierefreiheit testen – Vertiefung
+# Barrieren vermeiden: Erklaerung
-Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erfordert manuelles Testen und idealerweise echte Nutzer mit Behinderungen.
+**Definition:** Praktische Massnahmen zur Pruefung und Sicherstellung der Barrierefreiheit von Webseiten.
-**Tastatur-Test (5 Minuten, jeder kann's):**
+**Tastatur-Test (selbst durchfuehren):**
-1. Maus weglegen, nur Tab + Enter + Pfeiltasten nutzen
+1. Tab druecken → Springt der Fokus logisch durch die Seite?
-2. Fokus-Indikator immer sichtbar? (kein `outline: none;`!)
+2. Ist der fokussierte Bereich immer sichtbar markiert?
-3. Logische Reihenfolge? (nicht kreuz und quer)
+3. Kann man alle Funktionen ohne Maus bedienen?
 4. Alle interaktiven Elemente erreichbar?
-**Automatisierte Tools:**
+**Screenreader-Test:**
 - **Mac:** VoiceOver aktivieren mit `Cmd + F5`
 - **Windows:** NVDA installieren (kostenlos)
 - **Frage:** Ergibt die vorgelesene Seite Sinn?
-| Tool | Typ | Findet |
+**Automatische Tools (finden ~30% der Probleme):**
-|------|-----|--------|
+- axe DevTools, WAVE (Browser-Extensions)
-| axe DevTools | Browser-Extension | ~30% der WCAG-Verstöße |
+- Lighthouse (in Chrome DevTools unter F12)
 | WAVE | Browser-Extension | Struktur-Probleme, Kontrast |
 | Lighthouse | Chrome DevTools | Performance + Accessibility |
 | Pa11y | CLI | CI/CD-Integration |
-**Screenreader-Kurztest:**
+**Merkhilfe WCAG-Prinzipien:** "**P**erceivable, **O**perable, **U**nderstandable, **R**obust" (POUR)
 - 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.
 ---
@@ -73,23 +73,18 @@ section.glossar {
 }
 section.erklaerung {
  font-size: 1.1rem;
-  background: repeating-linear-gradient(
+  background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
-    135deg,
+  border-left: 6px solid #a02060;
    #fce4ec,
    #fce4ec 40px,
    #fff 40px,
    #fff 80px
  ) !important;
 }
@media print {
  section.erklaerung {
    background: #fce4ec !important;
  }
 }
 section.erklaerung h1 {
-  font-size: 1.5rem;
+  font-size: 1.6rem;
  color: #a02060;
-  margin-bottom: 0.3rem;
+  margin-bottom: 0.5rem;
 }
 section.erklaerung h2 {
  font-size: 1.3rem;
  color: #1f2937;
  margin-top: 0;
 }
 section.erklaerung ul,
 section.erklaerung ol {
@@ -97,11 +92,11 @@ section.erklaerung ol {
  line-height: 1.4;
 }
 section.erklaerung p {
-  font-size: 1.0rem;
+  font-size: 1.05rem;
-  line-height: 1.4;
+  line-height: 1.5;
 }
 section.erklaerung table {
-  font-size: 0.9rem;
+  font-size: 0.95rem;
 }
 </style>
@@ -438,24 +433,22 @@ SPEAKER NOTES:
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# TCP/IP-Modell – Vertiefung
+# TCP/IP-Modell: Erklaerung
-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.
+**Definition:** Das TCP/IP-Modell beschreibt die Kommunikation im Internet in vier hierarchischen Schichten.
-**Schicht-Aufgaben im Detail:**
+| Schicht | Frage | Protokolle | Dateneinheit |
 |---------|-------|------------|--------------|
 | 4 Anwendung | Was will ich? | HTTP, DNS, SMTP | Daten |
 | 3 Transport | Kommt es an? | TCP, UDP | Segment |
 | 2 Internet | Welcher Rechner? | IP | Paket |
 | 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN | Frame |
-| Schicht | Frage | Protokolle | Geräte |
+**Kernprinzip:** Jede Schicht hat eine Aufgabe und kennt nur ihre Nachbarschichten.
 |---------|-------|------------|--------|
 | 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:**
+**Encapsulation:** Jede Schicht verpackt die Daten der darueberliegenden Schicht mit eigenem Header.
 - 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.
+**Merkhilfe Schichten:** "**A**lle **T**rinken **I**mmer **N**och" (Anwendung-Transport-Internet-Netzzugang)
 ---
@@ -522,26 +515,23 @@ SPEAKER NOTES:
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# Dateneinheiten & Encapsulation – Vertiefung
+# Dateneinheiten: Erklaerung
-**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
+**Definition:** Jede Schicht im TCP/IP-Modell hat eine eigene Bezeichnung fuer die Daten, die sie verarbeitet.
-**Was jeder Header enthält:**
+| Schicht | Dateneinheit | Was kommt hinzu? |
 |---------|--------------|------------------|
 | Anwendung | **Daten** (Message) | Anwendungsspezifische Infos |
 | Transport | **Segment** | Ports, Sequenznummern |
 | Internet | **Paket** | IP-Adressen (Quelle, Ziel) |
 | Netzzugang | **Frame** | MAC-Adressen, Pruefsumme |
-| Schicht | Einheit | Header-Inhalte |
+**Encapsulation-Prozess:**
-|---------|---------|----------------|
+```
-| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
+Daten → [TCP-Header + Daten] → [IP-Header + Segment] → [Eth-Header + Paket + Eth-Trailer]
-| 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):**
+**Merkhilfe:** "**D**er **S**ache **P**raktischer **F**olgen" (Daten-Segment-Paket-Frame, von oben nach unten)
 - 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.
 ---
@@ -728,27 +718,22 @@ SPEAKER NOTES:
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# IP, MAC, Port – Vertiefung
+# IP vs. MAC vs. Port: Erklaerung
-Drei Adressebenen lösen drei verschiedene Probleme:
+**Definition:** Drei verschiedene Adresstypen fuer drei verschiedene Fragen im Netzwerk.
-**IP-Adresse (Schicht 2 – Internet):**
+| Adresstyp | Frage | Reichweite | Aendert sich? |
- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
+|-----------|-------|------------|---------------|
- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
+| **IP-Adresse** | Welcher Rechner im Internet? | Global | Nein (Ziel bleibt) |
- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
+| **MAC-Adresse** | Welches Geraet nebenan? | Lokal (1 Hop) | Ja, bei jedem Hop |
 | **Port** | Welches Programm? | Auf einem Rechner | Nein |
-**MAC-Adresse (Schicht 1 – Netzzugang):**
+**Analogie Briefpost:**
- 48 Bit, vom Hersteller fest vergeben (theoretisch)
+- **IP** = Empfaengeradresse auf dem Brief (bleibt gleich)
- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
+- **MAC** = "Naechstes Postamt" (aendert sich bei jeder Station)
- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
+- **Port** = Wohnungsnummer im Mehrfamilienhaus
 - ARP (Address Resolution Protocol) übersetzt IP → MAC
-**Port (Schicht 3 – Transport):**
+**Merkhilfe:** "**I**P = **I**nternet-weit, **M**AC = **M**omentaner Nachbar, **P**ort = **P**rogramm"
 - 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?).
 ---
@@ -1038,29 +1023,24 @@ SPEAKER NOTES:
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# 3-Way-Handshake – Vertiefung
+# 3-Way-Handshake: Erklaerung
-Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
+**Definition:** Der TCP-Verbindungsaufbau in drei Schritten, bei dem Client und Server ihre Sequenznummern austauschen.
-**Warum zufällige Startwerte (ISN)?**
+**Die drei Schritte:**
- Sicherheit: Verhindert Session-Hijacking durch Raten
+1. **SYN** (Client → Server): "Ich will reden, starte bei Seq=1000"
- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
+2. **SYN-ACK** (Server → Client): "OK, ich starte bei Seq=5000, erwarte 1001"
- ISN = Initial Sequence Number, vom OS zufällig gewählt
+3. **ACK** (Client → Server): "Verstanden, erwarte 5001 - los geht's!"
-**TCP-Flags im Handshake:**
+**Warum so kompliziert?**
 - Beide Seiten muessen **bereit** sein
 - Sequenznummern werden **synchronisiert** (daher SYN)
 - Verlorene Pakete koennen spaeter **erkannt und nachgefordert** werden
-| Paket | Flags | Bedeutung |
+**Analogie Telefonat:**
-|-------|-------|-----------|
+- Klingeln → Abheben → "Hallo?" → Gespraech beginnt
 | 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?**
+**Merkhilfe:** "**S**ag mir → **S**icher, **A**ntworte → **A**lles klar" (SYN → SYN-ACK → ACK)
 - 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.
 ---
@@ -1575,31 +1555,24 @@ SPEAKER NOTES:
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# TCP vs. UDP – Vertiefung
+# TCP vs. UDP: Erklaerung
-Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
+**Definition:** Die zwei Transport-Protokolle mit unterschiedlichen Garantien und Anwendungsfaellen.
-**TCP (Transmission Control Protocol):**
+| Eigenschaft | TCP | UDP |
- Verbindungsorientiert (Handshake vor Daten)
+|-------------|-----|-----|
- Sequenznummern → Reihenfolge garantiert
+| Verbindungsaufbau | Ja (3-Way-Handshake) | Nein |
- ACKs + Retransmission → Kein Datenverlust
+| Reihenfolge | Garantiert | Nicht garantiert |
- Flow Control (Sliding Window) → Empfänger nicht überlasten
+| Verlorene Pakete | Werden nachgefordert | Gehen verloren |
- Congestion Control → Netzwerk nicht überlasten
+| Geschwindigkeit | Langsamer (Overhead) | Schneller |
-**UDP (User Datagram Protocol):**
+**Wann TCP?** Wenn **alles ankommen** muss:
- Verbindungslos (Fire-and-Forget)
+- Web (HTTP/HTTPS), E-Mail, Datei-Downloads
 - Keine Sequenznummern, keine ACKs
 - Header nur 8 Bytes (TCP: 20+ Bytes)
 - Anwendung muss selbst für Zuverlässigkeit sorgen
-| Anwendung | Protokoll | Grund |
+**Wann UDP?** Wenn **Geschwindigkeit** wichtiger ist als Vollstaendigkeit:
-|-----------|-----------|-------|
+- Video-Calls, Gaming, DNS, Streaming
 | 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).
+**Merkhilfe:** "**T**CP = **T**otal **C**omplete **P**ackages" vs. "**U**DP = **U**nsicher, **D**afuer **P**rompt"
 ---
@@ -1686,30 +1659,23 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# HTTP-Methoden – Vertiefung
+# HTTP-Methoden: Erklaerung
-HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
+**Definition:** HTTP-Methoden beschreiben die gewuenschte Aktion auf einer Ressource.
-**CRUD-Mapping (Create, Read, Update, Delete):**
+| Methode | Bedeutung | Typischer Einsatz |
 |---------|-----------|-------------------|
 | **GET** | Daten abrufen | Webseite laden, Bild anzeigen |
 | **POST** | Daten senden | Formular absenden, Login |
 | **PUT** | Daten ersetzen | Profil komplett aktualisieren |
 | **PATCH** | Daten teilweise aendern | Einzelnes Feld aendern |
 | **DELETE** | Daten loeschen | Account loeschen |
-| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
+**Idempotenz:** GET, PUT, DELETE koennen mehrfach ausgefuehrt werden mit gleichem Ergebnis. POST nicht (mehrfach absenden = mehrere Bestellungen).
 |---------|------|------------|------|-------------------|
 | 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).
+**REST-APIs:** Nutzen diese Methoden systematisch fuer CRUD-Operationen (Create, Read, Update, Delete).
 **Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
-**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
+**Merkhilfe:** "**G**ib mir, **P**oste das, **P**latziere neu, **D**elete" (GET, POST, PUT, DELETE)
 ```
 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
 ```
 ---
@@ -1752,24 +1718,24 @@ Status-Codes sagen euch, was passiert ist.
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# HTTP Status-Codes – Vertiefung
+# HTTP Status-Codes: Erklaerung
-Die erste Ziffer kategorisiert die Antwort:
+**Definition:** Dreistellige Codes, die der Server zurueckgibt, um das Ergebnis einer Anfrage zu beschreiben.
-| Bereich | Kategorie | Häufige Codes |
+| Bereich | Bedeutung | Wichtige Codes |
-|---------|-----------|---------------|
+|---------|-----------|----------------|
-| 1xx | Informational | 100 Continue, 101 Switching Protocols |
+| **2xx** | Erfolg | 200 OK, 201 Created, 204 No Content |
-| 2xx | Success | 200 OK, 201 Created, 204 No Content |
+| **3xx** | Umleitung | 301 Moved Permanently, 304 Not Modified |
-| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
+| **4xx** | Client-Fehler | 400 Bad Request, 403 Forbidden, 404 Not Found |
-| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
+| **5xx** | Server-Fehler | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
 | 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
-**Wichtige Unterscheidungen:**
+**Haeufigste Codes im Alltag:**
- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
+- **200:** Alles OK, hier sind die Daten
- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
+- **404:** Seite nicht gefunden (falsche URL)
- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
+- **403:** Zugriff verweigert (keine Berechtigung)
 - **500:** Server hat einen Fehler (nicht eure Schuld)
-**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
+**Merkhilfe:** "**2**=alles **g**ut, **3**=woanders, **4**=du Fehler, **5**=Server Fehler"
 ---
@@ -1813,33 +1779,27 @@ Wie Encapsulation funktioniert.
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# Netzwerk-Grundlagen – Vertiefung
+# Netzwerke Zusammenfassung: Erklaerung
-Die vier Kernkonzepte für Web-Entwickler:
+**Der Ablauf eines Webseitenaufrufs:**
 1. **DNS** (UDP:53): Domain → IP-Adresse aufloesen
 2. **TCP-Handshake:** SYN → SYN-ACK → ACK (Verbindung aufbauen)
 3. **HTTP-Request:** GET /index.html (Seite anfordern)
 4. **HTTP-Response:** 200 OK + HTML (Seite erhalten)
-**1. DNS-Auflösung:**
+**Die 4 Schichten (TCP/IP):**
 - 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:**
+| Schicht | Protokolle | Dateneinheit |
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
+|---------|------------|--------------|
- Keep-Alive: Verbindung bleibt offen für mehrere Requests
+| Anwendung | HTTP, DNS | Daten |
- HTTP/2: Multiplexing – viele Requests über eine Verbindung
+| Transport | TCP, UDP | Segment |
 | Internet | IP | Paket |
 | Netzzugang | Ethernet | Frame |
-**3. HTTP Request/Response:**
+**Merkhilfen:**
-```
+- Schichten: "**A**lle **T**rinken **I**mmer **N**och"
-Request:  Methode + URL + Header + (Body)
+- Dateneinheiten: "**D**er **S**ache **P**raktischer **F**olgen"
-Response: Status + Header + Body
+- IP bleibt gleich, MAC aendert sich bei jedem Hop
 ```
 **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.
 ---
@@ -2138,26 +2098,26 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# CSS Spezifität – Vertiefung
+# CSS Spezifitaet: Erklaerung
-Spezifität bestimmt, welche CSS-Regel gewinnt, wenn mehrere auf dasselbe Element zutreffen. Sie wird als 4-stellige Zahl berechnet: **(Inline, IDs, Klassen, Elemente)**.
+**Definition:** Spezifitaet bestimmt, welche CSS-Regel gewinnt, wenn mehrere Regeln auf dasselbe Element zutreffen.
-**Berechnung:**
+**Spezifitaet als 4-stellige Zahl (a,b,c,d):**
-| Selektor | Inline | IDs | Klassen | Elemente | Gesamt |
+| Kategorie | Gewicht | Beispiel |
-|----------|--------|-----|---------|----------|--------|
+|-----------|---------|----------|
-| `p` | 0 | 0 | 0 | 1 | 0,0,0,1 |
+| **a:** Inline-Style | 1,0,0,0 | `style="..."` |
-| `.info` | 0 | 0 | 1 | 0 | 0,0,1,0 |
+| **b:** ID | 0,1,0,0 | `#header` |
-| `p.info` | 0 | 0 | 1 | 1 | 0,0,1,1 |
+| **c:** Klasse, Attribut, Pseudo-Klasse | 0,0,1,0 | `.wichtig`, `:hover` |
-| `#header` | 0 | 1 | 0 | 0 | 0,1,0,0 |
+| **d:** Element, Pseudo-Element | 0,0,0,1 | `p`, `::before` |
 | `#header .nav a` | 0 | 1 | 1 | 1 | 0,1,1,1 |
-**Wichtige Regeln:**
+**Vergleich:** Von links nach rechts, hoehere Zahl gewinnt.
- Eine Klasse (0,0,1,0) schlägt **jede Anzahl** von Elementen (0,0,0,99)
+- 0,1,0,0 > 0,0,99,99 (eine ID schlaegt beliebig viele Klassen)
 - 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.
+**Praktische Tipps:**
 - Vermeide IDs in CSS (zu spezifisch)
 - Vermeide `!important` (bricht das System)
 - Nutze Klassen fuer wiederverwendbare Styles
 ---
@@ -2412,30 +2372,32 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
 <!-- _header: '' -->
 <!-- _footer: '' -->
-# Responsive Design – Vertiefung
+# Responsive Design: Erklaerung
-**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
+**Definition:** Webseiten passen sich automatisch an verschiedene Bildschirmgroessen an (Desktop, Tablet, Smartphone).
-**Breakpoints (gängige Werte):**
+**Mobile First Ansatz:**
 1. Basis-CSS fuer kleine Bildschirme schreiben
 2. Mit `@media (min-width: ...)` fuer groessere Bildschirme erweitern
-| Breakpoint | Gerät | Media Query |
+```css
-|------------|-------|-------------|
+/* Basis (Mobile) */
-| < 576px | Smartphone (Portrait) | Basis (kein Query) |
+.container { padding: 1rem; }
 | ≥ 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!):**
+/* Ab 768px (Tablet) */
-```html
+@media (min-width: 768px) { .container { padding: 2rem; } }
-<meta name="viewport" content="width=device-width, initial-scale=1">
+
 /* Ab 1024px (Desktop) */
@media (min-width: 1024px) { .container { max-width: 1200px; } }
 ```
 Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
-**Moderne Alternativen zu Media Queries:**
+**Typische Breakpoints:**
- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
+- **576px:** Kleine Smartphones
- Container Queries: Reagieren auf Container-Größe statt Viewport
+- **768px:** Tablets
- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
+- **1024px:** Desktop
 - **1200px:** Grosse Bildschirme
 **Merkhilfe:** "Mobile First" = Basis klein, dann groesser werden
 ---
@@ -3,9 +3,9 @@ marp: true
 theme: gaia
 paginate: true
 backgroundColor: #fff
-header: ""
+header: "Klausurfragen – 223015c"
-footer: ""
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
-title: "Fragenkatalog – IT-Grundlagen (223015c)"
+title: "Klausurfragen – Grundlagen IT- und Internettechnik"
 ---
 <style>
 :root {
@@ -13,42 +13,21 @@ title: "Fragenkatalog – IT-Grundlagen (223015c)"
  --color-highlight: #d63384;
  --color-dimmed: #4a4a6a;
 }
-section.invert {
+section.invert { --color-foreground: #fff; }
-  --color-foreground: #fff;
+section { font-size: 1.325rem; }
-}
+h1 { color: #a02060; }
-section {
+section.invert h1 { color: #fff; }
-  font-size: 1.325rem;
+h2 { color: #1f2937; }
-}
+pre { background: #0f0f23; border-radius: 8px; }
-h1 {
+pre code { background: transparent; color: inherit; }
-  color: #a02060;  /* darker raspberry */
+a { color: var(--color-highlight); }
-}
+section.disable { opacity: 0.3; }
 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**
+**Grundlagen IT- und Internettechnik · HdM Stuttgart · M. Czechowski**
-<small>Stand: 01.02.2026</small>
+<small>Stand: 02.02.2026</small>
 ---
@@ -60,7 +39,7 @@ section.disable {
 > `[ESSAY]` = `essay` (Freitext, manuell bewertet)
 > `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
 > `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
-> `[CLOZE]` = `cloze` (Lückentext, gemischt)`
+> `[CLOZE]` = `cloze` (Lückentext, gemischt)
 ---
@@ -392,8 +371,6 @@ Beschreibe die drei Schritte des TCP 3-Way-Handshakes. Erkläre, warum alle drei
 ---
 <!-- _class: disable -->
 ### B18 – TCP Sequenznummern: Wozu?
 **Thema:** TCP – Sequenznummern
 **Punkte:** 1
@@ -585,8 +562,6 @@ Erkläre, warum HTTP-Status-Codes aus einer dreistelligen Zahl bestehen und was
 ---
 <!-- _class: disable -->
 ### D1 – DNS: Was macht es?
 **Thema:** DNS – Grundfunktion
 **Punkte:** 1
@@ -603,8 +578,6 @@ Was ist die Hauptfunktion eines DNS-Servers?
 ---
 <!-- _class: disable -->
 ### D2 – DNS: Zeitlicher Ablauf
 **Thema:** DNS – Rolle im Gesamtablauf
 **Punkte:** 2
@@ -621,8 +594,6 @@ Sie geben `https://hdm-stuttgart.de` in die Adresszeile ein. Was passiert vor de
 ---
 <!-- _class: disable -->
 ### D3 – DNS: Warum zwingend nötig?
 **Thema:** DNS – Transfer/Begründung
 **Punkte:** 2
@@ -634,8 +605,6 @@ Erkläre in 2–3 Sätzen, warum der DNS-Schritt zwingend vor dem TCP-Handshake
 ---
 <!-- _class: disable -->
 ### D4 – DNS: Lückentext
 **Thema:** DNS – Terminologie
 **Punkte:** 1
@@ -727,8 +696,6 @@ Ordne jedem Element zu, ob es in `<head>` oder `<body>` gehört.
 ---
 <!-- _class: disable -->
 ### F3 – Charset: Was passiert ohne `<meta charset>`?
 **Thema:** HTML – Zeichenkodierung
 **Punkte:** 1
@@ -850,8 +817,6 @@ Ordne jedem Eingabegerät seine Nutzungsweise zu.
 ---
 <!-- _class: disable -->
 ### H2 – Einschränkungen: Temporär vs. situativ
 **Thema:** Barrierefreiheit – Einschränkungstypen
 **Punkte:** 2
Author	SHA1	Message	Date
libretech	64f4729f45	add erklaerung slides after klausur slides in 223015c - add section.erklaerung CSS class with pink theme styling - add 6 explanation slides to 01-geschichte-grundlagen-html.md - add 10 explanation slides to 02-netzwerke-protokolle-css.md - each slide includes definition, key points, and mnemonics	2026-02-02 14:03:54 +01:00
libretechandClaude Opus 4.5	c35541961e	add archive directory with old klausurfragen files Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-02-02 13:42:12 +01:00
libretechandClaude Opus 4.5	d8f68183f3	update 02-bild-audio-video.md structure and content Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-02-02 13:42:11 +01:00
libretechandClaude Opus 4.5	705c5e3457	add klausurfragen to topic map in generate-index.sh Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-02-02 13:42:02 +01:00
libretechandClaude Opus 4.5	9b0b6bc9d6	remove global klausurfragen from root index klausurfragen are now per-course, no longer shown on root index Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-02-02 13:41:58 +01:00
libretechandClaude Opus 4.5	62cd97c51a	update makefile for per-course klausurfragen - add klausurfragen to KAPITEL lists for both courses - remove standalone build-klausurfragen target - remove deploy-klausurfragen target - klausurfragen now built and deployed as part of each course Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-02-02 13:41:52 +01:00
libretechandClaude Opus 4.5	9f2c78d536	add course-specific klausurfragen files split klausurfragen by course with appropriate CI: - 223015b: blocks J-O (dateiformate) with blue CI - 223015c: blocks A-I (IT-grundlagen) with pink CI preserves existing disable markers for non-klausur questions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-02-02 13:41:48 +01:00
libretechandClaude Opus 4.5	fb0db03db9	restore 01-grundlagen.md for 223015b accidentally removed in `a8343c9`, restored from `d77b0f2` Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-02-02 13:41:42 +01:00