01Executive summary
Four milestones that connected machines in a building, secured communication between strangers, joined dissimilar networks into one, and then put a usable interface on top.
Ethernet in 1973 solved local connection with deliberate randomness. Public-key cryptography in 1976 made it possible to establish a secret with someone you have never met. The TCP/IP transition in 1983 gave dissimilar networks one addressing and transport layer. The World Wide Web, proposed in 1989 with the first server running in 1990–91, was an application built on top of all three.
02Ethernet: randomness as an engineering strategy
Connecting machines in a building could have been solved by giving each a scheduled slot, or by passing a token that grants permission to transmit. Both were tried and both work. Ethernet took a different approach: let any station transmit when the medium appears idle, detect the collision if two start together, and have both stop and retry after a random interval that doubles with each successive collision.
This is uncomfortable on first encounter. The protocol deliberately permits a failure mode and then recovers from it, rather than preventing it. The justification is load-dependent: at low to moderate utilisation, collisions are rare and a station transmits immediately with no coordination overhead at all, whereas a scheduled scheme pays its coordination cost on every transfer regardless of load.
Optimise for the common case
Making the frequent path cheap and the rare path expensive usually beats making every path uniformly moderate. The same reasoning drives caching, optimistic concurrency and exception-based error handling.
Randomness breaks symmetry
Two stations following identical deterministic rules will collide again immediately. A random wait guarantees they eventually differ. Exponential backoff now appears in essentially every retry policy in distributed systems.
Ethernet as deployed today has almost nothing in common with the original shared coaxial medium: switched full-duplex links mean collisions no longer occur. What survived is the frame format and the addressing — the interface, not the mechanism. That is the same outcome seen with the shipping container and the instruction set, and it is worth noticing how consistently the interface outlives the technology that motivated it.
03Public-key cryptography: a secret without a meeting
All cryptography before 1976 assumed the parties shared a secret key, distributed in advance by some trustworthy means. That is workable for a military or a bank and impossible for open commerce, because it requires a prior secure meeting between every pair of parties.
Diffie and Hellman showed that two parties could agree a shared secret over a channel an eavesdropper can hear completely, using operations that are easy to perform and believed hard to reverse. RSA in 1977 provided a practical construction supporting both encryption and digital signature. Equivalent results had been obtained earlier at GCHQ in the United Kingdom but were classified and not disclosed for decades, which is a genuine and instructive case of parallel invention hidden by secrecy.
These schemes are not proven secure. They rest on the belief that certain mathematical problems are computationally hard, a belief supported by sustained failure to find an efficient method rather than by proof. That is an unusual engineering position: a load-bearing assumption that could in principle be invalidated by a single result. It is the reason cryptographic agility — the ability to change algorithm without redesigning the system — is a design requirement rather than a refinement.
04TCP/IP: a common layer over dissimilar networks
By the early 1980s there were many networks using incompatible technologies. The internet problem was not building a network; it was joining networks that would never be made uniform.
The solution was a thin common layer. The Internet Protocol defines an addressing scheme and a packet format, and asks very little of the network beneath it — only that it can carry a packet, and it need not promise to succeed. Anything that can do that can participate. Reliability, ordering and flow control live above, in TCP, at the endpoints.
One protocol in the middle, many technologies below it and many applications above. Adding a new link technology requires no change to applications; adding a new application requires no change to networks. The value of the layer comes precisely from how little it does — every capability added to it would have to be implemented by every network beneath. Deliberate minimality at an interface is a recurring high-value design decision, and the temptation to enrich such a layer should be resisted hard.
The 1983 transition is worth noting as a project rather than a protocol. A large operational network changed protocol suite on an announced date, after a lengthy period in which both were supported and hosts were converted incrementally. Running old and new in parallel, converting progressively, then cutting over on a date with the fallback removed is a migration pattern that still works and is still routinely botched.
05The Web: an application, not the network
The Web and the internet are constantly conflated, and the distinction is not pedantry. The internet is the packet network and its protocols, developed over the two decades before. The Web is one application running on it, alongside mail, file transfer and many others. Tim Berners-Lee did not invent the internet; he invented a hypertext system that ran on it.
| Decision | Benefit | Cost accepted |
|---|---|---|
| Stateless requests | Any server can answer any request; servers are trivially replicated | Session state must be reconstructed each time, via cookies or tokens |
| Links may break | No central registry, so anyone can publish without permission or coordination | Link rot, and no referential integrity anywhere in the system |
| Tolerant parsing | Imperfect documents still render, lowering the barrier to publishing | Ambiguous behaviour, security issues, and decades of compatibility work |
| Text-based protocol | Easy to implement, debug and extend by anyone | Verbose on the wire, later addressed by binary framing in newer versions |
The middle two are the interesting ones. Both are, judged narrowly, defects. A system where links break and malformed documents render anyway is not what a careful designer would specify. But both decisions removed coordination requirements, and removing coordination requirements is what allowed unbounded growth without anyone’s permission. A stricter system would have been better engineered and very likely smaller.
06Takeaways for current practice
- Optimise the common path and recover from the rare one. Permitting a recoverable failure often beats preventing it, once load is considered.
- Use randomness to break symmetry. Identical deterministic agents contend forever; exponential backoff is the default answer.
- Keep the common layer as thin as possible. Every capability added to a narrow waist must be implemented by everything beneath it.
- Design for algorithm replacement. Cryptographic security rests on assumed hardness, so agility is a requirement.
- Removing coordination requirements enables growth. Strictness and scale trade against each other more often than is comfortable.
- Migrate by running both, converting incrementally, then cutting over. The 1983 flag day worked because of the years of dual support preceding it.