5 ms·

How do QUIC features and capabilities overlap with those of HTTP/2? For example would using them both defeat the purpose of using one in the area of encryption

How do QUIC features and capabilities overlap with those of HTTP/2? For example would using them both defeat the purpose of using one in the area of encryption or transfer speed?

moviuro 9y ago
> HTTP/2 was designed to address this problem using multiple "streams" built into a single connection. Multiple objects can be sent over a stream in parallel by multiplexing them into the connection. That helps, but it creates a new problem: the loss of a single packet will stall transmission of all of the streams at once, creating new latency issues. This variant on the head-of-line-blocking problem is built into TCP itself and cannot be fixed with more tweaks at the HTTP level. [0] https://lwn.net/Articles/745590/ https://lwn.net/Articles/745590/
- fsiefken 9y ago
  thanks for the succinct explanation, I also found these two bits: https://ac.els-cdn.com/S1877050915016853/1-s2.0-S1877050915016853-main.pdf https://ac.els-cdn.com/S1877050915016853/1-s2.0-S18770509150... https://www.callstats.io/2017/02/03/web-protocols-http2-quic/ https://www.callstats.io/2017/02/03/web-protocols-http2-quic...
baby 9y ago
You SHOULD use both of them at the same time. HTTP/2 intertwines your data by using different streams, except all of that is on top of TCP and one stream blocking (because a packet was dropped for example) will block the other streams. This is called head-of-line blocking and you basically can't do much to fix this in TCP unless you create multiple TCP connections for your different resources. But this has a bunch of other issues, you will need to figure out congestion control for each separate TCP connection even if they're connecting to the same service :/ QUIC also has multiple streams, but it doesn't have this head of line problem and other streams will continue to work fine if one stream blocks. So QUIC was made for HTTP/2, where your HTTP/2 streams are basically replaced by QUIC streams which are not affected by loss of packets at all. If you want to see how loss of packets affect an HTTP/2 connection over TCP, it's pretty bad. In general if you're on a lossy connection you should just use HTTP/1. Check this awesome talk: https://www.youtube.com/watch?v=0yzJAKknE_k https://www.youtube.com/watch?v=0yzJAKknE_k
- Aissen 9y ago
  I looked for this some time ago, but IIRC there's no third party implementation that does that. e.g integrating quic-go and grpc-go
niftich 9y ago
They overlap significantly, and some of it is by accident and some is by design. Most of this resulted from convergent evolution by some of the same authors; HTTP/2's transport innovations over HTTP/1.1 were largely lifted from SPDY by Google. QUIC is a more holistic view of the transport techniques to achieve some of the same design goals of SPDY, so the ultimate vision is HTTP/2-over-QUIC, and this is being reconciled [1]. In earlier versions of QUIC, it even included a homebrew transport encryption protocol [2], but this has since been downplayed in favor of TLS 1.3. [1] https://datatracker.ietf.org/doc/draft-ietf-quic-http/ https://datatracker.ietf.org/doc/draft-ietf-quic-http/ [2] https://www.ietf.org/proceedings/92/slides/slides-92-saag-5.pdf https://www.ietf.org/proceedings/92/slides/slides-92-saag-5....

How do QUIC features and capabilities overlap with those of HTTP/2? For example would using them both defeat the purpose of using one in the area of encryption or transfer speed?

moviuro 9y ago

> HTTP/2 was designed to address this problem using multiple "streams" built into a single connection. Multiple objects can be sent over a stream in parallel by multiplexing them into the connection. That helps, but it creates a new problem: the loss of a single packet will stall transmission of all of the streams at once, creating new latency issues. This variant on the head-of-line-blocking problem is built into TCP itself and cannot be fixed with more tweaks at the HTTP level. [0] https://lwn.net/Articles/745590/ https://lwn.net/Articles/745590/

fsiefken 9y ago
thanks for the succinct explanation, I also found these two bits: https://ac.els-cdn.com/S1877050915016853/1-s2.0-S1877050915016853-main.pdf https://ac.els-cdn.com/S1877050915016853/1-s2.0-S18770509150... https://www.callstats.io/2017/02/03/web-protocols-http2-quic/ https://www.callstats.io/2017/02/03/web-protocols-http2-quic...

baby 9y ago

You SHOULD use both of them at the same time. HTTP/2 intertwines your data by using different streams, except all of that is on top of TCP and one stream blocking (because a packet was dropped for example) will block the other streams. This is called head-of-line blocking and you basically can't do much to fix this in TCP unless you create multiple TCP connections for your different resources. But this has a bunch of other issues, you will need to figure out congestion control for each separate TCP connection even if they're connecting to the same service :/ QUIC also has multiple streams, but it doesn't have this head of line problem and other streams will continue to work fine if one stream blocks. So QUIC was made for HTTP/2, where your HTTP/2 streams are basically replaced by QUIC streams which are not affected by loss of packets at all. If you want to see how loss of packets affect an HTTP/2 connection over TCP, it's pretty bad. In general if you're on a lossy connection you should just use HTTP/1. Check this awesome talk: https://www.youtube.com/watch?v=0yzJAKknE_k https://www.youtube.com/watch?v=0yzJAKknE_k

Aissen 9y ago
I looked for this some time ago, but IIRC there's no third party implementation that does that. e.g integrating quic-go and grpc-go

niftich 9y ago

They overlap significantly, and some of it is by accident and some is by design. Most of this resulted from convergent evolution by some of the same authors; HTTP/2's transport innovations over HTTP/1.1 were largely lifted from SPDY by Google. QUIC is a more holistic view of the transport techniques to achieve some of the same design goals of SPDY, so the ultimate vision is HTTP/2-over-QUIC, and this is being reconciled [1]. In earlier versions of QUIC, it even included a homebrew transport encryption protocol [2], but this has since been downplayed in favor of TLS 1.3. [1] https://datatracker.ietf.org/doc/draft-ietf-quic-http/ https://datatracker.ietf.org/doc/draft-ietf-quic-http/ [2] https://www.ietf.org/proceedings/92/slides/slides-92-saag-5.pdf https://www.ietf.org/proceedings/92/slides/slides-92-saag-5....