What Actually Happens When You Visit a Website

You type https://example.com and hit Enter. A page appears. Simple, right?

Behind that click, your browser executes a precise sequence of steps involving DNS, TCP, TLS, and HTTP. Every one of those steps is a potential target for attackers - and a potential signal for defenders.

If you haven’t read the first post in this series on IP addresses, DNS, and routing, start there. We’ll build directly on those concepts.

The Full Sequence

Here’s what happens, in order:

1. URL Parsing       → Browser figures out what you're asking for
2. DNS Resolution    → Finds the server's IP address
3. TCP Handshake     → Establishes a reliable connection
4. TLS Handshake     → Encrypts the connection (HTTPS)
5. HTTP Request      → Asks the server for the page
6. HTTP Response     → Server sends the page back
7. Rendering         → Browser displays the content

Let’s walk through each one.

Step 1: URL Parsing

When you type https://example.com/about, your browser breaks this into parts:

Part	Value	Meaning
Protocol	https	Use HTTP with TLS encryption
Domain	example.com	The server to connect to
Path	/about	The specific page to request
Port	(implied 443)	HTTPS defaults to port 443

If you typed http:// instead of https://, the browser would use port 80 and skip encryption. We’ll cover why that matters shortly.

Step 2: DNS Resolution

The browser needs an IP address. It asks: “What IP does example.com point to?”

This was covered in detail in the previous post. Quick recap:

Browser → DNS Resolver → "example.com is 93.184.216.34"

The browser now knows where to send its request. But first, it needs to establish a connection.

Step 3: TCP Handshake

TCP (Transmission Control Protocol) is how most internet communication works. Unlike UDP (which just fires data and hopes it arrives), TCP guarantees delivery by establishing a connection first.

This is the three-way handshake:

Your browser ──SYN──▶        Server
             ◀──SYN-ACK──
             ──ACK──▶

In plain language:

1. SYN: “Hey, I want to talk.”
2. SYN-ACK: “Got it. I’m ready too.”
3. ACK: “Great. Let’s go.”

After these three packets, a connection is established. Both sides know the other is listening and ready.

Why This Matters for Security

The TCP handshake is where several attacks operate:

• SYN Flood: An attacker sends thousands of SYN packets but never completes the handshake. The server wastes resources waiting for connections that never finish. This is a type of Denial of Service (DoS) attack.
• Port scanning: Tools like nmap send SYN packets to see which ports respond with SYN-ACK (meaning they’re open and listening).
• Connection tracking: Firewalls and IDS systems monitor handshakes to detect unusual patterns.

Step 4: TLS Handshake (HTTPS Only)

If the URL starts with https://, an additional step happens before any real data is sent: the TLS handshake.

TLS (Transport Layer Security) encrypts everything between your browser and the server. Without it, anyone on the network between you and the server can read your data.

The simplified version:

Browser: "Hi, I support these encryption methods"
Server:  "Let's use this one. Here's my certificate."
Browser: "Certificate checks out. Here's a shared secret."
Both:    *start encrypting everything with the shared secret*

What’s in the Certificate?

The server’s certificate proves its identity. It contains:

• The domain name it’s valid for
• Who issued it (Certificate Authority like Let’s Encrypt, DigiCert)
• When it expires
• The server’s public key

Your browser checks:

1. Is the certificate valid for this domain?
2. Was it issued by a trusted authority?
3. Has it expired?
4. Has it been revoked?

If any check fails, you get the “Your connection is not private” warning.

Why This Matters for Security

• Without TLS (HTTP): Everything is in plaintext. Passwords, cookies, page content - all readable by anyone on the network. Public Wi-Fi without HTTPS is essentially broadcasting your data.
• Certificate pinning: Some apps check not just that a certificate is valid, but that it’s the specific certificate they expect. This prevents man-in-the-middle attacks even if an attacker has a valid certificate.
• TLS version matters: TLS 1.0 and 1.1 have known vulnerabilities. Modern servers should use TLS 1.2 or 1.3.

Step 5: HTTP Request

Now the connection is established and encrypted. Your browser sends an HTTP request:

GET /about HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html
Accept-Language: en-US
Cookie: session=abc123

Breaking this down:

Line	Meaning
GET /about HTTP/1.1	Method (GET), path (/about), protocol version
Host: example.com	Which website (a server can host many)
User-Agent	What browser you’re using
Accept	What content types you’ll accept
Cookie	Session data from previous visits

HTTP Methods

Different methods tell the server what you want to do:

Method	Purpose	Example
GET	Retrieve data	Loading a page
POST	Send data	Submitting a form, logging in
PUT	Update data	Editing a profile
DELETE	Remove data	Deleting an account

Why this matters for security: GET requests put parameters in the URL (/search?q=password), which show up in browser history, server logs, and referrer headers. POST puts data in the request body, which is slightly better but still not secure without encryption.

Step 6: HTTP Response

The server processes your request and sends back a response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Set-Cookie: session=xyz789; HttpOnly; Secure
Content-Length: 1256

<!DOCTYPE html>
<html>
<head><title>About Us</title></head>
<body>...</body>
</html>

Status Codes

The first line contains a status code. You’ve seen some of these:

Code	Meaning	Security Relevance
200	OK	Normal response
301/302	Redirect	Can be used for phishing or open redirects
403	Forbidden	Access denied - might reveal what exists
404	Not Found	Useful for directory brute-forcing
500	Server Error	May leak internal details in error messages

Response Headers

Headers control browser behavior:

• Set-Cookie: Creates or updates cookies. The HttpOnly flag prevents JavaScript from reading the cookie (defends against XSS). The Secure flag ensures the cookie is only sent over HTTPS.
• Content-Security-Policy: Tells the browser what scripts, styles, and resources are allowed to load. A key defense against XSS.
• X-Frame-Options: Controls whether the page can be loaded in an iframe. Prevents clickjacking attacks.

Why this matters for security: Misconfigured headers are one of the most common web vulnerabilities. Missing HttpOnly on session cookies, missing CSP headers, verbose error pages - these are all things security testers check for.

Step 7: Rendering

Your browser takes the HTML, CSS, and JavaScript from the response and turns it into the page you see.

During rendering, the browser may make dozens more requests:

• CSS files for styling
• JavaScript files for interactivity
• Images, fonts, videos
• API calls for dynamic data

Each of these follows the same cycle: DNS → TCP → TLS → HTTP → Response.

A single page load can trigger 50-100+ HTTP requests behind the scenes.

The Full Picture

Let’s trace it all together:

You type: https://example.com/about

1. Browser parses URL → protocol=HTTPS, domain=example.com, path=/about
2. DNS lookup         → example.com = 93.184.216.34
3. TCP handshake      → SYN → SYN-ACK → ACK (connection established)
4. TLS handshake      → Certificate verified, encryption keys exchanged
5. HTTP request       → GET /about HTTP/1.1
6. HTTP response      → 200 OK + HTML content
7. Browser renders    → You see the page

Total time: typically 100-500 milliseconds. Dozens of network operations, security checks, and data exchanges - all invisible.

Where Attacks Happen

Now that you see the full chain, here’s where things go wrong:

Step	Attack	What Happens
DNS	DNS Spoofing/Poisoning	Fake DNS response sends you to a malicious server
TCP	SYN Flood	Overwhelm server with fake connection requests
TCP	Port Scanning	Discover what services are running
TLS	Downgrade Attack	Force connection to use weaker encryption
TLS	MITM (without TLS)	Intercept and read/modify unencrypted traffic
HTTP	Injection (XSS, SQLi)	Malicious input processed by the server
HTTP	Session Hijacking	Steal cookies to impersonate a user
Headers	Clickjacking	Load a page in a hidden iframe to trick clicks

We’ll cover each of these in detail throughout this series.

Try It Yourself

Watch the process happen in real time:

In Your Browser

Open your browser’s developer tools (F12 or Ctrl+Shift+I) and go to the Network tab. Now visit any website.

You’ll see every request: the initial HTML, then CSS, JavaScript, images, API calls. Click on any request to see:

• Request headers (what your browser sent)
• Response headers (what the server replied)
• Status code
• Timing (how long each step took)

In the Terminal

# See the full HTTP request and response headers
curl -v https://example.com 2>&1 | head -30

# Just the response headers
curl -I https://example.com

# Watch DNS resolution happen
dig example.com

# See the TCP connection (simplified)
curl -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

That last command shows you the timing for each phase. Run it a few times and notice which steps take longest.

What’s Next

You now understand the full lifecycle of a web request. Every web security topic - XSS, SQL injection, session hijacking, certificate attacks - happens at a specific point in this chain.

In the next post, we’ll look at ports and protocols in depth. Why do different services use different ports? What’s the difference between TCP and UDP? And why does this matter when you’re scanning a network or writing firewall rules?

References

• MDN - HTTP Overview
• Cloudflare - What is TLS?
• Cloudflare - What is TCP?

---

Every security tool you’ll ever use - Burp Suite, Wireshark, nmap - operates on the concepts in this post. Understand the request lifecycle, and the tools make sense.