Right now, however, it's time for some hands‑on,
so let's go ahead and open up our local copy of Wireshark and get out Lab1,
Hands‑On With QUIC.
So now we have Wireshark fired up,
and if we look at the lower‑left‑hand part of the screen,
we can see what trace file we've opened up,
and we can see Lab1‑QUIC,
so go ahead and join me there on your copy of Wireshark.
So as we can see, this is a simple conversation.
It's only 88 packets that we're looking at here,
and what the client first does is it has to go resolve the youtube.com name.
As we see, DNS comes back pretty quickly,
and we can see the address that it responds with.
Well, right away, the client turns around in packet number 4,
and it sends out a TCP SYN to the YouTube server.
Now, you might be thinking, wait a second.
QUIC is over UDP, so why are we looking at a TCP SYN?
Well, it's not uncommon right now, at least,
to see a browser first knock on the door,
so to speak,
of a web server to see if that web server is able to
support QUIC in the first place.
So essentially, that's what the client is first doing.
So it goes ahead and sends its TCP SYN, and if I look down a little further,
I can see a little bit more DNS conversation.
But I come down here, I can see a SYN, ACK come back from that server.
Then I see the TLS 1.3 Client Hello to start that TLS handshake.
Well, jumping down a little further, I see a Server Hello.
And not too much further, if I look at packet number 33,
that's where I see the first QUIC packet in the trace.
Now, for this lab,
we just want to take a quick peek at QUIC and see what it looks like.
And as we go through the class, we're going to dig deeper and deeper into it,
even decrypting QUIC to understand what's going on in the encrypted payload.
But to focus here, let's go and go up to our display filter,
and I'm going to come up here and just type in Q‑U‑I‑C,
and that's QUIC,
and that will filter for only the QUIC packets that I have here in this trace.
Now, I'm just going to tell you right now, this is an encrypted conversation.
So if you look at the Protocol column,
you can see only the QUIC protocol; however,
if this was decrypted, you would see QUIC along with HTTP/3.
Now, a little bit later in the course,
I'm going to show you how we can decrypt this and
get into that encrypted payload.
But for now, let's just take a quick snapshot at how QUIC really works.
So as we can see here, the client is sending this first packet to the server,
and let's go ahead and take a look at the Header values here.
If I select that first packet, and I want to come down to my detail view,
and I'm going to go up to the top, so here,
I can see that within this packet I have my standard headers
that I'm pretty comfortable with seeing,
but this is where things get into QUIC, so UDP destination port 443,
and this is what will make Wireshark dissect this as QUIC.
So within this UDP payload, I can see that I have two QUIC headers.
Now,
it's common to see with the Initial packet that goes off to a
server that the second one is just padding,
and really, Wireshark is telling us this.
This is basically packing peanuts that's padding this
packet out to the packet length of 1399.
Now, that's one interesting thing about QUIC.
It usually comes out the gate,
starting with larger packet values that are padded out,
unlike TCP that starts out with a very,
very small packets and then the large data filled
packets come a little bit later,
so that's something that we can observe about QUIC.
But let's go ahead and open up one of these QUIC frames.
If I expand this, here, now, I start to see some of the Header values of QUIC.
So what the client is doing is basically sending the
Initial packet of the conversation.
This is a Long Header, and within that Long Header we define our version of QUIC.
So here, we're using draft‑29 of QUIC.
Also here, within the Header, we can see the Connection ID.information.
So here, I see Destination Connection ID.
The Length of that ID is 8 bytes.
Well, right beneath that, this is the actual Connection identifier.
At the same time, the client is identifying itself,
the Source Connection ID Length: 3 bytes,
and this is the identifier for the source side of the connection.
So this is how, initially,
the client is going to identify this unique QUIC connection.
In a way, think about this almost like port numbers with TCP.
I got my client side, and I got my server side.
Now, down here, I have my Packet Number,
and that identifies the actual packet within QUIC should
this packet ever need to be retransmitted.
Also, within the Initial packet,
the Initial QUIC packet that goes off to the server,
I also see that I have already embedded my TLS 1.3 Client Hello.
So right here, right out the gate, we can see that QUIC saves us some time.
Now, if this was TCP, we first would have had to set up a TCP handshake,
establish that connection, and then we can send the TLS 1.3 Client Hello,
but here, we were able to send it immediately with the first packet.
Now, within that TLS 1.3, this is just standard TLS 1.3.
So if I come down here,
I can see the Cipher Suites that the client is offering to the server.
Also, if we come down to the server_name part of the TLS Client Hello,
we can see which server name we're connecting to,
and there's youtube.com.
Also, let's take a look at the application_layer_protocol_negotiation.
So down here, we are indicating to the server that we want to talk h3,
so HTTP/3, over draft‑29 QUIC,
so the server would also have to support that version.
And not to get too deep in the weeds with TLS,
we have all of our other different TLS info that goes along with a Client Hello.
But what I want to do is come down here to our quic_transport_parameters.
So much like with a TCP SYN how we offer the options to the server and the
server comes back and sends its options back to us, in a similar way, that's
what the client and server do with these Initial packets.
Really,
this is establishing the parameters of the conversation.
Now, we're going to get deeper into this information as
we go throughout our course.
But just to highlight a few things for you here, first,
we have our initial_max_stream_data unidirectional and bidirectional.
So basically,
if you think of this as it kind of acts almost like a window size. Also,
coming down here to streams, unidirectional and bidirectional,
we can support up to 16 streams within this QUIC conversation.
So in this part of the initial header, this is where some of those parameters are exchanged between client and server.