How do I see if web reqest/response uses QUIC and/or HTTP/2?

I am trying to do some tests in Chromium with HTTP/2, HTTP1.1, QUIC, and TCP. I want to try different combinations of the protocols. I am experiencing some very strange behaviour in my browser though. When I want to try HTTP1.1+QUIC I start my browser with:

chromium-browser --disable-http2 --enable-quic

And I can see at chrome://net-internals/ that HTTP2 is disabled and QUIC is enabled. However, when I do a web request to a server supporting HTTP2 and QUIC I get this:

Why would it say that the HTTP/2 is used when it so clearly says that http2 enabled: false at chrome://net-internals/ ?

I have previously been successful in running HTTP1.1 with QUIC. Has QUIC been updated to only work with HTTP/2? Or does the 'Protocol'-field display the wrong protocol?

I would love to if someone else have been successful is using QUIC with HTTP1.1

Many thanks!

QUIC only works with HTTP/2 and doesn’t make sense with HTTP/1.1.

HTTP/1.1 sends one request at a time on its one TCP connection. Browsers open 6-8 connections to allow some level of parallelisation but, other than that hack, HTTP/1.1 is basically synchronous - you send a request and can’t use that connection again until that request is responded to in its entirety. So HTTP/1.1 has a Head of Line (HOL) blocking problem as a slow, or delayed, response will block the connection so it can’t be used for a resource that could be responded to.

HTTP/2 is a binary, multiplexed protocol, which basically means requests and responses are split into packets which can be sent on a single TCP connection and intermingled. This is great as TCP connections are relatively expensive over the Internet due to the time to set up the TCP connection, to set up HTTPS potentially on top of that and then to build up the TCP slow start rate limiting window to an optimal size. So HTTP/2 being able to send and receive multiple HTTP requests and responses over one TCP connection is a massive improvement and solves the HOL Blocking problem at a HTTP level.

Unfortunately the HOL blocking problem is moved from HTTP layer to TCP layer. TCP is a guaranteed protocol - if a single TCP packet is lost then it is re-requested and the whole connection waits for that missed packet to come back. This is great as higher level protocols (like HTTP) can build upon this without worry about checking if pieces have made it or not or in the right order - TCP takes care of that. The downside with this is that protocols like HTTP/2 may not need this strict level of guarantees. If a server is sending 6 HTTP/2 responses on one connection at the same time, and one TCP packet gets dropped it will only be for one of those responses - the other 5 could in theory continue to be sent and then be processed by the browser. But TCP forbids this.

So QUIC aims to solve this by replacing the TCP part with a UDP based protocol that guarantees delivery at a stream level rather than a connection level. This could have been done by enhancing TCP but that’s so embedded into lots of servers, clients, operating systems, network infrastructure... etc. that it was easier to build upon UDP instead. Eventually learnings from this might be incorporated into TCP. Until then QUIC allows quick experimentation and innovation as UDP is very, very light and any additions to it (e.g. delivery guarantees) are basically implemented in the user-space land rather than lower level internals where it can’t be upgraded. QUIC will likely eventually be used for protocols other than HTTP but for the moment that’s it’s primary use case.

So QUIC effectively replaces the TCP part, but it also needs to change the lower level parts of HTTP/2 which means it also needs to implement the in between TLS part. The best diagram for explain it’s place is this diagram (taken from this presentation):

I have previously been successful in running HTTP1.1 with QUIC.

I seriously doubt this. As per above explanation QUIC only makes sense over a multiplexed protocol like HTTP/2. Perhaps Chrome used to call it QUIC rather than HTTP/2 + QUIC but it would always have been using HTTP/2 (or its similar predecessor SPDY).

Also HTTP/2 really only changes how the messages are sent on the wire. At a higher level, as used by web developers and users, it often acts the same way as HTTP/1.1 with the same verbs (GET, POST... etc.) and HTTP Headers (mostly). So since QUIC just improves how those HTTP/2 messages are sent on the wire, rather than the higher level “HTTP” protocol it really doesn’t make sense to discuss or measure how HTTP/1.1 over QUIC (if it did exist) would differ from HTTP/2 over QUIC - since HTTP/1.1 over QUIC would basically become HTTP/2 over QUIC.

Finally when QUIC has completed standardisation (as opposed to the non-standard Google QUIC version often called gQUIC), it will use a modified version of HTTP/2 which will be called HTTP/3. For now browsers will only use gQUIC and HTTP/2.