Zum Hauptinhalt springen

9. HTTP/2 Connections (HTTP/2-Verbindungen)

HTTP/2-Verbindungen sind Anwendungsschichtprotokolle, die auf einem zuverlässigen Transport [TCP] laufen und Transport Layer Security (TLS) [TLS13] verwenden, um die über das Netzwerk ausgetauschten Daten zu schützen.

HTTP/2 verwendet dieselben "http"- und "https"-URI-Schemas wie HTTP/1.1. HTTP/2 teilt dieselben Standard-Portnummern: Port 80 für "http"-URIs und Port 443 für "https"-URIs. Infolgedessen müssen Implementierungen Anfragen an Zielressourcen-URIs wie http://example.org/foo oder https://example.com/bar verarbeiten, indem sie zunächst herausfinden, ob der Upstream-Server (der unmittelbare Peer, zu dem der Client eine Verbindung herstellen möchte) HTTP/2 unterstützt.

9.1. Connection Management (Verbindungsverwaltung)​

HTTP/2-Verbindungen sind persistent. Für beste Leistung wird erwartet, dass Clients Verbindungen nicht schließen, bis festgestellt wird, dass keine weitere Kommunikation mit einem Server erforderlich ist (z. B. wenn ein Benutzer von einer bestimmten Webseite wegnavigiert) oder bis der Server die Verbindung schließt.

Clients SOLLTEN NICHT mehr als eine HTTP/2-Verbindung zu einem gegebenen Host- und Port-Paar öffnen, wobei der Host von einem URI, einem ausgewählten alternativen Dienst [ALT-SVC] oder einem konfigurierten Proxy abgeleitet wird.

Ein Client kann zusätzliche Verbindungen als Ersatz erstellen, entweder um Verbindungen zu ersetzen, die kurz davor sind, den verfügbaren Stream-Identifikatorraum zu erschöpfen (Abschnitt 5.1.1), um das Schlüsselmaterial für eine TLS-Verbindung zu erneuern oder um Verbindungen zu ersetzen, bei denen Fehler aufgetreten sind (Abschnitt 5.4.1).

Ein Client KANN mehrere Verbindungen zum selben Ziel öffnen, um: neue Verbindungen zu erstellen, um atomare Anfragen zu versuchen (siehe Abschnitt 9.1.2), oder um jeden Stream-Identifikator größer als 0 zu ersetzen, der in einem GOAWAY-Frame empfangen wurde und sich im "aktiven" oder "inaktiven" Zustand befindet (siehe Abschnitt 6.8).

Servern wird empfohlen, Verbindungen so lange wie möglich offen zu halten, aber sie sind berechtigt, inaktive Verbindungen bei Bedarf zu beenden. Wenn ein Endpunkt wählt, die Transportschicht-TCP-Verbindung zu schließen, SOLLTE der beendende Endpunkt zuerst einen GOAWAY-Frame (Abschnitt 6.8) senden, damit beide Endpunkte zuverlässig bestimmen können, ob zuvor gesendete Frames verarbeitet wurden, und alle notwendigen verbleibenden Aufgaben ordnungsgemäß abschließen oder beenden können.

9.1.1. Connection Reuse (Verbindungswiederverwendung)​

Verbindungen, die zu einem Ursprungsserver hergestellt werden, entweder direkt oder durch einen mit der CONNECT-Methode erstellten Tunnel (Abschnitt 8.5), KÖNNEN für Anfragen mit mehreren unterschiedlichen URI-Autoritätskomponenten wiederverwendet werden. Eine Verbindung kann wiederverwendet werden, solange der Ursprungsserver autoritativ ist (Abschnitt 10.1). Bei TCP-Verbindungen ohne TLS hängt dies davon ab, dass der Host auf dieselbe IP-Adresse aufgelöst wurde.

Für "https"-Ressourcen hängt die Wiederverwendung von Verbindungen zusätzlich davon ab, ein gültiges Zertifikat für den Host im URI zu haben. Das vom Server präsentierte Zertifikat MUSS alle Überprüfungen erfüllen, die der Client durchführen würde, wenn er eine neue TLS-Verbindung für den Ursprung bildet.

Ein Ursprungsserver kann ein Zertifikat mit mehreren Ursprüngen anbieten, von denen jeder für die Verwendung der Verbindung autoritativ ist. Beispielsweise kann ein Zertifikat mehrere Hostnamen im Feld subjectAltName enthalten. Alternativ kann ein Hostname mit einem Platzhalter auch auf andere Ursprünge anwendbar sein.

In einigen Fällen kann die URI-Autorität von der im Zertifikat identifizierten Menge von Ursprüngen abweichen (z. B. verwenden einige Bereitstellungen URIs, um anderswo etablierte Identitätsbehauptungen zu tragen), und andere Attribute der Autorität stimmen ebenfalls nicht überein. Ein Client KANN versuchen, eine vorhandene Verbindung zu verwenden, MUSS aber die Anfrage mit einem URI senden, den der Client als autoritativ betrachtet. Wenn der Server die Anfrage nicht akzeptieren möchte, SOLLTE er einen 421 (Misdirected Request)-Statuscode erzeugen, der den Client veranlasst, die Anfrage erneut zu versuchen.

Wenn der Client entdeckt, dass die Verbindung, die er wiederzuverwenden versucht, nicht mehr verfügbar ist, KANN er eine unsichere Anfrage über eine neue Verbindung wiederholen.

Ein Proxy KANN Verbindungen zum selben Ursprungsserver wiederverwenden.

9.1.2. The 421 (Misdirected Request) Status Code (Der 421 (Fehlgeleitete Anfrage)-Statuscode)​

Der 421 (Misdirected Request)-Statuscode zeigt an, dass die Anfrage an einen Server gerichtet wurde, der keine Antwort erzeugen kann. Dies kann von einem Server gesendet werden, der nicht konfiguriert ist, Antworten für die Kombination von Schema und Autorität zu erzeugen, die in der Anfrage-URI enthalten sind.

Clients, die eine 421 (Misdirected Request)-Antwort erhalten, KÖNNEN die Anfrage wiederholen, unabhängig davon, ob die Anfragemethode idempotent ist oder nicht, über eine andere Verbindung. Dies ist möglich, weil es nur erlaubt ist, einen 421-Antwortcode zu erzeugen, bevor der Server wählt, keine autoritative Antwort zu liefern.

Dieser Statuscode DARF NICHT von Proxies generiert werden. Eine 421-Antwort ist cachebar; sie ist standardmäßig heuristisch cachebar, sofern in der Antwort nichts anderes angegeben ist (siehe Abschnitt 4.2.2 von [HTTP-CACHING]).

9.2. Use of TLS Features (Verwendung von TLS-Funktionen)​

Implementierungen von HTTP/2 MÜSSEN TLS-Version 1.2 [TLS12] oder höher für "https"-URIs verwenden. Allgemeine Anleitungen zur Verwendung von TLS-Implementierungen werden in [TLSBCP] gegeben.

Implementierungen von TLS MÜSSEN die Server Name Indication (SNI)-Erweiterung [TLS-EXT] unterstützen. HTTP/2-Clients MÜSSEN den Zieldomänennamen während des TLS-Handshakes angeben, es sei denn, es wird ein alternativer Mechanismus zur Angabe des Zielhosts bereitgestellt.

Bereitstellungen von HTTP/2, die auf TLS 1.3 [TLS13] oder höher angewiesen sind, SOLLTEN die TLS Application-Layer Protocol Negotiation (ALPN)-Erweiterung [TLS-ALPN] für Clients und Server unterstützen und verwenden. Dies identifiziert die Verwendung von HTTP/2 während des TLS-Handshakes ohne Verbrauch eines Roundtrips.

Während verbindungsspezifische Optionen nicht spezifisch für die Verwendung von HTTP sind, kann ein Server, der HTTP/2 verwendet, seine Präferenzen für Verbindungen übermitteln. TLS bietet Verschlüsselung, die die Fähigkeit von Lauschern minimieren kann, zu erfahren, welche Informationen zwischen einem Client und einem Server ausgetauscht werden. TLS bietet auch Integritätsschutz und stellt sicher, dass Informationen während der Übertragung nicht modifiziert werden, weder durch unbeabsichtigte Netzwerkverschmutzung noch durch aktive Angreifer.

Die Regeln in Abschnitt 7.4.1.4 von [TLS12] MÜSSEN befolgt werden, nachdem die Verwendung von HTTP/2 ausgehandelt wurde. Diese Regeln verwenden das Serverzertifikat zur Feststellung der Identität; Clientzertifikate können für diesen Zweck nicht verwendet werden. Die Überprüfungen der Zertifikatskette und der Zertifizierungsstelle (CA) sind ebenfalls erforderlich.

Wenn HTTP/2 über TLS 1.2 ausgehandelt wird, MUSS die TLS 1.2-Cipher-Suite-Blacklist (Abschnitt 9.2.2) angeboten werden.

Die Verwendung komprimierter TLS-Zertifikate wird nicht empfohlen; Zertifikate, die von Clients und Servern in HTTP/2 verwendet werden, SOLLTEN NICHT komprimiert werden, es sei denn, dies wird vom Client ausdrücklich angefordert.

9.2.1. TLS 1.2 Features (TLS 1.2-Funktionen)​

Dieser Abschnitt beschreibt Einschränkungen bei der Verwendung von TLS 1.2, die spezifisch für HTTP/2 sind. Da diese Einschränkungen hauptsächlich in TLS 1.3 adressiert werden, werden Implementierungen ermutigt, TLS 1.3 oder höher zu verwenden. Implementierungen, die nur TLS 1.2 verwenden, MÜSSEN die Anforderungen in diesem Abschnitt erfüllen.

9.2.1.1. TLS 1.2 Features for HTTP/2 Clients (TLS 1.2-Funktionen für HTTP/2-Clients)​

HTTP/2-Client-Implementierungen MÜSSEN das Senden von TLS Server Name Indication (SNI) [TLS-EXT] über das Erweiterungsfeld im Handshake unterstützen.

HTTP/2-Clients MÜSSEN TLS Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN] unterstützen.

9.2.1.2. TLS 1.2 Features for HTTP/2 Servers (TLS 1.2-Funktionen für HTTP/2-Server)​

Wenn der Server HTTP/2 durch andere Mittel als ALPN oder NPN aushandelt, MUSS der Server dem Client eine Gelegenheit bieten anzugeben, ob er bereit ist, HTTP/2 zu verwenden.

HTTP/2-Server SOLLTEN die extended master secret-Erweiterung [RFC7627] senden. Wenn der Client diese Erweiterung nicht unterstützt, DARF der Server KEINE zuvor etablierte Sitzung fortsetzen. Wenn das extended master secret ausgehandelt wird, KANN der Server eine zuvor etablierte Sitzung fortsetzen.

9.2.2. TLS 1.2 Cipher Suites (TLS 1.2-Cipher-Suites)​

Bereitstellungen von HTTP/2 über TLS 1.2 MÜSSEN TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] mit der elliptischen Kurve secp256r1 [RFC8422] unterstützen. Beachten Sie, dass Clients ihre Unterstützung für Kurven, die sie unterstützen, über die supported_groups-Erweiterung [TLS13] in der TLS ClientHello-Nachricht anzeigen, und Server zeigen die Unterstützung für eine Kurve an, indem sie eine der aufgelisteten Kurven auswählen, die die Erweiterung bietet.

Clients KÖNNEN die Unterstützung jeder Cipher-Suite auf TLS 1.2 ankündigen, die mit HTTP/2 verwendet wird. Die unten aufgeführten Cipher-Suites haben jedoch bekannte Eigenschaften schlechter Qualität und sind daher für die Verwendung in HTTP/2 über TLS 1.2 verboten. Diese Suites haben eine oder mehrere der folgenden Eigenschaften:

  • NULL-Cipher-Suites, die keine Verschlüsselung bieten.
  • Stream-Cipher-basierte Suites, deren Verwendung in TLS anfällig für Angriffe ist.
  • RC4-basierte Suites, die schwerwiegende Sicherheitsprobleme haben.
  • 3DES-basierte Suites, die weniger als 112 Bits tatsächlicher Sicherheit bieten.
  • CBC-Modus-Blockcipher-Suites, die in TLS empfindlich auf Angriffe reagieren, insbesondere in TLS 1.2 und früher.
  • RSA-Schlüsselaustausch-basierte Suites, die keine Forward Secrecy bieten.
  • Suites, die Diffie-Hellman-Parameter verwenden, die für die Verwendung mit TLS nicht empfohlen werden.
  • Suites, die SHA-1-Digests mit schlechter Unterstützung für AEAD-Algorithmen verwenden.

Eine vollständige Liste der verbotenen Cipher-Suites ist in Anhang A angegeben.

9.3. Connection Preface (Verbindungspräambel)​

In HTTP/2 ist jeder Endpunkt verpflichtet, eine Verbindungspräambel als endgültige Bestätigung des verwendeten Protokolls und zur Festlegung der Anfangseinstellungen für die HTTP/2-Verbindung zu senden. Client und Server senden jeweils eine unterschiedliche Verbindungspräambel.

Die Client-Verbindungspräambel beginnt mit einer Sequenz von 24 Oktetten, die in Hexadezimalnotation ist:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

Das heißt, die Verbindungspräambel beginnt mit der Zeichenfolge PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n. Diese Sequenz MUSS von einem SETTINGS-Frame (Abschnitt 6.5) gefolgt werden, der leer sein KANN. Der Client sendet die Client-Verbindungspräambel sofort nach Erhalt der Server-Verbindungspräambel.

| Hinweis: Die Client-Verbindungspräambel ist so gewählt, dass die Möglichkeit minimiert wird, | dass eine HTTP/2-Verbindung von Servern, die andere HTTP-Protokolle verarbeiten, als gültige | HTTP/1.1-Anfrage angesehen wird. Beachten Sie, dass keine HTTP/1.1-Anfrage vernünftigerweise | "PRI" als Methodentoken enthalten kann.

Die Server-Verbindungspräambel besteht aus einem möglicherweise leeren SETTINGS-Frame (Abschnitt 6.5), der der erste Frame sein MUSS, den der Server in der HTTP/2-Verbindung sendet.

Ein Client, der ein Upgrade durchführt und eine 101 (Switching Protocols)-Antwort erhalten hat, die HTTP/1.1 (oder früher) erfordert, MUSS die Client-Verbindungspräambel sofort senden.

Der Server empfängt die Client-Verbindungspräambel und der Client empfängt die Server-Verbindungspräambel. Der SETTINGS-Frame in der Verbindungspräambel MUSS bestätigt werden (siehe Abschnitt 6.5.3) als Teil der weiteren Verbindungsherstellung (siehe Abschnitt 3.4).

Um unnötige Latenz zu vermeiden, dürfen Clients zusätzliche Frames an den Server senden, unmittelbar nach dem Senden der Client-Verbindungspräambel, ohne auf den Empfang der Server-Verbindungspräambel zu warten. Es ist jedoch wichtig zu beachten, dass der SETTINGS-Frame der Server-Verbindungspräambel Parameter enthalten kann, die beachtet werden müssen, um mit dem Server zu kommunizieren. Nach Erhalt des SETTINGS-Frames SOLLTE der Client alle etablierten Parameter beachten. 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 eine ungültige Verbindungspräambel als Verbindungsfehler (Abschnitt 5.4.1) vom Typ PROTOCOL_ERROR behandeln. Ein GOAWAY-Frame (Abschnitt 6.8) KANN in diesem Fall weggelassen werden, da eine ungültige Präambel anzeigt, dass der Peer HTTP/2 nicht verwendet.

Kapitel 9 abgeschlossen!

References​

  • [TCP] RFC 793
  • [TLS13] RFC 8446
  • [TLS12] RFC 5246
  • [TLS-EXT] RFC 6066
  • [TLS-ALPN] RFC 7301
  • [TLSBCP] RFC 9325
  • [TLS-ECDHE] RFC 5289
  • [RFC8422] RFC 8422
  • [RFC7627] RFC 7627
  • [ALT-SVC] RFC 7838
  • [HTTP-CACHING] RFC 9111
Letztes Update am