What advantage does QUIC have over TCP?

What advantage does QUIC have over TCP?

I was updating my post, while you were typing :)

I think you can find more information here :
[ietf.org...]

The easy peasy simplified QUIC definition: HTTP2 over UDP.

Note: when reading about it pay attention to the date, the current IETF development standard has significant differences to the initial Google critter of the same name.

A major technical hindrance is that many/most extant middle boxes, routers, et al don't recognise it as 'web' traffic even though it arrives at Ports 80 and 443. Instead, unable to identify the protocol they default to treating it as generic layer 4 UPD. Besides not 'working' this is a potential security hole large enough to drive a supertanker through.

Additional concerns are that, by it's current nature, it is impractical/impossible for a browser to enforce 'safe' search or to restrict access. Conversely, it is currently impractical/impossible to pre-emptively identify and stop malware et al downloads. Etc.

It definitely has it's benefits. It, also, definitely has critical drawbacks. Therefore I see QUIC having an uptake similar to IPv6 ... a good idea but with substantial headwinds without an urgent driving impulse.

Note: most/all Google apps have been using QUIC to communicate with the mothership for quite some time as has Chrome browser (on by default)..

Just as I was beginning to look at and 'get' the finer details of HTTP 2.

Not sure what to think of the Google inspiration behind both 2 and 3, though to be fair to them if anyone has their hands dirty with dealing with the webs protocols and its implementations, it's them.

I can't recall many threads ranting about the limitations of the latest HTTP protocol... but it'd be interesting to hear what people think about the direction/evolution of them.

Additional concerns are that, by it's current nature, it is impractical/impossible for a browser to enforce 'safe' search or to restrict access. Conversely, it is currently impractical/impossible to pre-emptively identify and stop malware et al downloads. Etc.

I remember some talks arguing that if Google was developing it, this is to bypass ad blockers :) but I have no idea if this is true or not.

but it'd be interesting to hear what people think about the direction/evolution of them.

I am only talking about my "own" experience, which might not apply to everybody of-course.

So in "my" situation and HTTPS sites:

- HTTP/2 is faster than HTTP 1.1 by 20%, which is not to be neglected,

- HTTP/2 has a PUSH feature that I love. When used wisely, it can great optimize the speed of web sites, and first paint, which, on mobile device is great.

It was my understanding that QUIC is not nessarily faster than HTTP/2, particularly when network conditions are good.

QUIC is not HTTP over UDP

QUIC is a TCP + TLS replacement that works over UDP.

So it is HTTP over QUIC (which in turn is over UDP)

Just realised the title of the thread is wrong too. HTTP/3 is not "aka QUIC". it is "aka HTTP over QUIC"

Just realised the title of the thread is wrong too. HTTP/3 is not "aka QUIC". it is "aka HTTP over QUIC"

Indeed. May be a mod can edit the title.

title edited to add "HTTP over"

Just for the info, only two web servers are already supporting "working draft" of QUIC in their "production" versions.

- LiteSpeed WebServer : [litespeedtech.com...] (not the OpenLiteSpeed version)

- Caddy WebServer : [caddyserver.com...] (both the paid and open source version are using quic-go)

Nginx, Apache, H2O... have QUIC implementation (not necessarily the latest draft) in their experimental / under development versions.

Additional read about HTTP/2 and QUIC (from last February, but still interesting) : [callstats.io...]

The Callstats post is interesting. It seems they are replacing websockets with WebRTC and this is connected to the move toe HTTP/2.

Why is no one trying to replace/upgrade TCP altogether instead of running a TCP replacement over UDP? Too hard to get traction?

My understanding (which can be very wrong), is that TCP is too "ossified", so UDP might offers more flexibility.

I understand they want to replace TCP, but why not a "TCP 2" or "QUIC over IP" rather than "QUIC" over UDP? Why not look to provide the replacement at the level TCP and UDP operate at rather than layering it over UDP?

Nginx, Apache, H2O... have QUIC implementation (not necessarily the latest draft) in their experimental / under development versions.

Do you happen to have a link to a source for nginx? I can't seem to find anything recent.

Do you happen to have a link to a source for nginx? I can't seem to find anything recent.

Indeed. I put nginx in the list because of this page : [w3techs.com...] , where it looks like 5.2% of QUIC enabled sites are running under nginx, so I assume there is an experimental module somewhere, but the only one I could find was not updated since 3 years(!)

Implementations of QUIC:
[github.com...]

the only one I could find was not updated since 3 years(!)

That's probably the one with just a bit of boilerplate content; it's not a working module.

I can't find any actual implementations, so maybe those stats come from nginx running behind a server with QUIC support. Or the stats may be bad, given that there are allegedly IIS servers [w3techs.com] running QUIC.

QUIC support for Nginx is a request since 2 years : [trac.nginx.org...] , but apparently, no words from the nginx developers. This is surprising because nginx was a very early adopter of the SPDY (ancestor of HTTP/2) , even before the standard was finalized. So, nginx liked to surf on the edge of technologies. Now, it's not a big deal either.

Additional reading : [dev.to...]

An issue which is arising with the new http/3 protocol, is that it consumes twice more CPU resources than http/2. This will certainly be improved as the protocol mature, and later when it will be part of the kernels but still, ...

Hi, sorry to bump an old thread. But I thought this is as good as any. I just noticed that Cloudflare enabled HTTP3 on my site. However, none of the popular browsers are using HTTP3 when accessing my website. But Chrome is switching to Quic when accessing google, youtube, gmail etc.
Is there any way to send out any 'signal' -- other than the h3-23 header -- to get Chrome (at least) to start accessing it via HTTP3?
If not, what exactly is the point of enabling h3 on a site right now? I know Canary can be made to use h3 by turning on a certain flag at the time of starting it. But that's not what I have in mind.

Hello-

If not, what exactly is the point of enabling h3 on a site right now?

Testing the protocol. Detecting possible issues. And in all events, everything has to have a beginning :).

About Cloudflare, this is also for marketing purpose, and make the buzz, showing they handle all the most recent and modern stuffs.

As for Chrome and google's sites, it's because these sites are not using the HTTP/3 protocol, but still the HTTP/2 + QUIC version. For example, if you use the LiteSpeed WebServer, which handles several drafts of the "QUIC" protocol. You can serve HTTP/2 + QUIC pages to Chrome's users.

ps: the H2O web server handles HTTP/3 too.

I had tested Caddy community edition a year ago, and about 35% of my total traffic was going via UDP, which was quite decent. It was also QUIC.

But I couldn't continue with caddy because it didn't handle certain rewrite algorithms, such as reusing part of the url using placeholders.

Any idea if h2o handles such rewrite logic?

Example - (Nginx) --- location ~ ^/([0-9]+)_(.*) {return 301 /a/1/$1_$2;}

Hello-

I don't think that H2O has a rewrite engine. They use the mruby scripting for this kind of things, but I never looked at it (no need for my usage).