Okay, so now we've learned quite a bit about QUIC.
Let's take a closer look at streams, packets, and frames in Wireshark.
So now, let's talk about streams, packets, and frames.
So to do this, we're going to open up Lab3, which is QUIC Streams.
And just to remind you how to load the key for that,
I'm going to go to Wireshark, Preferences,
again, if you're on a Windows box, you're going to go to Edit,
Preferences, and we're going to select our Protocols,
jump down to TLS, and down in TLS,
let's go down and select that TLS protocol, this is
what I'm going to say Browse, and we're going to go ahead and load those keys,
and then we'll be able to decrypt this session.
That's really important to do, especially for this.
So first, connections.
Let's talk about that.
So in the Initial packet, this is where a client,
when it talks to the server, it uses a Long Header.
The reason it does that is because it's going to fully identify the
Destination Connection ID and the Source Connection ID.
If you take a look at it later on, you're going to see the client or server,
whichever one is sending to. It only needs to send this to a
certain destination. But at the beginning,
with a Long Header, we have to identify both.
So the client comes in and says, hey, server,
this is going to be an 8‑byte Destination Connection ID, and here's this long,
hard‑to‑determine number.
So it sends this to the server,
and the server will use this to identify this connection.
And again,
the point here is that any passive listener of this connection can't
determine the application based on this information.
So I can't go, oh, great, this is secure web, or, oh,
this is secure FTP, or this is SSH, right, like we could with TCP.
So here,
Destination Connection ID, it's also going to identify on its side
the Source Connection ID, so there's 3 bytes,
and this is the Connection ID that this is going to use on the source side.
So in the opposite direction, let's take a look at the server coming back to us.
We can see, it's using those two Connection IDs in the opposite direction.
But let's jump down from an Initial packet, and in fact,
Initial handshake.
Let's actually go down to where we actually see data starting to move.
So I'm going to jump down to packet number 9, and this is where
I can see the QUIC Connection Information.
If I expand that out,
this is where I can see the Connection Number: 0.
Wireshark is telling me about that.
It's just saying, hey, this is the first full connection that I see.
But this time, QUIC is using a Short Header.
Let's expand that out.
So this is from client to server,
and this time, the client is only identifying the Destination Connection ID.
So, hey, server, there's your connection identifier.
I no longer am going to tell you what mine is, nor do I need
to specify how long yours is, remember,
we used to have an 8 there to show us how many bytes it was, and
then we have a packet number. So we're going to go into that
again in the next module in our course.
So in the opposite direction, let's take a look at Packet Number: 12.
We can see the opposite happen.
The Connection ID, it's only 3 bytes, coming back to the client here,
so that's the destination, this is a Short Header, so this
is how this connection is identified.
Now, it's possible, let's just say that the IPs or port numbers changed,
this QUIC Connection could still live on between these two endpoints. So
QUIC is poised for mobility or for any other path adjustment within the network between the two endpoints.