Cybersecurity

How Websites Actually Work: DNS, HTTPS, Servers and Browsers

Python JavaScript AI Agents Encryption Databases SQL Redis HTML CSS Node.js Java Certificates TLS HTTPS

863 words Includes Code

Key Takeaway: Every website visit involves six stages — URL parsing, DNS resolution, TCP connection, TLS encryption, HTTP request/response, and browser rendering — all completing in under a second. Understanding this journey is fundamental to web development, security, and debugging.

How Websites Actually Work: DNS, HTTPS, Servers and Browsers

You type a URL, press Enter, and a page appears. But what actually happens between those two moments? This article traces the complete journey from URL to rendered page — DNS resolution, TCP handshake, TLS encryption, HTTP request/response, server processing, and browser rendering.

This is the foundation every web developer, security engineer, and network administrator needs to understand.

Complete website journey showing URL, DNS, TCP, TLS, HTTP, server processing and browser rendering with timing measurements

Step 1: URL Parsing

When you type https://bestwordz.com/articles/ and press Enter, your browser first decomposes the URL:

https://bestwordz.com:443/articles/
│         │              │    │
│         │              │    └─ Path (which page)
│         │              └────── Port (443 = HTTPS)
│         └───────────────────── Hostname (domain name)
└─────────────────────────────── Scheme (https = encrypted)

The scheme tells the browser to use HTTPS (encrypted). The hostname identifies the server. The port defaults to 443 for HTTPS. The path identifies the specific page.

Step 2: DNS Resolution (Domain → IP Address)

Computers don't understand domain names — they need IP addresses. DNS (Domain Name System) translates bestwordz.com into an IP address like 145.79.24.188.

# DNS resolution in action
$ nslookup bestwordz.com
Server:    8.8.8.8
Address:   8.8.8.8#53

Non-authoritative answer:
Name:      bestwordz.com
Address:   145.79.24.188
Address:   145.79.29.75

DNS record types you should know:

Record	Purpose	Example
A	Maps domain to IPv4 address	example.com → 93.184.216.34
AAAA	Maps domain to IPv6 address	example.com → 2606:2800:220:1:...
CNAME	Aliases one domain to another	www → example.com
MX	Mail server for domain	mail.example.com (priority 10)
TXT	Text records (SPF, DKIM, verification)	v=spf1 include:_spf.google.com ~all

DNS responses are cached at multiple levels: browser, operating system, router, and ISP. First visit may take 50-200ms; cached visits take under 5ms.

Step 3: TCP Connection (Three-Way Handshake)

Before any data flows, the browser and server establish a reliable connection using TCP's three-way handshake:

Browser                                    Server
  │                                          │
  │──── SYN (seq=1000) ──────────────────→│  ① "I want to connect"
  │                                          │
  │←─── SYN-ACK (seq=3000, ack=1001) ──────│  ② "OK, I acknowledge"
  │                                          │
  │──── ACK (ack=3001) ──────────────────→│  ③ "Connection confirmed"
  │                                          │
  │          TCP Connection Open             │

Key details:

Source port: Random high port (e.g., 52847) chosen by your browser
Destination port: 443 (HTTPS) or 80 (HTTP)
Sequence numbers: Ensure packets arrive in order
Typical time: 20-80ms depending on geographic distance

Step 4: TLS Handshake (HTTPS Encryption)

After TCP connects, TLS creates an encrypted tunnel. This is what makes HTTPS secure:

Browser                                        Server
  │                                              │
  │── ClientHello: TLS 1.3, cipher list ────→│  ① Supported versions
  │                                              │
  │←── ServerHello: chosen cipher + cert ─────│  ② Certificate + choice
  │                                              │
  │    [Verify certificate chain]              │  ③ Browser validates cert
  │    [Check domain matches]                  │
  │                                              │
  │── Finished: encrypted verify ────────────→│  ④ Encrypted handshake
  │                                              │
  │←── Finished: encrypted verify ────────────│  ⑤ Server confirms
  │                                              │
  │           Encrypted tunnel open              │

What was measured from bestwordz.com:

Property	Value
TLS Version	TLSv1.3
Cipher Suite	TLS_AES_256_GCM_SHA384
Certificate Issuer	Let's Encrypt
Domains Covered	bestwordz.com, www.bestwordz.com
Expires	October 10, 2026

Step 5: HTTP Request and Response

With the encrypted tunnel open, the browser sends an HTTP request:

# HTTP Request
GET /articles/ HTTP/2
Host: bestwordz.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Cookie: session_id=abc123...

# HTTP Response
HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 45238
Server: hcdn
Cache-Control: public, max-age=3600

<!DOCTYPE html>
<html lang="en">
  <head>...</head>
  <body>...</body>
</html>

HTTP/2 brings significant improvements over HTTP/1.1:

Feature	HTTP/1.1	HTTP/2
Multiplexing	One request per connection	Multiple parallel streams
Header Compression	Uncompressed	HPACK compression
Server Push	Not supported	Server can push resources
Binary Protocol	Text-based	Binary (faster parsing)

Step 6: Server Processing

The server receives the request and processes it through multiple layers:

① Reverse Proxy (Nginx / Caddy)
   └─ Receives request, terminates TLS
   └─ Routes to appropriate backend

② Application (Python / Node.js / Go)
   └─ Parses URL and parameters
   └─ Authenticates user (if needed)
   └─ Queries database
   └─ Renders HTML template
   └─ Adds security headers

③ Database (PostgreSQL / MySQL / Redis)
   └─ Retrieves requested data
   └─ Returns results to application

④ Response
   └─ HTTP 200 OK
   └─ Compressed HTML (gzip/brotli)
   └─ Cache headers
   └─ Security headers

Complete HTTP request sequence diagram showing DNS, TCP, TLS, HTTP phases with timing

Step 7: Browser Rendering

The browser receives HTML and transforms it into visible pixels through a multi-stage pipeline:

Stage	What Happens	Output
Parse HTML	Read HTML tokens, build element tree	DOM tree
Load CSS	Download, parse, apply styles	CSSOM tree
Execute JS	Run scripts, modify DOM/CSSOM	Updated DOM
Render Tree	Combine DOM + CSSOM (visible only)	Render tree
Layout	Calculate positions and sizes	Geometry data
Paint	Draw text, colors, images, borders	Pixel layers
Composite	Layer ordering, GPU acceleration	Visible page

Performance tip: JavaScript blocks HTML parsing. Place <script> tags at the bottom of <body> or use defer/async attributes to avoid blocking the render pipeline.

Complete Timing Breakdown

Measured from a real visit to bestwordz.com:

Stage	Typical Time	What Happens
DNS	~5ms (cached)	Domain → IP lookup
TCP	~30ms	Three-way handshake
TLS	~50ms	Certificate verification + key exchange
HTTP	~200-740ms	Server processing + response transfer
Render	~50-200ms	DOM + CSSOM + Layout + Paint
Total	~300-1000ms	URL entry to visible page

What Can Go Wrong

Stage	Problem	Symptom
DNS	Domain not registered	DNS_PROBE_FINISHED_NXDOMAIN
DNS	DNS server down	DNS resolution timeout
TCP	Firewall blocking port 443	Connection timeout
TLS	Expired certificate	NET::ERR_CERT_DATE_INVALID
TLS	Domain mismatch	NET::ERR_CERT_COMMON_NAME_INVALID
HTTP	Server error	500 Internal Server Error
HTTP	Page not found	404 Not Found
Render	JavaScript error	Blank page or broken layout

Try It Yourself — BestWordz Tools

URL Encoder/Decoder — Understand URL structure and encoding
<CIDR Subnet Calculator — Understand IP addressing and DNS
Certificate Decoder — Inspect TLS certificates
SSL Server Test — Test HTTPS configuration

Summary

Every website visit follows the same six-stage journey:

URL Parsing — Browser decomposes scheme, host, port, path
DNS Resolution — Domain name translated to IP address (~5ms)
TCP Handshake — Reliable connection established (~30ms)
TLS Handshake — Encrypted tunnel created (~50ms)
HTTP Request/Response — Request sent, HTML received (~200-740ms)
Browser Rendering — DOM → CSSOM → Layout → Paint → Visible (~50-200ms)

Total time: under one second for most websites. Understanding this journey is the foundation for web development, security debugging, performance optimization, and network troubleshooting.

How Websites Actually Work: DNS, HTTPS, Servers and Browsers

How Websites Actually Work: DNS, HTTPS, Servers and Browsers

Step 1: URL Parsing

Step 2: DNS Resolution (Domain → IP Address)

Step 3: TCP Connection (Three-Way Handshake)

Step 4: TLS Handshake (HTTPS Encryption)

Step 5: HTTP Request and Response

Step 6: Server Processing

Step 7: Browser Rendering

Complete Timing Breakdown

What Can Go Wrong

Try It Yourself — BestWordz Tools

Related BestWordz Articles

Summary

Further Reading

Try the URL Encoder

💬 Discuss this topic

📚 Related Articles

Cross-Site Scripting Explained for Web Developers

SQL Injection Explained and Prevented

Hashing vs Encryption vs Encoding: What's the Difference?

From Prompt Crafting to System Design

Secrets Management for Developers: From .env Files to Secret Managers

Is AI-Generated Code Secure? A Developer Security Checklist

🔧 Related Tools

URL Encoder

URL Encoder

Base64 Encoder

Base64URL Decoder

💬 Discuss on BestWordz Community