TCP, DNS, and TLS

What happens before HTTP starts

Everything we have covered so far, the methods, status codes, headers, and bodies, that is all HTTP. But HTTP does not just magically appear. Before any HTTP message can be sent, three things have to happen: the client has to find the server (DNS), establish a connection (TCP), and encrypt it (TLS). These steps happen every time you make your first request to a new server, and they add real latency. Understanding them helps you understand why things are sometimes slow and what you can do about it.

DNS: finding the server’s address

When you request https://api.example.com/books, the browser does not know where api.example.com physically is. It just has a name. It needs an IP address, a number like 93.184.216.34 that identifies a specific machine on the internet.

api.example.com -> 93.184.216.34

The browser asks a DNS (Domain Name System) server to translate the name into an address. Think of DNS as a phone book for the internet: you look up a name and get a number.

This lookup takes 10 to 100 milliseconds on the first request. But the result is cached, so subsequent requests to the same domain skip this step entirely. That is why the first page load is slower than subsequent ones.

TCP: establishing a reliable connection

HTTP messages travel over TCP (Transmission Control Protocol). TCP is the layer that guarantees your data arrives reliably, in order, and without duplication. It is what makes HTTP work over an unreliable network like the internet.

Before any HTTP data can be sent, the client and server need to establish a TCP connection through a process called the three-way handshake:

Client                    Server
  |--- SYN ------------->|     "I want to connect"
  |<-- SYN-ACK ----------|     "OK, I accept"
  |--- ACK ------------->|     "Great, we are connected"

SYN is the client saying “I want to connect.” SYN-ACK is the server saying “OK, accepted.” ACK is the client confirming. After these three messages, both sides can send data.

This takes one round trip. On a 50ms connection, the handshake adds 50ms of latency before any HTTP data is sent.

TLS: encrypting the connection

If you are using HTTPS (and you should be), there is another step after TCP: the TLS (Transport Layer Security) handshake. This is what makes the connection encrypted, preventing anyone between the client and server (your internet provider, a coffee shop’s WiFi, anyone) from reading or modifying the data.

Client                    Server
  |--- ClientHello ----->|     "I support these encryption methods"
  |<-- ServerHello ------|     "Let's use this one, here's my certificate"
  |--- KeyExchange ----->|     "Here's my part of the shared secret"
  |<-- Finished ---------|     "OK, encrypted connection established"

The TLS handshake adds 1 to 2 more round trips. On a 50ms connection, that is another 50 to 100ms of latency before HTTP can start.

The certificate is important. It proves the server is who it claims to be. When you see the padlock icon in your browser, it means two things: the connection is encrypted (nobody can eavesdrop), and the server’s identity is verified (you are actually talking to example.com, not someone pretending to be example.com).

[!NOTE] The Deploying with Docker course covered TLS certificates (Let’s Encrypt, certbot). This lesson explains what those certificates do at the protocol level: they are part of the TLS handshake that happens before HTTP starts.

The full timeline

Putting it all together, here is what happens before your first HTTP request gets sent:

0ms    DNS lookup (10-100ms)
50ms   TCP handshake (1 round trip)
100ms  TLS handshake (1-2 round trips)
200ms  HTTP request sent
215ms  HTTP response received

200 milliseconds of overhead before the first byte of HTTP data. That is significant, and it explains why a few things matter:

DNS caching matters because it skips the lookup on subsequent requests to the same domain.

Keep-alive connections matter because they skip both the TCP and TLS handshakes on subsequent requests to the same server. Instead of opening a new connection for every request, you reuse the existing one.

HTTP/2 matters because it allows multiple requests to share a single connection, reducing the need to open new connections at all.

The next lesson covers how HTTP connections evolved from HTTP/1.0 to HTTP/2 and why that matters for performance.

Exercises

Exercise 1: Use curl -v https://example.com and look for the TLS handshake in the output. Lines mentioning “SSL” or “TLS” are what you are looking for.

Exercise 2: Use curl -w "%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer}\n" to measure DNS, TCP, TLS, and first byte timings separately.

Exercise 3: Make two requests to the same server. Compare the timing. The second request should be faster because DNS is cached and the connection is reused.