Background
gRPC is an open-source high-performance RPC framework developed by Google. The design goal of gRPC is to run in any environment, supporting pluggable load balancing, tracing, health checking, and authentication. It not only supports service calls within and across data centers but is also suitable for the last mile of distributed computing, connecting devices, mobile applications, and browsers to backend services. For more on the motivation and principles behind gRPC's design, refer to this article: gRPC Motivation and Design Principles.
This article is first published in the medium MPP plan. If you are a medium user, please follow me in medium. Thank you very much.
Key points from the official article:
- Internally, there is a framework called Stubby, but it is not based on any standard.
- Supports use in any environment, including IoT, mobile, and browsers.
- Supports streaming and flow control.
In reality, performance is not the primary goal of gRPC design. So why choose HTTP/2?
What is HTTP/2
Before discussing why gRPC chose HTTP/2, let's briefly understand HTTP/2.
HTTP/2 can be simply introduced with an image:
From: https://hpbn.co/
- The header in HTTP/1 corresponds to the HEADERS frame in HTTP/2.
- The payload in HTTP/1 corresponds to the DATA frame in HTTP/2.
In the Chrome browser, openchrome://net-internals/#http2to see information about HTTP/2 connections.
Many websites are already running on HTTP/2.
gRPC Over HTTP/2
Strictly speaking, gRPC is designed in layers, with the underlying layer supporting different protocols. Currently, gRPC supports:
However, most discussions are based on gRPC over HTTP2. Let's look at a real gRPC SayHello request and see how it is implemented over HTTP/2 using Wireshark:
You can see the following headers:
Header: :authority: localhost:50051
Header: :path: /helloworld.Greeter/SayHello
Header: :method: POST
Header: :scheme: http
Header: content-type: application/grpc
Header: user-agent: grpc-java-netty/1.11.0
Then the request parameters are in the DATA frame:
GRPC Message: /helloworld.Greeter/SayHello, Request
In short, gRPC puts metadata in HTTP/2 Headers and serialized request parameters in the DATA frame.
Advantages of HTTP/2 Protocol
HTTP/2 is an Open Standard
Google thought this through and chose not to open-source its internal Stubby but to create something new. As technology becomes more open, the space for proprietary protocols is shrinking.
HTTP/2 is a Proven Standard
HTTP/2 was developed based on practical experience, which is crucial. Many unsuccessful standards were created by a group of vendors before implementation, leading to chaos and unusability, such as CORBA. HTTP/2's predecessor was Google's SPDY. Without Google's practice and promotion, HTTP/2 might not exist.
HTTP/2 Naturally Supports IoT, Mobile, and Browsers
In fact, mobile phones and mobile browsers were the first to adopt HTTP/2. The mobile internet has driven the development and adoption of HTTP/2.
Multi-language Implementation of HTTP/2 is Easy
Discussing only the implementation of the protocol itself, without considering serialization:
- Every popular programming language has a mature HTTP/2 Client.
- HTTP/2 Clients are well-tested and reliable.
- Sending HTTP/2 requests with a Client is much easier than sending/receiving packets with sockets.
HTTP/2 Supports Stream and Flow Control
There are many streaming solutions in the industry, such as those based on WebSocket or rsocket. However, these solutions are not universal.
Streams in HTTP/2 can also be prioritized, which might be used in complex scenarios, although less frequently in RPC.
Easy Support for HTTP/2 in Gateway/Proxy
- Nginx support for gRPC: https://www.nginx.com/blog/nginx-1-13-10-grpc/
- Envoy support for gRPC: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/grpc#
HTTP/2 Ensures Security
- HTTP/2 naturally supports SSL, although gRPC can run on a clear text protocol (i.e., unencrypted).
- Many proprietary RPC protocols might wrap a layer of TLS support, making it very complex to use. Do developers have enough security knowledge? Are users configuring it correctly? Can operators understand it correctly?
- HTTP/2 ensures secure transmission over public networks. For example, the CRIME attack is hard to prevent in proprietary protocols.
Mature Authentication in HTTP/2
- Authentication systems developed from HTTP/1 are mature and can be seamlessly used in HTTP/2.
- End-to-end authentication from front-end to back-end without any conversion or adaptation.
For example, traditional RPC like Dubbo requires writing a Dubbo filter and considering how to pass authentication-related information through thread local. The RPC protocol itself also needs to support it. In short, it's very complex. In fact, most RPCs in companies do not have authentication and can be called freely.
Disadvantages of HTTP/2 Protocol
Inefficient Transmission of RPC Metadata
Although HPAC can compress HTTP Headers, for RPC, determining a function call can be simplified to an int. Once negotiated between both ends, it can be directly looked up in a table, without the need for HPAC encoding and decoding.
Consider optimizing an HTTP/2 parser specifically for gRPC to reduce some general processing and improve performance.
gRPC Calls in HTTP/2 Require Two Decodings
One for the HEADERS frame and one for the DATA frame.
The HTTP/2 standard itself only allows one TCP connection, but in practice, gRPC may have multiple TCP connections, which needs attention during use.
Choosing HTTP/2 for gRPC means its performance won't be top-notch. But for RPC, moderate QPS is acceptable, and generality and compatibility are the most important. Refer to the official benchmark: https://grpc.io/docs/guides/benchmarking.html
https://github.com/hank-whu/rpc-benchmark
If your scenario is to...
Google's Standard-Setting Ability
In the past decade, Google's ability to set standards has grown stronger. Here are some standards:
- HTTP/2
- WebP image format
- WebRTC for real-time communication
- VP9/AV1 video encoding standards
- Service Worker/PWA
- QUIC/HTTP/3
Of course, Google doesn't always succeed. Many initiatives it tried to push failed, such as Chrome's Native Client.
gRPC is currently the de facto standard in the Kubernetes ecosystem. Will gRPC become the RPC standard in more areas and larger fields?
Why gRPC Emerged
Why did an HTTP/2-based RPC emerge?
I believe an important reason is that in the trend of Cloud Native, the need for open interoperability inevitably leads to HTTP/2-based RPC. Even without gRPC, there would be other HTTP/2-based RPCs.
gRPC was first used internally at Google on Google Cloud Platform and public APIs: https://opensource.google.com/projects/grpc
Summary
Although gRPC may not replace internal RPC implementations, in an era of open interoperability, not just on Kubernetes, gRPC will have more and more stages to showcase its capabilities.