In the last lesson I asked you to open DevTools → Network and poke around. Let's look at what you found before we explain anything.
A few questions to talk through:
Everything you saw in that Network tab is what this lesson explains. By the end you'll know exactly what each line means — the method, the URL, the status code, the headers, all of it.
DNS is the internet's phone book. A domain name like volcanoic-pantheon.vercel.app is a human-friendly alias — computers don't route by name, they route by IP address (e.g. 76.76.21.21). DNS bridges these two worlds: it takes a domain name you can remember and returns the numeric address the network actually uses.
When your browser needs to resolve a domain name, it walks through this chain until it gets an answer:
/etc/hosts file (or Windows hosts file) for any manual overrides.8.8.8.8. This server does the hard work of asking other servers on your behalf..app domain, the TLD server for .app knows which authoritative name server is responsible for Vercel's domains.volcanoic-pantheon.vercel.app.No single server knows every domain name on the internet — there are hundreds of millions of them. Instead, DNS uses distributed authority: each zone (root, TLD, individual domain) is managed separately. The recursive resolver acts as your agent, asking each level of the hierarchy in turn until it finds someone who has the definitive answer.
TTL (time-to-live) is how many seconds a DNS record can be cached before it must be refreshed. Vercel sets short TTLs — typically 60–300 seconds — so their CDN can update IP addresses quickly when traffic needs to be rerouted. A longer TTL (like 86400s for a static personal site) means faster lookups but slower propagation when you change DNS records.
Once DNS gives the browser an IP address, it needs to open a connection to that server. TCP (Transmission Control Protocol) handles this. TCP is a reliable, ordered delivery protocol — it guarantees that data arrives in the right order and retransmits anything that gets lost.
Before any HTTP data can flow, TCP performs a three-way handshake:
Only after this handshake completes does the browser send its first HTTP request.
Data travelling across the internet is not sent as one giant stream — it is broken into chunks called packets. Each packet contains:
The receiving end reassembles packets in sequence order. If a packet is lost or corrupted in transit, TCP detects this via the sequence numbers and requests a retransmit — the missing packet is sent again.
For HTTPS, there is also a TLS handshake after the TCP handshake — the browser and server negotiate encryption before any HTTP data flows. We cover that in Section 5.
HTTP (HyperText Transfer Protocol) is the protocol browsers use to ask for resources, and that servers use to respond. It is a plain-text request-response protocol — every interaction follows the same pattern: client sends a request, server sends back a response.
Here is a raw HTTP request — exactly what your browser sends when you visit Volcanic Pantheon:
GET /index.html HTTP/1.1
Host: volcanoic-pantheon.vercel.app
Accept: text/html,application/xhtml+xml
Accept-Language: en-AU,en;q=0.9
Connection: keep-aliveGET) + path (/index.html) + protocol version (HTTP/1.1)keep-alive means reuse this TCP connection for multiple requests rather than closing and reopening Beyond NESAThe method tells the server what action you want to perform:
| Method | Purpose | Body? | Safe? |
|---|---|---|---|
GET |
Retrieve a resource | No | Yes |
POST |
Submit data / create resource | Yes | No |
PUT Beyond NESA |
Replace a resource entirely | Yes | No |
DELETE Beyond NESA |
Remove a resource | No | No |
PATCH Beyond NESA |
Partially update a resource | Yes | No |
"Safe" means the request doesn't modify server state — safe requests can be repeated without side effects.
fetch() call you write sends one of these methods. Fetching a JSON data file is GET. Submitting a login form is POST. Deleting a user account via an API would be DELETE.The server's reply follows an equally structured format:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 4321
Cache-Control: public, max-age=3600
<!DOCTYPE html>
<html>...HTTP/1.1) + status code (200) + reason phrase (OK)Status codes are grouped by their first digit. Knowing the groups means you can reason about any code, even ones you haven't seen before:
| Range | Meaning | Common Examples |
|---|---|---|
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirect | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
| 5xx | Server error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
Two terms you need before diving into TLS:
{"password": "hunter2"} is plaintext — anyone who intercepts it can read it immediately.TLS's job is to convert all HTTP traffic from plaintext to ciphertext for the duration of the connection. The server and browser are the only parties with the session key needed to decrypt it.
HTTPS = HTTP + TLS (Transport Layer Security). Everything about HTTP stays the same — the same methods, headers, status codes, request and response structure. The difference is that the entire connection is encrypted before any HTTP data flows.
After the TCP handshake completes, a TLS handshake happens in three phases:
Cross-link to Lesson 7: You covered asymmetric vs symmetric cryptography in Lesson 7 — this is that same asymmetric-then-symmetric handoff in real-world practice. The handshake uses asymmetric crypto to bootstrap a symmetric session key safely.
TLS certificates don't stand alone — they form a chain of trust. For Volcanic Pantheon:
volcanoic-pantheon.vercel.app, issued to your site by Vercel via Let's EncryptYour browser walks this chain: "I trust ISRG Root X1 (it's in my trust store) → ISRG Root X1 vouches for Let's Encrypt → Let's Encrypt vouches for this leaf certificate → the leaf certificate is valid for this domain." If any link in the chain breaks, the browser shows a certificate error.
Certificate verification relies on two more cryptographic tools:
A hash function takes any input and produces a fixed-length output called a hash value (or digest). The same input always produces the same hash. Critically, even a one-character change to the input produces a completely different hash, and it is computationally infeasible to reverse — you cannot reconstruct the original input from the hash alone.
Example: SHA-256 always outputs 64 hex characters regardless of input size. This makes hash values useful for verifying that data has not been tampered with.
A digital signature proves that a piece of data was created by a specific party and has not been modified since. Here is how a CA uses one to sign your TLS certificate:
This is why forging a TLS certificate without the CA's private key is computationally impossible — you cannot produce a valid signature.
Without HTTPS: anyone on the same network (café WiFi, university network) can read every request and response — usernames, passwords, session tokens, page contents, everything. This is called a man-in-the-middle (MITM) attack.
With HTTPS: even if traffic is intercepted, it is encrypted gibberish without the session key. The attacker can see that you connected to a domain, but not what was exchanged.
Vercel handles HTTPS automatically for all sites, including Volcanic Pantheon — it provisions the Let's Encrypt certificate and renews it every 90 days without you doing anything.
Every protocol runs on a specific port — a numbered channel on a server. When your browser connects to a server, it specifies both an IP address and a port. Protocols have standard ("well-known") ports so software knows where to connect without being told.
| Protocol | Port(s) | Purpose | Encrypted? |
|---|---|---|---|
HTTP |
80 | Web pages (unencrypted) | No |
HTTPS |
443 | Web pages (TLS encrypted) | Yes |
DNS |
53 | Domain name resolution | No (by default) |
FTP |
20 / 21 | File transfer (unencrypted) | No |
SFTP |
22 | Secure file transfer (SSH) | Yes |
SMTP |
25 / 587 | Sending email | 587 uses TLS |
POP3 |
110 / 995 | Receiving email (download & remove) | 995 uses TLS |
IMAP |
143 / 993 | Receiving email (sync across devices) | 993 uses TLS |
When no port is in a URL, the browser assumes port 80 for HTTP and 443 for HTTPS. A URL like https://example.com:8443 explicitly overrides the default.
FTP (File Transfer Protocol) is one of the oldest internet protocols, designed for transferring files between computers. It predates the web entirely. The critical problem: FTP sends everything in plaintext, including usernames and passwords. Anyone intercepting the connection can read credentials directly.
SFTP (SSH File Transfer Protocol) replaces FTP with an encrypted alternative. Despite the similar name, SFTP is not FTP-over-TLS — it is a completely different protocol built on top of SSH (Secure Shell). All data, including credentials, is encrypted end-to-end.
Modern servers use SFTP. FTP is still encountered in legacy systems but must not be used for anything sensitive — credentials travel in plaintext.
Email uses separate protocols for sending and receiving:
Key distinction: POP3 downloads and removes. IMAP syncs. If marking an email as read on your phone also marks it on your laptop — that's IMAP.
FTP separates control from data. Port 21 carries the control connection — commands like login, list directory, retrieve file. Port 20 carries the actual data transfer. This split design is a historical quirk from the 1970s that SFTP eliminates entirely by running everything over a single SSH connection on port 22.
The scale of data flowing through the modern web creates architectural challenges that ordinary web design doesn't address. Three key concepts:
Data mining is the automated process of analysing large datasets to discover patterns, correlations, and insights that would not be visible by reading data manually. Web applications generate enormous volumes of behavioural data — clicks, search queries, purchase histories, time spent on pages — and data mining extracts actionable intelligence from it.
Examples: Netflix mining viewing patterns to recommend content; Google mining search queries to improve autocomplete; retailers mining purchase histories to target advertising.
Metadata is data about data — it describes the properties of a resource without being the resource itself:
Metadata is often more revealing than content. Even if HTTPS hides what you downloaded, your ISP can still see which server you connected to and when.
Delivering continuous data (video, audio, live events) at scale requires specialised infrastructure:
Here is a raw HTTP request. Work through the questions below before revealing the answers.
POST /api/login HTTP/1.1
Host: app.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Content-Length: 47
{"username": "blake", "password": "hunter2"}POST — it's sending data to the server, not just retrieving something. Specifically, it's submitting login credentials. A GET request couldn't carry a body, and putting credentials in a URL (as GET parameters) would be a serious security mistake — URLs appear in logs, browser history, and Referer headers.
A Bearer token — specifically a JWT (JSON Web Token, identifiable by its eyJ... prefix). The client already has a session token and is sending it alongside this request. This is unusual for a login endpoint (you'd normally authenticate to get a token), so this might be a token-refresh request, or the client is re-authenticating while already holding a session.
No. Even though the URL doesn't reveal the password, the request body contains credentials in plaintext: "password": "hunter2". Without HTTPS, anyone intercepting traffic on the network can read the body verbatim. The Content-Type is application/json, not encrypted — HTTP carries it in the clear. Always use HTTPS for any endpoint that handles credentials or sensitive data.
Success: 200 OK (with a JWT or session token in the response body). Some APIs return 201 Created if a new session resource is being created.
Wrong credentials: 401 Unauthorized — the client failed to authenticate. The server should not reveal which part was wrong (username vs password), to avoid leaking whether a username exists.
HSC-style questions. Try to answer each one before expanding — the exam will expect you to write these out in full sentences.
GET / HTTP/1.1 with a Host header of example.com.HTTP/1.1 200 OK and the HTML body.401 Unauthorized means the client has not provided valid authentication credentials — you are not logged in, or your token is missing or invalid. The message is: "I don't know who you are; try authenticating."
403 Forbidden means the client is authenticated (the server knows who you are) but you do not have permission to access the requested resource — you are logged in, but your role or access level doesn't cover this endpoint or resource.
The distinction matters for security: returning 403 reveals that the resource exists but is off-limits. Sometimes servers return 404 instead of 403 to avoid disclosing whether a resource exists at all — this is called "security through obscurity" (which you covered in Lesson 10).
FTP transmits everything — including usernames and passwords — as plaintext. Anyone on the same network path can intercept the connection and read credentials directly, with no decryption required.
The developer should use SFTP (SSH File Transfer Protocol) instead. SFTP encrypts all data, including credentials, using SSH — so intercepted traffic is ciphertext that cannot be read without the private key.
A common misconception: SFTP is not FTP with TLS bolted on — it is an entirely different protocol built on SSH, and it runs on port 22 (not FTP's ports 20/21).
If even one byte of the certificate was altered after signing, the hashes would not match and the browser would display a certificate error.
Even entirely public pages benefit from HTTPS for several reasons: