Aspnetcore: Support QUIC

[ststeiger]

Support QUIC on Kestrel
Page-load speed (and quality), and therefore QUIC, affect google-ranking.

Like HTTP/2, QUIC multiplexes multiple streams into one connection, so that a connection can serve several HTTP requests simultaneously. But HTTP/2 uses TCP as its transport, so all of its streams can be blocked when a single TCP packet is lost—a problem called head-of-line blocking. QUIC is different: Loss of a UDP packet within a QUIC connection only affects the streams contained within that packet. In other words, QUIC won’t let a problem with one request slow the others down, even on an unreliable connection.

Source: https://cloudplatform.googleblog.com/2018/06/Introducing-QUIC-support-for-HTTPS-load-balancing.html

[TechnikEmpire]

https://github.com/aspnet/KestrelHttpServer/issues/1980

[ststeiger]

QUIC is a quickly emerging standard that is looking to improve perceived performance of connection-oriented web applications that are currently using TCP. When QUIC comes around we'll want to be able to support it with the same abstraction.

It has come around ;)

[TechnikEmpire]

Meh. The only reason I was googling it is because I'm looking at a problematic situation and I think it's caused by chrome and quic. Frankly I find it disgusting that Google has forced their own protocol on the world simply by exploiting their own users on their own products.

No one was interested in QUIC and if it were anyone else, it would have died in a dark hole years ago. But because its Google and because they forced it on the world through chrome and Google services, here we are all giving up and adopting it.

[ststeiger]

Meh, QUIC is a quick-fix for the problems of SPDY.
And SPDY was the precursor of what simply took way too long to become HTTP/2.0.
So see it as HTTP/2.1 or HTTP/2.0-rev1
And I guarantee you because HTTP/2 improves TLS performance with TLS1.3 and frees you from the 2 concurrent connections limitations, as well as from sprites and bundling, EVERYBODY is going to be interested in HTTP 2.0 resp. 2.1
And it would be a bit sad if a website didn't load because an image couldn't be transmitted.

Also, quic offers 0-RTT, low-latency, lower congestion network transport.

You might want to read:
Introducing Zero Round Trip Time Resumption (0-RTT)
0-RTT is now enabled by default for all sites on Cloudflare’s free service.
Also, you would want a good place in the techempower latency benchmark.

https://github.com/mholt/caddy/wiki/QUIC
https://github.com/lucas-clemente/quic-go

There's also quic-protocol-buffers
https://github.com/google/proto-quic/tree/master/src/third_party/protobuf/csharp
and a C# implementation
https://github.com/seanmcelroy/QuicDotNet

[muratg]

We'll revisit this after 3.0.0 ships.

[hismichael]

It seems that the HTTP/3 stack (or HTTP over QUICK) is quite different from its previous versions.

[gradx]

3.0 shipped, please reopen

[davidfowl]

cc @jkotalik

[jkotalik]

I'm drafting an announcement for our plans with QUIC and HTTP/3 for 5.0 soon. Exciting things are coming 😄. I'll re-ping this issue when the announcement is made.

[jkotalik]

Announcement here: https://github.com/aspnet/Announcements/issues/393. Going to close this issue for now as it will be eclipsed by other individual issues.