5. HTTP-Datagramm-Nutzlastformat
- HTTP-Datagramm-Nutzlastformat
Wenn HTTP-Datagramme (siehe Abschnitt 2 von [HTTP-DGRAM]) UDP-Proxying-Anfragestreams zugeordnet sind, hat das HTTP Datagram Payload-Feld das in Abbildung 7 definierte Format, unter Verwendung der Notation aus Abschnitt 1.3 von [QUIC]. Beachten Sie, dass, wenn HTTP-Datagramme unter Verwendung von QUIC DATAGRAM-Frames [QUIC-DGRAM] kodiert werden, das unten definierte Context ID-Feld direkt auf das Quarter Stream ID-Feld folgt, das sich am Anfang der QUIC DATAGRAM-Frame-Nutzlast befindet; siehe Abschnitt 2.1 von [HTTP-DGRAM].
UDP Proxying HTTP Datagram Payload { Context ID (i), UDP Proxying Payload (..), }
Abbildung 7: UDP-Proxying-HTTP-Datagramm-Format
Context ID: Eine Ganzzahl variabler Länge (siehe Abschnitt 16 von [QUIC]), die den Wert der Context ID enthält. Wenn ein HTTP/3-Datagramm empfangen wird, das eine unbekannte Context ID trägt, MUSS der Empfänger dieses Datagramm entweder stillschweigend verwerfen oder es vorübergehend (in der Größenordnung einer Round-Trip-Zeit) puffern, während er auf die Registrierung der entsprechenden Context ID wartet. UDP Proxying Payload: Die Nutzlast des Datagramms, deren Semantik vom Wert des vorherigen Feldes abhängt. Beachten Sie, dass dieses Feld leer sein kann.
UDP-Pakete werden unter Verwendung von HTTP-Datagrammen kodiert, bei denen das Context ID-Feld auf Null gesetzt ist. Wenn das Context ID-Feld auf Null gesetzt ist, enthält das UDP Proxying Payload-Feld die unveränderte Nutzlast eines UDP-Pakets (in [UDP] als Datenoktette bezeichnet).
Aufgrund der Definition des UDP-Headers [UDP] ist es nicht möglich, UDP-Nutzlasten zu kodieren, die länger als 65527 Bytes sind. Daher DÜRFEN Endpunkte KEINE HTTP-Datagramme mit einem UDP Proxying Payload-Feld senden, das länger als 65527 ist, wenn Context ID Null verwendet wird. Ein Endpunkt, der ein HTTP-Datagramm unter Verwendung von Context ID Null empfängt, dessen UDP Proxying Payload-Feld länger als 65527 ist, MUSS den entsprechenden Stream abbrechen. Wenn ein UDP-Proxy weiß, dass er aufgrund seiner zugrunde liegenden Link-MTU nur UDP-Pakete einer bestimmten Länge senden kann, hat er keine andere Wahl, als eingehende HTTP-Datagramme unter Verwendung von Context ID Null zu verwerfen, deren UDP Proxying Payload-Feld länger als dieses Limit ist. Wenn das verworfene HTTP-Datagramm durch eine DATAGRAM-Kapsel transportiert wurde, SOLLTE der Empfänger diese Kapsel verwerfen, ohne den Kapselinhalt zu puffern.
Wenn ein UDP-Proxy ein HTTP-Datagramm empfängt, bevor er die entsprechende Anfrage empfangen hat, MUSS er dieses HTTP-Datagramm entweder stillschweigend verwerfen oder es vorübergehend (in der Größenordnung einer Round-Trip-Zeit) puffern, während er auf die entsprechende Anfrage wartet.
Beachten Sie, dass das Puffern von Datagrammen (entweder weil die Anfrage noch nicht empfangen wurde oder weil die Context ID noch nicht bekannt ist) Ressourcen verbraucht. Empfänger, die Datagramme puffern, SOLLTEN Pufferlimits anwenden, um das Risiko einer Ressourcenerschöpfung zu verringern. Empfänger können beispielsweise die Gesamtzahl der gepufferten Datagramme oder die kumulative Größe der gepufferten Datagramme auf Stream-, Kontext- oder Verbindungsbasis begrenzen.
Ein Client KANN optimistisch mit dem Senden von UDP-Paketen in HTTP-Datagrammen beginnen, bevor er die Antwort auf seine UDP-Proxying-Anfrage empfängt. Implementierer sollten jedoch beachten, dass solche geproxten Pakete möglicherweise nicht vom UDP-Proxy verarbeitet werden, wenn dieser auf die Anfrage mit einem Fehler antwortet oder wenn die geproxten Pakete vom UDP-Proxy vor der Anfrage empfangen werden und der UDP-Proxy sich entscheidet, sie nicht zu puffern.