3. Connection Setup and Management (Verbindungsaufbau und -verwaltung)
3.1. Discovering an HTTP/3 Endpoint (Erkennung eines HTTP/3-Endpunkts)
HTTP basiert auf dem Konzept einer autoritativen Antwort (Authoritative Response): eine Antwort, die als die am besten geeignete Antwort für diese Anfrage bestimmt wurde, gegeben den Zustand der Zielressource zum Zeitpunkt der Entstehung der Antwortnachricht durch (oder unter Anweisung von) dem Ursprungsserver (Origin Server), der innerhalb der Ziel-URI identifiziert wird. Die Lokalisierung eines autoritativen Servers für eine HTTP-URI wird in Abschnitt 4.3 von [HTTP] besprochen.
Das "https"-Schema verbindet Autorität mit dem Besitz eines Zertifikats, das der Client für den durch die Autoritätskomponente (Authority Component) der URI identifizierten Host als vertrauenswürdig erachtet. Nach Empfang eines Serverzertifikats im TLS-Handshake muss (MUST) der Client überprüfen, dass das Zertifikat eine akzeptable Übereinstimmung für den Ursprungsserver der URI ist, unter Verwendung des in Abschnitt 4.3.4 von [HTTP] beschriebenen Prozesses. Wenn das Zertifikat nicht in Bezug auf den Ursprungsserver der URI verifiziert werden kann, darf (MUST NOT) der Client den Server nicht als autoritativ für diesen Ursprung betrachten.
Ein Client kann (MAY) versuchen, auf eine Ressource mit einer "https"-URI zuzugreifen, indem er die Host-Kennung in eine IP-Adresse auflöst, eine QUIC-Verbindung zu dieser Adresse am angegebenen Port herstellt (einschließlich der Validierung des Serverzertifikats wie oben beschrieben) und eine HTTP/3-Anfragenachricht sendet, die auf die URI abzielt, über diese gesicherte Verbindung an den Server. Sofern kein anderer Mechanismus zur Auswahl von HTTP/3 verwendet wird, wird das Token "h3" in der ALPN-Erweiterung (Application-Layer Protocol Negotiation; siehe [RFC7301]) während des TLS-Handshakes verwendet.
Verbindungsprobleme (z. B. Blockieren von UDP) können zu einem Fehler beim Herstellen einer QUIC-Verbindung führen; Clients sollten (SHOULD) in diesem Fall versuchen, TCP-basierte Versionen von HTTP zu verwenden.
Server können (MAY) HTTP/3 auf jedem UDP-Port bereitstellen; eine Alternative Service Advertisement enthält immer einen expliziten Port, und URIs enthalten entweder einen expliziten Port oder einen mit dem Schema verbundenen Standardport.
3.1.1. HTTP Alternative Services (HTTP-Alternative Dienste)
Ein HTTP-Ursprung kann die Verfügbarkeit eines äquivalenten HTTP/3-Endpunkts über das Alt-Svc HTTP-Antwort-Header-Feld oder den HTTP/2 ALTSVC-Frame ([ALTSVC]) unter Verwendung des "h3" ALPN-Tokens ankündigen.
Beispielsweise könnte ein Ursprung in einer HTTP-Antwort angeben, dass HTTP/3 auf UDP-Port 50781 am selben Hostnamen verfügbar war, indem das folgende Header-Feld eingeschlossen wird:
Alt-Svc: h3=":50781"
Nach Erhalt eines Alt-Svc-Eintrags, der HTTP/3-Unterstützung anzeigt, kann (MAY) ein Client versuchen, eine QUIC-Verbindung zum angegebenen Host und Port herzustellen; wenn diese Verbindung erfolgreich ist, kann der Client HTTP-Anfragen unter Verwendung der in diesem Dokument beschriebenen Zuordnung senden.
3.1.2. Other Schemes (Andere Schemata)
Obwohl HTTP vom Transportprotokoll unabhängig ist, verbindet das "http"-Schema Autorität mit der Fähigkeit, TCP-Verbindungen am angegebenen Port des Hosts zu empfangen, der innerhalb der Autoritätskomponente identifiziert wird. Da HTTP/3 kein TCP verwendet, kann HTTP/3 nicht für den direkten Zugriff auf den autoritativen Server für eine durch eine "http"-URI identifizierte Ressource verwendet werden. Protokollerweiterungen wie [ALTSVC] erlauben es dem autoritativen Server jedoch, andere Dienste zu identifizieren, die ebenfalls autoritativ sind und möglicherweise über HTTP/3 erreichbar sind.
Bevor Anfragen für einen Ursprung gestellt werden, dessen Schema nicht "https" ist, muss (MUST) der Client sicherstellen, dass der Server bereit ist, dieses Schema zu bedienen. Für Ursprünge, deren Schema "http" ist, wird eine experimentelle Methode zur Erreichung dessen in [RFC8164] beschrieben. Andere Mechanismen könnten in Zukunft für verschiedene Schemata definiert werden.
3.2. Connection Establishment (Verbindungsherstellung)
HTTP/3 basiert auf QUIC Version 1 als zugrunde liegendem Transport. Die Verwendung anderer QUIC-Transportversionen mit HTTP/3 kann (MAY) durch zukünftige Spezifikationen definiert werden.
QUIC Version 1 verwendet TLS Version 1.3 oder höher als Handshake-Protokoll (Handshake Protocol). HTTP/3-Clients müssen (MUST) einen Mechanismus unterstützen, um den Zielhost während des TLS-Handshakes dem Server anzuzeigen. Wenn der Server durch einen Domainnamen ([DNS-TERMS]) identifiziert wird, müssen (MUST) Clients die Server Name Indication (SNI; [RFC6066]) TLS-Erweiterung senden, es sei denn, es wird ein alternativer Mechanismus zur Angabe des Zielhosts verwendet.
QUIC-Verbindungen werden wie in [QUIC-TRANSPORT] beschrieben hergestellt. Während der Verbindungsherstellung wird HTTP/3-Unterstützung durch Auswahl des ALPN-Tokens "h3" im TLS-Handshake angezeigt. Unterstützung für andere Anwendungsschichtprotokolle kann (MAY) im selben Handshake angeboten werden.
Während Optionen auf Verbindungsebene, die das Kern-QUIC-Protokoll betreffen, im anfänglichen Krypto-Handshake festgelegt werden, werden HTTP/3-spezifische Einstellungen im SETTINGS-Frame übermittelt. Nach der Herstellung der QUIC-Verbindung muss (MUST) von jedem Endpunkt ein SETTINGS-Frame als anfänglicher Frame seines jeweiligen HTTP-Kontrollstreams (HTTP Control Stream) gesendet werden.
3.3. Connection Reuse (Verbindungswiederverwendung)
HTTP/3-Verbindungen sind über mehrere Anfragen hinweg 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.
Sobald eine Verbindung zu einem Server-Endpunkt besteht, kann (MAY) diese Verbindung für Anfragen mit mehreren unterschiedlichen URI-Autoritätskomponenten wiederverwendet werden. Um eine bestehende Verbindung für einen neuen Ursprung zu verwenden, müssen (MUST) Clients das vom Server für den neuen Ursprungsserver präsentierte Zertifikat unter Verwendung des in Abschnitt 4.3.4 von [HTTP] beschriebenen Prozesses validieren. Dies impliziert, dass Clients das Serverzertifikat und alle zusätzlichen Informationen, die zur Verifizierung dieses Zertifikats benötigt werden, behalten müssen; Clients, die dies nicht tun, können die Verbindung nicht für zusätzliche Ursprünge wiederverwenden.
Wenn das Zertifikat aus irgendeinem Grund in Bezug auf den neuen Ursprung nicht akzeptabel ist, darf (MUST NOT) die Verbindung nicht wiederverwendet werden, und es sollte (SHOULD) eine neue Verbindung für den neuen Ursprung hergestellt werden. Wenn der Grund, warum das Zertifikat nicht verifiziert werden kann, auf andere bereits mit der Verbindung verbundene Ursprünge zutreffen könnte, sollte (SHOULD) der Client das Serverzertifikat für diese Ursprünge erneut validieren. Wenn beispielsweise die Validierung eines Zertifikats fehlschlägt, weil das Zertifikat abgelaufen oder widerrufen wurde, könnte dies verwendet werden, um alle anderen Ursprünge zu invalidieren, für die dieses Zertifikat zur Feststellung der Autorität verwendet wurde.
Clients sollten (SHOULD NOT) nicht mehr als eine HTTP/3-Verbindung zu einer gegebenen IP-Adresse und einem UDP-Port öffnen, wobei die IP-Adresse und der Port von einer URI, einem ausgewählten alternativen Dienst ([ALTSVC]), einem konfigurierten Proxy oder der Namensauflösung eines dieser Elemente abgeleitet werden können. Ein Client kann (MAY) mehrere HTTP/3-Verbindungen zur selben IP-Adresse und zum selben UDP-Port unter Verwendung unterschiedlicher Transport- oder TLS-Konfigurationen öffnen, sollte (SHOULD) jedoch vermeiden, mehrere Verbindungen mit derselben Konfiguration zu erstellen.
Server werden ermutigt, offene HTTP/3-Verbindungen so lange wie möglich aufrechtzuerhalten, sind aber berechtigt, inaktive Verbindungen (Idle Connections) bei Bedarf zu beenden. Wenn einer der Endpunkte wählt, die HTTP/3-Verbindung zu schließen, sollte (SHOULD) der beendende Endpunkt zuerst einen GOAWAY-Frame (Abschnitt 5.2) 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.
Ein Server, der nicht möchte, dass Clients HTTP/3-Verbindungen für einen bestimmten Ursprung wiederverwenden, kann anzeigen, dass er für eine Anfrage nicht autoritativ ist, indem er einen 421-Statuscode (Misdirected Request, Fehlgeleitete Anfrage) als Antwort auf die Anfrage sendet; siehe Abschnitt 7.4 von [HTTP].