Deutsch
Menü

HTTP/1.1 vs. HTTP/2 vs. HTTP/3: Transport, Multiplexing, Head-of-Line-Blocking

Die drei Versionen teilen dieselbe HTTP-Semantik (RFC 9110), etwa Methoden, Statuscodes und Header-Felder; unterschiedlich sind das Format und der Transport, mit dem sie übertragen werden. HTTP/1.1 (RFC 9112) sendet Textnachrichten über TCP und liefert auf jeder Verbindung die Antworten nacheinander. HTTP/2 (RFC 9113) teilt Nachrichten in binäre Frames und multiplext mehrere Streams über eine TCP-Verbindung. HTTP/3 (RFC 9114) nutzt QUIC (RFC 9000), das über UDP läuft und Stream-Multiplexing sowie TLS-1.3-Verschlüsselung im Transport übernimmt. Damit wird das Head-of-Line-Blocking von TCP vermieden, bei dem der Verlust eines einzigen Pakets alle Streams aufhält.

MerkmalHTTP/1.1HTTP/2HTTP/3
SpezifikationRFC 9112 (Semantik in RFC 9110, gemeinsam für alle drei Versionen)RFC 9113RFC 9114 (QUIC ist RFC 9000)
TransportTCPTCPQUIC (läuft über UDP)
NachrichtenformatText: eine Anfragezeile und Header-Felder, eines pro ZeileBinäre FramesBinäre Frames (auf QUIC-Streams)
MultiplexingKeines: Eine Verbindung bearbeitet jeweils nur eine Anfrage und Antwort, für paralleles Abrufen müssen mehrere Verbindungen geöffnet werdenMehrere Streams werden parallel über eine TCP-Verbindung gesendetMehrere QUIC-Streams werden parallel gesendet; die Streams verwaltet der Transport
Head-of-Line-BlockingTritt auf der HTTP-Schicht auf: Auf derselben Verbindung kann die nächste Antwort erst nach der vorherigen gesendet werden (auch mit Pipelining kommen die Antworten in Anfragereihenfolge zurück)Auf der HTTP-Schicht gelöst, aber weil TCP Bytes strikt in Reihenfolge liefert, lässt der Verlust eines Pakets alle Streams auf die Wiederholung wartenQUIC verwaltet die Reihenfolge je Stream, daher betrifft ein Verlust nur die Streams, deren Daten verloren gingen
Header-KompressionKeine (der Body kann komprimiert werden, Header gehen aber als Klartext)HPACK (RFC 7541)QPACK (RFC 9204), eine Anpassung von HPACK, die auch funktioniert, wenn Streams in anderer Reihenfolge ankommen
VerschlüsselungOptional: https nutzt TLS, http wird im Klartext gesendetDie Spezifikation definiert sowohl über TLS (h2) als auch im Klartext (h2c); über TLS verlangt sie mindestens TLS 1.2. Die großen Browser unterstützen HTTP/2 nur über TLSPflicht: TLS 1.3 ist in QUIC eingebaut, einen Klartextmodus gibt es nicht
Umläufe bis zum VerbindungsaufbauEiner für TCP plus einer mit TLS 1.3, sodass die Anfrage nach insgesamt zwei Umläufen gesendet wirdWie HTTP/1.1 (zwei Umläufe für TCP und TLS)QUIC fasst Transport- und Krypto-Handshake in einem Umlauf zusammen; für zuvor kontaktierte Server ist auch 0-RTT verfügbar, das schon im allerersten Flug Daten sendet
Bei einem NetzwechselEine TCP-Verbindung wird über Quell- und Zieladressen und -ports identifiziert, daher ist bei geänderter IP-Adresse eine neue Verbindung nötigWie HTTP/1.1QUIC identifiziert Verbindungen über Verbindungs-IDs, daher kann dieselbe Verbindung beim Wechsel vom WLAN ins Mobilfunknetz weiterlaufen (Verbindungsmigration)

Die Zahlenwerte sind typische Größenordnungen und variieren je nach Prozessgeneration und Produkt.

Wann welche Variante?

HTTP/1.1
Die Basisversion, die jeder Client und Server nutzen kann. Wird auch für die Kommunikation innerhalb von Serversystemen und für einfache Weboberflächen wie Geräte-Einstellungsseiten verwendet.
HTTP/2
Wenn eine Webseite, die viele kleine Dateien lädt, effizient über eine Verbindung ausgeliefert werden soll. Da es auch in Netzwerken funktioniert, die UDP blockieren, ist es selbst bei Websites mit HTTP/3-Unterstützung die Rückfalloption.
HTTP/3
Wenn sich Streams auf verlustbehafteten Verbindungen mit hoher Latenz wie Mobilfunknetzen nicht gegenseitig aufhalten sollen oder ein schnellerer Verbindungsaufbau gewünscht ist. Manche Netzwerke blockieren UDP, daher unterstützen Websites meist auch HTTP/2 oder HTTP/1.1.

Häufige Fragen

Hat HTTP/2 das Head-of-Line-Blocking nicht beseitigt?

Auf der HTTP-Schicht ja, auf der TCP-Schicht bleibt es bestehen. HTTP/2 multiplext mehrere Streams über eine TCP-Verbindung, aber TCP weiß nicht, zu welchem Stream die Daten gehören, und liefert Bytes strikt in Reihenfolge. Geht ein Paket verloren, werden daher auch Daten unbeteiligter Streams der empfangenden Anwendung vorenthalten, bis die Wiederholung eintrifft. Bei HTTP/3 verwaltet QUIC die Reihenfolge je Stream, sodass nur die Streams mit den verlorenen Daten warten müssen.

Woher weiß ein Client, dass ein Server HTTP/3 unterstützt?

HTTP/3 nutzt UDP und muss daher getrennt von einer TCP-Verbindung gestartet werden. Typischerweise verbindet sich der Client zuerst mit HTTP/1.1 oder HTTP/2 über TCP, und der Server kündigt im Antwort-Header Alt-Svc an, dass HTTP/3 (h3) verfügbar ist. Für spätere Verbindungen nutzt der Client dann QUIC. Unabhängig davon wird über TLS per ALPN im TLS-Handshake entschieden, ob HTTP/1.1 oder HTTP/2 verwendet wird.

Gibt es bei 0-RTT in HTTP/3 etwas zu beachten?

Ja. Mit 0-RTT gesendete Daten kann ein Angreifer aufzeichnen und erneut senden (ein Replay-Angriff). Bei 0-RTT ist daher Vorsicht geboten, etwa indem nur Anfragen wie GET gesendet werden, die bei mehrfachem Empfang keinen Schaden anrichten.

Müssen Webanwendungen für HTTP/2 oder HTTP/3 neu geschrieben werden?

Meist nicht. Die Bedeutung von Methoden, Statuscodes und Header-Feldern ist allen drei Versionen gemeinsam (RFC 9110); nur die Art der Übertragung unterscheidet sich. Da die Version je Verbindung gewählt wird, ist es verbreitet, dass ein Reverse Proxy oder CDN von Browsern HTTP/2 oder HTTP/3 annimmt und mit den dahinterliegenden Anwendungsservern HTTP/1.1 spricht.

Verständnis prüfen

Welche Kombination nennt die Elemente der ersten Zeile (der Anfragezeile) einer HTTP/1.1-Anfrage richtig?

  1. AMethode, Ziel der Anfrage (etwa ein Pfad), HTTP-Version
  2. BHTTP-Version, Statuscode, kurze Begründungsphrase
  3. CQuell-IP-Adresse, Zielportnummer, Methode
Antwort und Erläuterung anzeigen

Antwort: A. Methode, Ziel der Anfrage (etwa ein Pfad), HTTP-Version

Eine HTTP-Anfrage besteht in dieser Reihenfolge aus der Anfragezeile, den Headern (ein „Name: Wert“ pro Zeile), einer Leerzeile und dem Body. „GET /docs/index.html HTTP/1.1“ ist zum Beispiel eine Zeile, die mit der Methode GET /docs/index.html anfordert. Bei HTTP/1.1 muss außerdem immer der Host-Header gesendet werden, damit der Server erkennen kann, an welche Website sich eine Anfrage richtet, auch wenn mehrere Websites unter derselben IP-Adresse betrieben werden. Die erste Zeile der Antwort ist die Statuszeile; sie enthält wie in „HTTP/1.1 200 OK“ die Version, den Statuscode und die Begründungsphrase (Reason Phrase).

Welche Aussage über HTTP/2 und HTTP/3 ist richtig?

  1. AHTTP/2 kann über eine TCP-Verbindung mehrere Anfragen parallel abwickeln, doch ein Paketverlust kann auch andere Streams warten lassen; HTTP/3 verringert dies mit QUIC über UDP
  2. BHTTP/2 verwendet Nachrichten im selben Textformat wie HTTP/1.1 und baut für jede Anfrage parallel eine neue TCP-Verbindung auf, damit mehrere Ressourcen gleichzeitig empfangen werden können
  3. CHTTP/3 läuft wie HTTP/2 über TCP und ändert nur das Verfahren der Header-Kompression; Paketverluste wirken sich genauso aus wie bei HTTP/2, und UDP wird nicht verwendet
Antwort und Erläuterung anzeigen

Antwort: A. HTTP/2 kann über eine TCP-Verbindung mehrere Anfragen parallel abwickeln, doch ein Paketverlust kann auch andere Streams warten lassen; HTTP/3 verringert dies mit QUIC über UDP

Auch HTTP/1.1 kann mit persistenten Verbindungen (Keep-Alive) eine TCP-Verbindung wiederverwenden, doch über eine Verbindung werden die Antworten der Reihe nach einzeln empfangen; deshalb bauten Browser mehrere Verbindungen parallel auf. HTTP/2 zerlegt Nachrichten in binäre Frames und multiplext mehrere Streams über eine TCP-Verbindung, sodass sie parallel gesendet werden. Weil TCP seinen Bytestrom jedoch in der richtigen Reihenfolge ausliefert, müssen bei einem einzigen verlorenen Paket auch die Daten anderer, unbeteiligter Streams warten, bis die Sendewiederholung ankommt (Head-of-Line-Blocking). HTTP/3 verwendet QUIC, das über UDP läuft und die Reihenfolge je Stream verwaltet, sodass sich ein Verlust nur auf den betroffenen Stream auswirkt.

Von einem Webserver mit einer Umlaufzeit (RTT) von 40 ms werden eine HTML-Datei und die vier darin referenzierten Bilder nacheinander einzeln abgerufen. Der Aufbau einer TCP-Verbindung dauert einen Umlauf, jede Anfrage mit Antwort ebenfalls einen Umlauf; Übertragungszeit der Daten, Verarbeitungszeit des Servers, TLS und Verbindungsabbau werden nicht berücksichtigt. Wie groß ist der Zeitunterschied zwischen einer neuen TCP-Verbindung für jedes Objekt und der Wiederverwendung einer einzigen TCP-Verbindung (persistente Verbindung)?

  1. A160 ms
  2. B200 ms
  3. C400 ms
Antwort und Erläuterung anzeigen

Antwort: A. 160 ms

Es gibt insgesamt fünf Objekte. Mit einer neuen Verbindung für jedes Objekt braucht jedes Objekt zwei Umläufe, einen für den Verbindungsaufbau und einen für Anfrage und Antwort: 5 × 2 × 40 = 400 ms. Bei einer persistenten Verbindung wird die Verbindung nur einmal zu Beginn aufgebaut, danach folgen nur die fünf Anfragen mit Antworten: (1 + 5) × 40 = 240 ms. Der Unterschied beträgt 400 − 240 = 160 ms; eingespart werden vier Verbindungsaufbauten. Bei HTTP/1.1 sind persistente Verbindungen das Standardverhalten.

  1. Ein Client baut zu einem Webserver mit einer Umlaufzeit (RTT) von 100 ms eine neue HTTPS-Verbindung auf (TLS 1.3 über TCP). Wie lange dauert es ungefähr, bis die Antwort auf die erste Anfrage einzutreffen beginnt? Die DNS-Namensauflösung ist bereits erledigt; Verarbeitungszeit des Servers und Übertragungszeit der Daten werden vernachlässigt.
  2. Was wird durch HTTPS (durch TLS geschütztes HTTP) geschützt?

Übungsfragen zu Grundlagen der Webtechnologien

Wichtige Begriffe erklärt

HTTP (Hypertext Transfer Protocol)
Protokoll der Anwendungsschicht, mit dem unter anderem Webbrowser und Webserver HTML, Bilder und Daten austauschen. Der Client sendet eine Anfrage aus Methode, URL, Headern und Body, der Server gibt eine Antwort aus Statuscode, Headern und Body zurück. Als Protokoll ist HTTP zustandslos; Zustände wie eine Anmeldung werden etwa mit Cookies gehalten. HTTP/1.1 verwendet ein Textformat und persistente Verbindungen, HTTP/2 multiplext mehrere Streams über eine TCP-Verbindung, und HTTP/3 verwendet QUIC über UDP. Mit TLS geschütztes HTTP heißt HTTPS.
TLS (Transport Layer Security)
Protokoll, das die Kommunikation verschlüsselt, Manipulationen erkennt und Server mithilfe von Zertifikaten authentifiziert. HTTPS ist durch TLS geschütztes HTTP.
Drei-Wege-Handschlag (Three-Way Handshake)
Ablauf, mit dem eine TCP-Verbindung aufgebaut wird. Drei Nachrichten – SYN des Clients, SYN+ACK des Servers und ACK des Clients – bestätigen die initialen Sequenznummern beider Seiten.
HTTP-Methode
Das Wort in einer HTTP-Anfrage, das die gewünschte Operation auf eine Ressource angibt. Beispiele sind GET (abrufen), HEAD (nur die Header abrufen), POST (verarbeiten oder anlegen), PUT (ersetzen), PATCH (teilweise aktualisieren), DELETE (löschen) und OPTIONS (verfügbare Funktionen erfragen). Eine Methode, die den Zustand des Servers nicht ändert, heißt „sicher“; eine, bei der beliebig häufiges Senden zum selben Zustand führt wie einmaliges Senden, heißt „idempotent“. GET ist sicher und idempotent, PUT und DELETE sind idempotent, aber nicht sicher, und POST ist im Allgemeinen keines von beiden.
HTTP-Statuscode
Dreistellige Zahl in der ersten Zeile einer HTTP-Antwort, die das Ergebnis der Anfrage angibt. Die Hunderterstelle gibt die Klasse an: 1xx steht für Information, 2xx für Erfolg (200 OK, 201 Created, 204 No Content), 3xx für Umleitung (301 Moved Permanently, 302 Found, 304 Not Modified), 4xx für einen Fehler auf der Clientseite (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found) und 5xx für einen Fehler auf der Serverseite (500 Internal Server Error, 503 Service Unavailable). 401 wird verwendet, wenn Authentifizierungsdaten fehlen oder ungültig sind, 403, wenn der Client zwar authentifiziert ist, ihm aber die Berechtigung fehlt.
Reverse Proxy
Server, der vor Webservern steht, Anfragen der Nutzer stellvertretend für die Server entgegennimmt und an einen oder mehrere dahinterliegende Server weiterleitet. Er übernimmt Aufgaben wie die zentrale Verarbeitung der HTTPS-Verschlüsselung (TLS-Terminierung), das Zwischenspeichern und Zurückgeben häufig genutzter Antworten, das Verteilen der Last auf mehrere Server und das Verbergen des Aufbaus der dahinterliegenden Server. Von einem Forward Proxy, der auf der Seite der Nutzer steht und sich für sie mit externen Websites verbindet, unterscheidet er sich durch seinen Platz und durch das, was er schützt.

Verwandte Vergleiche