blog: post about turning QUIC frames into datagrams#494
Open
matheus23 wants to merge 14 commits into
Open
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
matheus23
marked this pull request as ready for review
July 21, 2026 14:14
flub
reviewed
Jul 23, 2026
|
|
||
| These three encryption levels are in the order of increasing guarantees. | ||
| A connection starts out using "Initial" keys, then during the handshake moves to "Handshake" keys and after the full key exchange moves on to the "data" encryption level. | ||
| We only ever send application data using the "data" encryption level, also sometimes called the 1-RTT encryption level. |
Contributor
There was a problem hiding this comment.
The real encryption levels are those that @divagant-martian nicely separated out in the EncryptionLevel enum. I think those names come from RFC9001.
| Using this key it can then process all handshake data, which gives it the necessary information to derive the key of the final encryption level: The data key. | ||
| Although both keys are derived from the ephemeral key shares from the client and server, the data encryption level provides some important guarantees by including a hash of the whole handshake transcript. | ||
|
|
||
|  |
Contributor
There was a problem hiding this comment.
It's odd that you don't include an ACK for the Handshake from client to server here.
| Each packet in the initial or handshake encryption level is a so-called "long header" packet which means it also has a length field indicating where the packet ends. | ||
| This allows us to put two packets prepended with their QUIC headers back-to-back into a datagram. | ||
|
|
||
| This does not work with the data encryption level. In that level the header doesn't contain a length field, presumably to save some bytes, as packet coalescing is pretty much only useful during the handshake and it's worth saving those bytes after the handshake when no coalescing happens instead. |
Contributor
There was a problem hiding this comment.
With a nitpicking view this kind of mixes up encryption levels and packet types. The long header is a 1-RTT packet type. That is kind of orthogonal to the encryption level it goes in.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
My ramblings about QUIC