3. Starting HTTP/2 (HTTP/2 starten)
Implementierungen, die HTTP-Anfragen generieren, müssen herausfinden, ob ein Server HTTP/2 unterstützt.
HTTP/2 verwendet die in Abschnitt 4.2 von [HTTP] definierten URI-Schemata "http" und "https" mit denselben Standard-Portnummern wie HTTP/1.1 [HTTP/1.1]. Diese URIs enthalten keine Angabe darüber, welche HTTP-Versionen ein Upstream-Server (der unmittelbare Peer, zu dem der Client eine Verbindung herstellen möchte) unterstützt.
Die Mittel, mit denen die Unterstützung für HTTP/2 bestimmt wird, sind für "http"- und "https"-URIs unterschiedlich. Die Erkennung für "https"-URIs wird in Abschnitt 3.2 beschrieben. Die HTTP/2-Unterstützung für "http"-URIs kann nur durch Out-of-Band-Mittel (Out-of-Band Means) erkannt werden und erfordert Vorwissen (Prior Knowledge) über die Unterstützung, wie in Abschnitt 3.3 beschrieben.
3.1. HTTP/2 Version Identification (HTTP/2-Versionsidentifikation)
Das in diesem Dokument definierte Protokoll hat zwei Identifikatoren. Das Erstellen einer Verbindung basierend auf einem der beiden impliziert die Verwendung des Transports, des Framings und der Nachrichtensemantik, die in diesem Dokument beschrieben werden.
-
Die Zeichenfolge "h2" identifiziert das Protokoll, bei dem HTTP/2 Transport Layer Security (TLS) verwendet; siehe Abschnitt 9.2. Dieser Identifikator wird im TLS Application-Layer Protocol Negotiation (ALPN)-Erweiterungsfeld [TLS-ALPN] und an jedem Ort verwendet, an dem HTTP/2 über TLS identifiziert wird.
Die Zeichenfolge "h2" wird als ALPN-Protokollidentifikator als Zwei-Oktett-Sequenz serialisiert: 0x68, 0x32.
-
Die Zeichenfolge "h2c" wurde zuvor als Token für das Upgrade-Header-Feld des HTTP-Upgrade-Mechanismus (Abschnitt 7.8 von [HTTP]) verwendet. Diese Verwendung wurde nie weit verbreitet und wird durch dieses Dokument veraltet. Das Gleiche gilt für das HTTP2-Settings-Header-Feld, das mit dem Upgrade auf "h2c" verwendet wurde.
3.2. Starting HTTP/2 for "https" URIs (HTTP/2 für "https"-URIs starten)
Ein Client, der eine Anfrage an einen "https"-URI stellt, verwendet TLS [TLS13] mit der ALPN-Erweiterung [TLS-ALPN].
HTTP/2 über TLS verwendet den Protokollidentifikator "h2". Der Protokollidentifikator "h2c" darf nicht (MUST NOT) von einem Client gesendet oder von einem Server ausgewählt werden; der Protokollidentifikator "h2c" beschreibt ein Protokoll, das kein TLS verwendet.
Sobald die TLS-Verhandlung abgeschlossen ist, müssen sowohl der Client als auch der Server eine Verbindungspräambel (Connection Preface, Abschnitt 3.4) senden (MUST).
3.3. Starting HTTP/2 with Prior Knowledge (HTTP/2 mit Vorwissen starten)
Ein Client kann durch andere Mittel erfahren, dass ein bestimmter Server HTTP/2 unterstützt. Beispielsweise könnte ein Client mit dem Wissen konfiguriert sein, dass ein Server HTTP/2 unterstützt.
Ein Client, der weiß, dass ein Server HTTP/2 unterstützt, kann eine TCP-Verbindung herstellen und die Verbindungspräambel (Abschnitt 3.4) gefolgt von HTTP/2-Frames senden. Server können diese Verbindungen durch das Vorhandensein der Verbindungspräambel identifizieren. Dies betrifft nur die Herstellung von HTTP/2-Verbindungen über Klartext-TCP; HTTP/2-Verbindungen über TLS müssen (MUST) Protokollverhandlung in TLS [TLS-ALPN] verwenden.
Ebenso muss der Server eine Verbindungspräambel senden (MUST) (Abschnitt 3.4).
Ohne zusätzliche Informationen ist die frühere Unterstützung für HTTP/2 kein starkes Signal dafür, dass ein bestimmter Server HTTP/2 für zukünftige Verbindungen unterstützen wird. Beispielsweise ist es möglich, dass sich Serverkonfigurationen ändern, dass Konfigurationen zwischen Instanzen in geclusterten Servern unterschiedlich sind oder dass sich Netzwerkbedingungen ändern.
3.4. HTTP/2 Connection Preface (HTTP/2-Verbindungspräambel)
In HTTP/2 ist jeder Endpunkt verpflichtet, eine Verbindungspräambel (Connection Preface) als endgültige Bestätigung des verwendeten Protokolls zu senden und die anfänglichen Einstellungen für die HTTP/2-Verbindung festzulegen. Client und Server senden jeweils eine unterschiedliche Verbindungspräambel.
Die Client-Verbindungspräambel beginnt mit einer Sequenz von 24 Oktetten, die in Hex-Notation lautet:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
Das heißt, die Verbindungspräambel beginnt mit der Zeichenfolge "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n". Auf diese Sequenz muss (MUST) ein SETTINGS-Frame (Abschnitt 6.5) folgen, der leer sein kann (MAY). Der Client sendet die Client-Verbindungspräambel als erste Anwendungsdaten-Oktette einer Verbindung.
Hinweis: Die Client-Verbindungspräambel wurde so gewählt, dass ein großer Teil der HTTP/1.1- oder HTTP/1.0-Server und Vermittler nicht versucht, weitere Frames zu verarbeiten. Beachten Sie, dass dies die in [TALKING] aufgeworfenen Bedenken nicht adressiert.
Die Server-Verbindungspräambel besteht aus einem möglicherweise leeren SETTINGS-Frame (Abschnitt 6.5), der der erste Frame sein muss (MUST), den der Server in der HTTP/2-Verbindung sendet.
Die SETTINGS-Frames, die von einem Peer als Teil der Verbindungspräambel empfangen werden, müssen (MUST) nach dem Senden der Verbindungspräambel bestätigt werden (siehe Abschnitt 6.5.3).
Um unnötige Latenz zu vermeiden, dürfen Clients unmittelbar nach dem Senden der Client-Verbindungspräambel zusätzliche Frames an den Server senden, ohne auf den Empfang der Server-Verbindungspräambel zu warten. Es ist jedoch wichtig zu beachten, dass der SETTINGS-Frame der Server-Verbindungspräambel Einstellungen enthalten kann, die notwendigerweise ändern, wie ein Client mit dem Server kommunizieren soll. Nach Erhalt des SETTINGS-Frames wird vom Client erwartet, dass er alle festgelegten Einstellungen berücksichtigt. In einigen Konfigurationen ist es möglich, dass der Server SETTINGS überträgt, bevor der Client zusätzliche Frames sendet, was eine Gelegenheit bietet, dieses Problem zu vermeiden.
Clients und Server müssen (MUST) eine ungültige Verbindungspräambel als Verbindungsfehler (Connection Error, Abschnitt 5.4.1) vom Typ PROTOCOL_ERROR behandeln. Ein GOAWAY-Frame (Abschnitt 6.8) kann (MAY) in diesem Fall weggelassen werden, da eine ungültige Präambel anzeigt, dass der Peer kein HTTP/2 verwendet.