The Illustrated QUIC Connection | Hacker News Reader

The Illustrated QUIC Connection

quic.ulfheim.net

185 pointscaust1c37 comments

Having lived through a production datacenter meltdown due to software engineers throwing away TCP, along with stuff like slow start and congestion control, and obliterating ethernet switch buffers with UDP, I'm a bit concerned as to how QUIC is supposed to be used in order to avoid that?

If your fabric has end-to-end flow control this would be fine, but this seems like it could be greatly misused and should come with some warning labels.

https://web.archive.org/web/20220328033933/https://datatrack...

They copied directly from TCP and made several adjustments to improve signalling.

Oh that's a relief.

Looks like someone finally did the "lets replace TCP with UDP" job right.

And it looks like a hell of a lot of work.

That’s the hope, anyway. It’s hard to compete with decades of TCP refinement but at least there’s some big guns behind making this work.

There’s a lot of thought that has gone into QUIC and the protocol has several rules and mechanisms to prevent problems, such as the 3x amplification limit. Both the browser authors and server side (e.g. google) are on the lookout for problems and how they can improve on them.

There's a new Homa protocol specifically designed for data center to replace TCP by Ousterhout (TCL/TK and Raft author).

Ousterhout is now looking for people to test the Homa protocol for the data center to improve its implementation [1].

[1]Linux implementation of Homa, a protocol to replace TCP for low-latency RPC:

https://news.ycombinator.com/item?id=28440542

The TLS 1.3 explanation (https://tls13.ulfheim.net) and others on the same site are also excellent.

A protocol that only works on the whim of a third party corporate person is not optimal for human people. Baking in a requirement of CA based TLS is not great.

>TLS: Certificate, the certificate for this host, containing the hostname, a public key, and a signature from a third party asserting that the owner of the certificate's hostname holds the private key for this certificate

And your solution is?

DNSCurve's self-authenticating domains: https://en.m.wikipedia.org/wiki/DNSCurve

It's like "onion URLs" without the rest of Tor. Or like b32.i2p domains without the rest of I2P.

I hope to god this catches on. At this rate it won't, because a FAANG company isn't supporting it. But I still hope somehow it will catch on. DJB's work is fantastic and this is no exception.

I don't believe it will catch on. Consumers don't care about security. Engineers do, but not at expense of usability.

It's very simple. Allow not using encryption. Plain text + encrypted make a great team. Either by themselves is not great.

You can generate your own root cert and self-sign. No need for third-parties.

Do mainline browsers (chrome/firefox/safari) accept this? Do they do it without scaremongering warning the prevent access like with normal TLS and self-signing?

You import your "CA cert" into the browser or the underlying operating system, and then the browser accepts the certs signed by it.

I found minica very useful to do something like this (no affiliation): https://github.com/jsha/minica

Author here; let me know if there are any comments or questions I can answer.

Does anyone understand how TLS is happening over UDP? I thought TLS was a TCP-based protocol

Quic can have multiple streams. Every stream is guaranteed to be ordered like TCP. The TLS is wrapped in "CRYPTO-frames" whose content is passed verbatim to TLS. Quic does require collaboration with TLS. There are a couple of events in which TLS calls the Quic implementation, for example for TLS state changes.

What I dont quite get is how the individual streams are encrypted. As I understood it, the initial vector(IV) is generated during the initial handshake, so all the streams would reuse the same IV which could make it leak the requested file.

I'm reasonably sure that the encryption uses packet numbers, which are global across the entire connection.

Each endpoint maintains a packet number, starting at 0 and increasing by one for each packet sent. This is an input to the packet encryption IV.

Note that unlike TCP retries do not re-use the packet number, they get a higher packet number on re-transmit. This lets endpoints differentiate packet retries from delayed packets, which isn’t possible in TCP (and the ambiguity of which is a problem in TCP stacks that want to react differently to each).

There is a separate standard for TLS over UDP, namely DTLS which is unrelated to QUIC. (https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...)

TLS is not TCP specific.

DTLS is regularly used in IoT applications such as smart metering where the overhead of a TCP stack is costly.

It's almost identical to TLS over TCP, the main difference is that QUIC is responsible for reliable delivery of packets/frames once the TLS handshake is complete. The handshake itself is done in a special CRYPTO frame [1].

1: https://greenbytes.de/tech/webdav/draft-ietf-quic-tls-latest...

Ironically TLS is not suited to TCP. TLS is record-based, and the stream-based TCP doesn’t have record boundaries.

TLS-over-TCP solves this by sending TLS records with a type-and-length byte header. QUIC uses UDP which is more record based, and sends TLS records encapsulated in QUIC packets.

yes and no. The TLS records are transmitted in CRYPTO frames, which form a crypto stream (just like a TLS stream) that is more or less transparent to the QUIC stack. QUIC implementations forward an arbitrary datastream from the peer into the TLS library, and place the data that is produced by that stack again onto the ordered bytestream. There's no record layer for CRYPTO streams - that one would again be above on the TLS layer.

Quic is a great protocol but IIUC you have to apply a user space library for things that normally (TCP) is kernel/hardware. Well, at least in my own experiments with a Golang implementation, I've seen CPU be the bottleneck for high bandwidth transfers (MTU is ~1300b). Add to that that common OS:s don't give you a particularly large UDP receive buffer, which can cause a BDP bottleneck for high latency connections.

There's no fundamental reason quic couldn't happen in kernel-space, it just hasn't been done yet.

That's true, and maybe lower-level optimizations will start to emerge. But I suspect QUIC was intentionally left in userspace to allow for more rapid development. Indeed there are already many libraries available which means you can use it today. If we had to wait for kernels and middleware to support it, that might still be years out.

I agree, and I think userspace development was a good idea. I also don't think it needs to stay in userspace forever.

In particular, ideally we'll have kernel support that allows for more capable userspace stacks to run, and also allows just opening a socket.

Msquic can be built as a driver. https://github.com/microsoft/msquic/blob/main/msquic.kernel....

Do any browsers API's support quic ?

https://caniuse.com/http3

Latest Chrome and Firefox both do.

Make sure the server sends h3 with the alt-svc (http) header and adds h3 to the (tls v1.3) alpn. The browser may connect to h1 or h2 endpoints at first, then upgrading it to h3 for subsequent connections where supported (provided, the firewall isn't blocking QUIC).

https://tools.ietf.org/id/draft-ietf-quic-http-23.html#rfc.s...

Although the newer HTTP protocols have ALPN names like h2 and h3, the older ones are named http/0.9, http/1.0 and http/1.1

I mean if I can access it from javascript, like webrtc.

Chrome actually has deployed a version of WebTransport, which is basically a way of using QUIC directly from the browser for datagram/stream connections (e.g. to implement game networking, in browser.) But it's relatively new, and you need to modify the QUIC stack in order to accept and handle WebTransport connections; so it doesn't "just work" out of the box with any popular QUIC libraries I know of.

It's unclear where this will all end up right now; you'll probably have to wait a bit for it to be production ready. But there's clearly broad interest in the topic, though.

If you do a HTTP request in Javascript using any of the available APIs (fetch, XHR), it would automatically use HTTP/3 for those requests if the peer is known to understand HTTP/3. No special APIs are needed unless the protocol you care about is on top of QUIC but not actually using HTTP/3. As the sibling comment mentions, WebTransport might help with non-HTTP use-cases.

Reply on news.ycombinator.com