Module -04: How the Internet Works — Design & Code Foundations

01

The Request-Response Cycle

Every webpage load is a conversation: your browser asks (request), a server answers (response). This happens hundreds of times for a single page.

⊞

Your Browser

REQUEST →

← RESPONSE

▦

Web Server

Request: "Give me index.html"
Response: "Here's the HTML, CSS, images, and scripts"

How a Page Loads

Your browser sends a request ("I want this page"). The server sends a response (the actual files). This happens for every file: HTML, CSS, JavaScript, images, fonts. A typical page makes 50-200 requests.

Key insight: One page = dozens to hundreds of individual requests

GETRetrieve data

"Give me this page/image/file"

POSTSend data

"Here's form data, process it"

PUTUpdate data

"Replace this resource with new data"

DELETERemove data

"Delete this resource"

Types of Requests

HTTP methods tell the server what you want to do. GET retrieves data (loading pages). POST sends data (submitting forms). PUT updates, DELETE removes. Most browsing is GET requests.

CRUD basics: GET = read, POST = submit, PUT = update, DELETE = remove

2xx

Success

200 OK, 201 Created

3xx

Redirect

301 Moved, 302 Found

4xx

Client Error (your fault)

404 Not Found, 403 Forbidden

5xx

Server Error (their fault)

500 Internal Error, 503 Unavailable

Server Response Codes

Every response includes a status code. 200 = success. 404 = page not found. 500 = server crashed. The first digit tells you the category: 2xx good, 4xx your problem, 5xx their problem.

Common codes: 404 = page doesn't exist. 500 = server broke.

ElementsConsoleNetworkSources

NameStatusTypeTime
index.html200document45ms
styles.css200stylesheet23ms
app.js200script67ms
hero.webp200image234ms

See It Yourself: Network Tab

Press F12 (or Cmd+Option+I on Mac) and click the Network tab. Reload the page. You'll see every request, its status, type, and load time. This is how you debug slow pages.

Try it now: F12 → Network tab = see all requests for any page

02

DNS: The Internet's Phone Book

Computers don't understand 'google.com' — they need numbers (IP addresses). DNS translates human-readable names into computer-readable addresses.

WHAT COMPUTERS USE

142.250.80.46

IP Address (hard to remember)

WHAT HUMANS USE

google.com

Domain name (easy to remember)

DNS = the translation layer between human names and computer addresses

Why DNS Exists

Every device on the internet has an IP address (like 142.250.80.46). But humans can't remember numbers for every website. DNS (Domain Name System) translates 'google.com' into its IP address.

Core concept: DNS translates names → numbers. Like a phone book.

1

Browser cache: "Do I already know this IP?"

2

OS cache: "Does my computer know?"

3

Router cache: "Does my router know?"

4

ISP DNS: "Ask my internet provider"

5

Root servers: "Ask the global DNS system"

Usually resolved at step 1-4. Root servers only needed for new/rare domains.

How DNS Resolution Works

When you type a URL, your browser checks multiple caches before asking the global DNS system. That's why the first visit to a site is slower — DNS hasn't been cached yet.

Why first load is slower: First visit = DNS lookup. Repeat visits = cached, faster.

A

Points domain to IPv4 address (142.250.80.46)

AAAA

Points domain to IPv6 address (longer format)

CNAME

Alias: "www" points to same place as root domain

MX

Mail server: where to send emails for this domain

TXT

Text data: verification, SPF records, etc.

Types of DNS Records

DNS isn't just names → IPs. Different record types serve different purposes. A records are for websites. MX records route email. You'll encounter these when setting up domains.

Domain setup: A record = website. MX record = email. CNAME = alias.

03

Client vs Server

The web is split into two sides: the client (your browser) and the server (remote computers). Understanding this split explains why some things happen instantly and others need loading.

CLIENT-SIDE (Your Browser)

HTML rendering
CSS styling
JavaScript interactions
Local storage
Animations

Runs on YOUR computer

SERVER-SIDE (Remote Computer)

Database queries
User authentication
File storage
API processing
Business logic

Runs on THEIR computer

Client-Side vs Server-Side

Client-side code runs in your browser — it's instant but limited (can't access databases). Server-side code runs on remote servers — it's powerful but requires network requests (slower).

The tradeoff: Client = instant but limited. Server = powerful but slow.

FRONTEND

What users see & interact with

HTMLCSSJS

↔

BACKEND

Data, logic, authentication

NodePythonSQL

Frontend vs Backend

Frontend = client-side (HTML, CSS, JavaScript). Backend = server-side (databases, APIs, authentication). They communicate via HTTP requests. Most websites have both.

Industry terms: Frontend = visible. Backend = hidden data/logic.

API = Application Programming Interface

Your App

→ "Get user profile" →

API

→

Database

// Example API request
GET /api/users/123

// Response
{"name": "John", "email": "..."}

What is an API?

An API is a standardized way for programs to talk to each other. Instead of accessing a database directly, your frontend asks the API, which safely handles the request and returns data (usually as JSON).

Analogy: API = the waiter between your app and the kitchen (database)

04

HTTPS & Security

The 'S' in HTTPS means secure. Without it, anyone between you and the server can read everything. Understanding this explains browser warnings and padlock icons.

⚠HTTP (Not Secure)

http://site.com

Data sent as plain text.
Anyone can intercept.

⊕HTTPS (Secure)

https://site.com

Data encrypted end-to-end.
Only you and server can read.

Why HTTPS Matters

HTTP sends data in plain text — like a postcard anyone can read. HTTPS encrypts data — like a sealed letter. Always use HTTPS, especially for passwords, payments, or personal data.

Security basics: HTTP = postcard. HTTPS = sealed envelope.

1

Handshake: Browser and server agree on encryption method

2

Certificate: Server proves its identity with SSL certificate

3

Key exchange: Create shared secret key for this session

4

Encrypted: All data encrypted with that key

How Encryption Works

SSL/TLS creates an encrypted tunnel between your browser and the server. The padlock icon means this connection is secure. Invalid certificates trigger browser warnings.

Browser indicators: Padlock = encrypted. Warning = certificate problem.

DV (Domain Validation)

Proves you own the domain. Free via Let's Encrypt. Good for most sites.

OV (Organization Validation)

Verifies organization exists. More trust, costs money.

EV (Extended Validation)

Extensive verification. Shows company name in browser. Banks use these.

Let's Encrypt: Free DV certificates. No reason not to use HTTPS.

SSL Certificates Explained

SSL certificates prove a site is who they claim to be. Let's Encrypt provides free certificates, so there's no excuse for HTTP anymore. Browsers increasingly block/warn about non-HTTPS sites.

Modern standard: Let's Encrypt = free HTTPS. No excuse for HTTP.

How the Internet Works

Core Concepts

The Request-Response Cycle

DNS: The Internet's Phone Book

Client vs Server

HTTPS & Security

Key Takeaways