How DNS, TCP, TLS & HTTP Actually Work

Hey guys, this post is a massive one for any beginner or for intermediate one's in security field as i am sure of it. I explained all the concepts in detail and recommended to complete this post and have a good understanding about How things work behind your device, as of this post we discuss only about DNS ,TCP,TLS,HTTP.

Every time you type a URL into your browser and hit Enter, a surprisingly complex sequence of events unfolds in milliseconds. Most people think "the page just loads" — but underneath there are at least four distinct protocols working together in a precise order.

The full journey looks like this:
1.DNS Resolution — translate the human-readable domain name into an IP address
2.TCP Handshake — open a reliable connection to that IP address
3.TLS Handshake — secure the connection with encryption
4.HTTP Request/Response — fetch and receive the actual web content
5.TCP Termination — cleanly close the connection

This guide walks through each stage in depth. By the end you will understand not just what happens, but why each step exists and what goes wrong when it fails.

1. DNS — Domain Name System
What Is DNS and Why Does It Exist?
Computers communicate using IP addresses (like 93.184.216.34), but humans are far better at remembering names (like example.com). DNS is the system that bridges this gap — it is essentially the internet's phone book, translating human-readable domain names into machine-readable IP addresses.

Without DNS, you would need to memorize a numerical IP address for every website you visit. DNS automates that lookup invisibly, every single time you load a page.

The DNS Resolver
The DNS Resolver (also called the Recursive Resolver) is the DNS client that works on your behalf. When you type a URL, your operating system contacts a resolver — usually provided by your ISP or a public service like Google (8.8.8.8) or Cloudflare (1.1.1.1).

Think of the resolver as a detective. It receives your question ("what is the IP for example.com?"), goes out and finds the answer by talking to other DNS servers, and then delivers the final IP address back to your browser. The resolver does all the legwork so your PC doesn't have to.

--> The resolver is the only server your PC directly talks to during DNS resolution. Everything else — Root servers, TLD servers, Authoritative servers — is handled by the resolver behind the scenes.

The DNS Hierarchy
DNS is organized as a strict hierarchy, like a tree. Every domain name is read from right to left, matching this hierarchy exactly.

            Root  (invisible — the "." at the end of every domain)
             |
    ─────────────────────
    |         |         |
   .com      .org      .in        ← Top-Level Domains (TLD)
    |
example.com                        ← Second-Level Domain
    |

www.example.com ← Hostname / Subdomain

The Four Types of DNS Servers
Each level of the hierarchy has a corresponding type of server with a specific, limited job:

A crucial detail: Root servers and TLD servers never know IP addresses. They only know "who to ask next." This delegation model is what makes DNS scalable to billions of domains.

The DNS Resolution Process — Step by Step
Let's trace exactly what happens when your browser needs the IP for www.example.com. Assume the resolver has no cached answer.

6.Your PC sends the query ("what is www.example.com?") to the Resolver
7.Resolver asks a Root Server: "Where can I find .com?"
8.Root Server replies: "I don't know the IP — ask the .com TLD server at this address"
9.Resolver asks the .com TLD Server: "Where can I find example.com?"
10.TLD Server replies: "I don't know the IP — ask example.com's authoritative server"
11.Resolver asks the Authoritative Server: "What is the IP for www.example.com?"
12.Authoritative Server replies: "93.184.216.34" — this is the actual answer
13.Resolver returns 93.184.216.34 to your PC and caches it for future requests

PC → Resolver → Root → TLD (.com) → Authoritative (example.com) → IP

But why 13 Root Servers? There are 13 logical root server addresses in the world, labeled A through M. But "logical" is key — each is actually a cluster of hundreds of physical servers distributed globally via anycast routing, giving the system enormous redundancy.

DNS Caching — The Speed Optimization
After a resolver retrieves an answer, it stores (caches) it for a period of time defined by the domain owner — this is called the TTL (Time to Live). On the next request for the same domain, the resolver returns the cached answer instantly without walking up the hierarchy again.

Your browser and operating system also maintain their own DNS caches. This is why DNS changes (like pointing a domain to a new server) can take time to propagate — old cached records need to expire first.

2. TCP — Transmission Control Protocol
What Is TCP and Why Is It Used?
Once the resolver returns an IP address, the browser needs to establish a connection to that server before sending any data. TCP (Transmission Control Protocol) is the protocol that creates this connection.

TCP is a connection-oriented protocol, meaning both sides must formally agree to open a session before any data flows. It guarantees reliable, ordered delivery — if a packet is lost, TCP automatically retransmits it. This reliability is why HTTP (and HTTPS) runs over TCP rather than UDP.

The 3-Way Handshake — Opening the Connection
Before a single byte of HTTP data is sent, TCP performs a 3-way handshake to synchronize both sides and establish a reliable session. The process uses special control flags in the TCP header: SYN (Synchronize) and ACK (Acknowledge).

Client ──── SYN ────────────────────→ Server
Client ←─── SYN + ACK ────────────── Server
Client ──── ACK ────────────────────→ Server
↓
Connection established — ready for data

Step 1 — SYN (Client → Server)
The client sends a TCP segment with the SYN flag set and an Initial Sequence Number (ISN) — a random starting number for tracking data order. The ISN is critical for reassembling packets in the right order and for detecting retransmissions.

Step 2 — SYN-ACK (Server → Client)
The server acknowledges the client's ISN by sending back SYN + ACK. The ACK confirms the client's sequence number (client ISN + 1). The server also sends its own ISN so the client can track the server's data stream.

Step 3 — ACK (Client → Server)
The client acknowledges the server's ISN (server ISN + 1). Both sides have now exchanged sequence numbers and confirmed each other is reachable. A full-duplex, reliable TCP session is open. Data can flow in both directions simultaneously.

So, Why do we need Sequence Numbers?
->Sequence numbers let TCP detect lost packets, reorder out-of-sequence segments, and prevent old duplicate packets from being accepted. Without them, TCP would have no way to guarantee ordered, reliable delivery.

The 4-Way Termination — Closing the Connection
Because TCP is full-duplex (data flows independently in both directions), each direction must be closed separately. This requires 4 steps instead of 3.

Client ──── FIN ────────────────────→ Server (client done sending)
Client ←─── ACK ──────────────────── Server (server acknowledges)
Client ←─── FIN ──────────────────── Server (server done sending)
Client ──── ACK ────────────────────→ Server (client acknowledges)
↓
Connection closed

Modern HTTP uses a Connection: keep-alive header to avoid this teardown overhead. With keep-alive, the same TCP connection is reused for multiple HTTP requests to the same server — significantly speeding up page loads that require many resources.

3. TLS — Transport Layer Security
What Is TLS and Where Does It Fit?
After the TCP connection is open, the browser initiates a TLS (Transport Layer Security) handshake before sending any HTTP data. TLS is the cryptographic protocol that turns HTTP into HTTPS — securing communication so that no one eavesdropping on the network can read or tamper with the data.

Protocol Layer Purpose
HTTP Application Web content — requests and responses
TLS Presentation / Security Encryption, integrity, and authentication
TCP Transport Reliable, ordered delivery
IP Network Routing packets across networks

The formula is: HTTPS = HTTP + TLS + TCP + IP. TLS sits between the application and transport layers, wrapping all HTTP data in an encrypted envelope before TCP transmits it.

What the TLS Handshake Achieves
Before any encrypted data can flow, the client and server must agree on three things:
•Confidentiality — which encryption algorithm to use so data cannot be read by outsiders
•Integrity — which hashing algorithm to use so tampering can be detected
•Authentication — verifying the server is genuinely who it claims to be (via certificates)

Cipher Suites — Agreeing on the Algorithms
A cipher suite is a named combination of cryptographic algorithms that defines how the TLS session will be secured. For example:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The client sends a list of all cipher suites it supports. The server picks the strongest one it also supports. If there is no overlap, the TLS handshake fails and the connection is rejected.

TLS 1.2 Handshake — Step by Step

Client ──── ClientHello ────────────────────────→ Server
Client ←─── ServerHello + Certificate ────────── Server
[Client verifies certificate]
Client ──── Key Exchange ───────────────────────→ Server
[Both derive session keys]
Client ──── ChangeCipherSpec + Finished ────────→ Server
Client ←─── ChangeCipherSpec + Finished ──────── Server
↓
Encrypted HTTPS channel established

Step 1 — ClientHello
The client opens TLS negotiation by sending a ClientHello message. This contains the supported TLS versions, the list of cipher suites the client supports, a client random number (used later in key derivation), and extensions like SNI (Server Name Indication — tells the server which domain is being requested, allowing one server to host multiple TLS certificates).

Step 2 — ServerHello + Certificate
The server responds by selecting the TLS version and cipher suite, then sends its own server random number. It also sends its digital certificate, which contains the server's public key, the domain name it is valid for, the Certificate Authority (CA) that issued it, the validity period, and a digital signature.

*Step 3 — Certificate Verification *(The Critical Security Step)
Before proceeding, the client must verify that the server's certificate is legitimate. This is the step that prevents man-in-the-middle attacks. The client checks:
•CA signature — was the certificate signed by a trusted Certificate Authority?
•Domain match — does the certificate's domain name match the URL being visited?
•Expiry — is the certificate still within its valid date range?
•Chain of trust — does the certificate trace back through intermediate CAs to a Root CA the browser already trusts?

Root CA (pre-installed in your OS/browser)
↓ signs →
Intermediate CA
↓ signs →
Server Certificate (presented during TLS handshake)

If any check fails — expired certificate, wrong domain, unknown CA — your browser shows a security warning and blocks the connection. This is not an inconvenience; it is the system working as intended.

Why a Chain? Root CAs are extremely sensitive. If a Root CA private key is compromised, every certificate it ever signed becomes untrusted. Intermediate CAs add a buffer — only the intermediate's key is used day-to-day, limiting exposure if it's ever compromised.

Step 4 — Key Exchange
With the server authenticated, the client and server now need to establish a shared secret that neither side transmitted in plaintext. This is where RSA or ECDHE key exchange comes in.

In RSA key exchange, the client generates a pre-master secret, encrypts it with the server's public key (from the certificate), and sends it over. Only the server can decrypt this using its private key. Both sides then independently compute the same session keys using:

Session Keys = PRF(pre-master secret, client random, server random)

This produces several keys: one for encrypting client-to-server data, one for server-to-client data, and MAC keys for integrity checking. The random values from each side ensure that even if the same pre-master secret were reused, the session keys would be different every time.

Why Not Encrypt Everything with the Public Key? Public key (asymmetric) cryptography is mathematically expensive — it can be hundreds of times slower than symmetric encryption. TLS uses asymmetric crypto only for the key exchange, then switches to fast symmetric ciphers (like AES) for all actual data. This hybrid approach gives you the security of asymmetric with the speed of symmetric.

Step 5 — ChangeCipherSpec + Finished
Both client and server send a ChangeCipherSpec message signaling "I'm switching to encrypted mode now." They then each send a Finished message — the first message encrypted with the newly derived session keys — which contains a hash of the entire handshake transcript. If both sides can successfully decrypt and verify each other's Finished message, the handshake is complete and the session keys are confirmed correct.

TLS 1.3 — A Faster Modern Alternative
TLS 1.3 (the current standard) reduces the handshake to fewer round trips — it can often complete in 1-RTT (one round trip) instead of 2-RTT for TLS 1.2. It also removed weaker cipher suites entirely, making the negotiation simpler and more secure. If you see TLS 1.3 in browser dev tools, this is what is running.

4. HTTP — HyperText Transfer Protocol
What Happens After TLS?
With a TCP connection open and TLS encryption active, the browser can finally request the actual web content. HTTP (HyperText Transfer Protocol) is the application-layer protocol that defines how browsers and servers ask for and deliver web resources.

Everything from this point forward — the request, the response, all the HTML/CSS/JS — travels inside TLS-encrypted envelopes. An attacker monitoring the network can see that you are talking to a server, but cannot read the content of any request or response.

HTTP Request — What the Browser Sends
Every HTTP request has three parts: a request line, headers, and an optional body.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 Chrome/120
Accept: text/html,application/xhtml+xml
Cookie: sessionID=abc123
Connection: keep-alive

**The Request Line
**The first line contains three pieces: the HTTP method (what the browser wants to do), the resource path (which file or endpoint is being requested), and the HTTP version.

Method Purpose Has Body? Common Use
GET Retrieve a resource No Loading pages, images, files
POST Send data to the server Yes Form submission, logins, API calls
PUT Replace a resource Yes Updating a record via API
DELETE Remove a resource No Deleting via API
HEAD Get headers only (no body) No Check if resource exists/changed

Request Headers
Headers carry metadata about the request. They tell the server who is asking, what formats are acceptable, what language is preferred, and what cookies are stored. Key headers to know:

HTTP Response — What the Server Sends Back
The server processes the request and sends back a response, also in three parts: a status line, response headers, and the body (the actual content).

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 4521
Cache-Control: max-age=3600
Set-Cookie: sessionID=xyz; HttpOnly; Secure
Server: nginx/1.24

Example
...

Status Codes
The three-digit status code tells the browser exactly what happened with the request. They are grouped by the first digit:

One Page = Many HTTP Requests
A common misconception is that loading a webpage is a single request. In reality, the initial HTML response contains references to dozens of other resources — each requiring its own HTTP request.

A typical page load sequence looks like:

1. GET /index.html — the main HTML document
2. GET /styles/main.css — stylesheet referenced in the HTML
3. GET /scripts/app.js — JavaScript file
4. GET /images/logo.png — logo image
5. GET /images/banner.jpg — hero image
6. GET /fonts/roboto.woff2 — web font
7. GET /api/user — API call for dynamic data (if logged in)

Modern browsers handle these in parallel using multiple TCP connections or HTTP/2 multiplexing (which allows many requests over a single TCP connection). This parallelism is why HTTP/2 provides a meaningful performance boost over HTTP/1.1 for content-heavy pages.

Browser Rendering — What Happens With the Response
Once the browser starts receiving the HTML, it begins parsing and rendering before the entire response even arrives. The process:

21.Parse HTML → Build DOM (Document Object Model) — a tree of every element on the page
22.Parse CSS → Build CSSOM (CSS Object Model) — style rules for every element
23.Execute JavaScript — which may modify the DOM or trigger additional network requests
24.Combine DOM + CSSOM → Render Tree — only the visible elements with their computed styles
25.Layout — calculate the exact position and size of every element on screen

1. Paint — draw pixels to the display

Performance Note: JavaScript blocks HTML parsing by default. This is why performance-conscious developers place script tags at the bottom of the HTML body, or use async and defer attributes — so JS doesn't delay page rendering.

5. The Complete End-to-End Flow
Here is the full sequence from URL to rendered page, with every protocol in order:

1. User types URL in browser
2. Browser checks its own DNS cache
3. If no cache → Resolver query → Root → TLD → Authoritative → IP
4. TCP 3-way handshake (SYN → SYN-ACK → ACK)
5. TLS handshake (ClientHello → ServerHello → Cert verify → Keys → Finished)
6. HTTP GET request (encrypted inside TLS)
7. Server processes request
8. HTTP response with HTML (encrypted inside TLS)
9. Browser parses HTML, requests additional resources (CSS, JS, images)
10. Browser renders the page
11. TCP connection kept alive for further requests (or closed with FIN)

6. Security Risks at Each Stage

Key Takeaways
•DNS translates domain names to IPs through a hierarchy: Resolver → Root → TLD → Authoritative
•The Resolver is your PC's single point of contact — it walks the hierarchy on your behalf
•DNS caching (TTL) prevents this full lookup on every request — most lookups are instant cache hits
•TCP's 3-way handshake (SYN/SYN-ACK/ACK) establishes a reliable, ordered connection before any data flows
•TLS provides confidentiality, integrity, and authentication — it is the reason HTTPS is trustworthy
•Certificate verification is the critical security step — it prevents you from being fooled by fake servers
•TLS uses hybrid cryptography: asymmetric (RSA/ECDHE) for key exchange, symmetric (AES) for data — the best of both worlds
•HTTP is a request/response protocol — one page load triggers many individual requests for resources
•Modern browsers pipeline and parallelize requests; HTTP/2 multiplexes them over one TCP connection
•Every stage has a corresponding attack surface — understanding the protocol is the first step to understanding the security

-->The full order is always DNS → TCP → TLS → HTTP. You cannot skip steps. Each layer depends on the one before it being established correctly.