Is there a tool like Fiddler that works for analyzing GRPC traffic?

[nicholas...@lucidworks.com]

I'm just curious I haven't tried it yet or anything but...

For Http1.1 traffic it's always been a pretty useful tool to launch Fiddler to analyze http network traffic of a running program. 

But what about for Http2 with GRPC?

We can use Wireshark but it is a so much more low-level than Fiddler, it's not too ideal.

I found this post from pretty long time ago: https://community.akamai.com/community/web-performance/blog/2015/06/05/useful-tools-for-http2-debugging

Stating that the Fiddler and Charles applications don't work for http2 yet. 

Any cool tools out there? Or is wireshark enough? 

[Carl Mastrangelo]

Disclaimer: I work on gRPC so my opinion is quite biased.

Debugging is difficult from an external program for a few reasons:

1.  Traffic is usually encrypted.  HTTP/2 forces us to use ciphers that can't easy dump the TLS keys to disk for use with wireshark or other.  This is a security feature of ephemeral keys, but also a debugging hindrance.

2.  There are usually application/library level knobs that don't show up in the traffic.  For example  the socket option TCP_NOTSENT_LOWAT changes when writes take place, but is never visible from the traffic.    
3.  gGRPC has it's own protocol that requires headers and data frames to behave in a way a normal HTTP/2 traffic may not.  (for example, binary headers have to be base 64 decoded based on the header name).  

The most helpful tools I have used are dumping the http/2 frames directly from the program before they are encrypted and sent.   Secondly, running strace against the binary really help in telling why reads and writes may be slow, and what unusual socket operations are happening.  Lastly, dumping the HTTP/2 flow control window from the application itself is quite helpful for debugging slowdowns and stalls.   Only the changes in window are sent on the wire, but never the absolute amounts.  I guess what I'm getting at is that debugging from outside the program is much harder than having internal probes to the inside.

There is something really cool coming up called Channelz (search this forum for it).  This is a special gRPC service that you can enable to find out all the channels and servers you have running, what their channel state is, how active they are, and low level info about the sockets.  It will even have a channel trace expose that lets you inquire at runtime what interesting events have happened on a channel recently.  (For example, When re resolving DNS names, there was a failure that caused some of the subchannels to go idle).   Right now the spec is finalized, and the implementation is underway.   Eventually we will also release a client (probably JS), so you can view this debug into directly in your browser.