Networking

How the internet works

How the internet actually works. 60 minutes — a preview, not a course.

The whole idea

A website is just another computer

The cloud is not a place. It is a rented computer in a building.

Anatomy

What a URL is made of

https://www.example.com:443/exercises?topic=trees#practice

Part	Example	Job
Scheme	https	The protocol to use
Host	www.example.com	The server's name
Port	443	The service to contact; often implied by the scheme
Path	/exercises	The resource to request
Query	?topic=trees	Extra parameters sent with the request
Fragment	#practice	A location within the page; not sent to the server

The host is a name. Computers only use numbers.

DNS

The phone book of the internet

DNS resolves names into records, including IP addresses. A recursive resolver does this lookup for your device; an authoritative server holds a domain's records.

Names are for humans. IP addresses are for machines.

DNS

A name is a path down a tree

Read www.example.com from right to left: the DNS root, then com, then example, then www. Each level can delegate responsibility for the next part of the name.

The dots are not decoration. Each one is a step down a level.

DNS

Nobody has the answer. Everybody knows who to ask.

Browser → recursive resolver
              → root: “Ask the .com servers.”
              → .com: “Ask example.com's servers.”
              → authoritative server: “Here is the address.”
Browser ← recursive resolver ← answer

Three questions, two referrals, one answer. Each level knows only the next level down.

DNS · in depth

Two jobs, two kinds of server

The recursive resolver follows referrals and caches answers for you. The authoritative server answers from the records it is responsible for. A resolver with a valid cached answer can skip the walk.

The walk on the last slide is the worst case. Usually it stops one step in.

DNS · why round two is faster

The answer gets remembered

For a record with a TTL of 300 seconds, a resolver may reuse the cached answer for up to five minutes. That saves lookups, but an address change may not appear until the old answer expires.

Every answer carries a TTL — how long it may be remembered.

Ports

One machine, many doors

An IP address gets traffic to a machine's network interface. A port identifies a communication endpoint, letting services share that address. HTTPS commonly uses port 443; HTTP commonly uses port 80.

Building address, then apartment number.

NAT

Your laptop's IP is not your IP

Your laptop can have a private address such as 192.168.1.20. A website usually sees your router's public IPv4 address instead, because the router performs Network Address Translation (NAT).

Search “what is my IP” and it disagrees with your network settings. Both are right.

NAT

The router rewrites and remembers

For a typical outgoing connection, the router replaces the private source address and port with its public address and a mapped port. It keeps a table so returning traffic goes to the right laptop. Two devices can share one public address because their mappings differ.

One public address, many devices, told apart by port. This is why ports came first.

NAT · in depth

Which is why nothing can call you

Unsolicited incoming traffic normally has no existing mapping to an internal device. Port forwarding adds a rule connecting a public port to a private device and service. Firewall rules still determine which traffic is allowed.

Hosting a game server from your bedroom means port forwarding — a table row you add by hand.

TCP · in depth

Every segment carries bookkeeping

Field	Purpose
Sequence number	Where this segment's data starts in the byte stream
Acknowledgement number	The next byte expected from the other side
Flags	Signals such as SYN, ACK, and FIN
Receive window	How much more data the receiver can accept

The four highlighted fields are how TCP keeps its promises.

TCP · the three-way handshake

Watch a connection open

Client → Server: SYN, sequence x
Client ← Server: SYN-ACK, sequence y, acknowledgement x + 1
Client → Server: ACK, acknowledgement y + 1

The SYN itself consumes one sequence number. This three-way handshake establishes both sides' starting points.

Each side picks a random starting number.

TCP · in depth

Then every segment counts bytes

If a segment starts at sequence number 501 and contains 100 bytes, its data occupies positions 501 through 600. The receiver can acknowledge 601 once it has all preceding bytes in order.

seq = where my data sits. ack = the next byte I expect from you.

TCP

Scrambled in, ordered out

TCP detects gaps, retransmits missing data, and reassembles an ordered byte stream for the application. Data arriving later can be buffered until the missing earlier bytes arrive.

This is the guarantee you pay for.

TCP · in depth

The receiver sets the pace

TCP's advertised receive window tells the sender how much buffer space is available. This is flow control. Congestion control is a separate mechanism that responds to conditions on the network.

A slow phone can tell a fast server to back off — and it obeys.

TCP · the price

One lost segment stalls the rest

The application cannot read past a gap in TCP's ordered stream, even when later bytes have arrived. Several downloads sharing one TCP connection can therefore wait on the same loss.

Order is a promise, and promises cost. This is head-of-line blocking.

TCP · in depth

Closing takes four, not three

In a typical orderly close, one side sends FIN, the other acknowledges it, then sends its own FIN, which is acknowledged. Each direction closes separately. Some steps can be combined, so this is a common sequence rather than a rule that every close uses four packets.

UDP · in depth

Eight bytes. Four fields. That is all.

A UDP header has four fields: source port, destination port, length, and checksum. UDP sends separate datagrams and does not itself guarantee delivery, ordering, or retransmission. Applications can add the guarantees they need.

TCP vs UDP

What happens when one is lost

TCP recovers missing bytes so the application sees the stream in order. With UDP, the application decides whether to recover a missing update, skip it, or use the next one.

TCP cares that it arrives. UDP cares that it arrives now.

TCP vs UDP

Where each one actually shows up

Downloading a file needs every byte. A live call can often skip an old audio update because playing it late is no longer useful. Choose the application's delivery requirements first, then the transport.

Ask one question to decide: is stale data still worth having?

The same content, opposite answers

YouTube is TCP. A call is UDP.

Buffered video can wait for missing data, while a live conversation depends on timely playback. This heading captures that trade-off; actual video services can use several transports, including HTTP/3 over QUIC/UDP.

When a firewall blocks UDP, calls fall back to TCP — and you can hear it.

The twist

HTTP/3 chose UDP on purpose

HTTP/3 uses QUIC, which builds reliable streams over UDP. A gap in one stream need not stop delivery on an independent stream. Reliability still exists, but streams no longer all share TCP's one ordered byte stream.

It rebuilds ordering per download — so it pays TCP’s price only where it has to.

HTTP

One request in, one answer out

The browser requests a resource such as /exercises. The server responds with a status, headers, and often a body containing HTML, JSON, an image, or another kind of content.

HTTP · in depth

Both sides, same three parts

In HTTP/1.1, a message has a start line, headers, and an optional body, separated from the headers by a blank line. A request starts with a method and target; a response starts with a status code.

A GET usually has no body at all. A POST almost always does.

Request headers

What the browser volunteers

Request headers can describe acceptable formats (Accept), identify the target host (Host in HTTP/1.1), carry eligible cookies (Cookie), or describe a sent body (Content-Type). Cookies depend on the request matching the cookie's scope and browser policy.

Response headers

What the server declares

Response headers can identify the body format (Content-Type), control caching (Cache-Control), set a cookie (Set-Cookie), or provide a resource location (Location). They tell the browser how to handle the answer.

The security ones exist because the default answers turned out to be dangerous.

One header, three defences

Set-Cookie is the whole login

A common login flow sets a session cookie, then checks it on later requests. The cookie is one part of the flow: the server still authenticates credentials and validates the session. HttpOnly restricts JavaScript access, Secure limits transmission to secure connections, and SameSite controls when cookies accompany cross-site requests.

The payload

Content-Type decides how to read it

application/json means the body is JSON; text/html means HTML; image/png means a PNG image. The receiver needs the type as well as the bytes to interpret the payload correctly.

A real POST, top to bottom

Submitting an exercise

POST /api/submissions HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length: 76
Cookie: session=abc123

{"exercise":"bsearch-ex2","language":"python","code":"def search(a,t): ..."}

HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Location: /api/submissions/8814
Content-Length: 54

{"id":8814,"status":"passed","exercise":"bsearch-ex2"}

201, not 200 — something was created. Location says where it now lives.

The payload

How the receiver knows where to stop

In HTTP/1.1, Content-Length can specify the body's byte count. Chunked transfer encoding instead sends a length before each chunk and finishes with a zero-size chunk. HTTP/2 and HTTP/3 use their own framing.

A zero-size chunk means “that was the end”.

Headers doing real work

The 304: an answer with no body

A browser can ask whether its saved copy is still valid, for example with If-None-Match. A 304 Not Modified response tells it to reuse that copy. The response still transfers headers, but does not resend the resource body.

The rows in the lab with status 304 and a size in bytes. That was this.

HTTP

Four verbs cover almost everything

Method	Typical purpose
GET	Read a resource
POST	Submit data or request processing, often creating a resource
PUT	Create or replace the resource at a known URL
DELETE	Request removal of a resource

Other methods exist, including PATCH for partial updates and HEAD for retrieving response metadata without the body.

Nearly every request you make all day is a GET.

Status codes

Memorize the first digit, not the list

Family	Meaning	Example
1xx	Informational	100 Continue
2xx	Success	200 OK, 201 Created
3xx	Redirection or conditional reuse	301 Moved Permanently, 304 Not Modified
4xx	A problem with the request or its permissions	404 Not Found
5xx	A server-side failure	500 Internal Server Error

Statelessness

The server forgets you instantly

HTTP does not automatically make one request remember another. Servers can still keep application state in databases or session stores; each request supplies the information needed to connect it to that state.

So you prove who you are every single time. That is what a cookie is.

HTTPS

Same language, sealed envelope

HTTPS carries HTTP through TLS, which encrypts traffic in transit, protects its integrity, and authenticates the server using certificates. It protects the connection; it does not prove every claim on the page is true.

Email

Nobody is waiting on the other end

SMTP transfers email between mail systems. A receiving server can store a message until the recipient reads it. Unlike a live call, the sender and recipient do not need to be online together.

The web is pull — you ask, it answers. Email is push and store — handed along, no one waiting.

SMTP · in depth

It is a conversation, in text

S: 220 mail.example.com ESMTP
C: EHLO mail.sender.com
S: 250 Hello mail.sender.com

C: MAIL FROM:<amara@sender.com>
S: 250 OK
C: RCPT TO:<tutor@example.com>
S: 250 Accepted

C: DATA
S: 354 Go ahead, end with a lone dot

C: Subject: Exercise submitted
C: From: Amara <amara@sender.com>
C:
C: I finished the BST one.
C: .
S: 250 Queued as 8814
C: QUIT

Numbered replies, exactly like HTTP: 250 fine, 354 keep going, 550 rejected.

Email · in depth

The sender is just a claim

A displayed From address alone does not prove who sent a message. SPF, DKIM, and DMARC add checks around sending authorization, signatures, and domain alignment; they do not make every message trustworthy.

SMTP was built for a small, trusted network. Every anti-spam check was bolted on afterwards.

All of it, in order

One page, one journey

URL → DNS lookup or cached answer → server address
    → transport connection + TLS for HTTPS
    → HTTP request → server logic → database if needed
    ← HTTP response ← result
    → browser parses HTML and requests assets or data
    → browser renders pixels

Connections and cached resources can be reused. The exact order depends on the HTTP version and what is already cached.

A few hundred milliseconds. Dozens of round trips. This is the diagram to keep.

25 minutes · open DevTools

Now go watch it happen

1. Open your browser's DevTools, select Network, then reload a page.
2. Inspect one document request: find its URL, method, status, headers, and response.
3. Filter to Fetch/XHR and look for JSON data requests.
4. Visit a nonexistent path and find the 404 response.
5. Try network throttling, reload twice, and compare timing and caching. Turn throttling off afterwards.

Network tab → find the request → find the data → break it → slow it down.

Honesty

What we skipped

Routing, Wi-Fi, Ethernet, IPv6, TLS cryptography, congestion algorithms, and browser rendering each deserve their own lesson. This session gives you places to attach those ideas later.

Each one is a real subject. This was a map, not the territory.