Here 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 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 with more easily routable IP addresses, and identifies the next protocol in the chain (or additional header fields for e.g. debugging).
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 1995. IPv6 should last us until intersteller communication, or nanobots are eating our planet.
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.
UDP very simply 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 “adrian.geek.nz” 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 ongoing switch to IPv6 did.
And it’s worth mentioning that there are those questioning the need for human readable names to be seperate from IP addresses. This is what Named Data Networking’s all about!
Now that you can send “datagrams” to any (if not for NATs, a legacy measure against IPv4 scarcity) 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.
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 crypto parameters.