HTTP2 multiplexing principle and gRPC packet capture analysis

1. Background

In this article about getting started with HTTP2, we talked about using multiplexing technology to implement a TCP connection to carry multiple HTTP parallel requests, but how is it implemented specifically, because HTTP2 multiplexing is the main reason for the high performance of gRPC. One, let’s take a closer look below

2. Basic principles of HTTP2 multiplexing

1. Frame

HTTP2 introduces a binary framing layer based on HTTP1. The data is broken into smaller frames and encoded and transmitted in binary before being sent to the lower layer protocol.

frame structure

2. flow

Stream is a virtual concept. We abstract all frames with the same stream identifier in a request/response into a stream.

Data is ordered at the stream level, but unordered at the TCP level. Multiplexing is achieved by decomposing multiple HTTP messages into independent frames, sending them interleavedly (the same HTTP message is sent in sequence), and assembling them at the other end based on the stream identifier.

3. gRPC case packet capture analysis

We first  packaged and deployed the server side in the initial gRPC experience   in the test environment 118.178.255.158 (internal IP: 172.16.79.224), and then ran the client code on this machine to conduct a packet capture experiment.

tcpdump -ieth0 port 50051 -w grpc.pcap

After opening with WireShark, you need to set the 50051 port to use HTTP2 protocol analysis

The complete data package is as follows:

Protocol protocols include TCP, HTTP2, and GRPC.


1. The 1st to 3rd packets TCP three-way handshake
2. The 4th packet Server->Client The frame type is SETTINGS. Set the connection parameters and manage the flow control window.
3. The 5th packet is the client's response.
4. The 6th packet is the client -> server. The frame type is Magic. The main function is to confirm the use of the HTTP2 protocol and confirm that the HTTP2 connection is enabled.
5. The 7th to 8th packets, server -> client, server's response and SETTINGS frame
6. The 9th to 11th packet, client -> server, management flow control window, response, SETTINGS frame.
7. The 12th package, server->client, response
8. The 13th package, GRPC client->server, sends HEADERS frame. The HEADERS frame is used to transmit HTTP header information, and a DATA frame is also sent. Includes two parts GRPC Message and ProtoBuf

9. The 14th package, server->client, sends HEADERS frame and DATA frame

10. The 15th to 18th TCP waves four times

Summarize

1. gRPC will send MAGIC and SETTINGS frames after the TCP three-way handshake to confirm the protocol and configuration.
2. gRPC will design flow control strategies such as sliding windows during the data transmission process.
3. gRPC additional information is transmitted based on HEADERS frames, and specific request and response data are transmitted based on DATA frames.
4. gRPC requests and responses are divided into HTTP and gRPC states.
Note: I have just learned a HelloWorld with gRPC but have not studied it in depth. I have been doubting it for the past two days because the example is completely based on SDK calls instead of requesting the HTTP interface. I really doubt that gRPC uses TCP Socket directly. The layer still uses HTTP2. Through packet capture analysis, it is found that it does use HTTP2. We will further study the use and source code of gRPC in the future.

Guess you like

Origin blog.csdn.net/2301_76787421/article/details/132841475