The protocol between server and client created by goquic are UDP not QUIC!

51 views
Skip to first unread message

devins...@gmail.com

unread,
Aug 31, 2017, 11:18:57 PM8/31/17
to Chromium-dev
I download goquic source code from github:


I compile it according to README file and then generate the server and client file.But when I run  the client on my machine to visit a web provided by server on another machine(both are ubuntu OS) with these commands:

./server -addr my_ip -cert xxx.pem -key xxx.pem -port 8080 -quic_only

./client -url https://{ip}/port

then I capture packets by wireshark between server and client,It shows me that the transport protocol is UDP  rather than QUIC.I am confused about that.Does anyone have meet this problem before?Does anyone can tell me the reason?Thank you.  

Nick Harper

unread,
Sep 1, 2017, 3:50:31 AM9/1/17
to Chromium-dev, devins...@gmail.com
The QUIC protocol is built on top of UDP, so it makes sense that wireshark shows UDP as the transport protocol.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/6891ee82-f642-4556-95a6-3ed1728314d4%40chromium.org.

devins...@gmail.com

unread,
Sep 1, 2017, 4:03:03 AM9/1/17
to Chromium-dev, devins...@gmail.com
yes,It's based on UDP,and in  UDP payload,it doesn't have QUIC header,but when I capture the packets from chrome browse and google server,it shows QUIC protocol is used. So I guess there must be some configurations are wrong.
在 2017年9月1日星期五 UTC+8下午3:50:31,Nick Harper写道:

Nick Harper

unread,
Sep 1, 2017, 2:17:26 PM9/1/17
to Chromium-dev, devins...@gmail.com
In the UDP packets you captured, do you see anything like Q036 (you might see a different number)? I noticed the libquic in the library you linked to was last updated about a year ago, so it's quite likely the QUIC header format changed between what you're seeing with that client/server and what chrome is speaking with google.

devins...@gmail.com

unread,
Sep 3, 2017, 8:55:56 PM9/3/17
to Chromium-dev, devins...@gmail.com
No,I didn't see QUIC version in UDP payload.So I guess maybe it has some errors in source code.I get this link via github,Do you mean that the libquic hasn't been updated more than one years or is it that I just get a out of date link?if so,it's really a bad news. Thank you for your reply.

在 2017年9月2日星期六 UTC+8上午2:17:26,Nick Harper写道:

devins...@gmail.com

unread,
Sep 6, 2017, 3:55:26 AM9/6/17
to Chromium-dev, devins...@gmail.com
Does anyone face this problem?

在 2017年9月4日星期一 UTC+8上午8:55:56,devins...@gmail.com写道:

devin shen

unread,
Sep 6, 2017, 4:03:09 AM9/6/17
to Chromium-dev, devins...@gmail.com

packet is as below




在 2017年9月6日星期三 UTC+8下午3:55:26,devins...@gmail.com写道:

Nick Harper

unread,
Sep 6, 2017, 2:41:04 PM9/6/17
to devins...@gmail.com, Chromium-dev
It's hard to see anything useful from those screenshots. If you're running a QUIC server on port 9090, then that looks like QUIC traffic (for whatever version of QUIC that server is using). The version of quic used in https://github.com/devsisters/goquic is a year old - there have been a lot of changes to the protocol since then. I'd suggest using https://github.com/google/proto-quic or https://github.com/lucas-clemente/quic-go instead. If wireshark for you is showing Chrome-Google traffic as QUIC, but not your local client/server, that's probably because the wireshark dissector you're using doesn't know the older version used by your client/server.

This mailing list is focused on chromium development. If you're having trouble with a third-party QUIC implementation, I'd suggest asking that implementation's maintainers instead.

devin shen

unread,
Sep 6, 2017, 9:06:33 PM9/6/17
to Chromium-dev, devins...@gmail.com
OK.thank you very much,I will have a try.

在 2017年9月7日星期四 UTC+8上午2:41:04,Nick Harper写道:
Reply all
Reply to author
Forward
0 new messages