03 WorldWideWeb Flashcards by Leonard H

Definition

HTTP/0.9: Zweck

Kurzfokus

“HyperText Transfer Protocol zum Verbreiten von Wissen über das Internet; textuelles Protokoll für Hypertext mit Links.”

Geburtsstunde des World Wide Web laut Folien.

How well did you know this?

Not at all

Perfectly

Definition

HTTP/0.9: Ursprung

Wer/wo?

“Entwickelt von Tim Berners-Lee am CERN; zusammen mit HTML und URL.”

Name vom ersten Browser abgeleitet.

How well did you know this?

Not at all

Perfectly

Architektur/Zuordnung

HTTP/1.0: Request/Response Felder

Aufbau

“Request: Version

Adresse

Methode

How well did you know this?

Not at all

Perfectly

Definition

HTTP Version: Notation

Schreibweise

“HTTP/<Major>.<Minor>; höhere Major-Version kann brechende Änderungen bedeuten; höhere Minor-Version ohne brechende Änderungen."</Minor></Major>

Entspricht semantischer Versionierung.

How well did you know this?

Not at all

Perfectly

Definition

URI: Begriff

Was ist das?

“Uniform Resource Identifier: Zeichenkette zur einheitlichen Identifikation einer Ressource; nur ASCII

keine Leer- oder Kontrollzeichen.”

URL = Zugriffsschema; URN = eindeutiger Name.

How well did you know this?

Not at all

Perfectly

Architektur/Zuordnung

HTTP-Adresse: Bestandteile

Zerlege die URL

“Schema

Host-Adresse

optional Port

How well did you know this?

Not at all

Perfectly

Definition

HTTP/1.0 Methoden

Welche?

“GET (Ressource abrufen)

HEAD (nur Header)

POST (Ressource übertragen)

How well did you know this?

Not at all

Perfectly

Definition

HTTP/1.1 Methoden (Ergänzung)

Welche?

“PUT (aktualisieren)

DELETE (löschen); OPTIONS

CONNECT

How well did you know this?

Not at all

Perfectly

Definition

HTTP-Header: Zweck

Wofür?

“Zusatzinfos von Client/Server; Beispiele: Content-Encoding

Content-Length

Content-Type

How well did you know this?

Not at all

Perfectly

Anwendung/Beispiele

HTTP-Statuscodes: Erfolg

Beispiele

“200 OK

201 Created

202 Accepted

How well did you know this?

Not at all

Perfectly

Anwendung/Beispiele

HTTP-Statuscodes: Umleitung

Beispiele

“301 Moved Permanently

302 Moved Temporarily

304 Not Modified.”

How well did you know this?

Not at all

Perfectly

Anwendung/Beispiele

HTTP-Statuscodes: Clientfehler

Beispiele

“400 Bad Request

401 Unauthorized

403 Forbidden

How well did you know this?

Not at all

Perfectly

Anwendung/Beispiele

HTTP-Statuscodes: Serverfehler

Beispiele

“500 Internal Server Error

501 Not Implemented

502 Bad Gateway

How well did you know this?

Not at all

Perfectly

Prozess/Handshake

HTTP Roundtrip: Beispiel

Schritte

“Gegeben: GET auf /wiki/Verteiltes_System.\n- Client: „GET … HTTP/1.1“ + Host\n- Server: „HTTP/1.1 200 OK“ + Header\n- Inhalt: HTML kann weitere Ressourcen anfordern (z. B. CSS)\nEndergebnis: Mehrere nachgelagerte Requests möglich.”

How well did you know this?

Not at all

Perfectly

Prozess/Handshake

HTTP Ablauf mit Redirect

TLS-Redirect

“Gegeben: Aufruf http://…\n- Server: 301 auf https://…\n- Client: GET auf HTTPS-Ziel\n- Server: 200 OK + Content\nEndergebnis: Umstieg auf HTTPS vor Inhaltsabruf.”

How well did you know this?

Not at all

Perfectly

Verständnis

HTTP/1.1: Verbindungsmanagement

Keep-Alive

“Problem: HTTP/1.0 schließt TCP nach jedem Request. Lösung: Verbindung offen lassen per Client-Header „keepalive“. Requests bleiben sequentiell.”

Browser öffnen oft bis zu 6 Verbindungen parallel.

How well did you know this?

Not at all

Perfectly

Definition

HTTP/1.1: Zustandslosigkeit

Eigenschaft

“HTTP/1.1 ist zustandslos; TCP-Verbindung wird nach dem Laden geschlossen.”

Webanwendungen benötigen dennoch Zustand.

How well did you know this?

Not at all

Perfectly

Definition

Cookies: Mechanik

Wie?

Study These Flashcards

“Server sendet „Set-Cookie“

Browser speichert; Client sendet Cookie bei jedem Request mit; wegen Overhead meist nur ein Identifier.”

Definition

HTTPS: Ziel & Port

Sicherung

Study These Flashcards

“Transportsicherheit via TLS; alle Nachrichten zwischen Client und Server verschlüsselt; Standardport 443 (statt 80).”

HTTP Strict Transport Security per Header „Strict-Transport-Security“.

Verständnis

HTTP/1.1: Grenzen

Warum neu?

Study These Flashcards

“Ausufernde Header; pro TCP-Verbindung nur eine Ressource gleichzeitig; jede Server-Antwort benötigt vorherigen Client-Request.”

Kompatibilität bleibt wichtig.

Definition

HTTP/2.0: Kernideen

Welche?

Study These Flashcards

“Multiplexing

Header-Komprimierung

Server Streaming.”

Definition

Headerkomprimierung (HTTP/2.0)

Wie?

Study These Flashcards

“Header binär kodiert und mit HPACK (u. a. Huffman) komprimiert; pro Verbindung gecacht

erneute Übertragung entfällt.”

Definition

Multiplexing (HTTP/2.0)

Zuordnung

Study These Flashcards

“Frames tragen eine Stream ID; mehrere Requests/Responses parallel über eine TCP-Verbindung; Client ordnet per Stream ID zu.”

Definition

Server Streaming (HTTP/2.0)

Prinzip

Study These Flashcards

“Server kann Ressourcen proaktiv zusagen (Promise) und senden; Client kann ablehnen (z. B. Cache).”

Typisch eher für statische Inhalte.

# Rechnung/Denkaufgabe Zeit: HTTP/1.0 mit 100 Ressourcen | 12 ms RTT

"Gegeben/Gesucht: 1 HTML | 1 CSS ## Footnote 10 Skripte

# Rechnung/Denkaufgabe Zeit: HTTP/1.1 (eine Verbindung) | 12 ms RTT

"Gegeben: wie zuvor.\n- 1× TCP-TLS\n- 100 Requests/Responses sequentiell\n- Rechnung: 3 + 100 * 12 ms\nEndergebnis: 1 | 24 s."

# Rechnung/Denkaufgabe Zeit: HTTP/1.1 (6 Verbindungen) | Parallelität

"Gegeben: wie zuvor.\n- 6 parallele Verbindungen\n- Ablauf: HTML/CSS/Skripte parallel (2 Runden) | Bilder in 15 Runden\n- Rechnung: 3 + 1 + 2 + 15 * 12 ms\nEndergebnis: 252 ms."

# Rechnung/Denkaufgabe Zeit: HTTP/2.0 (Multiplexing) | Parallel 3 Streams

"Gegeben: wie zuvor.\n- 1× TCP-TLS\n- 3 parallele Requests/Responses\n- Rechnung: 3 + 1 + 1 + 1 * 12 ms\nEndergebnis: 72 ms."

# Rechnung/Denkaufgabe Zeit: HTTP/2.0 (Server Streaming) | Push alles

"Gegeben: wie zuvor.\n- 1× TCP-TLS\n- 1 Request | 100 Responses parallel\n- Rechnung: 3 + 1 * 12 ms\nEndergebnis: 48 ms." ## Footnote Faktor ~100 schneller vs. HTTP/1.0 laut Folie.

# Verständnis Head-of-Line-Blocking: Bildidee | Pizza-Analogie

"Lieferdienst liefert reihenfolgetreu; fällt eine frühe Lieferung aus | warten alle folgenden: „Head-of-Line-Blocking“." ## Footnote Reihenfolgentreue bleibt pro Datei wichtig.

# Definition ALPN: Zweck | Aushandlung

"Application-Layer Protocol Negotiation in TLS listet unterstützte Protokolle (z. B. http/1.1 | h2 ## Footnote h3); Server wählt Version."

# Definition HTTP/3.0: Ansatz | Warum UDP?

"Wechsel auf UDP | um TCP-bedingtes Head-of-Line-Blocking und Verbindungsabbrüche beim Netzwechsel zu vermeiden; Zuverlässigkeit wird im darüberliegenden Protokoll sichergestellt."

# Definition QUIC: Charakter | Transport

"Zuverlässiges | verbindungsorientiertes Transportprotokoll oberhalb von UDP; Sicherheit integriert; Ziel: Roundtrips minimieren ## Footnote Paketgrößen nicht begrenzen."

# Verständnis QUIC: Latenz-Priorität | Begründung

"Bandbreite oft hoch (VDSL/Glasfaser) | Latenz physikalisch limitiert; daher Fokus auf Reduktion von Roundtrips und besseres Caching."

# Definition QUIC: Sequenz und ACKs | Messung

"Streng monotone Sequenznummern und separate Acknowledgements erlauben genauere Schätzung der Roundtrip-Zeit; Staukontrolle ähnlich TCP."

# Definition QUIC: Connection ID | Stabilität

"Dedizierte Connection ID pro Verbindung; Verbindungsparameter bleiben trotz UDP-Wechsel erhalten; Verbindung über Netzwechsel hinweg stabil (z. B. LTE → WLAN)."

# Verständnis QUIC: Multiplexing ohne globales HOL | Streams

"Reihenfolgentreue wird pro Stream ID gewährleistet; verhindert Head-of-Line-Blocking zwischen parallelen Streams."

# Verständnis QUIC: NAT-Probleme | Warum?

"Viele Switches behandeln QUIC wie UDP-Datagramme; kürzere Timeouts; Mapping kann vor Serverpaketen verfallen; QUIC_Close oft unbekannt." | TCP-Verhalten ist Geräten vertrauter.

# Rechnung/Denkaufgabe Zeit: HTTP/3.0 (QUIC, Streaming) | 1 RTT

"Gegeben: wie zuvor | RTT = 12 ms.\n- 1× QUIC-Aufbau (1 Roundtrip)\n- 1 Request ## Footnote 100 Responses parallel\n- Rechnung: 1 + 1 * 12 ms\nEndergebnis: 24 ms; mit gespeicherten Parametern ggf. 12 ms."

# Architektur/Zuordnung Webserver-Programmierung: Bausteine | Überblick

"Controller (Routen) | Dependency Injection ## Footnote Request-Pipeline (z. B. Authentifizierung)

# Anwendung/Beispiele Spring Boot: Einfaches Beispiel | Route

"Beispiel zeigt @GetMapping „/hello“ mit Query-Parameter „name“ und String-Response; läuft typischerweise auf Apache Tomcat." | Routen können Platzhalter enthalten.

# Anwendung/Beispiele ASP.NET Core: Einfaches Beispiel | Route

"Beispiel mit [ApiController] | Route „hello“ ## Footnote HttpGet und optionalem Parameter „name“; Hosting über Kestrel

# Zusammenfassung HTTP-Evolution: Kernaussage | Überblick

"Primitive (Methoden | Ressourcen ## Footnote URLs

# Verständnis Prüfungsfokus (aus Folienfragen) | Hinweis

"Erläutere Bestandteile einer HTTP-Adresse; Beispiele für Header | Statuscodes ## Footnote Methoden; Unterschiede HTTP/1.1 vs. HTTP/2.0 und HTTP/2.0 vs. HTTP/3.0; Head-of-Line-Blocking; Zeitvorteile bei Umstieg."

03 WorldWideWeb Flashcards

(44 cards)