QGrpcHttp2Channel Class

Ausführliche Beschreibung

Die Klasse `QGrpcHttp2Channel` implementiert ` QAbstractGrpcChannel` und ermöglicht so gRPC™ die Kommunikation über HTTP/2-Framing ermöglicht.

HTTP/2 bietet gegenüber seinem Vorgänger HTTP/1.1 mehrere Vorteile, wodurch sich QGrpcHttp2Channel gut für leistungsstarke Echtzeitanwendungen eignet, die eine effiziente Kommunikation erfordern, ohne dabei Abstriche bei Sicherheit oder Zuverlässigkeit zu machen, indem multiplexierte TCP-Verbindungen genutzt werden.

Der Kanal kann mit SSL-Unterstützung, einem benutzerdefinierten ` serializationFormat` oder anderen Optionen angepasst werden, indem er mit einem ` QGrpcChannelOptions ` erstellt wird, der die erforderlichen Anpassungen enthält.

Transportschema

Die Implementierung von `QGrpcHttp2Channel` bevorzugt je nach den angegebenen ` hostUri`, ` scheme ` und Optionen unterschiedliche Transportmethoden. Es gelten die folgenden Kriterien:

Content-Type

Der Content-Type in „ gRPC “ über HTTP/2 bestimmt das Format der Nachrichtenserialisierung. Er muss mit „ application/grpc “ beginnen und kann ein Suffix enthalten. Das Format folgt diesem Schema:

"content-type": "application/grpc" [("+proto" / "+json" / {custom})]

Beispiel:

• application/grpc+proto gibt die Protobuf-Kodierung an.
• application/grpc+json spezifiziert die JSON-Kodierung.

Das Serialisierungsformat kann entweder durch Angabe des „ content-type “ in den Metadaten oder durch direkte Festlegung von „ serializationFormat “ konfiguriert werden. Standardmäßig wird der Content-Type „ application/grpc “ verwendet.

So konfigurieren Sie QGrpcHttp2Channel mit dem JSON-Serialisierungsformat unter Verwendung der Metadaten „ content-type “:

auto jsonChannel = std::make_shared<QGrpcHttp2Channel>(
    QUrl("http://localhost:50051"_L1),
    QGrpcChannelOptions().setMetadata({
        { "content-type"_ba, "application/grpc+json"_ba },
    })
);

Bei einem benutzerdefinierten Serializer und „ content-type “ können Sie das Serialisierungsformat direkt festlegen:

class DummySerializer : public QAbstractProtobufSerializer
{
    ...
};
QGrpcSerializationFormat dummyFormat("dummy", std::make_shared<DummySerializer>());

auto dummyChannel = std::make_shared<QGrpcHttp2Channel>(
    QUrl("http://localhost:50051"_L1),
    QGrpcChannelOptions().setSerializationFormat(dummyFormat)
);

Dabei wird „ DummySerializer “ zum Kodieren und Dekodieren von Nachrichten mit dem Suffix „ dummy “ verwendet. Bei der Übertragung über HTTP/2 ergibt sich daraus der Content-Type „ application/grpc+dummy “.

Reservierte Metadaten-Schlüssel

Metadaten werden als HTTP/2-Header übertragen: Schlüssel sind ASCII-Zeichenfolgen, bei denen Groß- und Kleinschreibung keine Rolle spielt; Werte können ASCII-Zeichenfolgen oder Binärdaten sein. Die folgenden Schlüssel sind von HTTP/2 oder dem gRPC -Protokoll reserviert und werden beim Aufbau der Anfrage aus den Benutzermetadaten entfernt:

• HTTP/2-Pseudo-Header (jeder Schlüssel, der mit „ : “ beginnt).
• Jeder Schlüssel mit dem Präfix „ grpc- “ oder „ qtgrpc- “.
• te, content-type, user-agent.

Ein vom Benutzer bereitgestelltes „ content-type “ wird bei der Kanalerstellung weiterhin zur automatischen Erkennung des Serializers herangezogen (siehe Content-Type); es wird jedoch nicht als „Custom-Metadata“-Eintrag weitergeleitet.

Weitere Informationen zu HTTP/2-Headern finden Sie in RFC 7540, Abschnitt 8.1.2.

Empfangsfenster

Die HTTP/2-Flusssteuerung begrenzt die Datenmenge, die ein Sender übertragen darf, bevor der Empfänger diese bestätigt. Der Kanal teilt dem Server zwei solcher Grenzwerte mit, die Empfangsfenster:

• Das Stream-Fenster begrenzt die nicht bestätigten Daten eines einzelnen RPC.
• Das Verbindungsfenster begrenzt die Gesamtmenge der noch nicht bestätigten Daten aller RPCs, die sich eine Verbindung teilen.

Ein Fenster begrenzt die Datenmenge, die sich gerade im Transfer befindet, nicht die Größe einer Übertragung. Da Bestätigungen einen Netzwerk-Roundtrip erfordern, begrenzt es auch den Durchsatz:

maximum throughput = window / round-trip time

Beide Fenster werden in Byte über Umgebungsvariablen konfiguriert:

• QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE für die Stream-Fenster; (Standardwert: 4 MiB)
• QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE für das Verbindungsfenster; (Standardwert ist das Vierfache des Stream-Fensters, 16 MiB)

Wird nur „ QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE “ festgelegt, wird das Verbindungsfenster automatisch auf das Vierfache des Stream-Fensters skaliert. Setzen Sie „ QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE “ explizit, um ein anderes Verhältnis zu verwenden.

Die Standardwerte führen zu einer Überlastung lokaler Netzwerke und der meisten Internetverbindungen. Bei schnellen Verbindungen mit langen Round-Trip-Zeiten reichen sie nicht aus. Beispiel: Eine Anwendung empfängt große Nachrichten von einem entfernten Server:

link: 1 Gbit/s (125 MB/s), 100 ms round-trip time

Der Server sendet ein Stream-Fenster mit Daten und wartet dann eine Hin- und Rücklaufzeit auf die Bestätigung. Mit dem Standardfenster überträgt er höchstens 4 MiB alle 100 ms:

4 MiB / 0.1 s = 42 MB/s, 34% of the 125 MB/s the link carries

Um die Verbindung auszulasten, muss das Fenster die gesamte Datenmenge fassen, die die Verbindung während einer Hin- und Rückreise überträgt – das Bandbreiten-Verzögerungs-Produkt (BDP) der Verbindung:

BDP = 125 MB/s x 0.1 s = 12.5 MB

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=12500000
12.5 MB / 0.1 s = 125 MB/s, the link is saturated

Parallele RPCs teilen sich ein einziges Empfangsfenster der Verbindung. Solange jeder Stream kontinuierlich gelesen wird, bleibt die Gesamtmenge der in der Übertragung befindlichen Daten durch das BDP begrenzt. Wird ein Stream jedoch nicht gelesen, beanspruchen seine gepufferten Daten einen Teil des gemeinsamen Verbindungsfensters und können andere Streams blockieren. Eine gute Faustregel ist es, das Verbindungsfenster auf die Summe aller gleichzeitig aktiven Stream-Fenster zu dimensionieren. Für acht parallele Übertragungen auf der oben genannten Verbindung gilt:

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=12500000       (12.5 MB = BDP)
QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE=100000000  (8 x 12.5 MB)

Jedes RPC kann die vollen 125 MB/s nutzen, wenn es die einzige aktive Übertragung ist. Bei acht gleichzeitigen RPCs teilen sie sich die Verbindung mit jeweils etwa 15 MB/s. Im schlimmsten Fall, wenn die Anwendung das Lesen aus allen Streams einstellt, kann der Kanal bis zu 100 MB an Daten puffern.

Alternativ können die Stream-Fenster so dimensioniert werden, dass sie gemeinsam in ein Verbindungsfenster passen, das der BDP entspricht. Dies begrenzt die maximal gepufferten Daten, beschränkt jedoch jeden RPC auf seinen zugewiesenen Anteil, selbst wenn er alleine übertragen wird:

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=1562500        (12.5 MB / 8)
QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE=12500000   (= BDP)

Jeder RPC ist auf etwa 15 MB/s begrenzt, unabhängig davon, ob er allein oder zusammen mit sieben anderen übertragen wird. Der Vorteil besteht darin, dass der Kanal niemals mehr als etwa 12,5 MB ungelesener Daten puffert.

Verwenden Sie Stream-Fenster in voller Größe, wenn die Minimierung der Übertragungslatenz wichtiger ist als der Speicherverbrauch. Verwenden Sie kleinere Stream-Fenster, wenn die Begrenzung des Speicherverbrauchs Priorität hat. Halten Sie in beiden Fällen das Verbindungsfenster groß genug, um mehrere Stream-Fenster aufzunehmen; andernfalls kann ein einzelner ungelesener Stream das gemeinsame Verbindungsfenster ausschöpfen und alle anderen RPCs blockieren.

Beide Fenster akzeptieren Werte bis zu 2147483647 Bytes. Das Stream-Fenster hat eine Untergrenze von 1024 Bytes, wodurch Empfänger mit begrenztem Speicherplatz die Pufferung pro Stream begrenzen können; das Verbindungsfenster hat eine Untergrenze von 65535 Bytes, dem anfänglichen Fenster des Protokolls.

Ausweichmöglichkeiten über Umgebungsvariablen

Einige Kanaleinstellungen können über Umgebungsvariablen konfiguriert werden. Diese werden beim Aufbau jedes Kanals ausgewertet. Ist eine Umgebungsvariable nicht gesetzt, wird der integrierte Standardwert verwendet.