1. What a network is, and why TCP/IP won

1.1 The problem being solved

A network exists to move a chunk of data from a process on one machine to a process on another machine, across links that are unreliable, of varying speed, owned by different organizations, and constantly changing shape.

Break that sentence into the hard sub-problems:

TCP/IP is not one protocol. It is a layered set of protocols where each layer solves one of those sub-problems and hands the rest to the layer below.

1.2 A one-paragraph history (why it matters)

The suite came out of the US DARPA-funded ARPANET research in the 1970s. Vint Cerf and Bob Kahn's 1974 paper split the original monolithic "Transmission Control Program" into IP (best-effort delivery of packets) and TCP (reliability on top). The design goals — in priority order — were: survive loss of network hardware, support multiple transport services, accommodate many different networks, allow distributed management, be cost-effective, allow easy host attachment, and account for resources. Security and accurate billing were explicitly low priority. That ranking explains almost every rough edge you will ever hit: NAT exists because host attachment and address conservation mattered; spoofing is easy because security was #7; congestion control had to be bolted on after the 1986 "congestion collapse" of the NSFNET.

The competing standard, the OSI protocol suite, was designed by committee, was more complete on paper, and lost — because TCP/IP had running code, was free with Berkeley Unix (the "sockets" API, 1983), and was good enough. "Rough consensus and running code" (the IETF motto) beat formal completeness.

1.3 The three ideas that make it work

1. Packet switching, not circuit switching. The phone network of the era set up a dedicated end-to-end circuit per call. TCP/IP chops data into independently-addressed packets that share links statistically. A link with 1 Gbit/s capacity can serve thousands of mostly-idle connections because they rarely all burst at once.

2. The end-to-end principle. Keep the network core dumb and fast; push intelligence (reliability, encryption, ordering) to the endpoints. A router in the middle just forwards packets toward their destination. It does not track your TCP connection, retransmit for you, or care what's inside. This is why you can invent QUIC (a new reliable transport) without upgrading a single router.

3. The narrow waist. Everything runs over IP, and IP runs over everything. Draw the protocol suite as an hourglass: many link layers at the bottom (Wi-Fi, Ethernet, LTE, fiber), many applications at the top (HTTP, DNS, SMTP, SSH), and a single skinny neck in the middle — IP. Agreeing on exactly one internetworking protocol is what lets any app talk over any medium.

   HTTP  DNS  SMTP  SSH  RTP  QUIC  ...        <- many applications
      \    \   |    |   /    /
             TCP        UDP                     <- a few transports
                \      /
                  IP                            <- THE narrow waist
                /      \
      Ethernet  Wi-Fi  LTE  DOCSIS  MPLS ...    <- many link layers

1.4 War story

A startup ran its own "reliable UDP" protocol between microservices to "avoid TCP overhead." It worked in the lab. In production, p99 latency was 40x worse than a sister service on plain TCP. Root cause: they had reimplemented retransmission but not congestion control, so under load their traffic caused queue buildup at a shared switch, which caused loss, which caused more retransmits — a miniature congestion collapse. Lesson: the hard part of TCP is not the handshake, it's the 35 years of congestion-control tuning you get for free.

Try it yourself

# See the layers in one packet
sudo tcpdump -i any -c1 -vvv -e 'tcp port 443'
# -e shows the Ethernet (link) header; -vvv expands IP and TCP headers.