How the internet actually works

Where did the two seconds go?

Kofi, in Douala, taps a link to his mobile-money statement. The screen stays white for two seconds, then the page appears. What did his phone do in the meantime? To answer with something better than "the internet is slow", you need to know that opening a page is made of four successive operations, each of which can fail or slow down independently of the others.

1. DNS   name -> address           shop.bac.example -> 203.0.113.20
2. TCP   address -> connection     three messages: SYN, SYN-ACK, ACK
3. TLS   connection -> private     keys agreed, certificate checked (https only)
4. HTTP  connection -> request     GET /statement -> 200 + the data

The addresses in this workshop are fictitious: 203.0.113.0/24 is a range reserved for documentation, and the .example domain does not exist on the real internet.

The four phases in one sentence each

• DNS (Domain Name System): a directory. The network can only deliver to numeric addresses, so you ask a server called a resolver which address matches the name.
• TCP (Transmission Control Protocol): you open a reliable channel between two programs, a bit like picking up the phone and hearing "hello?" before you speak.
• TLS (Transport Layer Security): you agree on secret keys and check a certificate so that the conversation is private and tied to one named server. This phase only exists for https addresses.
• HTTP (HyperText Transfer Protocol): finally the useful conversation. The client sends a few lines of text ("give me /statement"), the server answers with a code (200 = success, 404 = not found) and some data.

A worked example

Assume a round trip (RTT, round-trip time: how long a message takes to reach the server and for the reply to come back) of 100 ms to the server, and a nearby resolver that already knows the answer (30 ms). In the usual case, with no connection already open:

This calculation is a simplified model, not a measurement: it ignores the server's processing time, the size of the reply and packet loss. It still shows the essential point: three of the four phases each cost a full round trip to the server, however little data moves. Browsers reduce this cost by reusing connections that are already open and by caching DNS answers (keeping them in memory); HTTP/3 even merges the opening of the transport with the cryptographic phase. We study the classic path because the newer variants are understood as shortcuts of it.

What each phase guarantees — and does not

Recap

Opening a page = DNS, then TCP, then TLS, then HTTP. Each phase costs time (often one round trip) and gives a narrow guarantee. Use the interactive diagram below: step through it and note, at each step, what an observer sitting on the path can read.

One capture, three protocols mixed together

A tool such as Wireshark or tcpdump shows every packet crossing a network interface. Below is a fictitious, simplified extract (private and documentation addresses): a phone 10.0.0.5 opens an https page.

No.  Source             Destination        Proto  Info
 1   10.0.0.5:53012     10.0.0.1:53        DNS    query   A shop.bac.example
 2   10.0.0.1:53        10.0.0.5:53012     DNS    answer  A 203.0.113.20
 3   10.0.0.5:40111     203.0.113.20:443   TCP    SYN
 4   203.0.113.20:443   10.0.0.5:40111     TCP    SYN, ACK
 5   10.0.0.5:40111     203.0.113.20:443   TCP    ACK
 6   10.0.0.5:40111     203.0.113.20:443   TLS    ClientHello
 7   203.0.113.20:443   10.0.0.5:40111     TLS    ServerHello (the rest of the handshake is encrypted)

How do you tell the three families apart? By what the packet is and by the port (a number naming the targeted program on a machine, after the colon):

• Lines 1-2, DNS. Port 53 is the DNS port. The phone asks 10.0.0.1 (here, the home router acting as a resolver); the web server has not been contacted yet. The answer carries the address 203.0.113.20. DNS usually travels over UDP, a light transport with no connection: one question, one answer.
• Lines 3-5, TCP. The first packet sent to the web server is line 3: SYN, "I would like to talk". Then SYN-ACK, then ACK: the connection is open. Port 443 is the usual HTTPS port.
• Lines 6-7, TLS. Once TCP is open, the client sends ClientHello: the cryptographic phase starts on top of the existing connection. In TLS 1.3, everything after the ServerHello, certificate included, is already encrypted: a capture therefore does not show it in clear (in TLS 1.2 the certificate was visible).

Layers: nested envelopes

Each message is slipped into an envelope, itself slipped into another:

The seven-layer and four-layer models in textbooks slice these envelopes slightly differently; what matters here is the order and the role, not a number to memorise.

IP routing: hop by hop

An IPv4 address is 32 bits, written as four bytes: 203.0.113.20. CIDR notation adds a slash and the number of bits that name the network: in 192.168.1.0/26 the first 26 bits name the network and the last 6 name the machines. That gives 2^6 = 64 addresses, from 192.168.1.0 (the network address) to 192.168.1.63 (the broadcast address). By convention those two extreme addresses are not assigned to machines, which leaves 62 usable addresses (the special cases /31 and /32 are out of scope).

A router has no map of the internet. It has a table: "packets for this prefix go to that neighbour". At each hop it reads the destination address, picks the line matching the most specific prefix and forwards. Each router also decrements a counter, the TTL (time to live); at zero the packet is discarded and the router reports it to the sender. The traceroute tool exploits exactly this: it sends packets with TTL 1, 2, 3… and notes who answers each time, which draws the path hop by hop.

One last useful detail: most phones and computers carry a private address (for example 10.x.x.x or 192.168.x.x). The server does not see that address: it sees the address of the device that translates at the exit of the local network.

What this does not guarantee

IP does not promise delivery: it is TCP, above it, that spots gaps and asks for missing packets again. And neither IP nor TCP protects the content: an observer on the path reads the addresses, the ports and, without TLS, the data.

Recap

DNS = a question put to a resolver (port 53, before any contact with the server). IP = addressing and routing of packets, with no guarantee. TCP = the reliable connection between two programs, recognisable by SYN, SYN-ACK, ACK. In a capture you recognise them by their nature and their port.

Why can a small page be slower than a big file?

Awa downloads a 5 MB file on a good connection, and it is quick. Then she opens a 20 KB page whose every element needs a new request, and it is slow. Two different quantities are at play, and people confuse them constantly:

• latency: the time a message takes to go and come back (RTT), in milliseconds. It depends mostly on distance and on how many devices are crossed;
• bandwidth (or throughput): how much data passes per second, in megabits per second (Mbit/s). It depends on the capacity of the narrowest link on the path.

An image: on a road, latency is the empty-road travel time; bandwidth is the number of lanes. Adding lanes does not shorten a 300 km journey.

The calculation model

To estimate the time of an exchange we will use a simplified model:

total time = (setup round trips × RTT) + (size × 8 ÷ bandwidth)

Size is in megabytes; multiply by 8 to get megabits (1 byte = 8 bits). The TCP, TLS and request phases each count as one setup round trip; DNS is counted separately (lesson 1) and is assumed already resolved here.

Example. A 5 MB file, bandwidth 20 Mbit/s, RTT 120 ms, 3 setup round trips (TCP, TLS, request):

• data transmission: 5 × 8 ÷ 20 = 2 seconds = 2,000 ms;
• setup: 3 × 120 = 360 ms;
• total: 2,000 + 360 = 2,360 ms.

Here bandwidth dominates: transmission weighs more than five times the setup. Now take a 20 KB page (0.02 MB) on the same connection: 0.02 × 8 ÷ 20 = 0.008 s = 8 ms of transmission, against 360 ms of setup. This time latency dominates almost entirely. And if the page needs ten requests over ten fresh connections, you pay the round trips ten times.

A physical floor

Light in an optical fibre travels at roughly two thirds of its speed in vacuum, about 200,000 km/s. For a 6,000 km path (a round figure, for illustration), the one-way trip takes at best 30 ms, so the round trip at least 60 ms — and real routes are longer than a straight line, with devices to cross. No software optimisation goes under that floor; you can only make fewer round trips or move servers closer.

That is why serious systems reuse connections, remember DNS answers (the first lookup is often much slower than the next ones) and batch requests. TLS 1.3 (RFC 8446, see RFC 8446) was designed, among other aims, so that a full handshake costs a single round trip, where TLS 1.2 needed two.

Why this matters later

When a blockchain node relays a block to its neighbours, or a wallet queries a remote service, the same laws apply: many small messages cost round trips, one big message costs bandwidth. You will meet this reasoning again when block propagation comes up in the consensus workshops.

What the model does not say

It is an approximation: it ignores packet loss (which forces retransmissions), TCP's gradual start (it does not use the full bandwidth at the beginning of a connection), congestion, and the server's processing time. To know what really happens you have to measure — that is the point of the independent lab.

Recap

Latency = time of a round trip; bandwidth = volume per second. Small requests are limited by latency, big files by bandwidth. Distance sets a floor that software cannot cross.

Does the padlock mean "safe site"?

A message arrives: "Your account is blocked, sign in here". The link leads to a site with a padlock in the address bar. Is the site trustworthy? No — and understanding why means separating three guarantees that are too often summed up in a single word, "encrypted".

Three guarantees, not one

The third rests on the certificate: a document, signed by an authority your device already knows, stating "this key belongs to the domain name shop.bac.example". How signatures work is the subject of workshop 105; for now remember that your device ships with a list of trusted authorities and checks that the certificate presented is signed by one of them and matches the requested name.

The flow, roughly, with TLS 1.3 (RFC 8446): the client sends ClientHello; the server replies with its key-exchange elements (ServerHello), then sends its certificate, already encrypted with the keys derived from that exchange; both sides compute the same session keys without ever sending them; everything after that is encrypted and authenticated with those keys.

What disabling verification does

A certificate error is annoying, and a lot of code "that works" bypasses it with settings such as verify=False or --insecure. What is removed then is precisely the third guarantee. The conversation stays encrypted — with someone you no longer know anything about. An attacker on the path presents their own certificate, the program accepts it; the attacker decrypts, reads, possibly modifies, re-encrypts and relays. Both ends see a perfectly encrypted connection. This is a man-in-the-middle attack, and encryption does not hinder it: it conceals it. For a test machine you control, with its self-signed certificate, the good practice is not to switch everything off: tell the tool to trust THAT specific certificate (for example curl --cacert cert.pem, or verify="cert.pem" with the Python requests library). Verification then stays active for that server only. On a path you do not control, switching it off is never acceptable.

What TLS does not protect, even correctly configured

• What you look at stays visible. The server's IP address is readable, out of necessity. In the classic setup the server name also travels in clear at the start of the handshake (the SNI field, server name indication), and the DNS query before it already did. Extensions (Encrypted Client Hello, encrypted DNS) exist to reduce these leaks, but they are not enabled everywhere. An observer therefore does not read your messages, but knows who you talk to and when.
• Size and rhythm leak. Encrypted messages whose length and tempo are known say a lot without a single byte being decrypted.
• The server sees everything. TLS protects the transport, not the destination: whatever you send to a service, it reads in clear.
• A valid certificate does not prove honesty. It attests a domain name, nothing more. A phishing site with a misleading name can obtain a valid certificate.
• The endpoints stay exposed. An infected phone reads the data before encryption and after decryption.

The question to keep

Facing any system, through the rest of the curriculum, the question is not "is it encrypted?" but:

Who can lie here, and what happens then?

You have just answered it once, across the four phases of an HTTPS request: DNS can lie (forged answer), the network can read or drop packets, the server can lie about the content. Each layer reduced part of the problem; none removed it.

Recap

TLS = confidentiality + integrity + authentication of the named server. It hides neither the server's address nor, classically, its name; it does not prove honesty; and it stops at the endpoints. Disabling verification removes authentication, not encryption.