How Web is limited by the speed of light?

Almost always, when talking about the performance of a website, we are talking about the time the user waits for some event (“First Meaningful Paint”, etc.). We often discuss front-end and back-end optimizations. And this is cool, but the root of all troubles remains — the speed of light. Often Web developers overlook this problem 😀

Can it happen that in 30 years the Internet will be so fast that a site from a server in San Francisco will instantly open in Kyiv? Physics says no.

Let’s assume:

1. Your backend renders a page (or generates JSON) in 20ms.
2. There is no WiFi, providers, routing, etc. There’s just a fiber optic cable that’s plugged into your laptop at one end in Kyiv and directly into a server in San Francisco with the other end. The distance in a straight line from Kyiv to San Francisco is 9.848 km (let’s take 10 thousand km for ease of calculation).
3. The speed of light in a vacuum is 300 thousand km per second, the speed of light in an optical fiber will be lower — 200 thousand km per second.

If we calculate the time that our request will take in transit, then we get 100ms (10k/200k*2). The speed of light will not allow you to get the answer faster. We add the request processing time and we get 120ms — 6 times longer than our request processed on our backend.

Okay, we already figured out that we will never play CS:GO with the guys from San Francisco with a ping below 100ms. Let’s move on :)

Before requesting data from the server, we must establish a network connection. The HTTP protocol runs on top of TCP (usually), so we need a TCP connection to the server.

To establish a TCP connection, the so-called “TCP 3-way handshake” is used, and now our request looks like:

We don’t spend extra 50ms after the TCP handshake, since we can start sending the request immediately after sending the ack, we don’t have to wait for a response from the server. The server, as it accepts ack, considers the connection open and immediately starts processing our request.

That is, the user will receive a response in 220ms, 11 times longer than our backend worked out.

But we are using HTTPS and we need an SSL/TLS connection and it is over TCP and it has its own handshake mechanism for exchanging encryption keys and this needs to be done before we send our request to the server.

Our schema becomes:

That is, in conditions that cannot even exist, when a user has a 10 thousand km long fiber optic cable plugged directly into laptop and the server, the response will arrive in 420ms, 21 times longer than our backend is working out. This is without taking into account the fact that we still need to request DNS server at first to get the server’s IP address.

If you a web developer (whether frontend or backend) you can be limited by the speed of light 🙂

To be continued…

PS: The post was inspired by the “High Performance Browser Networking” book by Ilya Grigorik. It is a book that I highly recommend to everyone who does web development!

Originally published at https://www.linkedin.com.