CODEWITHSUNDEEP
resthttpgoogle-cloud-platformhttp2grpc
Lakshman Diwaakar
Lakshman Diwaakar

Reputation: 7579

Is gRPC(HTTP/2) faster than REST with HTTP/2?

The goal is to introduce a transport and application layer protocol that is better in its latency and network throughput. Currently, the application uses REST with HTTP/1.1 and we experience a high latency. I need to resolve this latency problem and I am open to use either gRPC(HTTP/2) or REST/HTTP2.

HTTP/2:

  1. Multiplexed
  2. Single TCP Connection
  3. Binary instead of textual
  4. Header compression
  5. Server Push

I am aware of all the above advantages. Question No. 1: If I use REST with HTTP/2, I am sure, I will get a significant performance improvement when compared to REST with HTTP/1.1, but how does this compare with gRPC(HTTP/2)?

I am also aware that gRPC uses proto buffer, which is the best binary serialization technique for transmission of structured data on the wire. Proto buffer also helps in developing an language agnostic approach. I agree with that and I can implement the same feature in REST using graphQL. But my concern is over serialization: Question No. 2: When HTTP/2 implements this binary feature, does using proto buffer give an added advantage on top of HTTP/2?

Question No. 3: In terms of streaming, bi-directional use-cases, how does gRPC(HTTP/2) compare with (REST and HTTP/2)?

There are so many blogs/videos out in the internet that compares gRPC(HTTP/2) with (REST and HTTP/1.1) like this. As stated earlier, I would like to know the differences, benefits on comparing GRPC(HTTP/2) and (REST with HTTP/2).

Upvotes: 163

Views: 59719

Answers (4)

oussama gadria
oussama gadria

Reputation: 29

gRPC over HTTP/2 is generally faster than REST over HTTP/2, and the reasons come down to how each is designed. gRPC uses Protocol Buffers (protobuf), which is a compact and efficient binary format, unlike REST, which typically relies on JSON—a text-based format that's slower to process and takes up more space. Another advantage of gRPC is its built-in support for bidirectional streaming, allowing the client and server to send data back and forth in real-time. REST, on the other hand, sticks to the traditional request-response model, which isn’t as efficient for streaming. While both gRPC and REST benefit from HTTP/2 features like multiplexing and header compression, gRPC is designed to make the most of these features, resulting in lower latency and better performance, especially in high-throughput scenarios.

Upvotes: -1

deathrace
deathrace

Reputation: 1073

What I found out is, If you want to send files such as txt, img or video files then REST/HTTP is much faster than gRPC. If you want to send objects over the wire, then gRPC is effecient.

Sources: For sending files,, sending large files,, another blog

Upvotes: 0

Carl Mastrangelo
Carl Mastrangelo

Reputation: 6628

gRPC is not faster than REST over HTTP/2 by default, but it gives you the tools to make it faster. There are some things that would be difficult or impossible to do with REST.

  • Selective message compression. In gRPC a streaming RPC can decide to compress or not compress messages. For example, if you are streaming mixed text and images over a single stream (or really any mixed compressible content), you can turn off compression for the images. This saves you from compressing already compressed data which won't get any smaller, but will burn up your CPU.
  • First class load balancing. While not an improvement in point to point connections, gRPC can intelligently pick which backend to send traffic to. (this is a library feature, not a wire protocol feature). This means you can send your requests to the least loaded backend server without resorting to using a proxy. This is a latency win.
  • Heavily optimized. gRPC (the library) is under continuous benchmarks to ensure that there are no speed regressions. Those benchmarks are improving constantly. Again, this doesn't have anything to do with gRPC the protocol, but your program will be faster for having used gRPC.

As nfirvine said, you will see most of your performance improvement just from using Protobuf. While you could use proto with REST, it is very nicely integrated with gRPC. Technically, you could use JSON with gRPC, but most people don't want to pay the performance cost after getting used to protos.

Upvotes: 157

nfirvine
nfirvine

Reputation: 1539

I am not an expert on this by any means and I have no data to back any of this up.

The "binary feature" you're talking about is the binary representation of HTTP/2 frames. The content itself (a JSON payload) will still be UTF-8. You can compress that JSON and set Content-Encoding: gzip, just like HTTP/1.

But gRPC does gzip compression as well. So really, we're talking about the difference between gzip-compressed JSON vs gzip-compressed protobufs.

As you can imagine, compressed protobufs should beat compressed JSON in every way, or else protobufs have failed at their goal.

Besides the ubiquity of JSON vs protobufs, the only downside I can see to using protobufs is that you need the .proto to decode them, say in a tcpdump situation.

Upvotes: 37

Related Questions