Is QUIC only built for HTTP or can it be also used as a secure infrastructure for any L7 protocol?
Some notes about HTTP/3
51–60 of 181 posts
Re: Some notes about HTTP/3
#52have any of you geniuses figured out this will break websites for tor users yet?
Tor doesn't support UDP so no HTTP/3 but one would expect most services would be available for the foreseeable future over HTTP/2 as well.
Re: Some notes about HTTP/3
#53Re: Some notes about HTTP/3
#54>With QUIC, however, the identifier for a connection is not the traditional concept of a "socket" (the source/destination port/address protocol combination), but a 64-bit identifier assigned to the connection. This means that as you move around, you can continue with a constant stream uninterrupted from YouTube even as your IP address changes, or continue with a video phone call without it being dropped. This is the…
In a typical scenario, when you connect to a website with one IP address, then change your network and connect again with different IP but using the same device/browser, that website knows that you are the same user. I don't see how having an identifier inside encrypted connection makes anything worse.
Re: Some notes about HTTP/3
#55Earlier quoted context omitted.
Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are s…
How does QUIC compare to HTTP/2 over SCTP?
QUIC is somewhat comparable to SCTP. But in both situations you wouldn't be using HTTP/2 on top of it. One of the main points of HTTP/2 is multiplexing several streams over a single transport stream. This isn't needed anymore with QUIC or SCTP, since they already perform stream multiplexing. The only thing which is left is transferring HTTP semantics over those QUIC or SCTP streams. The most simple way to do that would be doing HTTP/1.1 over them. However as far as I know (haven't read the latest state) QUIC uses a more sophisticated mechanism, which also provides header compression and caching across multiple streams, similar to HTTP/2. So it adopted some parts of HTTP/2, but isn't really HTTP/2 over QUIC/SCTP.
Re: Some notes about HTTP/3
#56Interesting comment under the post:
>The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested link with another one implementing BBR, the BBR grabs the lion's share of the bandwidth:
>https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf
>QUIC specifies NewReno as default and mentions CUBIC, but the choice of algorithm is left to the implementation. I can easily envision Google using BBR for connections between Chrome and Google properties, which means Google traffic would be prioritized over competitors'. Over time, more players would implement BBR in a race to the bottom (or a tragedy of the commons) and Internet brown-outs as in the 1980s and 1990s would come back.
https://blog.erratasec.com/2018/11/some-notes-about-http3.ht...
Re: Some notes about HTTP/3
#57have any of you geniuses figured out this will break websites for tor users yet?
Is there anything that prevents Tor from supporting this protocol?
Re: Some notes about HTTP/3
#58Earlier quoted context omitted.
Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.
Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.
There are a ton of IPv4 firewalls and middleboxes that have stateful tracking even when NAT is not in use.
Re: Some notes about HTTP/3
#59Is QUIC only built for HTTP or can it be also used as a secure infrastructure for any L7 protocol?
[deleted]
Re: Some notes about HTTP/3
#60Is QUIC only built for HTTP or can it be also used as a secure infrastructure for any L7 protocol?
The latter.
In fact, as I understand it, the point of the rename to HTTP/3 is to distinguish the QUIC-HTTP bindings from the QUIC-by-itself protocol.