Zum Hauptinhalt springen

2. HTTP/2-Protokollübersicht

HTTP/2 bietet einen optimierten Transport für HTTP-Semantik. HTTP/2 unterstützt alle Kernfunktionen von HTTP, zielt aber darauf ab, effizienter als HTTP/1.1 zu sein.

HTTP/2 ist ein verbindungsorientiertes Anwendungsschichtprotokoll, das über eine TCP-Verbindung läuft ([TCP]). Der Client ist der Initiator der TCP-Verbindung.

Die grundlegende Protokolleinheit in HTTP/2 ist ein Frame (Abschnitt 4.1). Jeder Frame-Typ dient einem anderen Zweck. Beispielsweise bilden HEADERS- und DATA-Frames die Grundlage von HTTP-Anfragen und -Antworten (Abschnitt 8.1); andere Frame-Typen wie SETTINGS, WINDOW_UPDATE und PUSH_PROMISE werden zur Unterstützung anderer HTTP/2-Funktionen verwendet.

Multiplexing von Anfragen wird erreicht, indem jeder HTTP-Anfrage/Antwort-Austausch mit seinem eigenen Stream (Abschnitt 5) verknüpft wird. Streams sind weitgehend unabhängig voneinander, sodass eine blockierte oder stockende Anfrage oder Antwort den Fortschritt anderer Streams nicht verhindert.

Die effektive Nutzung von Multiplexing hängt von Flusskontrolle und Priorisierung ab. Flusskontrolle (Abschnitt 5.2) stellt sicher, dass es möglich ist, gemultiplexte Streams effizient zu nutzen, indem die übertragenen Daten auf das beschränkt werden, was der Empfänger verarbeiten kann. Priorisierung (Abschnitt 5.3) stellt sicher, dass begrenzte Ressourcen am effektivsten genutzt werden. Diese Revision von HTTP/2 macht das Priorisierungssignalisierungsschema aus [RFC7540] veraltet.

Da HTTP-Felder, die in einer Verbindung verwendet werden, große Mengen redundanter Daten enthalten können, werden Frames, die sie enthalten, komprimiert (Abschnitt 4.3). Dies hat besonders vorteilhafte Auswirkungen auf Anfragegrößen im üblichen Fall und ermöglicht es, viele Anfragen in ein Paket zu komprimieren.

Schließlich fügt HTTP/2 einen neuen, optionalen Interaktionsmodus hinzu, bei dem ein Server Antworten an einen Client pushen kann (Abschnitt 8.4). Dies soll es einem Server ermöglichen, spekulativ Daten an einen Client zu senden, die der Server erwartet, dass der Client sie benötigt, wobei eine gewisse Netzwerknutzung gegen einen potenziellen Latenzgewinn eingetauscht wird. Der Server tut dies, indem er eine Anfrage synthetisiert, die er als PUSH_PROMISE-Frame sendet. Der Server ist dann in der Lage, eine Antwort auf die synthetische Anfrage auf einem separaten Stream zu senden.

2.1. Dokumentorganisation

Die HTTP/2-Spezifikation ist in vier Teile unterteilt:

  • Das Starten von HTTP/2 (Abschnitt 3) behandelt, wie eine HTTP/2-Verbindung initiiert wird.

  • Die Frame- (Abschnitt 4) und Stream-Schichten (Abschnitt 5) beschreiben die Art und Weise, wie HTTP/2-Frames strukturiert und zu gemultiplexten Streams geformt werden.

  • Frame- (Abschnitt 6) und Fehlerdefinitionen (Abschnitt 7) enthalten Details zu den in HTTP/2 verwendeten Frame- und Fehlertypen.

  • HTTP-Zuordnungen (Abschnitt 8) und zusätzliche Anforderungen (Abschnitt 9) beschreiben, wie HTTP-Semantik mit Frames und Streams ausgedrückt wird.

Während einige der Frame- und Stream-Schicht-Konzepte von HTTP isoliert sind, definiert diese Spezifikation keine vollständig generische Frame-Schicht. Die Frame- und Stream-Schichten sind auf die Bedürfnisse von HTTP zugeschnitten.

2.2. Konventionen und Terminologie

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Alle numerischen Werte sind in Netzwerk-Byte-Reihenfolge. Werte sind vorzeichenlos, sofern nicht anders angegeben. Literalwerte werden je nach Bedarf dezimal oder hexadezimal angegeben. Hexadezimale Literale sind mit "0x" vorangestellt, um sie von dezimalen Literalen zu unterscheiden.

Diese Spezifikation beschreibt binäre Formate unter Verwendung der in Abschnitt 1.3 von RFC 9000 [QUIC] beschriebenen Konventionen. Beachten Sie, dass dieses Format Netzwerk-Byte-Reihenfolge verwendet und dass hochwertige Bits vor niederwertigen Bits aufgelistet werden.

Die folgenden Begriffe werden verwendet:

client: Der Endpunkt, der eine HTTP/2-Verbindung initiiert. Clients senden HTTP-Anfragen und empfangen HTTP-Antworten.

connection: Eine Transportschicht-Verbindung zwischen zwei Endpunkten.

connection error: Ein Fehler, der die gesamte HTTP/2-Verbindung unbrauchbar macht.

endpoint: Entweder der Client oder Server der Verbindung.

frame: Die kleinste Kommunikationseinheit innerhalb einer HTTP/2-Verbindung, bestehend aus einem Header und einer variablen Länge von Oktetten, die entsprechend dem Frame-Typ strukturiert sind.

peer: Ein Endpunkt. Bei der Diskussion eines bestimmten Endpunkts bezieht sich "peer" auf den Endpunkt, der vom primären Diskussionsgegenstand entfernt ist.

receiver: Ein Endpunkt, das Frames empfängt.

sender: Ein Endpunkt, das Frames überträgt.

server: Der Endpunkt, der eine HTTP/2-Verbindung akzeptiert. Server empfangen HTTP-Anfragen und senden HTTP-Antworten.

stream: Ein bidirektionaler Fluss von Frames innerhalb der HTTP/2-Verbindung.

stream error: Ein Fehler auf dem einzelnen HTTP/2-Stream.

Schließlich sind die Begriffe "gateway", "intermediary", "proxy" und "tunnel" in Abschnitt 3.7 von [HTTP] definiert. Intermediäre fungieren zu verschiedenen Zeiten sowohl als Client als auch als Server.

Der Begriff "content", wie er auf Nachrichtenkörper angewendet wird, ist in Abschnitt 6.4 von [HTTP] definiert.