TCP sliding window includes the send window and the receive window. Let’s start with the relatively complex one — the send window.

Send Window

The diagram above is a snapshot from the sender’s point of view. We can categorize the data into 4 groups:

  1. Bytes that sent and acknowledged (blue)
  2. Bytes that sent but not yet acknowledged (yellow)
  3. Bytes that not sent and the recipient ready to receive (green)
  4. Bytes that not sent and the recipient NOT prepared to receive (grey)

Category 3 is also referred to as the usable window because this is the window the sender can use.

The send…

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.


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.

In the early era of the network, people send files in single-digit KB size. In 2021, we enjoy hi-res MB-size images and watch 4K (soon 8K) video in several GB.

Even with a good internet connection, it still takes a while to download a 5GB file. If owning an Xbox or PlayStation, you know how it feels.

We have three ways to shorten the time sending extensive data by HTTP:

  • compress data
  • send chunked data
  • request data in a selected range

They are not exclusive. You can use all means together depending on use cases.

Compress data

To compress data, we need…


a coder 👨‍💻

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store