Est-ce que gRPC (HTTP/2) est plus rapide que REST avec HTTP/2?
le but est d'introduire un protocole de couche de transport et d'application qui est meilleur dans son latence et débit du réseau. Actuellement, l'application utilise reste HTTP / 1.1 et nous éprouvons une latence élevée. J'ai besoin de résoudre ce problème de latence et je suis ouvert à utiliser gRPC (HTTP/2) ou REST / HTTP2.
HTTP / 2:
- Multiplexé
- Seule Connexion TCP
- Binaire au lieu de texte
- compression de L'en-tête
- Server Push
je suis conscient de tous les avantages ci-dessus. La Question N ° 1: Si j'utilise reste avec HTTP / 2, j'en suis sûr, je vais obtenir une amélioration significative de la performance comparativement à reste avec HTTP / 1.1, mais comment cela se compare avec gRPC (HTTP/2)?
je suis également conscient que le gRPC utilise le tampon proto, qui est le meilleur la sérialisation binaire<!-Technique de transmission de données structurées sur fil. Proto buffer aide également à développer une approche agnostique du langage. Je suis d'accord avec cela et je peux implémenter la même fonctionnalité dans REST en utilisant graphQL. Mais ma préoccupation est de sérialisation: Question N ° 2: Quand HTTP / 2 implémente cette binaire de la fonction, est-ce que l'utilisation de proto buffer donne un avantage supplémentaire sur HTTP/2?
Question N ° 3: En termes de streaming, bi-directionnel de cas d'utilisation, Comment le gRPC(HTTP/2) se compare-t-il avec (REST et HTTP/2)?
Il y a tellement de blogs/vidéos sur l'internet qui compare gRPC (HTTP / 2) avec (REST et HTTP/1.1) comme . Comme dit plus tôt, je je voudrais connaître les différences, les avantages sur la comparaison GRPC (HTTP / 2) et (reste avec HTTP/2).
2 réponses
gRPC n'est pas plus rapide que REST over HTTP/2 par défaut, mais il vous donne les outils pour le rendre plus rapide. Il y a certaines choses qui seraient difficiles ou impossibles à faire avec le repos.
- compression sélective des messages. En gRPC, une RPC de streaming peut décider de compresser ou non des messages. Par exemple, si vous diffusez du texte et des images mixtes sur un seul flux (ou tout contenu compressible mixte), vous pouvez désactiver la compression pour les images. Cela vous permet d'économiser de compresser des données déjà compressées qui ne seront pas plus petites, mais qui brûleront votre CPU.
- équilibrage de charge de première classe. Bien qu'il ne s'agisse pas d'une amélioration dans les connexions point à point, gRPC peut intelligemment choisir le backend à qui envoyer du trafic. (c'est une fonction de bibliothèque, pas un fil protocole de fonction). Cela signifie que vous pouvez envoyer vos requêtes au serveur d'arrière-plan le moins chargé sans avoir recours à un proxy. C'est un temps de latence gagner.
- Fortement optimisé. gRPC (la bibliothèque) est sous continue repères pour s'assurer qu'il n'y a pas de régression de la vitesse. 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é gRPC.
comme nfirvine l'a dit, Vous constaterez une grande amélioration de vos performances juste en utilisant Protobuf. Alors que vous utilisez proto avec le repos, il est très bien intégré avec gRPC. Techniquement, vous pourriez utiliser JSON avec gRPC, mais la plupart des gens ne veulent pas payer le coût de la performance après s'être habitués aux protos.
Je ne suis pas un expert en la matière et je n'ai aucune donnée pour étayer quoi que ce soit.
la" fonctionnalité binaire " dont vous parlez est la représentation binaire des trames HTTP/2. Le contenu lui-même (une charge JSON) sera toujours UTF-8. Vous pouvez compresser ce JSON et mettre Content-Encoding: gzip, comme HTTP / 1.
mais gRPC fait aussi de la compression gzip. Donc vraiment, nous parlons de la différence entre gzip-compressed JSON vs gzip-compressed protobufs.
comme vous pouvez l'imaginer, les protobufs compressés devraient battre les JSON compressés de toutes les façons, ou bien les protobufs ont échoué à leur but.
en plus de L'ubiquité de JSON vs protobufs, le seul inconvénient que je peux voir à utiliser protobufs est que vous avez besoin de la .proto pour les décoder, disons dans une situation tcpdump.