Est-ce que gRPC (HTTP / 2) est plus rapide que REST avec HTTP / 2?

Question

L'objectif est d'introduire des transports et du protocole de la couche application qui est meilleur en son temps de latence et le débit du réseau. Actuellement, l'application utilise le REPOS avec HTTP/1.1 et nous faisons l'expérience d'une latence élevée. J'ai besoin de résoudre ce problème de latence et je suis ouvert à utiliser gRPC(HTTP/2) ou de REPOS/HTTP2.

HTTP/2:

1. Multiplexés
2. Seule Connexion TCP
3. Binaire au lieu d'textuelle
4. Compression d'en-tête
5. Server Push

Je suis conscient de tous les avantages ci-dessus. Question n ° 1: Si j'utilise le REPOS avec de HTTP/2, j'en suis sûr, je vais obtenir une amélioration significative de la performance comparativement au RESTE avec HTTP/1.1, mais comment cela se compare avec gRPC(HTTP/2)?

Je suis aussi conscient que gRPC utilise proto tampon, qui est la meilleure de sérialisation binaire technique de transmission de données structurées sur le fil. Proto tampon contribue également à l'élaboration d'un langage agnostique approche. Je suis d'accord avec cela et je peux appliquer la même fonction dans le RESTE de l'aide graphQL. Mais ma préoccupation est de sérialisation: Question n ° 2: Lors de HTTP/2 implémente cette fonction binaire, avec les proto tampon de donner un avantage supplémentaire sur le dessus de HTTP/2?

Question n ° 3: En termes de streaming, bi-directionnelle des cas d'utilisation, comment ne gRPC(HTTP/2) comparer avec (de REPOS et de HTTP/2)?

Il y a tellement de blogs/vidéos dans l'internet qui compare gRPC(HTTP/2) avec (le REPOS et HTTP/1.1) comme cela. Comme indiqué précédemment, je voudrais savoir les différences, les avantages de la comparaison de GRPC(HTTP/2) et (RESTE avec HTTP/2).

Answer 1

gRPC n'est pas plus rapide que le RESTE de sur HTTP/2 par défaut, mais il vous donne les outils pour le rendre plus rapide. Il y a certaines choses qu'il serait difficile ou impossible à faire avec le RESTE.

• Message sélective de compression. Dans gRPC un streaming RPC peut décider de comprimer ou de ne pas compresser les messages. Par exemple, si vous diffusez un mélange de texte et d'images sur un seul flux de données (ou vraiment tout mélangé compressible de contenu), vous pouvez désactiver la compression des images. Cela vous évite de comprimer des données déjà compressées qui va pas faire plus petit, mais il brûle de votre CPU.
• La première classe d'équilibrage de charge. Alors que pas une amélioration des connexions point à point, gRPC pouvez choisir intelligemment qui backend pour envoyer le trafic à. (c'est une fonction de bibliothèque, pas un fil protocole de fonction). Cela signifie que vous pouvez envoyer vos demandes pour le moins chargé serveur d'arrière-plan sans recourir à l'utilisation d'un proxy. C'est un temps de latence gagner.
• Largement optimisés. gRPC (la bibliothèque) se trouve sous la continue de repères pour s'assurer qu'il n'y a pas de vitesse des régressions. Ces résultats sont en amélioration constante. Encore une fois, cela n'a rien à voir avec gRPC le protocole, mais votre programme sera plus rapide pour avoir utilisé le gRPC.

Comme nfirvine dit, vous le verrez, la plupart de votre amélioration de la performance juste de l'aide de Protobuf. Alors que vous pourriez utiliser proto avec le RESTE, il est très bien intégré avec gRPC. Techniquement, vous pouvez utiliser JSON avec gRPC, mais la plupart des gens ne veulent pas payer le coût de performance, après s'être habitué aux protos.

Answer 2

Je ne suis pas un expert sur ce par tous les moyens et je n'ai pas de données à l'arrière de tout cela en place.

Le "binaire fonctionnalité" vous parlez, c'est la représentation binaire de HTTP/2 cadres. Le contenu lui-même (une charge utile JSON) seront toujours en UTF-8. Vous pouvez compresser JSON et définissez Content-Encoding: gzip, tout comme HTTP/1.

Mais gRPC ne gzip compression. Alors, vraiment, nous allons parler de la différence entre compressée par gzip JSON vs compressée par gzip protobufs.

Comme vous pouvez l'imaginer, comprimé protobufs devrait battre comprimé JSON dans tous les sens, ou d'autre protobufs ont échoué dans leur objectif.

En plus de l'omniprésence de JSON vs protobufs, le seul inconvénient que je vois à l'aide de protobufs est que vous devez avoir .proto de les décoder, dire dans un tcpdump situation.