O gRPC (HTTP / 2) é mais rápido do que o REST com HTTP / 2?

O objetivo é introduzir um protocolo de camada de transporte e aplicação que seja melhor em sua latência e rendimento de rede . Atualmente, o aplicativo usa REST com HTTP / 1.1 e experimentamos uma alta latência. Preciso resolver esse problema de latência e estou aberto para usar gRPC (HTTP / 2) ou REST / HTTP2 .

HTTP / 2:

1. Multiplexado
2. Conexão TCP Única
3. Binário em vez de textual
4. Compressão de cabeçalho
5. Push de servidor

Estou ciente de todas as vantagens acima. Pergunta nº 1: Se eu usar REST com HTTP / 2 , tenho certeza que terei uma melhora significativa de desempenho em comparação com REST com HTTP / 1.1 , mas como isso se compara com gRPC (HTTP / 2) ?

Também estou ciente de que o gRPC usa proto buffer, que é a melhor técnica de serialização binária para transmissão de dados estruturados na rede. O buffer de protótipo também ajuda no desenvolvimento de uma abordagem independente de linguagem. Eu concordo com isso e posso implementar o mesmo recurso em REST usando o GraphQL. Mas minha preocupação é com a serialização: Pergunta nº 2: Quando o HTTP / 2 implementa esse recurso binário , o uso do buffer proto oferece uma vantagem adicional em relação ao HTTP / 2?

Pergunta nº 3: em termos de streaming, casos de uso bidirecionais , como o gRPC (HTTP / 2) se compara ao (REST e HTTP / 2)?

Há tantos blogs / vídeos fora na internet que compara gRPC (HTTP / 2) com (REST e HTTP / 1.1) como este . Como afirmado anteriormente, gostaria de saber as diferenças, benefícios em comparar GRPC (HTTP / 2) e (REST com HTTP / 2).

O gRPC não é mais rápido do que REST sobre HTTP / 2 por padrão, mas fornece as ferramentas para torná-lo mais rápido. Existem algumas coisas que seriam difíceis ou impossíveis de fazer com REST.

• Compressão seletiva de mensagem. No gRPC, um RPC de streaming pode decidir compactar ou não as mensagens. Por exemplo, se você estiver transmitindo texto e imagens misturados em um único fluxo (ou realmente qualquer conteúdo compactável misto), pode desativar a compactação das imagens. Isso evita que você comprima dados já compactados que não ficarão menores, mas queimarão sua CPU.
• Balanceamento de carga de primeira classe. Embora não seja uma melhoria nas conexões ponto a ponto, o gRPC pode escolher de maneira inteligente para qual back-end enviar o tráfego. (este é um recurso de biblioteca, não um recurso de protocolo de conexão). Isso significa que você pode enviar suas solicitações para o servidor back-end menos carregado, sem recorrer ao uso de um proxy. Esta é uma vitória de latência.
• Extremamente otimizado. gRPC (a biblioteca) está em benchmarks contínuos para garantir que não haja regressões de velocidade. Esses benchmarks estão melhorando constantemente. Novamente, isso não tem nada a ver com o protocolo gRPC, mas seu programa ficará mais rápido por ter usado o gRPC.

Como disse o nfirvine, você verá a maior parte da melhoria de desempenho apenas com o uso do Protobuf. Embora você possa usar proto com REST, ele é muito bem integrado com gRPC. Tecnicamente, você poderia usar JSON com gRPC, mas a maioria das pessoas não quer pagar pelo custo de desempenho depois de se acostumar com protos.

Eu não sou um especialista nisso de forma alguma e não tenho dados para comprovar nada disso.

O "recurso binário" de que você está falando é a representação binária de quadros HTTP / 2. O conteúdo em si (uma carga JSON) ainda será UTF-8. Você pode compactar esse JSON e definir Content-Encoding: gzip, assim como HTTP / 1.

Mas gRPC também faz compactação gzip. Então, realmente, estamos falando sobre a diferença entre JSON compactado com gzip e protobufs compactados com gzip.

Como você pode imaginar, os protobufs compactados devem superar o JSON compactado em todos os sentidos, ou os protobufs falharam em seu objetivo.

Além da onipresença de JSON vs protobufs, a única desvantagem que vejo no uso de protobufs é que você precisa do .proto para decodificá-los, digamos em uma situação tcpdump.