Understanding gRPC and HTTP/2

Traditional RPC Solutions:

1. JSON + HTTP 1.x

2. TCP + Custom Protocol

Limitations

Method	Limitations
HTTP/1.x + JSON	Single connection order calls, frequent connection establishment incurs high overhead;Large JSON payloads, slow parsing; not suitable for streaming communication;Manual SDK writing required for multi-language calls or handling compatibility
TCP Custom Protocol	Packet sticking, unpacking, message boundaries, and concurrency control must be implemented manually; cross-language support is difficult;Lack of unified standards

Summary: Traditional methodshave low performance, complex development, cross-language difficulties, and poor concurrency capabilities.

Goals of gRPC

1. High performance, low data volume, long connections

2. Multi-language support

3. Clear message boundaries

4. Concurrency and streaming communication

Core Features and Optimizations

Feature/Optimization	Description
HTTP/2Multiplexing	Multiple RPC requests can be sent simultaneously over a single TCP connection, each request has a unique Stream ID, and they do not interfere with each other
Protobuf Serialization	Binary, efficient, small size, cross-language, can directly generate code
Streaming RPC	Unary (single request single response),Server Streaming,Client Streaming,Bidirectional Streaming
Message Boundaries	Each request and response has a length-prefix, automatically assembling frames to avoid packet sticking
Service Registration and Method Dispatch	Methods are automatically dispatched through Map/reflection, no need to manually write switch-case
High Concurrency Handling	Stream ensures safe concurrent calls internally through Stream ID and frame assembly
Code Generation	Proto definition → automatically generate client and server code → call like a local function

Underlying Logic of gRPC

• Physical Layer: TCP long connection

• Application Layer: HTTP/2

• Logical Channel: Stream (each RPC call corresponds to a Stream)

gRPC utilizes multiple features of HTTP/2 to achieve efficient communication, but it cannot be directly equated to the HTTP protocol, as the frontend cannot recognize it

The requests in gRPC indeed use HTTP/2 frames at the lower level, but their content is not a standard HTTP text request:

• Headers are special binary fields (e.g., <span>content-type: application/grpc</span>);

• The body is a Protobuf encoded binary stream;

• Supports streaming data (Stream), rather than the traditional request-response model.

Therefore, from the browser’s perspective, this request is completely in an “unknown format”, a dialect of HTTP/2, and the browser will not help you parse it.

HTTP 1.1

The HTTP protocol is based on TCP/IP and uses a request-response communication model

1. Long Connections

   If neither end explicitly requests to close the connection, the TCP connection remains open

2. Pipelining

   A request can be sent again without waiting for the previous one to return

3. Head-of-line Blocking

   Compared to HTTP 1.0

Defects

1. Only the body is compressed

2. Servers respond in order, leading to head-of-line blocking

3. Servers cannot actively push

4. Plain text transmission

5. Identity verification

6. Information integrity

HTTP 2.0

Advantages

1. Header Compression

2. Binary Format

3. Concurrent Transmission

1. A TCP connection can contain multiple streams,streams contain multiple Messages (corresponding to requests and responses in HTTP 1.x), and Frame is the smallest unit in HTTP/2, storing the content in a binary compressed format

2. Different HTTP requests (Messages for different stream IDs) are distinguished by unique stream IDs

4. Server Push

   Both parties establish streams, with clients using odd-numbered streams and servers using even-numbered streams.

HTTP/1.1 is a long connection, so why can’t it implement chat?

Because it is half-duplex, meaning that at any given time, only one side (client or server) can actively send data

Since gRPC uses HTTP/2, which is also a long connection, why can’t it implement chat?

Primarily because the frontend cannot recognize it; it requires a specific protocol, and the protocols are not unified