The Cloud Native Computing Foundation (CNCF) is a non-profit open-source organization focused on promoting the development and standardization of cloud-native computing. gRPC (Google Remote Procedure Call) is a high-performance, cross-language RPC framework initiated and open-sourced by Google. In 2017, Google donated the gRPC project to CNCF, making it one of the core components of the cloud-native ecosystem. gRPC is deeply integrated with CNCF projects such as Kubernetes (container orchestration), Prometheus (monitoring), and Istio (service mesh), and is widely used in microservices architecture and cloud-native applications, with its importance increasingly highlighted as the cloud-native concept becomes more prevalent.gRPC cleverly combines mature technologies such as ProtoBuf and HTTP/2 to provide comprehensive and standardized solutions to the three major RPC issues mentioned above.1) Data Representation: By default, ProtoBuf is used as its IDL and efficient binary serialization scheme.2) Data Transmission: Built on top of the HTTP/2 protocol, it utilizes features such as multiplexing, flow control, and header compression to achieve efficient network communication.3) Method Convention: Service interfaces and message structures are defined through ProtoBuf IDL (.proto files).HTTP/2 Protocol
HTTP/2 is a significant upgrade from HTTP/1.1, designed based on Google’s SPDY protocol, and officially became a standard in 2015 (RFC 7540). Although HTTP/1.1 is widely used, its inherent performance bottlenecks—such as head-of-line blocking, high connection establishment latency, and inefficient text header transmission—are increasingly unable to meet the demands of modern web applications for high performance and low latency. HTTP/2 aims to overcome these issues, significantly improving transmission efficiency and user experience.Unlike the plain text transmission of HTTP/1.1, HTTP/2 introduces a Binary Framing Layer. All HTTP messages (requests/responses) are encapsulated into binary-encoded frames for transmission. This design not only improves processing efficiency and robustness (parsing binary is faster and less error-prone than text) but also lays the foundation for advanced features such as multiplexing, header compression, and server push.The core architecture of HTTP/2 includes several key concepts.1) Connection: A single TCP connection supports multiple concurrent Streams, reducing the overhead and latency of multiple TCP connections in HTTP/1.1.2) Stream: An independent bidirectional communication channel used to transmit one or more Messages, avoiding head-of-line blocking.3) Message: Corresponding to HTTP/1.1 requests or responses, composed of one or more Frames, making data transmission more flexible.4) Frame: The smallest unit of communication, using a binary format, containing metadata and payload, used for information transfer between client and server.
Frame StructureA frame is a length-prefixed message. A frame starts with a fixed 9-byte header, followed by a variable-length frame payload. The frame header includes the following common fields: Type, Length, Flags, and Stream Identifier.
+-----------------------------------------------+| Length (24) |+---------------+---------------+---------------+| Type (8) | Flags (8) |+-+-------------+---------------+-------------------------------+|R| Stream Identifier (31) |+=+=============================================================+| Frame Payload (0...) ...+---------------------------------------------------------------+The HTTP/2 protocol defines 10 different types of frames, among which the general format includes several key types that collectively define the behavior and content of frames.1) Length: Indicates the length of the frame payload in bytes. Its maximum length is 2^14 (i.e., 16384 bytes), excluding the 9 bytes of the frame header.2) Type: Used to identify the type of frame. Among them, DATA frames and HEADERS frames correspond to data and header information in HTTP/1.1, respectively. Other frame types include SETTINGS, PRIORITY, RST_STREAM, etc., used to implement various advanced features of the protocol.3) Flags: This field contains a set of flags used to convey additional control information for the frame. Commonly used flags include: END_HEADERS: Indicates that the current frame is the last frame of header data, equivalent to the empty line after header information in HTTP/1.1 (“\r\n”); END_STREAM: Indicates that the current frame is the last frame in the stream, marking the end of unidirectional data transmission (End of Stream, EOS), equivalent to the end marker of chunked transfer encoding in HTTP/1.1 (“0\r\n\r\n”); PRIORITY: Used to indicate the priority of the stream, helping the server and client optimize resource allocation.4) R (Reserved Field): This field is a reserved bit, currently unused, and must be set to 0.5) Stream Identifier: Used to identify the stream to which the frame belongs. Each stream has a unique identifier to distinguish different concurrent streams within the same TCP connection. The length of the stream identifier is 31 bits, with odd identifiers used for client-initiated streams and even identifiers for server-initiated streams.Message Semantic CompatibilityThe HTTP/2 protocol maintains compatibility with HTTP/1 as much as possible. From the perspective of the application, the functionality of the protocol has not fundamentally changed. To achieve this, all request and response semantics of HTTP/1 are preserved, although the syntax conveying those semantics has changed.HTTP/1 uses a start-line to convey the target URI, request method, and response status code, while HTTP/2 uses special fields (pseudo-headers) starting with the ‘:’ character to achieve the same purpose.
In the first request, the first two headers are typically similar to HTTP/1.
GET /resoure HTTP/1.1Host: https://example.com...Now split into a header block.
:method: GET:scheme: https:host: example.com:path: /resource...While the remaining headers are largely the same, they are all in lower-case characters.HTTP/2 attempts to minimize payload size as much as possible. It compresses headers that are the same as those in the previous request. In HTTP/1, a consecutive request looks like an initial request for different resources.
GET /otherResource HTTP/1.1Host: https://example.org...In HTTP/2, consecutive requests to the same server only need the :path header information.
:path: /otherResourceBecause all other header information is indexed and cached, and can be restored through “indexing”.To be continuedIt was great to meet you! If you liked this article, remember to follow us!