IP and MAC layers have restricted memories to send packets. Consequently, both will limit the length of messages.

This restriction requires TCP to package variable-length bytes into several segments before serving them to the IP layer. Each segment should be in an appropriate length.

Here is a simple diagram showing how segments are sent through the internet.

The client’s HTTP layer is sending an 18-byte stream to the target server.

While byte 16–18 yet to reach the TCP layer, byte 12–15 is passed through it. …

Handshake has a purpose — exchanging information to establish a connection.

Why we need a connection? The answer relates to the role TCP plays.

It is easier to understand it by looking at our day-to-day activity — visiting a web page.

Browser initializes a GET HTTP request. With the help of IP and MAC layers, the request finds the best route to the destination.

DNS message is relatively simple: the browser queries a domain name and gets an IP address.

If a DNS server doesn’t recognize the domain name, it will pass the query along to the following DNS server. Later, when receiving a response, it carries the response to the browser.

Interesting in how DNS resolution works? Hope this post could help.

Query Message

Though HTTP/3 is still in draft today, teams such as Shopify and Medium have implemented it in production.

Here is a screenshot of Medium homepage requests. Most of them are through the HTTP/3 protocol noting as h3-29.

The h3 stands for HTTP/3, and the 29 is the implemented draft's version.

Though the latest draft is version 34, all known teams choose version 29 as it was a significant update. The differences in later versions are minimal.

Why we need HTTP/3? An important reason is solving the head-of-line blocking issue.

Head-of-Line Blocking on HTTP/2

TLS helps improve security. Now it is time for performance enhancement, the focus of HTTP/2 design.

The first challenge is making it compatible with HTTP/1.x.

To achieve it, HTTP/2 inherits semantics from HTTP/1.x, including request methods, status codes, headers, etc.

Most importantly, it inherits the scheme design. There is no http2 or http2s schemes. We continue using the http and https. This decision avoids so much trouble in upgrading the protocol.

While keeping the semantics as is, HTTP/2 introduces new “syntax”, featuring:

• connection preface,
• header compression,
• binary-encoded frames, and
• streams.

Connection Preface

The ultimate goal of the TLS handshake is safely exchanging the master secret for future secure communication.

TLS 1.2 Handshake

It takes 4 steps to complete the handshake before sending the first encrypted request from a browser:

1. Client Hello
2. Server Hello
3. Client key exchange and generate the master secret
4. Finished

Let’s take a look at the details.

Step 1 — Client Hello

The handshake starts with the Client Hello message from the browser. The message includes:

• the TLS version,
• a 28-byte random number (Client Random), and
• a list of cipher suites.

The random number is essential, and we will use it later. Let’s put it aside for now.

Step 2 — Server Hello

…

HTTP is the abbreviation of Hypertext Transfer Protocol. Its name tells us a lot.

Protocol

An HTTP request is expensive.

Whenever possible, we reach out to cache, which keeps (almost) the latest resource.

Cache lives at every node of the network, including

• clients (in our context, browsers),
• proxy servers, and
• origin servers

Two-players: browser and origin server

Cache-Control from the server

If you have saved an edit in a Medium post, you want other visitors to see the updated one.

Which player knows whether the content is the latest one?

A browser doesn’t know without sending a request. The server holding resources is the one knowing it.

With the Cache-Control header, the server informs the browser when to use cache or request new resources.