Does gRPC use only http2? tcpdump from a particular client does not show it as http2

83 views
Skip to first unread message

Pramma

unread,
Nov 28, 2018, 9:37:25 AM11/28/18
to grpc.io

While analysing tcpdump of gRPC comm between our client (restricted env, on a network device) to server, i find following behaviour. In SSL npn negotiation, it negotiated for "h2", but in actual grpc packet, Application Data Protocol says 'Application Data' instead of 'http2'.


I compared another tcpdump from diff client (not a network device, on a ubuntu), SSL npn negotiation happened for h2 and packet header had, Application Data Protocol: http2


So i want to understand which is the fallback protocol grpc client might have used to send the actual grpc data after negotiating for h2?

I am concerned because in this restricted env (network device), grpc fails intermittently. Note i am using gRPC 1.0.0. and i cannot change it for now. 


Is grpc relying on any external took for h2 support?? In both these cases, i used gRPC 1.0.0. 1st client seems not capable of sending h2 at least as per this dump.

Any help will be appreciated

Michael Lumish

unread,
Nov 28, 2018, 1:44:00 PM11/28/18
to grpc.io
What language(s) are you using gRPC with? In any case, it will be very hard for us to help with such an old version; is there any way for you to update it?

pramm...@gmail.com

unread,
Nov 29, 2018, 1:42:09 AM11/29/18
to grpc.io
Thanks for the prompt response.
We use Python grpcio 1.0.0. 
No as i mentioned, for now version will not be updated as Network device i am talking about is already deployed in customer networks.
We have to make our application work with this for now.

My question is more towards, 
What does grpc rely on to for http2 capability? (any tool in os environment or http2 capability is inbuilt in grpc?)
Why same version in another Ubuntu VM used http2, where as this specific env, it did not use http2?

Josh Humphries

unread,
Nov 29, 2018, 1:13:27 PM11/29/18
to pramm...@gmail.com, grp...@googlegroups.com
The main gRPC libraries only use HTTP/2. As you saw, they negotiate the same protocol during NPN step of TLS handshake: "h2". It is more likely that whatever analysis tool you used in the first case did not recognize "h2" as the HTTP/2 protocol, so treated it as an unknown application protocol.

----
Josh Humphries
jh...@bluegosling.com


--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/ff3c3be4-e3e0-4f3d-af4e-73595f2018e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Srini Polavarapu

unread,
Nov 29, 2018, 7:47:56 PM11/29/18
to grpc.io

What does grpc rely on to for http2 capability? (any tool in os environment or http2 capability is inbuilt in grpc?)

gRPC Python has a built-in HTTP/2 stack. 

pramm...@gmail.com

unread,
Nov 30, 2018, 2:23:00 AM11/30/18
to grpc.io
Thanks for writing.
Same tool i am using for capturing and viewing 2 dumps, 1 dump it shows http2 where as this dump it shows application protocol.
Looking at other replies and going thru other documents, i hope grpc cannot work without http2.

But my issue is at least half of the time, after Server Hello, client closes the connection sending TCP FIN. 
For that i am trying to understand the root cause for the same. 

pramm...@gmail.com

unread,
Nov 30, 2018, 2:53:31 AM11/30/18
to grpc.io
Thanks.

pramm...@gmail.com

unread,
Nov 30, 2018, 5:35:09 AM11/30/18
to grpc.io
In addition to my tcpdump analysis where it does not classify it as http2
I tries haproxy also does not classify it as http2 packet,

haproxy rejects with following line,
use_backend test_backend if { ssl_fc_npn -i h2 }

but works with following line,
default_backend test_backend

this further ensures that the packet is not proper http2.
Reply all
Reply to author
Forward
0 new messages