The Connection request and the TLS Client hello are happend in the same packet.

The ACk for the connection request and the TLC Server hello is in the response packet for the request

Only in the initial converstion (1 request, 2 ACK, 3 client ACk) the headers of the QUIC is clear text after that the all the packets of the QUIC is encrypted

TCP Roundtrips

QUIC Roundtrips

Header Security

TCP Headers are clear text

Protocol Stack

Standard TCP Web

QUIC stack

HTTP/3 over QUIC

Cons of HTTP2

QUIC

PCAP

TLS is inside QUIC

TCP to QUIC handoff

Clients often first will check in with a server over TCP before they attempt a new QUIC connection.

Especially since so many servers don't yet support it, a client just can't come out of the gate with just a QUIC connection.

At the same time, on the client side, there's many browsers that don't yet default to QUIC, so a server, at this time, can't be exclusive to QUIC either.

Now, in the future, as QUIC is more widely adopted, clients will be able to use QUIC at the first packet. In fact, if we've already visited a site in the past and QUIC was supported, then this is a function that we could use, even now.

Now, if the server does support QUIC, it can suggest an alternate service to the client using an HTTP redirect, so the client will start over TCP, but the server will suggest the connection move to QUIC.

Now, let's take a look at how that handoff will work in some scenarios. Bear in mind that not all scenarios work this way, but this gives us an example of how a possible QUIC handoff could work for an application. So the first step, like normal, like we're accustomed to, the client initiates a TCP handshake to connect to the server over TCP. Immediately following this, it starts a TLS handshake to set up the encryption of the session. After this process, it can start to request data from the application server. Now, at this point, the server can respond and suggest to the client that the conversation continue over QUIC using an alternate service advertisement.

*Note: This is just an example but in the real world this is not the case always. (but TCP to QUIC handoff can also occur in this way)

• After the TCP connection and TLS exchange when the Client request a data the Server replies for the request and also it has the Header alt-svc

alt-svc : Alternate Service. The Server says here are my alternative service you might use it.

h3-29 - HTTP/3 over QUIC (draft-29 is the version of QUIC)

Now client can switch to QUIC if it supports,

QUIC Handshake

old way

Time to First byte, meaning, how much time does it take until the first byte of actual application traffic is received on this connection.

QUIC handshake

QUIC Connection

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.

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.

Streams

Stream has its own parameters for the data transfer

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.

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.

Streams in a single QUIC connection and its Application data along with it

Packet/Frames

Note: The Padding is done when the QUIC payload is smaller so that Network Device could drop that packet so QUIC adds a Padding to fill the empty space.

Test QUIC Connection