Wie funktioniert das Web? HTTP, Browser, Server

Bevor wir HTML und CSS schreiben, müssen wir verstehen wo dieser Code überhaupt landet und wer ihn ausführt. Wenn du www.beispiel.de in den Browser tippst, passiert in Bruchteilen einer Sekunde eine ganze Maschinerie: dein Browser fragt einen DNS-Server nach der IP-Adresse, baut eine Verbindung zum richtigen Server auf, schickt eine HTTP-Anfrage, bekommt HTML zurück und stellt das auf deinem Bildschirm dar.

Stell dir das wie einen Anruf in einem riesigen Telefonbuch vor. Du kennst den Namen einer Firma (die Domain), aber nicht deren Telefonnummer (die IP-Adresse). Du fragst die Auskunft (den DNS-Server) nach der Nummer, dann rufst du an. So funktioniert das Web im Prinzip jeden Tag, milliardenfach.

1) Client und Server – die Grundrollen

Im Web gibt es immer mindestens zwei Beteiligte: einen Client (meist dein Browser) und einen Server (irgendwo im Internet). Der Client fragt, der Server antwortet. Dieses Muster heißt Request/Response und ist die Grundlage praktisch jeder Web-Kommunikation. Klicke „Schritt" und beobachte den Ablauf:

HTTP Request/Response in Aktion

🌐

Browser (Client)

Chrome, Firefox, Safari

→ GET /index.html HTTP/1.1

← HTTP/1.1 200 OK + HTML-Inhalt

🖥️

Server

nginx, Apache, ...

← Drücke „Nächster Schritt".

Schritt: –

Wichtig: ein Server ist meist nicht „ein Computer", sondern ein Programm das Anfragen entgegennimmt. Bekannte Server-Programme: nginx, Apache HTTPD, Caddy. Sie laufen auf realen Computern in Rechenzentren irgendwo auf der Welt. Mehr zur Server-Infrastruktur und virtuellen Servern in K31 Cloud.

2) Vom Namen zur IP-Adresse – DNS in 5 Schritten

Server haben IP-Adressen (z.B. 185.199.108.153). Aber Menschen tippen Namen ein. Das DNS (Domain Name System) ist die Übersetzungsschicht dazwischen. Wenn du www.example.com aufrufst, durchläuft die Anfrage diese Stationen – klicke jede für Details:

DNS-Auflösung: Name → IP

Schritt 1

Browser-Cache

schon bekannt?

→

Schritt 2

OS-Cache

hosts-Datei?

→

Schritt 3

DNS-Resolver

Provider/8.8.8.8

→

Schritt 4

Root + TLD

.com? .de?

→

Schritt 5

Authoritative

die Antwort

← Klick einen Schritt für Details.

Im Idealfall ist die IP schon im Browser- oder OS-Cache (Schritt 1-2) – dann passiert das in <1 ms. Erst beim ersten Besuch einer Domain läuft die volle Kette ab. Caches haben eine TTL (Time to Live) die festlegt wie lange ein Eintrag gültig ist. Mehr über das DNS-System inkl. der Rekord-Typen A, AAAA, CNAME, MX in K16 DNS.

3) Eine URL aufgedröselt

Jede URL hat dieselbe Grundstruktur. Wenn du sie verstehst, weißt du auch was beim Aufruf passiert. Klicke einen Teil:

URL-Anatomie

https://www.beispiel.de:443/blog/artikel-1?lang=de&v=2

← Klick einen URL-Teil.

Jede URL beantwortet implizit drei Fragen: Wie spreche ich den Server an (Schema/Protokoll)? Welchen Server (Host + Port)? Was will ich dort (Pfad + Query)? Wenn du nichts angibst, gelten Defaults: bei https:// der Port 443, bei http:// der Port 80. Deshalb tippst du fast nie eine Port-Nummer ein.

4) HTTP-Methoden – was will der Client?

Nicht jeder Request macht dasselbe. HTTP definiert verschiedene Methoden für unterschiedliche Absichten. Beim Browsen siehst du fast nur GET – aber sobald du ein Formular abschickst (siehe Lektion 5) oder eine API benutzt, kommen die anderen ins Spiel:

Methode	Zweck	Beispiel
GET	Daten holen	Webseite öffnen, Bild laden, API lesen
POST	Daten senden, oft neue Ressource erstellen	Formular abschicken, neuen User anlegen
PUT	Daten komplett ersetzen / aktualisieren	Profildaten aktualisieren
PATCH	Daten teilweise ändern	Nur das E-Mail-Feld eines Users ändern
DELETE	Ressource löschen	Einen Kommentar entfernen
HEAD	Wie GET, aber nur Header (ohne Body)	Prüfen ob eine Datei existiert / Größe

Konvention: GET soll nichts verändern. Wenn ein Link einfach „angeklickt" werden kann, darf er keine wichtigen Daten löschen. Deshalb verwendet man für sicherheitskritische Aktionen POST, PUT, DELETE – mit eingebautem Schutz vor Manipulation. Die Aufteilung GET/POST/PUT/DELETE ist auch die Basis von REST-APIs.

5) HTTP-Statuscodes – die Antwort in 3 Ziffern

Jede HTTP-Antwort beginnt mit einem dreistelligen Code. Die erste Ziffer sagt grob was passiert ist, die anderen zwei sind detaillierter. Hier die wichtigsten Klassen mit Beispielen:

HTTP-Statuscodes

1xx

Info

selten gesehen, z.B. 101 Switching Protocols

200

OK ✓

Alles bestens, Antwort kommt

201

Created

POST war erfolgreich, etwas Neues angelegt

204

No Content

Erfolg, aber kein Body (z.B. nach DELETE)

301

Moved

Permanent umgezogen, neue URL nutzen

302

Found

Temporäre Weiterleitung

304

Not Modified

Nichts geändert seit letzter Anfrage → Cache

400

Bad Request

Anfrage fehlerhaft (Client-Fehler)

401

Unauthorized

403

Forbidden

Kein Recht für die Ressource

404

Not Found

Seite/Ressource gibt's nicht

429

Too Many

Zu viele Anfragen (Rate Limit)

500

Server Error

Allgemeiner Server-Crash

502

Bad Gateway

Backend-Server antwortet nicht

503

Unavailable

Server überlastet/in Wartung

Die Faustregel: 2xx = Erfolg, 3xx = Weiterleitung, 4xx = Client-Fehler (du hast was falsch gemacht), 5xx = Server-Fehler (er hat ein Problem). Das berühmteste ist 404 – jeder hat es schon mal gesehen. Aber auch 200 ist wichtig: heißt nicht „erfolgreich" im Sinne von „hat geklappt was du wolltest", sondern nur „die HTTP-Übertragung war OK". Eine API kann 200 OK liefern und im Body trotzdem {"error": "..."} stehen haben.

6) HTTPS und Verschlüsselung

Reines HTTP überträgt alles im Klartext – Passwörter, Kreditkarten, alles. Bei unverschlüsselten Verbindungen kann jeder im selben WLAN (oder bei den ISP-Routern) mitlesen. Deshalb hat sich HTTPS durchgesetzt: HTTP plus TLS-Verschlüsselung. Heute zeigen alle Browser eine Warnung bei reinem HTTP – und Suchmaschinen ranken HTTPS höher.

Wie funktioniert HTTPS technisch? Beim Verbindungsaufbau (TLS-Handshake) tauschen Browser und Server Schlüssel aus, der Server beweist seine Identität per Zertifikat, und ab dann ist alles verschlüsselt. Mehr zur Kryptografie dahinter in K08. Web-spezifische Sicherheitsthemen wie XSS und CSRF behandelt K11 Secure Coding.

7) Was passiert WIRKLICH beim Seitenaufruf? Die Komplettübersicht

Setzen wir alles zusammen. Wenn du in deinen Browser tippst https://www.example.com und Enter drückst, passiert folgendes – meist in 50-300 Millisekunden:

URL-Parsing: Browser zerlegt die URL in Schema, Host, Port, Pfad.
DNS-Auflösung: www.example.com → 93.184.216.34 (siehe oben).
TCP-Verbindung: Browser baut eine Verbindung zur IP auf Port 443 auf (3-Way-Handshake).
TLS-Handshake: Schlüsseltausch, Zertifikat prüfen → ab jetzt verschlüsselt.
HTTP-Request: Browser schickt GET / HTTP/1.1 mit Header.
Server-Verarbeitung: Server findet die Datei, ggf. dynamische Generierung.
HTTP-Response: Server schickt Status, Header, HTML-Body zurück.
HTML-Parsing: Browser baut den DOM-Baum auf.
Subresource-Requests: Für jedes <link>, <img>, <script> im HTML wird ein eigener Request gemacht.
Rendering: Browser wendet CSS an, führt JS aus, malt die Seite auf den Bildschirm.

Bei modernen Seiten parallelisiert der Browser viele dieser Schritte und nutzt Caches an mehreren Stellen. Performance-Optimierung ist ein eigenes Riesen-Thema. Für den Anfang reicht: HTML, CSS, JavaScript klein halten, weniger Requests, gute Bilder-Kompression.

Zusammenfassung

Web = Client (Browser) fragt, Server antwortet – das Request/Response-Modell. Kommunikation über HTTP/HTTPS. Server haben IP-Adressen, Menschen tippen Domain-Namen – das DNS übersetzt zwischen beidem. Eine URL = Schema + Host + Port + Pfad + Query. HTTP-Methoden: GET (holen), POST (senden), PUT/PATCH (ändern), DELETE (löschen). Status-Codes: 2xx OK, 3xx Redirect, 4xx Client-Fehler, 5xx Server-Fehler. HTTPS = verschlüsseltes HTTP via TLS – heute Standard. Beim Seitenaufruf läuft eine Kette: DNS → TCP → TLS → HTTP → DOM → CSS → JS → Render.