¿Es gRPC (HTTP / 2) más rápido que REST con HTTP / 2?

96

El objetivo es introducir un protocolo de capa de aplicación y transporte que sea mejor en cuanto a latencia y rendimiento de red . Actualmente, la aplicación usa REST con HTTP / 1.1 y experimentamos una alta latencia. Necesito resolver este problema de latencia y estoy abierto a usar gRPC (HTTP / 2) o REST / HTTP2 .

HTTP / 2:

  1. Multiplexado
  2. Conexión TCP única
  3. Binario en lugar de textual
  4. Compresión de encabezado
  5. Empuje del servidor

Soy consciente de todas las ventajas anteriores. Pregunta No. 1: Si uso REST con HTTP / 2 , estoy seguro de que obtendré una mejora significativa en el rendimiento en comparación con REST con HTTP / 1.1 , pero ¿cómo se compara esto con gRPC (HTTP / 2) ?

También soy consciente de que gRPC usa proto buffer, que es la mejor técnica de serialización binaria para la transmisión de datos estructurados en el cable. Proto buffer también ayuda a desarrollar un enfoque independiente del lenguaje. Estoy de acuerdo con eso y puedo implementar la misma función en REST usando graphQL. Pero mi preocupación es la serialización: Pregunta No. 2: Cuando HTTP / 2 implementa esta característica binaria , ¿el uso de proto buffer brinda una ventaja adicional sobre HTTP / 2?

Pregunta No. 3: En términos de transmisión, casos de uso bidireccionales , ¿cómo se compara gRPC (HTTP / 2) con (REST y HTTP / 2)?

Hay tantos blogs / videos en Internet que comparan gRPC (HTTP / 2) con (REST y HTTP / 1.1) de esta manera . Como se indicó anteriormente, me gustaría conocer las diferencias y los beneficios de comparar GRPC (HTTP / 2) y (REST con HTTP / 2).

rest http google-cloud-platform http2 grpc Lakshman Diwaakar
fuente
¿Qué terminaste usando? ¿Existe un marco para HTTP2 + REST?
Knocte el
@knocte Terminé usando gPRC. Redujo bastante bien la latencia. Con respecto a HTTP / 2 + REST, no hay un marco específico, son las configuraciones las que necesita cambiar en el servidor que está utilizando. Digamos que está utilizando nginx, consulte los documentos para ver los pasos para configurar HTTP / 2.
Lakshman Diwaakar
y debe asegurarse de que HTTP / 1.1 reutilice la conexión. De lo contrario, busque "tcp cold start". gRPC reutiliza la conexión de forma predeterminada.
bohdan_trotsenko

Respuestas:

93

gRPC no es más rápido que REST sobre HTTP / 2 de forma predeterminada, pero le brinda las herramientas para hacerlo más rápido. Hay algunas cosas que serían difíciles o imposibles de hacer con REST.

  • Compresión selectiva de mensajes. En gRPC, un RPC de transmisión puede decidir comprimir o no los mensajes. Por ejemplo, si está transmitiendo texto e imágenes mezclados en una sola transmisión (o en realidad cualquier contenido comprimible mixto), puede desactivar la compresión de las imágenes. Esto le evita comprimir datos ya comprimidos que no serán más pequeños, pero quemarán su CPU.
  • Equilibrio de carga de primera clase. Si bien no es una mejora en las conexiones punto a punto, gRPC puede elegir inteligentemente a qué backend enviar tráfico. (esta es una función de biblioteca, no una función de protocolo de cable). Esto significa que puede enviar sus solicitudes al servidor backend menos cargado sin tener que recurrir al uso de un proxy. Esta es una victoria de latencia.
  • Muy optimizado. gRPC (la biblioteca) se encuentra bajo parámetros de referencia continuos para garantizar que no haya regresiones de velocidad. Esos puntos de referencia mejoran constantemente. De nuevo, esto no tiene nada que ver con el protocolo gRPC, pero su programa será más rápido por haber usado gRPC.

Como dijo nfirvine, verá la mayor parte de la mejora de su rendimiento solo con el uso de Protobuf. Si bien puede usar proto con REST, está muy bien integrado con gRPC. Técnicamente, podría usar JSON con gRPC, pero la mayoría de la gente no quiere pagar el costo de rendimiento después de acostumbrarse a los protos.

Carl Mastrangelo
fuente
Gracias @Carl por la respuesta. ¿Puede compartirnos algunos enlaces / documentos que expliquen todo lo anterior y el enlace para los puntos de referencia?
Lakshman Diwaakar
3
Actualicé la respuesta para vincularla al tablero. No tengo documentos que los expliquen directamente, pero soy un colaborador principal.
Carl Mastrangelo
proporcione el libraryenlace de equilibrio de carga
BozoJoe
15

No soy un experto en esto de ninguna manera y no tengo datos para respaldar nada de esto.

La "característica binaria" de la que estás hablando es la representación binaria de tramas HTTP / 2. El contenido en sí (una carga útil JSON) seguirá siendo UTF-8. Puede comprimir ese JSON y configurarlo Content-Encoding: gzip, como HTTP / 1.

Pero gRPC también realiza compresión gzip. Entonces, realmente, estamos hablando de la diferencia entre JSON comprimido con gzip y protobufs comprimidos con gzip.

Como puede imaginar, los protobufs comprimidos deberían vencer al JSON comprimido en todos los sentidos, o de lo contrario los protobufs no han logrado su objetivo.

Además de la ubicuidad de JSON vs protobufs, el único inconveniente que puedo ver en el uso de protobufs es que necesitas el .proto para decodificarlos, digamos en una situación tcpdump.

nfirvine
fuente
1
Gracias @nfirvine por tu opinión sobre la pregunta. La función de serialización tiene algo de sentido. ¿Puede agregar más detalles / explicación sobre cómo ocurre la serialización en REST y gRPC? Sería genial, si pudiera compartir algunos enlaces sobre el mismo.
Lakshman Diwaakar