it-swarm.com.de

Ist gRPC (HTTP / 2) schneller als REST mit HTTP / 2?

Das Ziel besteht darin, ein Transport- und Anwendungsschichtprotokoll einzuführen, das eine bessere Latenz und Netzwerkdurchsatz aufweist. Derzeit verwendet die Anwendung [~ # ~] rest [~ # ~] mit HTTP/1.1 und es tritt eine hohe Latenz auf . Ich muss dieses Latenzproblem lösen und bin offen für die Verwendung von gRPC (HTTP/2) oder REST/HTTP2 .

HTTP/2:

  1. Gemultiplext
  2. Einzelne TCP Verbindung
  3. Binär statt Text
  4. Header-Komprimierung
  5. Server Push

Mir sind alle oben genannten Vorteile bekannt. Frage Nr. 1: Wenn ich REST mit HTTP/2 verwende, kann ich mit Sicherheit eine deutliche Leistungsverbesserung erzielen im Vergleich zu REST mit HTTP/1.1 , aber wie verhält es sich mit gRPC (HTTP/2) ?

Mir ist auch bekannt, dass gRPC Proto Buffer verwendet, die beste binäre Serialisierungstechnik für die Übertragung von strukturierten Daten auf der Leitung. Proto Buffer hilft auch bei der Entwicklung eines sprachunabhängigen Ansatzes. Ich bin damit einverstanden und kann das gleiche Feature in REST mit graphQL implementieren. Mein Anliegen ist jedoch die Serialisierung: Frage Nr. 2: Wann HTTP/2 implementiert diese Binärfunktion . Gibt die Verwendung eines Protopuffers einen zusätzlichen Vorteil gegenüber HTTP/2?

Frage Nr. 3: In Bezug auf Streaming, bidirektionale Use-Cases , wie vergleicht sich gRPC (HTTP/2) mit (REST und HTTP/2)?

Es gibt so viele Blogs/Videos im Internet, die gRPC (HTTP/2) mit (REST und HTTP/1.1) wie this vergleichen. Wie bereits erwähnt, möchte ich die Unterschiede und Vorteile beim Vergleich von GRPC (HTTP/2) und (REST mit HTTP/2) kennen.

62

gRPC ist standardmäßig nicht schneller als REST über HTTP/2, bietet Ihnen jedoch die Tools, um es schneller zu machen. Es gibt einige Dinge, die mit REST schwierig oder unmöglich zu tun wären.

  • Selektive Nachrichtenkomprimierung. In gRPC kann ein Streaming-RPC entscheiden, ob Nachrichten komprimiert oder nicht komprimiert werden sollen. Wenn Sie beispielsweise gemischten Text und Bilder über einen einzelnen Stream (oder einen wirklich gemischten komprimierbaren Inhalt) streamen, können Sie die Komprimierung für die Bilder deaktivieren. Dies erspart Ihnen das Komprimieren bereits komprimierter Daten, die nicht kleiner werden, sondern Ihre CPU verbrennen.
  • Erstklassiger Load Balancing. Obwohl dies keine Verbesserung der Punkt-zu-Punkt-Verbindungen darstellt, kann gRPC auf intelligente Weise auswählen, an welches Backend der Datenverkehr gesendet werden soll. (Dies ist eine Bibliotheksfunktion, keine Drahtprotokollfunktion). Dies bedeutet, dass Sie Ihre Anforderungen an den am wenigsten ausgelasteten Back-End-Server senden können, ohne einen Proxy zu verwenden. Dies ist ein Latenzgewinn.
  • Stark optimiert. gRPC (die Bibliothek) befindet sich unter fortlaufende Benchmarks , um sicherzustellen, dass keine Geschwindigkeitsregressionen vorliegen. Diese Benchmarks verbessern sich ständig. Auch dies hat nichts mit dem gRPC-Protokoll zu tun, aber Ihr Programm ist schneller, wenn Sie gRPC verwendet haben.

Wie Nfirvine sagte, werden Sie den größten Teil Ihrer Leistungsverbesserung nur durch die Verwendung von Protobuf sehen. Während Sie Proto mit REST verwenden konnten , ist es sehr gut in gRPC integriert. Technisch gesehen könnten Sie JSON mit gRPC verwenden, aber die meisten Leute möchten die Leistungskosten nicht bezahlen, nachdem sie sich an Protos gewöhnt haben.

59

Ich bin in keiner Weise ein Experte in diesem Bereich und ich habe keine Daten, um irgendetwas davon zu sichern.

Die "Binärfunktion", von der Sie sprechen, ist die Binärdarstellung von HTTP/2-Frames. Der Inhalt selbst (eine JSON-Nutzlast) ist weiterhin UTF-8. Sie können diesen JSON komprimieren und Content-Encoding: gzip, genau wie HTTP/1.

GRPC komprimiert aber auch gzip. Wir sprechen also wirklich über den Unterschied zwischen gzip-komprimierten JSON- und gzip-komprimierten Prototypen.

Wie Sie sich vorstellen können, sollten komprimierte Protobufs komprimiertes JSON in jeder Hinsicht schlagen, sonst sind Protobufs an ihrem Ziel gescheitert.

Abgesehen von der Allgegenwart von JSON und Protobufs ist der einzige Nachteil, den ich bei der Verwendung von Protobufs feststellen kann, dass Sie die .proto-Datei benötigen, um sie zu dekodieren, beispielsweise in einer tcpdump-Situation.

8
nfirvine