Why Google Selected HTTP/2 for gRPC Implementation
Written on
Chapter 1: Understanding gRPC's Design Choices
gRPC is an open-source, high-performance Remote Procedure Call (RPC) framework developed by Google. Its design is aimed at functioning seamlessly across various environments, featuring support for pluggable load balancing, tracing, health checks, and authentication. This framework accommodates service calls both within and between data centers and is adept at connecting devices, mobile apps, and browsers to backend services.
For a deeper insight into the motivations and foundational principles guiding gRPC's creation, refer to this comprehensive article: gRPC Motivation and Design Principles.
Key Highlights from the Official Documentation:
- Internally, Google operates a framework named Stubby, which isn't aligned with any established standards.
- gRPC is versatile, catering to various environments including IoT, mobile platforms, and web browsers.
- It offers robust streaming and flow control capabilities.
- Notably, performance isn't the sole focus of gRPC's architecture.
What Leads to the Choice of HTTP/2?
Before delving into why gRPC adopted HTTP/2, it's essential to grasp the fundamentals of HTTP/2. This protocol enhances the communication framework significantly compared to its predecessor.
To explore HTTP/2 connections in Chrome, visit: chrome://net-internals/#http2.
gRPC operates on a layered architecture, allowing it to support various underlying protocols, with the current focus primarily on:
- gRPC over HTTP/2
- gRPC Web
Let’s analyze a sample gRPC SayHello request and observe its implementation over HTTP/2 using a tool like Wireshark:
The following headers are identified in the request:
- :authority: localhost:50051
- :path: /helloworld.Greeter/SayHello
- :method: POST
- :scheme: http
- content-type: application/grpc
- user-agent: grpc-java-netty/1.11.0
The request parameters are encapsulated in the DATA frame, illustrating that gRPC utilizes HTTP/2 Headers for metadata while the serialized request parameters reside in the DATA frame.
Advantages of HTTP/2
- Open Standard: Google opted to develop a new protocol rather than open-source Stubby, anticipating a shift towards more open technologies that limits proprietary protocols.
- Proven Track Record: HTTP/2 was built on practical experiences, avoiding the pitfalls of many standards that failed due to lack of implementation foresight.
- Support for Modern Platforms: Mobile devices and browsers were among the first to adopt HTTP/2, driven by the needs of the mobile internet.
- Ease of Multilingual Implementation: The existence of mature HTTP/2 clients across popular programming languages enhances its adoption.
- Stream and Flow Control: HTTP/2 offers prioritized streams, beneficial in complex scenarios.
- Gateway and Proxy Compatibility: Tools like Nginx and Envoy provide seamless support for gRPC.
- Inherent Security: HTTP/2 naturally incorporates SSL, making it easier to ensure secure communications.
- Mature Authentication: Existing authentication systems from HTTP/1 transition smoothly to HTTP/2, simplifying backend communication.
Disadvantages of HTTP/2
- RPC Metadata Transmission Inefficiencies: Although HPAC can compress HTTP headers, simplifying function calls could enhance performance.
- Multiple Decodings Required: Each gRPC call necessitates decodings for both HEADERS and DATA frames, which can introduce latency.
- TCP Connection Constraints: Although HTTP/2 typically allows a single TCP connection, practical implementations may necessitate multiple connections.
While HTTP/2 may not deliver the highest performance for gRPC, its moderate queries per second (QPS) are often acceptable, prioritizing generality and compatibility.
Google's Influence on Standards
Over the past decade, Google's role in establishing standards has strengthened, evident in:
- HTTP/2
- WebP image format
- WebRTC for real-time communication
- VP9/AV1 video encoding standards
- Service Worker/PWA
- QUIC/HTTP/3
Despite some setbacks, such as the failed Native Client initiative, gRPC has emerged as a key standard within the Kubernetes ecosystem.
The Emergence of gRPC
The rise of HTTP/2-based RPCs is largely driven by the demand for open interoperability in the Cloud Native landscape. Even without gRPC, other HTTP/2-based RPC solutions would likely have surfaced.
Initially, gRPC was implemented internally at Google for the Google Cloud Platform and public APIs.
Summary
Although gRPC may not replace internal RPC frameworks, its capacity for open interoperability will likely lead to its broader adoption beyond Kubernetes.
References
Chapter 2: Exploring gRPC's HTTP/2 Benefits
In this chapter, we will dive into the specific advantages and practical applications of gRPC over HTTP/2.
Video Description: This video discusses the essential aspects of gRPC and its relationship with HTTP/2, covering key advantages and use cases.
Video Description: A comprehensive crash course on gRPC, detailing its modes, examples, pros and cons, providing a well-rounded understanding of the framework.