---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Grundlagen IT- und Internettechnik (223015c)"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
---
<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #d63384;
  --color-dimmed: #4a4a6a;
}
section.invert {
  --color-foreground: #fff;
}
section {
  font-size: 1.7rem;
}
h1 {
  color: #a02060;  /* darker raspberry */
}
section.invert h1 {
  color: #fff;
}
h2 {
  color: #1f2937;  /* dark gray, almost black */
}
pre {
  background: #0f0f23;
  color: #d63384;
  border-radius: 8px;
  border-left: 3px solid #d63384;
}
pre code {
  background: transparent;
  color: inherit;
}
code {
  background: #1a1a2e;
  color: #d63384;
  padding: 0.15em 0.4em;
  border-radius: 4px;
}
a {
  color: var(--color-highlight);
}
section.klausur {
  background: repeating-linear-gradient(
    135deg,
    #fce4ec,
    #fce4ec 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.klausur {
    background: #fce4ec !important;
  }
}
section.aufgabe {
  background: #fce4ec !important;
}
section.aufgabe footer {
  display: none;
}
</style>

<!--
  ╔═══════════════════════════════════════════════════════════════════╗
  ║  AUTO-GENERATED FILE - DO NOT EDIT MANUALLY                       ║
  ║                                                                   ║
  ║  This file is generated by: make klausur                          ║
  ║  Source: scripts/extract-klausur.sh                               ║
  ║                                                                   ║
  ║  To update, edit the source slides and re-run make klausur        ║
  ╚═══════════════════════════════════════════════════════════════════╝
-->

<!-- _class: invert -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: black -->

![bg fit opacity:0.2](./assets/background-termin-2.png)

# Grundlagen IT- und Internettechnik

**223015c** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart

**Wintersemester 2025/26**

[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)

---

<!-- _header: "" -->
<!-- _footer: "" -->


# Die 5 Komponenten

| Komponente | Funktion |
|------------|----------|
| **Rechenwerk (ALU)** | Führt Berechnungen durch |
| **Steuerwerk** | Interpretiert Befehle, steuert Ablauf |
| **Speicherwerk** | Speichert Programme UND Daten |
| **Ein-/Ausgabe** | Tastatur, Bildschirm, Netzwerk |
| **Bus-System** | Verbindet alle Komponenten |

**Wichtig:** Programme und Daten **gemeinsam** im Speicher!

<!--
VON-NEUMANN-ARCHITEKTUR (1945): Grundlage aller modernen Computer
5 KOMPONENTEN:
- ALU (Arithmetic Logic Unit): Rechnet (+, -, ×, ÷) und vergleicht (>, <, =)
- Steuerwerk: Holt Befehle, dekodiert sie, steuert Ausführung (Fetch-Decode-Execute)
- Speicherwerk: RAM (flüchtig) + ROM (permanent), enthält Code UND Daten
- Ein-/Ausgabe (I/O): Tastatur, Maus, Bildschirm, Netzwerk, USB, Sensoren
- Bus-System: Adressbus (wo), Datenbus (was), Steuerbus (wie)
KERNPRINZIP: Stored Program Concept - Programme im selben Speicher wie Daten
VORHER (z.B. ENIAC): Programme durch Umstecken von Kabeln, tagelange Arbeit
NACHHER: Programme als austauschbare Daten → Flexibilität, Software-Industrie möglich
PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program Concept
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Von-Neumann-Architektur: Bedeutung

**Ohne Von-Neumann-Architektur:**
- Kein Betriebssystem
- Keine Apps
- Kein Multitasking
- Keine Updates bzw. Veränderungen am Computer System

**Die meisten Computer** basieren auf diesem Prinzip:
Laptop, Smartphone, Server, Spielkonsole...

**Ausnahme:** Mikrocontroller & DSPs nutzen oft die **Harvard-Architektur**
(separate Speicher für Code und Daten → schneller für Echtzeitanwendungen)

<!--
BEDEUTUNG VON-NEUMANN-ARCHITEKTUR:
- Betriebssystem möglich: Lädt verschiedene Programme aus gleichem Speicher
- Apps installierbar: Können gelöscht/installiert werden ohne Hardware-Änderung
- Multitasking: Mehrere Programme gleichzeitig im Speicher
- Updates: Software austauschbar, Hardware bleibt gleich
- Universalrechner: Gleiche Hardware für Text, Spiele, Video, Wissenschaft
HARVARD-ARCHITEKTUR (Alternative):
- Separate Speicher für Code und Daten
- Vorteil: Schneller (paralleler Zugriff), sicherer (Code nicht überschreibbar)
- Nachteil: Weniger flexibel, aufwändiger
- Anwendung: Mikrocontroller (Arduino, ESP32), DSPs, einige ARM-Chips
MODERNE CPUs: Modified Harvard (L1-Cache getrennt für Speed, RAM gemeinsam für Flexibilität)
PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beispiele
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# HTML Metadaten

```html
<html>
  <head>
    <title>Im Browsertab als Überschrift sichtbar</title>

    <meta name="description" content="" />

    <meta name="og:image" content="https://...." />
  </head>

  ...

</html>
```

- <small>*Webseiten werden nicht nur von Menschen besucht, sondern auch von Suchmaschinen, Programmen, Bots etc.*</small>
- <small>*Metadaten helfen bspw. auch Screen-Readern beim "Verstehen" der Inhalte*</small>

<!--
HEAD-BEREICH: Metadaten, nicht sichtbar im Browser-Fenster
WICHTIGE META-TAGS:
- <title>: Browser-Tab, Lesezeichen, Suchergebnis-Titel
- <meta name="description">: Suchergebnis-Snippet (max. 160 Zeichen)
- <meta name="viewport">: Mobile Darstellung (width=device-width)
- <meta charset="UTF-8">: Zeichenkodierung (Umlaute!)
OPEN GRAPH (og:*): Social Media Vorschau (Facebook, LinkedIn, WhatsApp)
- og:title, og:description, og:image, og:url
TWITTER CARDS: twitter:card, twitter:title, twitter:image
SEO-RELEVANZ: Google nutzt title + description für Ranking und Snippet
ACCESSIBILITY: <html lang="de"> für Screenreader-Aussprache
PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta-Tags
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Wie nutzen Menschen das Web?

| Eingabe | Nutzungsweise |
|---------|---------------|
| **Maus** | Klicken, Scrollen |
| **Tastatur** | Tab-Navigation, Enter, Pfeiltasten |
| **Screenreader** | Vorlesen von Inhalten (NVDA, VoiceOver, JAWS) |
| **Sprachsteuerung** | "Klicke auf Anmelden" |
| **Augensteuerung** | Eye-Tracking |
| **Switch-Geräte** | Ein-/Aus-Schalter |

→ **Nicht alle nutzen Maus + Bildschirm!**

<!--
ACCESSIBILITY (a11y): a + 11 Buchstaben + y
STATISTIK: ~15% der Weltbevölkerung haben eine Behinderung (WHO)
ARTEN VON EINSCHRÄNKUNGEN:
- Permanent: Blindheit, Taubheit, motorische Einschränkungen
- Temporär: Gebrochener Arm, Augen-OP, Ohrenentzündung
- Situativ: Helle Sonne (Kontrast), laute Umgebung (kein Audio), Baby auf Arm (eine Hand)
ASSISTIVE TECHNOLOGIEN:
- Screenreader: NVDA (Windows, kostenlos), VoiceOver (Apple), JAWS (kommerziell)
- Braillezeilen: Taktile Ausgabe für Blinde
- Switch-Geräte: Für motorische Einschränkungen
- Spracheingabe: Dragon NaturallySpeaking, Siri, Google Assistant
WCAG: Web Content Accessibility Guidelines (A, AA, AAA)
EUROPEAN ACCESSIBILITY ACT: Seit Juni 2025 verpflichtend!
PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Warum "Barrierefreiheit"?

**Rechtlich:**
- EU: European Accessibility Act (seit Juni 2025 in Kraft!)
- DE: BITV 2.0 (Behörden), Privatwirtschaft betroffen

**Ethisch:**
- Teilhabe für alle Menschen
- Digitale Inklusion

**Praktisch:**
- Bessere UX für **alle** (SEO, Mobile, ältere Menschen)
- Größerer Markt (~15% der Bevölkerung)

<!--
RECHTLICHER RAHMEN:
- European Accessibility Act (EAA): EU-Richtlinie, seit 28. Juni 2025 in Kraft
- Betrifft: E-Commerce, Banking, Telekommunikation, Transport, E-Books
- BITV 2.0: Barrierefreie Informationstechnik-Verordnung (DE, öffentliche Stellen)
- BFSG: Barrierefreiheitsstärkungsgesetz (DE-Umsetzung des EAA)
- Strafen: Bis zu 100.000€ Bußgeld möglich
CURB-CUT-EFFEKT:
- Bordsteinabsenkung für Rollstuhlfahrer → hilft auch Kinderwagen, Rollkoffern, Fahrrädern
- Untertitel für Gehörlose → helfen in lauter Umgebung, beim Sprachlernen
- Kontrastreiche Farben → besser bei Sonnenlicht, für ältere Menschen
BUSINESS CASE:
- 15% Zielgruppe (Menschen mit Behinderung)
- +20% ältere Menschen (Sehschwäche, motorische Einschränkungen)
- SEO-Vorteile: Alt-Texte, semantisches HTML = besser für Google
PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Barrieren im Netz vermeiden (a11y)

**Tastatur-Test:**
- Alle Funktionen nur mit Tab + Enter nutzbar?
- Fokus immer sichtbar?
- Logische Tab-Reihenfolge?

**Screenreader-Test:**
- VoiceOver (Mac): `Cmd + F5`
- NVDA (Windows): Gratis-Download

**Tools:**
- axe DevTools, WAVE (Browser-Extensions)
- Lighthouse (in Chrome DevTools)

<!--
Automatische Tests finden ~30% der Probleme
Manuelles Testen unverzichtbar
Echte NutzerInnen einbeziehen = Gold-Standard
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Das TCP/IP-Modell

| Schicht | Name | Aufgabe | Protokolle |
|---------|------|---------|------------|
| **4** | Anwendung | Was? Welcher Dienst? | HTTP, DNS, SMTP |
| **3** | Transport | Zuverlässigkeit, Ports | TCP, UDP |
| **2** | Internet | Routing, globale Adressen | IP |
| **1** | Netzzugang | Lokale Übertragung | Ethernet, WLAN |

**4 Schichten. Das reicht, um das Internet zu verstehen.**

<!--
SPEAKER NOTES:
- TCP/IP = das echte Internet
- 4 Schichten:
  - Anwendung: Was will ich? (HTTP, DNS, Mail)
  - Transport: Kommt an? Welches Programm? (TCP, UDP)
  - Internet: Wie zum Zielrechner? (IP)
  - Netzzugang: Wie zum nächsten Gerät? (Ethernet, WLAN)
- KLAUSUR: Welches Protokoll → welche Schicht
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Dateneinheiten pro Schicht

| Schicht | Name | Dateneinheit | Was kommt hinzu? |
|---------|------|--------------|------------------|
| Anwendung | HTTP, DNS | **Daten** | – |
| Transport | TCP, UDP | **Segment** | Ports, Sequenznummern |
| Internet | IP | **Paket** | IP-Adressen |
| Netzzugang | Ethernet | **Frame** | MAC-Adressen, Prüfsumme |

Merkhilfe: **D**aten → **S**egment → **P**aket → **F**rame
(„**D**er **S**ache **P**raktischer **F**olgen")

<!--
SPEAKER NOTES:
- Glossar-Begriffe jetzt eingeordnet:
  - Anwendung: Daten/Message
  - Transport: Segment
  - Internet: Paket
  - Netzzugang: Frame
- Merkhilfe: D-S-P-F (eigene erfinden!)
- KLAUSUR: Begriff → Schicht
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# IP vs. MAC vs. Port

| | IP-Adresse | MAC-Adresse | Port |
|---|-----------|-------------|------|
| **Frage** | Welcher Rechner? | Welches Gerät nebenan? | Welches Programm? |
| **Reichweite** | Global | Lokal (1 Hop) | Auf einem Rechner |
| **Ändert sich?** | Nein | Ja, bei jedem Hop | Nein |
| **Schicht** | Internet (IP) | Netzzugang (Ethernet) | Transport (TCP/UDP) |
| **Beispiel** | 212.132.79.37 | aa:bb:cc:dd:ee | 443 |

<!--
SPEAKER NOTES:
- KLAUSUR: Diese Tabelle
- IP: Welcher Rechner? Global. Bleibt gleich.
- MAC: Welcher Nachbar? Lokal. Ändert sich.
- Port: Welches Programm? Bleibt gleich.
- Merken: NUR MAC ändert sich unterwegs
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Der 3-Way-Handshake

```
Client (dein Laptop)                      Server
    |                                        |
    |-------- SYN (Seq=1000) --------------->|
    |         "Ich will reden"               |
    |                                        |
    |<--- SYN-ACK (Seq=5000, Ack=1001) ------|
    |     "OK, ich auch. Ich starte bei 5000"|
    |                                        |
    |-------- ACK (Ack=5001) --------------->|
    |         "Verstanden, los geht's"       |
    |                                        |
    |        [ Verbindung steht ]            |
```

**SYN** = Synchronize · **ACK** = Acknowledge

<!--
SPEAKER NOTES:
- 3 Pakete → Verbindung steht
- 1. Client SYN: "Will Verbindung, starte bei 1000"
- 2. Server SYN-ACK: "OK, ich starte bei 5000, erwarte 1001"
- 3. Client ACK: "Verstanden, erwarte 5001"
- Seq-Nr wichtig: Beide wissen nächstes erwartetes Byte
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# TCP vs. UDP

| | TCP | UDP |
|---|-----|-----|
| **Verbindung** | Ja (Handshake) | Nein |
| **Reihenfolge** | Garantiert | Nicht garantiert |
| **Verlorene Pakete** | Werden nachgefordert | Gehen verloren |
| **Overhead** | Höher | Niedriger |
| **Use Cases** | Web, Email, Downloads | Video-Calls, Gaming, DNS |

<!--
SPEAKER NOTES:
- Zwei Transport-Protokolle
- TCP: zuverlässig
  - Handshake, Seq-Nr, Bestätigungen, Neuübertragung
  - Perfekt für Web, Downloads (nichts darf fehlen)
- UDP: schneller
  - Kein Handshake, keine Bestätigungen
  - Verloren = weg
  - Perfekt für Video-Calls (Verzögerung schlimmer als Verlust)
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# HTTP-Methoden

| Methode | Bedeutung | Beispiel |
|---------|-----------|----------|
| **GET** | Daten abrufen | Seite laden |
| **POST** | Daten senden | Formular absenden |
| **PUT** | Daten ersetzen | Profil aktualisieren |
| **DELETE** | Daten löschen | Account löschen |

```http
GET /index.html HTTP/1.1
POST /login HTTP/1.1
```

<!--
SPEAKER NOTES:

Zum Schluss noch HTTP-Methoden.

GET ist das häufigste – "gib mir was". Wenn ihr eine URL aufruft, ist das ein GET.

POST schickt Daten zum Server – wenn ihr ein Formular abschickt.

PUT und DELETE sind für APIs – ersetzen oder löschen von Ressourcen.

Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# HTTP Status-Codes

```http
HTTP/1.1 200 OK
HTTP/1.1 404 Not Found
HTTP/1.1 500 Internal Server Error
```

| Code-Bereich | Bedeutung |
|--------------|-----------|
| **2xx** | Erfolg (200 OK, 201 Created) |
| **3xx** | Umleitung (301 Moved, 304 Not Modified) |
| **4xx** | Client-Fehler (400 Bad Request, 404 Not Found) |
| **5xx** | Server-Fehler (500 Internal Error, 503 Unavailable) |

<!--
SPEAKER NOTES:

Status-Codes sagen euch, was passiert ist.

2xx heißt: Alles gut. 200 OK ist der Normalfall.

3xx heißt: Umleitung. Die Seite ist woanders.

4xx heißt: Ihr habt was falsch gemacht. 404 kennt ihr – Seite nicht gefunden. 403 heißt: Zugriff verweigert.

5xx heißt: Der Server hat ein Problem. 500 ist ein generischer Fehler, 503 heißt: Server überlastet.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Zusammenfassung Teil 1

**Der Ablauf:**
1. DNS (UDP:53) → Name zu IP
2. TCP-Handshake (SYN → SYN-ACK → ACK)
3. HTTP-Request (GET /...)
4. HTTP-Response (200 OK + HTML)

**Die Konzepte:**
- 4 Schichten: Anwendung → Transport → Internet → Netzzugang
- IP bleibt gleich, MAC ändert sich pro Hop
- Ports identifizieren Programme
- Encapsulation: Jede Schicht verpackt die darüberliegende

<!--
SPEAKER NOTES:

Das ist die Zusammenfassung für Teil 1. Das solltet ihr können:

Den Ablauf: DNS, TCP-Handshake, HTTP-Request, HTTP-Response.

Die Schichten und ihre Protokolle.

Den Unterschied zwischen IP und MAC – was bleibt gleich, was ändert sich.

Was Ports tun.

Wie Encapsulation funktioniert.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Spezifität: Welche Regel gewinnt?

| Selektor | Spezifität |
|----------|------------|
| Element (`p`) | 0,0,0,1 |
| Klasse (`.wichtig`) | 0,0,1,0 |
| ID (`#header`) | 0,1,0,0 |
| Inline (`style="..."`) | 1,0,0,0 |

```css
p { color: blue; }           /* 0,0,0,1 */
.text { color: green; }      /* 0,0,1,0 → gewinnt */
#intro { color: red; }       /* 0,1,0,0 → gewinnt über beide */
```

<!--
SPEAKER NOTES:

Wenn mehrere Regeln auf ein Element zutreffen, gewinnt die spezifischere.

Spezifität wird in vier Zahlen gemessen. Von links nach rechts: Inline, IDs, Klassen, Elemente.

Ein Element-Selektor hat 0,0,0,1. Eine Klasse hat 0,0,1,0. Eine ID hat 0,1,0,0.

0,0,1,0 schlägt 0,0,0,99 – auch hundert Element-Selektoren schlagen keine Klasse.

Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Responsive Design

```css
/* Mobile First: Basis-Styles */
.container {
    padding: 1rem;
    background: white;
}

/* Ab 768px (Tablet): Anpassungen */
@media (min-width: 768px) {
    .container {
        padding: 2rem;
        background: red;
    }
}

/* Ab 1024px (Desktop): Weitere Anpassungen */
@media (min-width: 1024px) {
    .container {
        background: green;
    }
}
```

<!--
SPEAKER NOTES:

Responsive Design: Die Seite passt sich der Bildschirmgröße an.

Mobile First: Ihr schreibt zuerst die Styles für kleine Screens. Dann fügt ihr mit @media-Queries Anpassungen für größere Screens hinzu.

min-width heißt: "ab dieser Breite". Also: Basis gilt für alle. Ab 768px gelten zusätzliche Regeln. Ab 1024px noch mehr.

Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute Standard.
-->