In this chapter
We'll look underneath HTTP: how data is split into packets, why TCP is like registered post (reliable, in order) and UDP like a live radio broadcast (fast, no guarantees), and how TLS seals the envelope for HTTPS — encryption in transit, explained simply.
The Problem in Real Life
Anna asks a question John clearly loves: "The page is big. The network crosses dozens of other networks. Things must get lost on the way sometimes. How does the whole page still arrive perfectly, every time?"
"And while you're at it," she adds, "how does the padlock in the browser actually keep my password secret, if the data passes through all those strangers' networks?"
Two different promises: one says "everything arrives, in order." The other says "nobody else can read it." The internet needs both.
John
"Data Just Arrives" vs. Packets, Promises and Seals
Data travels in small pieces
A page isn't sent in one go — it's split into many small packets that may take different routes.
Pieces get lost
Some packets are lost or arrive out of order. Something has to notice and fix that.
Strangers handle your data
Your data passes through networks you don't control. Without encryption, anyone on the way could read it.
TCP, UDP and TLS
Packets — a book posted one page at a time: imagine sending a 300-page book by post, but each envelope can only hold one page. You number every page, post them separately, and they travel by different trucks. Some arrive early, some late, one might get lost. On the internet, every piece of data is split like this into small packets (usually around 1,500 bytes), each with the destination address on it. Routers pass each packet along independently. Something at the other end has to collect them, put them in order, and ask for any missing page. That's TCP's job.
- TCP — registered post with numbered pages: TCP (Transmission Control Protocol) makes the delivery reliable. It numbers every packet, the receiver confirms what arrived ("got pages 1 to 40"), missing packets are sent again, and everything is put back in the right order. Before sending data, the two sides shake hands to set up the connection: "Can we talk?" — "Yes, can you hear me?" — "Yes." (the three-way handshake). HTTP and HTTPS run on top of TCP, because a web page with a missing piece is a broken page.
- UDP — a live radio broadcast: UDP (User Datagram Protocol) just sends packets and doesn't check whether they arrived, doesn't resend and doesn't wait. That sounds worse — but it's much faster and has less delay. For live things, speed matters more than perfection: in a video call, a lost packet means one blurry frame, which is better than freezing to wait for it. Video calls, online games, live streaming and DNS lookups often use UDP.
- TLS — the sealed, signed envelope: TLS (Transport Layer Security) adds two things on top of TCP. Encryption: the data is scrambled so that only the browser and the server, who share a secret key, can unscramble it — everyone else in between sees nonsense. Identity: the server proves it really is
blueticket.exampleby showing a certificate — a digital ID card signed by a trusted organisation called a certificate authority. HTTPS is simply HTTP sent through TLS. - The TLS handshake, simply: when the browser connects, it says hello and lists the encryption methods it knows. The server replies with its choice and its certificate. The browser checks the certificate is valid, unexpired and really for this domain. Then both sides agree on a fresh secret key that nobody watching could work out — and from then on, everything is encrypted with it. All this takes a fraction of a second.
| Feature | TCP | UDP |
|---|---|---|
| Everyday version | Registered post with numbered pages | A live radio broadcast |
| Delivery guaranteed? | Yes — lost packets are resent | No |
| Order guaranteed? | Yes | No |
| Sets up a connection first? | Yes (three-way handshake) | No |
| Speed and delay | Slower, more overhead | Faster, less delay |
| Used for | Web pages, APIs, email, file downloads | Video calls, games, live streams, DNS |
| It means | It does NOT mean |
|---|---|
| The connection is encrypted | The website is honest or safe |
| Data can't be changed on the way unnoticed | The data is protected once stored on the server |
| The server proved it owns this domain | The company behind it is trustworthy |
What happens before the first byte of a web page
DNS lookup
blueticket.example → 203.0.113.10
TCP handshake
"Can we talk?" — "Yes" — "Yes" (port 443)
TLS handshake
check the certificate, agree a secret key
HTTP request and response
now encrypted — HTTPS
Encryption in transit — what it does and doesn't protect: encryption in transit means data is protected while it travels across the network. The campus Wi-Fi, the ISP and anyone on the same café network see only scrambled data. It does not protect data at rest — sitting in a database or on a disk. That's a separate protection you'll meet in Act 22.
The padlock in the browser means three things: the connection is encrypted, the data can't be changed on the way without being detected, and the server proved it owns the domain. It does not mean the website itself is honest — a scam site can have a padlock too. It only means nobody in the middle can read or change your conversation with it.
Anna sums it up in her notebook: "Packets carry the pieces. TCP makes sure all of them arrive, in order. UDP is for when fast matters more than perfect. TLS seals and signs the envelope." John reads it and adds one line under it: "And on Sale Day, an expired certificate breaks all of this at once." She underlines it, not knowing yet how true that will turn out to be.
Key Takeaway
Data travels in small packets. TCP is like registered post with numbered pages: it confirms delivery, resends what's lost and puts everything in order — used for the web. UDP is like a live broadcast: fast, no guarantees — used for calls, games and streaming. TLS seals and signs the envelope: it encrypts data in transit and proves the server's identity with a certificate; HTTPS is HTTP over TLS.
Why This Matters
Choosing TCP or UDP shapes how real-time features behave, and TLS is behind every login, payment and API call BlueTicket makes. Certificates expire, handshakes fail and connections time out — knowing the order of the steps (DNS, TCP, TLS, HTTP) tells you which one broke. It's exactly the checklist Anna will need on Sale Day.
Between the student's laptop and BlueTicket's server there are more than routers and cables. There are helpers in the middle — some that pass requests on, some that block them, and some that answer from a copy nearby. Northgate's problem was one of them; the next chapter covers the rest.