Exploring gRPC details with WireShark

 

In the previous article, we learned how to capture gRPC traffic using Wireshark. In this article, we will delve deeper into some details of gRPC. I am using the official example of gRPC grpc-go/examples/helloworld.

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.

Packet Capturing Details

gRPC combines HTTP/2 and Protocol Buffers, making packet capturing more convenient when you understand these aspects. For instance, when capturing packets with Wireshark, manually set unrecognized HTTP/2 protocols as HTTP/2 (otherwise, it will be parsed as binary over TCP). Also, note that when viewing HTTP/2, do not expect JSON data display (protobuf uses its own compression algorithm).

Overview of a gRPC Call

gRPC Call Overview [Image - gRPC Call Overview]

From the above image, you can see that in the helloworld gRPC scenario, multiple HTTP2 requests occur when the client calls the server. This can generally be categorized as: Magic->Settings->Headers->Data->Settings->Window-update, Ping->Ping->Headers, Data, Headers->Window_update, ping->Ping.

Settings

From the gRPC call overview image, you can observe two instances of Settings configurations with identical data. The specific data is as follows:
Settings.png

The screenshot of gRPC request Headers reveals some details:

  1. The Header data of HTTP/2 is compressed.
  2. Headers include method (POST), scheme (http), path (/helloword.Greeter/SayHello), content-type (application/grpc), and more.

Headers

Data

The Headers section primarily consists of data related to the client’s request to the server, while the Data section involves the server sending data to the client.

Data

Another Settings Configuration

The second Settings configuration is almost identical to the first, except for the ACK flag being set to True.
Settings-2

Window_update, Ping

In an HTTP/2 request, two stream blocks can be included.

Window_update-Ping

Ping (Pong)

When the client sends a ping request to the server, the server responds with a pong. The ping shown above is initiated by the client, while the subsequent ping is initiated by the server.

Pong

The data here represents what the server sends to the client (including header and body), as shown in the following screenshot.
Data-2

Window_update, Ping

It’s evident that not only can the client initiate a ping to the server, but the server can also ping the client in return.

Window_update

Another Ping (Pong)

After the server initiates a ping operation, the client responds with a pong.

Pong-2

Conclusion

By capturing a gRPC helloworld scenario, this article traced the potential data flow process of a gRPC call. Combining theoretical knowledge of gRPC with the packet capturing content in this article should provide a better understanding of gRPC (focusing on HTTP/2 technology).

References

Licensed under CC BY-NC-SA 4.0
Last updated on May 29, 2024 16:31 CST
Built with Hugo
Theme Stack designed by Jimmy