TCP sliding window includes the send window and the receive window. Let’s start with the relatively complex one — the send window.
The diagram above is a snapshot from the sender’s point of view. We can categorize the data into 4 groups:
Category 3 is also referred to as the usable window because this is the window the sender can use.
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.
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 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.
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
http2s schemes. We continue using the
https. This decision avoids so much trouble in upgrading the protocol.
While keeping the semantics as is, HTTP/2 introduces new “syntax”, featuring:
The ultimate goal of the TLS handshake is safely exchanging the master secret for future secure communication.
It takes 4 steps to complete the handshake before sending the first encrypted request from a browser:
Let’s take a look at the details.
The handshake starts with the Client Hello message from the browser. The message includes:
The random number is essential, and we will use it later. Let’s put it aside for now.
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
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.
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:
They are not exclusive. You can use all means together depending on use cases.
To compress data, we need…
a coder 👨💻