private-octopus / picoquic

Minimal implementation of the QUIC protocol
MIT License
544 stars 161 forks source link

Test http/0.9 with picoquicdemo. #1610

Closed hyunsube closed 6 months ago

hyunsube commented 9 months ago

Thank you for your great work.

I've trying to test picoquicdemo in many configurations.

Now, I'm trying to test the performance of picoquic compared to http/0.9(TCP protocol).

I could test picoquicdemo with http3 protocol by ./picoquicdemo -q client_log.csv -o ./received test.privateoctopus.com 4433 index.html

In the official test website(https://test.privateoctopus.com), I can see the website supports "http 0.9" application identified with ALPN "hq-23".

However, If I run ./picoquicdemo -a hq-interop -q client_log.csv -o ./received test.privateoctopus.com 4433 index.html , I can get the index.html, but the packet is still quic protocol when I checked the packets in Wireshark.

Also, as you can see in https://test.privateoctopus.com/qlog/6c45d8f8302d881a.d60.server.qlog, "common_fields": { "protocol_type": "QUIC_HTTP3", "reference_time": "1704439316226058"}, even though "proposed_alpn": ["hq-interop"],.

huitema commented 9 months ago

That's a bug in the QLOG header, not a bug in picoquic -- something about the formatting of the protocol identifier in the QLOG header. The packets were indeed exchanged using hq-interop. See for example the line saying command: GET /index.html?.

hyunsube commented 8 months ago

Thank you for pointing out that it was a bug in the QLOG header. I appreciate your help in identifying this issue.

I would like to ask a further question regarding hq-interop. Upon examining the packets captured with tcpdump, I noticed that there were no TCP or UDP protocols present in the pcap file. I had previously understood that the hq-interop feature of picoquic would translate QUIC packets into either TCP or UDP packets for an HTTP0.9 request. However, it seems that my understanding was incorrect. Could you please clarify this matter for me?

Here is the packets.

22  1.007016    192.168.1.5 34.238.92.221   QUIC    1294    Initial, DCID=fea7df142db4415e, SCID=57172fcf59281b15, PKN: 66246, PING, CRYPTO, PADDING
28  1.217054    34.238.92.221   192.168.1.5 QUIC    1294    Handshake, DCID=57172fcf59281b15, SCID=d9f1a5a4a640fccc
29  1.218400    192.168.1.5 34.238.92.221   QUIC    95  Handshake, DCID=d9f1a5a4a640fccc, SCID=57172fcf59281b15
30  1.221661    34.238.92.221   192.168.1.5 QUIC    1237    Protected Payload (KP0), DCID=57172fcf59281b15
31  1.221774    34.238.92.221   192.168.1.5 QUIC    1482    Protected Payload (KP0), DCID=57172fcf59281b15
32  1.222357    192.168.1.5 34.238.92.221   QUIC    445 Protected Payload (KP0), DCID=d9f1a5a4a640fccc
33  1.222624    192.168.1.5 34.238.92.221   QUIC    97  Protected Payload (KP0), DCID=d9f1a5a4a640fccc
34  1.232110    192.168.1.5 34.238.92.221   QUIC    97  Protected Payload (KP0), DCID=d9f1a5a4a640fccc
38  1.496338    192.168.1.5 34.238.92.221   QUIC    225 Handshake, DCID=d9f1a5a4a640fccc, SCID=57172fcf59281b15
huitema commented 8 months ago

To be clear, it is not exactly a "bug in qlog". The Qlog header describes the Qlog syntaxes that the file contains. "QUIC + HTTP3" means that the file may contain Qlog encoding of QUIC packets, and Qlog Encoding of HTTP3 frames. There is no Qlog encoding defined for HQ-interop frames.

The QUIC packets are in fact UDP packets. If you click on their representation in Wireshark, you can see the UDP header followed by the QUIC packets.

hyunsube commented 8 months ago

@huitema I see..

Still, I have one confusing point. I know HTTP protocols under HTTP3.0 including HTTP0.9 use TCP as the transport layer. I wonder if the picoquicdemo sends a request with TCP packet when we set ALPN as HTTP0.9 in client side.

What I want to do is compare HTTP3(QUIC) and other HTTP protocols that use TCP packets.

Can I do this kind of experiment with picoquicdemo or other tools in this repo?

huitema commented 8 months ago

The protocol "hq-interop" is used on top of QUIC, not on top of TCP. We devised that back in 2017, when HTTP3 was still under development. We needed something simple that could be used in tests. The consensus came to use HTTP/0.9, but instead of using it over TCP, use it over QUIC streams. So you get the following:

HTTP/09 HQ interop
start (nothing) open QUIC connection
start page open TCP connection open new QUIC bidirectional stream
get page send "Get XXX.html" over TCP send "Get XXX.html" over QUIC stream
receive page receive data on TCP until end of connection receive data on stream until end of stream
close TCP close stream

If you want to compare QUIC to TCP, the best is to compare getting some pages over QUIC from a QUIC server versus getting similar pages over HTTPS and HTTP2 using an HTTP server, e.g., Apache.

hyunsube commented 8 months ago

Thank you! It's clear to me now.

I would like to inquire about the possibility of implementing support for HTTP/09 using TCP connections based on the picoquicdemo. If this is feasible, could you kindly direct me to the relevant sections of your code? Or do you have any plan to support this?

Please share your opinion.

huitema commented 8 months ago

It depends whether you want to do HTTP/0.9, or HTTPS/0.9. If you just want to do HTTP, without TLS, then you will need to write the required low level code (socket, select, connect, accept, etc.), and then you can probably copy and edit or otherwise reuse some of the code in democlient.c and demoserver.c, but HTTP/0.9 is so simple that you are probably better off just writing the code from scratch.