How the Internet Works

Client-Server Model

The internet is built on a simple architecture: clients request resources and servers provide them.

Key Components

Client (Browser)          Server (Web Server)
     │                          │
     │   1. HTTP Request        │
     │ ──────────────────────►  │
     │                          │  Process request
     │                          │  Query database
     │   2. HTTP Response       │  Build response
     │ ◄──────────────────────  │
     │                          │

• Client: Your browser, mobile app, or any software that initiates requests
• Server: A computer running software that listens for requests and sends responses
• Network: The infrastructure (cables, routers, switches) that connects them

Types of Servers

DNS: The Internet's Phone Book

When you type google.com in your browser:

1. Browser checks its cache for the IP address
2. If not found, asks the operating system cache
3. OS queries the ISP's DNS resolver
4. Resolver queries root DNS servers → TLD servers → authoritative servers
5. Returns the IP address (e.g., 142.250.80.46)
6. Browser connects to that IP address

Browser → OS Cache → ISP DNS → Root Server → .com TLD → Google's DNS → IP Address

TCP/IP: The Transport Layer

TCP/IP is the protocol suite that makes internet communication reliable:

• IP (Internet Protocol): Handles addressing and routing packets
• TCP (Transmission Control Protocol): Ensures reliable, ordered delivery

The Three-Way Handshake

Client                    Server
  │─── SYN (let's talk) ───►│
  │◄── SYN-ACK (okay) ─────│
  │─── ACK (confirmed) ────►│
  │                          │
  │    Data transfer begins  │

This handshake establishes a reliable connection before any data is sent.

HTTP Request/Response Lifecycle

Every time you visit a web page, a complete request-response cycle occurs.

The Full Lifecycle

1. URL Parsing
   https://example.com:443/products?id=123
   ├── Scheme: https
   ├── Host: example.com
   ├── Port: 443
   └── Path: /products?id=123

2. DNS Resolution
   example.com → 93.184.216.34

3. TCP Connection
   SYN → SYN-ACK → ACK

4. TLS Handshake (HTTPS)
   Certificate verification → Key exchange → Encrypted connection

5. HTTP Request
   GET /products?id=123 HTTP/1.1
   Host: example.com
   Accept: text/html
   Cookie: session=abc123

6. Server Processing
   Parse request → Run business logic → Query database → Build response

7. HTTP Response
   HTTP/1.1 200 OK
   Content-Type: text/html
   Content-Length: 5432
   Set-Cookie: session=xyz789

8. Browser Rendering
   Parse HTML → Load CSS/JS → Render page

HTTP Methods

Status Code Categories

Connection: Keep-Alive

HTTP/1.1 uses persistent connections by default. Instead of opening a new TCP connection for every request, the browser reuses the same connection:

Request 1 ──► Response 1 ──► Request 2 ──► Response 2 ──► ... ──► Connection Close

This significantly reduces latency for loading pages with many assets (images, CSS, JS).

Real-World Example: Loading a Web Page

What Happens When You Visit amazon.com

1. DNS Resolution: amazon.com → 205.251.242.103
2. TCP Handshake: Establish connection to Amazon's load balancer
3. TLS Handshake: Negotiate encryption, verify SSL certificate
4. HTTP Request: GET / HTTP/1.1 with cookies and headers
5. Server Processing:
   • Load balancer routes to available server
   • Authentication middleware checks your session
   • Application renders personalized homepage
   • Queries product database, recommendation engine
6. HTTP Response: HTML document with links to CSS, JS, images
7. Browser Parsing:
   • Parses HTML, builds DOM tree
   • Encounters <link> and <script> tags
   • Makes additional requests for each resource
   • CSSOM + DOM = Render Tree
   • Layout → Paint → Composite

Performance Implications

• Each request takes 20-100ms round trip
• DNS adds 10-50ms (cached after first lookup)
• TLS handshake adds 50-150ms (connection reuse helps)
• HTTP/2 multiplexing allows parallel requests on one connection
• HTTP/3 (QUIC) eliminates head-of-line blocking

Why This Matters for Full Stack Developers

Understanding the request lifecycle helps you:

• Optimize load times: Minimize requests, use CDNs, enable compression
• Debug issues: Use browser DevTools Network tab to trace problems
• Design APIs: Return proper status codes and headers
• Handle errors: Implement retry logic for failed requests
• Improve UX: Show loading states during long requests