rest http google-cloud-platform http2 grpc

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



google-cloud-platform http2 (2)

El objetivo es introducir un protocolo de capa de aplicación y transporte que sea mejor en su 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. Servidor Push

Soy consciente de todas las ventajas anteriores. Pregunta No. 1: Si uso REST con HTTP / 2 , estoy seguro, 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 utiliza el búfer proto, 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 agnóstico del lenguaje. Estoy de acuerdo con eso y puedo implementar la misma característica en REST usando graphQL. Pero mi preocupación es sobre la serialización: Pregunta No. 2: Cuando HTTP / 2 implementa esta función binaria , ¿el uso de proto buffer ofrece 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 compara gRPC (HTTP / 2) con (REST y HTTP / 1.1) como this . Como se indicó anteriormente, me gustaría saber las diferencias, los beneficios de comparar GRPC (HTTP / 2) y (REST con HTTP / 2).

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á 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 configurar Content-Encoding: gzip , al igual que HTTP / 1.

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

Como puede imaginar, los protobufs comprimidos deberían vencer a JSON comprimido en todos los sentidos, o los protobufs han fallado en su objetivo.

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

gRPC no es más rápido que REST sobre HTTP / 2 de manera 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 comprimir mensajes. Por ejemplo, si está transmitiendo texto e imágenes mezclados a través de una sola transmisión (o realmente cualquier contenido compresible mixto), puede desactivar la compresión de las imágenes. Esto le ahorra 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 conexión). Esto significa que puede enviar sus solicitudes al servidor backend menos cargado sin recurrir al uso de un proxy. Esta es una victoria de latencia.
  • Muy optimizado. gRPC (la biblioteca) está bajo puntos de referencia continuos para garantizar que no haya regresiones de velocidad. Esos puntos de referencia están mejorando constantemente. Nuevamente, 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 su mejora de rendimiento solo con el uso de Protobuf. Si bien podría usar proto con REST, está muy bien integrado con gRPC. Técnicamente, podría usar JSON con gRPC, pero la mayoría de las personas no quieren pagar el costo de rendimiento después de acostumbrarse a los protos.