The Client-Server Model

Imagine you're at a pizza shop. You (the Client) place an order, and the chef (the Server) prepares the pizza and sends it back to you. This is exactly how the web works — and understanding this model is the foundation of everything else we'll learn about HTTP.

---

1. What is a Client?

A Client is any device or application that initiates a request for data or a service.

The key idea: clients always start the conversation.

---

2. What is a Server?

A Server is a programme (and the machine it runs on) that listens for incoming requests and sends back a response.

What Servers Do:

• Store files (HTML, CSS, images, videos)
• Run application logic (log you in, process payments)
• Query databases and return results
• Talk to other servers on your behalf

Servers run continuously, 24/7, waiting for clients to connect. They can handle thousands of requests per second from all over the world simultaneously.

Types of Servers

---

3. The Request–Response Cycle

The most important rule of HTTP is simple:

One request → One response. Always.

Client (Browser)                    Server (nandhoo.com)
     │                                       │
     │   1. GET /dashboard HTTP/1.1          │
     │──────────────────────────────────────►│
     │                                       │ 2. Look up the route,
     │                                       │    query the database,
     │                                       │    render HTML
     │   3. HTTP/1.1 200 OK                  │
     │◄──────────────────────────────────────│
     │      Content-Type: text/html          │
     │      [HTML body follows...]           │
     │                                       │

Steps in detail:

1. You type https://www.nandhoo.com/dashboard and press Enter
2. Your browser resolves the domain name to an IP address (DNS lookup)
3. Your browser opens a TCP connection to that IP address on port 443
4. Your browser sends an HTTP request through the encrypted TLS tunnel
5. The server processes the request and sends back an HTTP response
6. Your browser reads the response, renders the HTML, and shows you the page

---

4. How Your Browser Finds the Server: DNS

DNS (Domain Name System) is the internet's phone book. It translates a human-readable domain (nandhoo.com) into a machine-readable IP address (104.21.8.192).

You type: www.nandhoo.com
              │
              ▼
    Browser checks local cache
              │ (not found)
              ▼
    Asks Recursive Resolver (your ISP or 8.8.8.8)
              │
              ▼
    Resolver asks Root Nameserver → TLD Nameserver → Authoritative Nameserver
              │
              ▼
    Returns: 104.21.8.192
              │
              ▼
    Browser connects to 104.21.8.192:443

The entire DNS lookup typically takes < 50ms and the result is cached so it's not repeated on every request.

---

5. IP Addresses and Ports

Every device on the internet has an IP address, like a house address. Two versions exist:

Ports are like apartment numbers within that address:

When you visit https://nandhoo.com, your browser automatically uses port 443 for HTTPS.

---

6. How the Layers Work: A Quick Look at TCP/IP

HTTP doesn't work alone. It sits on top of a stack of networking protocols:

┌────────────────────────────────────────────────┐
│  APPLICATION LAYER   HTTP, HTTPS, FTP, DNS     │  ← You work here
├────────────────────────────────────────────────┤
│  TRANSPORT LAYER     TCP, UDP                  │  ← Reliable delivery
├────────────────────────────────────────────────┤
│  INTERNET LAYER      IP, ICMP                  │  ← Routing packets
├────────────────────────────────────────────────┤
│  LINK LAYER          Ethernet, Wi-Fi           │  ← Physical connection
└────────────────────────────────────────────────┘

TCP (Transmission Control Protocol) ensures data arrives in the right order and without errors. Before any HTTP data is sent, a TCP handshake happens:

Client    →    SYN       →    Server   (I want to connect)
Client    ←    SYN-ACK   ←    Server   (OK, acknowledged)
Client    →    ACK       →    Server   (Great, let's go!)

Only after this 3-step handshake does HTTP begin.

---

7. CDNs and Proxies

Content Delivery Networks (CDNs)

A CDN is a network of servers spread around the globe. When you visit a popular website, you are often served by the CDN server geographically nearest to you rather than the company's main server.

User in Mumbai ──────────► CDN edge in Singapore (50ms)
                                     │
                    (instead of)     └──────────── Origin server in US (250ms)

CDNs make the web faster by reducing latency (the time data takes to travel).

Proxies

A proxy sits between the client and the server:

---

8. Statelessness

HTTP is stateless — each request is completely independent. The server has no memory of previous requests by default.

This means:

• Server memory doesn't grow with the number of users
• Any server can handle any request (enabling horizontal scaling)
• But the client must re-send identity information (like an auth token) with every request

Solutions like cookies, sessions, and tokens (covered in Chapter 5) are layered on top of HTTP to add statefulness where needed.

---

9. Seeing it in Action — Code Examples

Basic Fetch (Browser Console)

// Try this in your browser's developer tools console!
fetch('https://api.github.com/users/torvalds')
  .then(response => response.json())
  .then(data => {
    console.log('Name:', data.name);
    console.log('Public repos:', data.public_repos);
    console.log('Followers:', data.followers);
  });

Inspecting the Full Request/Response Cycle

fetch('https://api.github.com/users/torvalds')
  .then(response => {
    // Status codes
    console.log('Status:', response.status);       // 200
    console.log('OK?', response.ok);               // true

    // Response headers from the server
    console.log('Content-Type:', response.headers.get('content-type'));
    console.log('Cache-Control:', response.headers.get('cache-control'));

    // The URL after any redirects
    console.log('Final URL:', response.url);

    return response.json();
  })
  .then(data => console.log('Body:', data));

Using curl (from your Terminal)

# A raw HTTP GET request
curl -v https://api.github.com/users/torvalds

# -v shows the full request/response headers (verbose mode)
# You can see the TLS handshake, request headers, and response headers

---

10. Visualising the Full Journey

Here is the complete journey of a single web page request:

1. You type: https://www.nandhoo.com
2. Browser checks DNS cache → miss
3. DNS resolver contacted → returns IP: 104.21.8.192
4. Browser connects TCP to 104.21.8.192:443
5. TLS handshake → encrypted tunnel established
6. Browser sends:
        GET / HTTP/2
        Host: www.nandhoo.com
        Accept: text/html
        User-Agent: Mozilla/5.0 ...
7. Server processes, queries DB, renders HTML
8. Server responds:
        HTTP/2 200 OK
        Content-Type: text/html; charset=utf-8
        ...
        [HTML page body]
9. Browser parses HTML → discovers CSS/JS/image URLs
10. Browser makes additional requests for each asset (steps 6–8 repeated)
11. Browser renders the complete page on screen

A typical page can require 50–200 individual sub-requests for all its assets!

---

11. Mini Exercises

1. Open your browser's DevTools (F12 → Network tab), then visit https://nandhoo.com. How many requests are made? What is the status code of the first one?
2. In the browser console, paste the fetch example from section 9. What does the GitHub API return about the user torvalds?
3. Look up the difference between latency and bandwidth. Write a one-sentence explanation of each.
4. Find a website and click the padlock icon in the address bar. Who is the Certificate Authority (CA) that issued the certificate?
5. Using the Network tab in DevTools, find a request to an API. What HTTP method does it use? What status code does it return?

---

12. Key Terms

---