Today I'll describe, off the top of my head, how the internet works. How it reliably gets a "packet" from one computer to another.

Put simply the internet's made of wires & standards, with even the wires being standardized! Then we use this incredible network to keep ourselves tethered to Silicon Valley-managed computers.

But once computers are hooked up to a common wire those computers need to know how to share it (if not for "switches"), and figure out where a message begins & ends.


Computers sharing communicating over a shared wire or (for wifi) frequency works much like a group conversation. You listen to see if anyone is speaking before you chime in. If two start to speak at the same time you both wait a random ammount of time. You announce longer messages, and when you're done saying it. You name (via a MAC address, uniquely allocated to the machines via their manufacturer) who you're talking to.

Then there's error detection/recovery, clock signals, & "framing"...


Such protocols like Ethernet or Wifi can only directly connect a handful of computers together. To access indirectly connected computers you use IP (Internet Protocol) which replaces MAC addresses more easily routable IP addresses, and identifies the next protocol in the chain (or additional header fields).

IP addresses used to be strictly hierarchical, but that's no longer necessary.

Many are stuck on 32bit IPv4 addresses, even though 128bit IPv6 addresses have been standard since 1998.

ARP (Address Resolution Protocol) allows you to ask who on your local network owns a given IP address.

DHCP (Dynamic Host Configuration Protocol) allows newly-connected computers to request IP/DNS configuration from a local DHCP server.

And there's several "routing protocols" for automatically configuring optimal "routing tables" on the "routers" that forward IP packets between networks.

3/7 b/b

UDP very simpler adds "port numbers" identifying which programs on your & the remote computer should receive the message. Also there's a length, & a checksum for detecting errors.

The error recovery is very basic, it only applies within a single "datagram" and doesn't gaurantee data arrives in the right order or at all. There's no encryption preventing wiretaps. I'll come back to how those are addressed...

But this suitable for simpler, bootstrapping, or realtime protocols like DNS...


DNS (Domain Name System, which I've mentioned twice already) is the protocol for looking up which IP addresses correspond to a human readable name like "" you can rent (personally I think there should be other allocation options). Which is a dot-seperated hierarchical small-endian notation.

This key-value database is *heavily* cached, and when you you ask your configured DNS server to perform a lookup it may point you elsewhere to ask. Or ask them itself.


I would be surprised if plenty of DNS servers weren't using DHTs today, it wouldn't even require changing the protocol! Though the switch to IPv6 did.

And it's worth mentioning (hence this 2nd DNS toot!) that there are those questioning the need for human readable to be seperate from IP addresses. This is what Named Data Networking's all about!

5/7? b/b

Now that you can send "datagrams" to any (if not for NATs) internet-connected computer how do you send longer ones, & do so reliably?

This is what TCP is for! Alongside port numbers & checksums like in UDP, it adds sequence numbers to each packet for the receiver to echo back, ideally in their next packet, via the ACK flag to confirm they've received it. This count is initialized to a random value for both client & server by the SYN flag, which also needs to be ACK'd.


P.S. Other bitflags in TCP control the rate at which packets are sent, indicates end of transmission, etc.

And most "application-level" protocols have by now switched from being implemented upon TCP to TLS, which adds crypto to prevent wiretapping. Which involves additional negotiation of the parameters.

I don't know much at all about TLS. Hopefully that'll change with the book I just ordered from @mwlucas ...

7/7 Fin. Anyone want to expand on this thread?

I've uploaded this thread with an XKCD865 link to:

I'll probably come back sometime to expand on how TLS works... Though I did write:

More such writing at

Now I've also added some Ben Eater videos for topics I've only mentioned...

@alcinnz Nitpick: RFC 1883 (IPv6 addresses) was 1995.

I guess you're referring to RFC 2460. Though it was only ratified in 2017!

Sign in to participate in the conversation

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).