Zum Hauptinhalt springen

5. Verbindungen (Connections)

5. Verbindungen​

Eine QUIC-Verbindung ist ein gemeinsamer Zustand zwischen einem Client und einem Server.

Jede Verbindung beginnt mit einer Handshake-Phase, in der die beiden Endpunkte mithilfe des kryptografischen Handshake-Protokolls [QUIC-TLS] gemeinsame Schlüssel einrichten und das Anwendungsprotokoll aushandeln. Der Handshake (Abschnitt 7) bestätigt, dass beide Endpunkte bereit sind zu kommunizieren (Abschnitt 8.1) und legt Parameter für die Verbindung fest (Abschnitt 7.4).

Das Anwendungsprotokoll kann die Verbindung während der Handshake-Phase verwenden, jedoch mit einigen Einschränkungen. 0-RTT ermöglicht es dem Client, Anwendungsdaten zu senden, bevor er eine Antwort vom Server erhält. 0-RTT bietet jedoch keinen Schutz gegen Replay-Angriffe; siehe Abschnitt 9.2 von [QUIC-TLS]. Der Server kann auch Anwendungsdaten an den Client senden, bevor er die endgültigen kryptografischen Handshake-Nachrichten erhält, die es ihm ermöglichen, die Identität und Aktivität des Clients zu bestätigen. Diese Fähigkeiten ermöglichen es Anwendungsprotokollen, Optionen bereitzustellen, die einige Sicherheitsgarantien gegen reduzierte Latenz eintauschen.

Die Verwendung von Verbindungs-IDs (Abschnitt 5.1) ermöglicht es einer Verbindung, zu einem neuen Netzwerkpfad zu migrieren, sowohl als direkte Wahl eines Endpunkts als auch wenn sie durch Middlebox-Änderungen erzwungen wird. Abschnitt 9 beschreibt Mitigationen für Sicherheits- und Datenschutzprobleme im Zusammenhang mit der Migration.

Für Verbindungen, die nicht mehr benötigt oder gewünscht werden, haben Client und Server mehrere Möglichkeiten, die Verbindung zu beenden, wie in Abschnitt 10 beschrieben.

5.1 Verbindungs-ID (Connection ID)​

Jede Verbindung besitzt eine Reihe von Verbindungsidentifikatoren oder Verbindungs-IDs, von denen jede die Verbindung identifizieren kann. Verbindungs-IDs werden von Endpunkten unabhängig ausgewählt; jeder Endpunkt wählt die Verbindungs-ID aus, die sein Peer verwendet.

Die Hauptfunktion einer Verbindungs-ID besteht darin, sicherzustellen, dass Adressierungsänderungen auf niedrigeren Protokollebenen (UDP, IP) nicht dazu führen, dass Pakete einer QUIC-Verbindung an den falschen Endpunkt zugestellt werden. Jeder Endpunkt wählt Verbindungs-IDs mithilfe einer implementierungsspezifischen (möglicherweise bereitstellungsspezifischen) Methode aus, die es ermöglicht, dass Pakete mit dieser Verbindungs-ID zum Endpunkt geroutet und beim Empfang vom Endpunkt identifiziert werden.

Mehrere Verbindungs-IDs werden verwendet, damit Endpunkte Pakete senden können, die von einem Beobachter ohne Zusammenarbeit mit dem Endpunkt nicht als zur selben Verbindung gehörig identifiziert werden können; siehe Abschnitt 9.5.

Verbindungs-IDs dürfen keine Informationen enthalten, die ein externer Beobachter (d. h. ein Beobachter ohne Zusammenarbeit mit dem Emittenten) verwenden könnte, um sie mit anderen Verbindungs-IDs derselben Verbindung zu korrelieren. Als einfaches Beispiel bedeutet dies, dass dieselbe Verbindungs-ID nicht mehrmals auf derselben Verbindung ausgegeben werden darf.

Pakete mit langem Header enthalten die Felder Quell-Verbindungs-ID (Source Connection ID) und Ziel-Verbindungs-ID (Destination Connection ID). Diese Felder werden verwendet, um Verbindungs-IDs für neue Verbindungen einzurichten; siehe Abschnitt 7.2 für Details.

Pakete mit kurzem Header (Abschnitt 17.3) enthalten nur die Ziel-Verbindungs-ID und lassen die explizite Länge aus. Die Länge des Felds Ziel-Verbindungs-ID sollte dem Endpunkt bekannt sein. Endpunkte, die einen Load Balancer verwenden, der basierend auf der Verbindungs-ID routet, können sich mit dem Load Balancer auf eine feste Länge für Verbindungs-IDs einigen oder auf ein Codierungsschema. Ein fester Teil kann eine explizite Länge codieren, wodurch die Länge der gesamten Verbindungs-ID variieren kann und dennoch vom Load Balancer verwendet werden kann.

Versionsverhandlungspakete (Abschnitt 17.2.1) geben die vom Client ausgewählte Verbindungs-ID zurück, sowohl um das korrekte Routing zum Client zu gewährleisten als auch um zu demonstrieren, dass das Paket eine Antwort auf ein vom Client gesendetes Paket ist.

Eine Verbindungs-ID mit der Länge Null kann verwendet werden, wenn die Verbindungs-ID nicht zum Routing zum korrekten Endpunkt benötigt wird. Bei Verwendung einer Verbindungs-ID mit der Länge Null führt das Multiplexen von Verbindungen auf derselben lokalen IP-Adresse und demselben Port jedoch bei Vorhandensein von Peer-Verbindungsmigration, NAT-Rebinding und Client-Port-Wiederverwendung zu Fehlern. Ein Endpunkt darf dieselbe IP-Adresse und denselben Port nicht für mehrere gleichzeitige Verbindungen mit einer Verbindungs-ID der Länge Null verwenden, es sei denn, er ist sicher, dass diese Protokollfunktionen nicht verwendet werden.

Wenn ein Endpunkt eine Verbindungs-ID mit nicht-null Länge verwendet, muss es sicherstellen, dass sein Peer genügend Verbindungs-IDs zur Auswahl hat, die für Pakete verwendet werden, die an den Endpunkt gesendet werden. Diese Verbindungs-IDs werden vom Endpunkt mithilfe von NEW_CONNECTION_ID-Frames (Abschnitt 19.15) bereitgestellt.

5.1.1 Ausgabe von Verbindungs-IDs (Issuing Connection IDs)​

Jede Verbindungs-ID hat eine zugeordnete Sequenznummer, um zu helfen, zu erkennen, wann NEW_CONNECTION_ID- oder RETIRE_CONNECTION_ID-Frames auf denselben Wert verweisen. Die anfängliche Verbindungs-ID, die von einem Endpunkt ausgegeben wird, wird während des Handshakes im Feld Quell-Verbindungs-ID des langen Paket-Headers (Abschnitt 17.2) gesendet. Die Sequenznummer der anfänglichen Verbindungs-ID ist 0. Wenn der Transportparameter preferred_address gesendet wird, hat die bereitgestellte Verbindungs-ID die Sequenznummer 1.

Zusätzliche Verbindungs-IDs werden dem Peer mithilfe von NEW_CONNECTION_ID-Frames (Abschnitt 19.15) mitgeteilt. Die Sequenznummer auf jeder neu ausgegebenen Verbindungs-ID muss um 1 erhöht werden. Die Verbindungs-ID, die der Client für das erste Feld Ziel-Verbindungs-ID auswählt, das er sendet, und alle Verbindungs-IDs, die von einem Retry-Paket bereitgestellt werden, erhalten keine Sequenznummern zugewiesen.

Wenn ein Endpunkt eine Verbindungs-ID ausgibt, muss es Pakete akzeptieren, die diese Verbindungs-ID tragen, während der Verbindung oder bis sein Peer die Verbindungs-ID über einen RETIRE_CONNECTION_ID-Frame (Abschnitt 19.16) ungültig macht. Ausgegebene und nicht zurückgezogene Verbindungs-IDs gelten als aktiv; jede aktive Verbindungs-ID ist jederzeit und in jedem Pakettyp für die aktuelle Verbindung gültig. Dies schließt die Verbindungs-ID ein, die der Server über den Transportparameter preferred_address ausgibt.

Ein Endpunkt sollte sicherstellen, dass sein Peer eine ausreichende Anzahl verfügbarer und nicht verwendeter Verbindungs-IDs hat. Endpunkte geben die Anzahl der aktiven Verbindungs-IDs an, die sie zu pflegen bereit sind, mithilfe des Transportparameters active_connection_id_limit. Ein Endpunkt darf nicht mehr Verbindungs-IDs bereitstellen als das Limit des Peers. Ein Endpunkt kann Verbindungs-IDs senden, die vorübergehend das Limit des Peers überschreiten, wenn der NEW_CONNECTION_ID-Frame auch den Rückzug eines überschüssigen Teils erfordert, indem ein ausreichend großer Wert im Feld Retire Prior To enthalten ist.

Ein NEW_CONNECTION_ID-Frame kann dazu führen, dass der Endpunkt basierend auf dem Wert des Feldes Retire Prior To einige aktive Verbindungs-IDs hinzufügt und andere aktive Verbindungs-IDs zurückzieht. Nach der Verarbeitung eines NEW_CONNECTION_ID-Frames und dem Hinzufügen und Zurückziehen aktiver Verbindungs-IDs muss der Endpunkt die Verbindung mit einem Fehler vom Typ CONNECTION_ID_LIMIT_ERROR schließen, wenn die Anzahl der aktiven Verbindungs-IDs den im Transportparameter active_connection_id_limit angekündigten Wert überschreitet.

Wenn der Peer eine Verbindungs-ID zurückzieht, sollte der Endpunkt eine neue Verbindungs-ID bereitstellen. Wenn der Endpunkt weniger Verbindungs-IDs als das active_connection_id_limit des Peers bereitgestellt hat, kann er eine neue Verbindungs-ID bereitstellen, wenn er ein Paket mit einer zuvor nicht verwendeten Verbindungs-ID erhält. Ein Endpunkt kann die Gesamtzahl der pro Verbindung ausgegebenen Verbindungs-IDs begrenzen, um das Risiko einer Erschöpfung der Verbindungs-IDs zu vermeiden; siehe Abschnitt 10.3.2. Ein Endpunkt kann auch die Ausgabe von Verbindungs-IDs einschränken, um die Menge an Zustand pro Pfad zu reduzieren, die es pflegt, wie z. B. den Pfadvalidierungszustand, da sein Peer möglicherweise über so viele Pfade mit ihm interagiert, wie es ausgegebene Verbindungs-IDs gibt.

Ein Endpunkt, das eine Migration initiiert und eine Verbindungs-ID mit nicht-null Länge benötigt, sollte sicherstellen, dass der Pool verfügbarer Verbindungs-IDs für den Peer es dem Peer ermöglicht, bei der Migration eine neue Verbindungs-ID zu verwenden, da der Peer nicht in der Lage sein wird zu antworten, wenn der Pool erschöpft ist.

Ein Endpunkt, das während des Handshakes eine Verbindungs-ID der Länge Null auswählt, kann keine neuen Verbindungs-IDs ausgeben. Ein Feld Ziel-Verbindungs-ID der Länge Null wird in allen Paketen verwendet, die über einen beliebigen Netzwerkpfad an einen solchen Endpunkt gesendet werden.

5.1.2 [Verbrauch und Rückzug von Verbindungs-IDs (Consuming and Retiring Connection IDs)​

Ein Endpunkt kann die Verbindungs-ID, die es für seinen Peer verwendet, jederzeit während der Verbindung zu einer anderen verfügbaren Verbindungs-ID wechseln. Ein Endpunkt verbraucht Verbindungs-IDs als Reaktion auf einen migrierenden Peer; siehe Abschnitt 9.5 für weitere Details.

Ein Endpunkt pflegt eine Menge von Verbindungs-IDs, die es von seinem Peer erhalten hat, von denen es beim Senden von Paketen eine beliebige verwenden kann. Wenn ein Endpunkt eine Verbindungs-ID aus der Verwendung entfernen möchte, sendet es einen RETIRE_CONNECTION_ID-Frame an seinen Peer. Das Senden eines RETIRE_CONNECTION_ID-Frames zeigt an, dass die Verbindungs-ID nicht mehr verwendet wird, und fordert den Peer auf, sie durch eine neue Verbindungs-ID mit einem NEW_CONNECTION_ID-Frame zu ersetzen.

Wie in Abschnitt 9.5 beschrieben, beschränken Endpunkte die Verwendung einer Verbindungs-ID auf Pakete, die von einer einzelnen lokalen Adresse an eine einzelne Zieladresse gesendet werden. Ein Endpunkt sollte eine Verbindungs-ID zurückziehen, wenn es die lokale oder Zieladresse, für die die Verbindungs-ID verwendet wurde, nicht mehr aktiv verwendet.

Ein Endpunkt muss möglicherweise unter bestimmten Umständen aufhören, zuvor ausgegebene Verbindungs-IDs zu akzeptieren. Ein solcher Endpunkt kann seinen Peer dazu veranlassen, Verbindungs-IDs zurückzuziehen, indem er einen NEW_CONNECTION_ID-Frame mit einem erhöhten Feld Retire Prior To sendet. Der Endpunkt sollte weiterhin zuvor ausgegebene Verbindungs-IDs akzeptieren, bis sie vom Peer zurückgezogen werden. Wenn der Endpunkt die angegebenen Verbindungs-IDs nicht mehr verarbeiten kann, kann er die Verbindung schließen.

Nach Erhalt eines erhöhten Feldes Retire Prior To muss der Peer aufhören, die entsprechenden Verbindungs-IDs zu verwenden, und sie mithilfe von RETIRE_CONNECTION_ID-Frames zurückziehen, bevor die neu bereitgestellten Verbindungs-IDs zur Menge der aktiven Verbindungs-IDs hinzugefügt werden. Diese Reihenfolge ermöglicht es einem Endpunkt, alle aktiven Verbindungs-IDs zu ersetzen, ohne die Möglichkeit, dass der Peer keine verfügbare Verbindungs-ID hat, und ohne das vom Peer im Transportparameter active_connection_id_limit festgelegte Limit zu überschreiten; siehe Abschnitt 18.2. Das Versäumnis, die Verwendung von Verbindungs-IDs bei Aufforderung einzustellen, kann zu einem Verbindungsfehler führen, da der ausgebende Endpunkt möglicherweise nicht in der Lage ist, die Verbindungs-ID in der aktiven Verbindung weiterhin zu verwenden.

Ein Endpunkt sollte die Anzahl der Verbindungs-IDs begrenzen, die es lokal zurückgezogen hat, für die jedoch noch keine RETIRE_CONNECTION_ID-Frames bestätigt wurden. Ein Endpunkt sollte das Senden und Verfolgen von mindestens dem Doppelten des Wertes des Transportparameters active_connection_id_limit an RETIRE_CONNECTION_ID-Frames erlauben. Ein Endpunkt darf eine Verbindungs-ID nicht vergessen, ohne sie zurückzuziehen, kann jedoch wählen, Verbindungs-IDs, die über diese Grenze hinaus zurückgezogen werden müssen, als Verbindungsfehler vom Typ CONNECTION_ID_LIMIT_ERROR zu behandeln.

Ein Endpunkt sollte keine Updates des Feldes Retire Prior To ausgeben, bevor es RETIRE_CONNECTION_ID-Frames erhalten hat, die alle durch den vorherigen Wert von Retire Prior To angezeigten Verbindungs-IDs zurückziehen.

5.2 Zuordnung von Paketen zu Verbindungen (Matching Packets to Connections)​

Eingehende Pakete werden beim Empfang klassifiziert. Pakete können einer bestehenden Verbindung zugeordnet werden oder, im Fall eines Servers, eine neue Verbindung erstellen.

Ein Endpunkt versucht, ein Paket einer bestehenden Verbindung zuzuordnen. Wenn das Paket eine Ziel-Verbindungs-ID mit nicht-null Länge hat, die einer bestehenden Verbindung entspricht, verarbeitet QUIC das Paket entsprechend. Beachten Sie, dass mehrere Verbindungs-IDs einer Verbindung zugeordnet sein können; siehe Abschnitt 5.1.

Wenn die Ziel-Verbindungs-ID die Länge Null hat und die Adressierungsinformationen im Paket mit den Adressierungsinformationen übereinstimmen, die der Endpunkt zur Identifizierung einer Verbindung mit einer Verbindungs-ID der Länge Null verwendet, verarbeitet QUIC das Paket als Teil dieser Verbindung. Ein Endpunkt kann nur die Ziel-IP und den Port oder sowohl Quell- als auch Zieladressen zur Identifizierung verwenden, obwohl dies die Verbindung wie in Abschnitt 5.1 beschrieben fragil macht.

Ein Endpunkt kann ein zustandsloses Reset (Abschnitt 10.3) für jedes Paket senden, das keiner bestehenden Verbindung zugeordnet werden kann. Ein zustandsloses Reset ermöglicht es dem Peer, schneller zu erkennen, wann eine Verbindung unbrauchbar wird.

Pakete, die einer bestehenden Verbindung entsprechen, werden verworfen, wenn sie mit dem Zustand dieser Verbindung nicht kompatibel sind. Pakete werden beispielsweise verworfen, wenn das Paket eine andere Protokollversion als die der Verbindung anzeigt oder wenn das Entfernen des Paketschutzes fehlschlägt, sobald die erwarteten Schlüssel verfügbar sind.

Ungültige Pakete ohne starken Integritätsschutz (wie Initial, Retry oder Version Negotiation) können verworfen werden. Wenn der Endpunkt einen Verbindungsfehler beim Verarbeiten des Inhalts dieser Pakete generiert, bevor ein Fehler entdeckt wird, oder alle während dieser Verarbeitung vorgenommenen Änderungen vollständig wiederherstellt, muss der Verbindungsfehler generiert werden.

5.2.1 [Client-Paketbehandlung (Client Packet Handling)​

Gültige Pakete, die an den Client gesendet werden, enthalten immer eine Ziel-Verbindungs-ID, die einem vom Client gewählten Wert entspricht. Clients, die sich für den Empfang einer Verbindungs-ID der Länge Null entscheiden, können die lokale Adresse und den Port verwenden, um eine Verbindung zu identifizieren. Pakete, die keiner bestehenden Verbindung entsprechen, basierend auf der Ziel-Verbindungs-ID oder (wenn dieser Wert die Länge Null hat) der lokalen IP-Adresse und dem Port, werden verworfen.

Aufgrund von Paketumsortierung oder -verlust können Clients Verbindungspakete erhalten, die mit Schlüsseln verschlüsselt sind, die sie noch nicht berechnet haben. Clients können diese Pakete verwerfen oder sie puffern in der Hoffnung, dass spätere Pakete es ihnen ermöglichen, die Schlüssel zu berechnen.

Wenn der Client ein Paket erhält, das eine andere Version als die ursprünglich ausgewählte verwendet, muss er das Paket verwerfen.

5.2.2 [Server-Paketbehandlung (Server Packet Handling)​

Wenn der Server ein Paket erhält, das eine nicht unterstützte Version anzeigt, und wenn das Paket groß genug ist, um eine neue Verbindung für eine unterstützte Version zu initiieren, sollte der Server ein Versionsverhandlungspaket senden, wie in Abschnitt 6.1 beschrieben. Der Server kann die Anzahl der Pakete begrenzen, auf die er mit einem Versionsverhandlungspaket antwortet. Der Server muss kleinere Pakete verwerfen, die eine nicht unterstützte Version angeben.

Das erste Paket einer nicht unterstützten Version kann unterschiedliche Semantiken und Codierungen für versionsspezifische Felder verwenden. Insbesondere können verschiedene Versionen unterschiedliche Paketschutzschlüssel verwenden. Ein Server, der eine bestimmte Version nicht unterstützt, kann wahrscheinlich die Nutzlast des Pakets nicht entschlüsseln oder das Ergebnis korrekt interpretieren. Server sollten mit einem Versionsverhandlungspaket antworten, vorausgesetzt, das Datagramm ist ausreichend groß.

Pakete mit einer unterstützten Version oder ohne Versionsfeld werden mithilfe der Verbindungs-ID oder, für Pakete mit einer Verbindungs-ID der Länge Null, der lokalen Adresse und des Ports einer Verbindung zugeordnet. Diese Pakete werden mit der ausgewählten Verbindung verarbeitet; andernfalls fährt der Server wie unten beschrieben fort.

Wenn das Paket ein vollständig konformes Initial-Paket ist, fährt der Server mit dem Handshake fort (Abschnitt 7). Dies verpflichtet den Server auf die vom Client gewählte Version.

Wenn der Server die Annahme einer neuen Verbindung ablehnt, sollte er ein Initial-Paket senden, das einen CONNECTION_CLOSE-Frame mit dem Fehlercode CONNECTION_REFUSED enthält.

Wenn das Paket ein 0-RTT-Paket ist, kann der Server eine begrenzte Anzahl dieser Pakete puffern in Erwartung eines verspätet eintreffenden Initial-Pakets. Clients können keine Handshake-Pakete senden, bevor sie eine Antwort vom Server erhalten, daher sollte der Server solche Pakete ignorieren.

Der Server muss eingehende Pakete in allen anderen Fällen verwerfen.

5.2.3 Überlegungen für einfache Load Balancer (Considerations for Simple Load Balancers)​

Serverbereitstellungen können den Load Balancing zwischen Servern nur unter Verwendung von Quell- und Ziel-IP-Adressen und Ports durchführen. Änderungen der Client-IP-Adresse oder des Ports können dazu führen, dass Pakete an den falschen Server weitergeleitet werden. Solche Serverbereitstellungen können eine der folgenden Methoden verwenden, um die Verbindungskontinuität aufrechtzuerhalten, wenn sich die Client-Adresse ändert.

  • Server können einen Out-of-Band-Mechanismus verwenden, um Pakete basierend auf der Verbindungs-ID an den richtigen Server weiterzuleiten.

  • Wenn Server eine dedizierte Server-IP-Adresse oder einen dedizierten Port verwenden können (anders als die Adresse oder der Port, zu dem der Client ursprünglich eine Verbindung hergestellt hat), können sie den Transportparameter preferred_address verwenden, um den Client aufzufordern, die Verbindung zu dieser dedizierten Adresse zu verschieben. Beachten Sie, dass Clients sich entscheiden können, die bevorzugte Adresse nicht zu verwenden.

Server in Bereitstellungen, die keine Lösung implementieren, um die Verbindungskontinuität aufrechtzuerhalten, wenn sich die Client-Adresse ändert, sollten den Transportparameter disable_active_migration verwenden, um anzuzeigen, dass Migration nicht unterstützt wird. Der Transportparameter disable_active_migration verbietet keine Client-Verbindungsmigration, nachdem auf den Transportparameter preferred_address reagiert wurde.

Serverbereitstellungen, die diese einfache Form des Load Balancing verwenden, müssen die Erstellung eines zustandslosen Reset-Orakels vermeiden; siehe Abschnitt 21.11.

5.3 [Operationen auf Verbindungen (Operations on Connections)​

Dieses Dokument definiert keine API für QUIC; stattdessen definiert es eine Reihe von Funktionen einer QUIC-Verbindung, auf die sich Anwendungsprotokolle verlassen können. Anwendungsprotokolle können davon ausgehen, dass die Implementierung von QUIC eine Schnittstelle bereitstellt, die die in diesem Abschnitt beschriebenen Operationen enthält. Implementierungen, die für ein bestimmtes Anwendungsprotokoll entwickelt wurden, können nur die von diesem Protokoll verwendeten Operationen bereitstellen.

Bei der Implementierung der Client-Rolle kann ein Anwendungsprotokoll:

  • Eine Verbindung öffnen, was den in Abschnitt 7 beschriebenen Austausch startet;
  • Early Data aktivieren (falls verfügbar);
  • Benachrichtigt werden, dass Early Data vom Server akzeptiert oder abgelehnt wurde.

Bei der Implementierung der Server-Rolle kann ein Anwendungsprotokoll:

  • Auf eingehende Verbindungen lauschen, was den in Abschnitt 7 beschriebenen Austausch vorbereitet;
  • Falls Early Data unterstützt wird, anwendungsgesteuerte Daten in das TLS-Wiederaufnahmeticket einbetten, das an den Client gesendet wird;
  • Falls Early Data unterstützt wird, anwendungsgesteuerte Daten aus dem Wiederaufnahmeticket des Clients abrufen und Early Data basierend auf diesen Informationen akzeptieren oder ablehnen.

In beiden Rollen kann ein Anwendungsprotokoll:

  • Einen Mindestwert für die anfängliche Anzahl erlaubter Streams jedes Typs konfigurieren, wie in Transportparametern kommuniziert (Abschnitt 7.4);
  • Die Ressourcenzuweisung des Empfangspuffers steuern, indem Flusskontrollgrenzen für Streams und die Verbindung festgelegt werden;
  • Identifizieren, ob der Handshake erfolgreich abgeschlossen wurde oder noch läuft;
  • Verhindern, dass die Verbindung stillschweigend geschlossen wird, indem PING-Frames generiert werden (Abschnitt 19.2) oder der Transport aufgefordert wird, zusätzliche Frames zu senden, bevor das Leerlaufzeitlimit abläuft (Abschnitt 10.1);
  • Sofort die Verbindung schließen (Abschnitt 10.2).

Vorheriges Kapitel: 4. Flusskontrolle (Flow Control)
Nächstes Kapitel: 6. Versionsverhandlung (Version Negotiation)

Letztes Update am