Now, when working with QUIC,
it's important to understand the difference between connections and streams.
So let's learn a little bit more detail about these concepts.
So first, let's define what a connection is.
Now, basically, it's a shared state between a client and server.
Now, each connection must first start with a handshake where the two
endpoints establish a shared secret for encryption, they negotiate the
application layer protocol that will be used,
and they establish the transport layer parameters, for example,
like the amount of data that can be sent or received at once. For
connections that are no longer needed or used, these can be closed by
being idle for too long and timing out,
exchanging close frames to indicate that the connection
should be closed, or much like TCP, they can abruptly be closed.
Now, each QUIC connection has a unique identifier
called a connection ID at each endpoint.
Now, in most cases, clients will initiate the connection.
So in the initial packet that they send, unless there
was a previous connection history,
they identify the connection identifier that they'll be using,
and advertise that to the server, as well as choose an 8‑byte
unpredictable value for the server side.
Now, one big reason for this long,
unpredictable value is that any passive observers on the wire
that capture this won't be able to tell the contents of the data
or what type of application is in use.
So don't think of these as one‑and‑the‑same as port numbers.
The client and the server will still use a UDP port number,
and we can see that here.
So in this example,
the client is sending the QUIC packet to the server on UDP Port 443. And
really, another port could possibly be used there. Now,
as we'll see in the next slide, connection IDs allow this
connection to continue to be supported, even if the
underlying IP and port numbers change.
Let's check out an example of how that could happen.
So imagine that your phone is connected to a content
server, and because of location, jumps from your home WiFi
connection to the LTE network.
Or maybe along the path, somehow there's a change to the
public port or IP than a NAT router uses when sending
these communications out. Now,
QUIC is designed with this type of change in mind. Now this
presented a big problem with TCP connections.
As we can see here, a client could start with one IP,
which would then be translated into another source IP and possible port number.
But if something changes while the TCP connection is alive,
this would break the TCP connection since the source information changed. Now,
there were some flavors of TCP that were trying to overcome this problem,
but these were not widely implemented.
Now, QUIC can live through this because of the connection identifiers.
It's designed to handle this adjustment and carry the application right along.
So now you can start a YouTube video on your phone at
home, and as you walk out to your car,
the video can continue unscathed on the new cell network
because the QUIC connection is still established.
Another core feature of QUIC is the ability to support streams.
Now, HTTP/2 over TCP, it was already supporting
this type of feature with streams,
but now it's a core‑embedded part of how QUIC works.
So think of streams in a QUIC connection almost like lanes on a freeway.
So, the QUIC connection is the freeway from one shoulder of the
pavement to the other shoulder of the pavement,
and the streams are the individual lanes.
Unlike a freeway lane, however,
a stream can send data in one direction or in both directions.
So in our example here, we have one UDP conversation with
one QUIC connection and four streams.
But QUIC can support many streams,
and those streams can have different types and attributes.
So let's take a look at an example. In that first stream there, a client
is requesting and receiving part of a web page. In the next one, the
client is requesting and receiving an image.
Now, in the last two streams,
we see a flow of data going from the server to the client, maybe this
could be a video stream, and from the client to the server in the final
stream, maybe that's an audio portion of an application. So streams are a fundamental part of how QUIC works.