TCP/IP Explained: The Protocol Suite Behind Every Network

TCP/IP is the phrase everyone uses and few people can describe precisely, because it names a whole family of protocols rather than a single thing. Once the division of labour inside that family is clear, a lot of otherwise mysterious network behaviour starts to make sense, from why video calls stutter while file transfers survive, to why a port number matters in a firewall rule.

At its core, TCP/IP is two ideas stacked together. IP handles getting packets to the right machine. TCP handles making a conversation out of those packets. Everything else is supporting work around them.

IP: Addressing and Best Effort Delivery

IP, the Internet Protocol, gives every host an address and forwards packets toward that address. It is deliberately simple and deliberately unreliable. A router that receives a packet looks at the destination and sends it on the best path it knows, with no promise that the packet arrives, no promise about order, and no promise about how long it takes.

That simplicity is what lets IP scale. Because a router does not have to track connections or guarantee delivery, it can forward enormous volumes of traffic with small amounts of state. The trade off is that reliability, ordering, and congestion control have to live somewhere else, which is where TCP comes in.

TCP and UDP: Two Ways to Use IP

TCP builds a reliable, ordered stream on top of IP. It opens a connection with the three-way handshake, numbers every byte it sends, acknowledges what the other side received, retransmits what was lost, and slows down when the network is congested. Applications that need every byte, such as a web page, a file transfer, or an SSH session, use TCP.

UDP takes the opposite approach. It sends datagrams with no connection, no ordering, and no retransmission. That sounds worse, but it is exactly right for DNS queries, video, voice, and games, where a late packet is worse than a lost one and the application would rather move on than wait. The application decides how to handle loss, or accepts it.

Ports and the Handshake

A packet reaches the right host because of its IP address, and the right application because of its port number. A server listens on a well-known port, a client picks an ephemeral port for its side, and the combination identifies the specific conversation. That is why a firewall rule is usually built from an address, a protocol, and a port, and why the common ports reference is one of the most used tables in networking.

The TCP handshake is the other piece you meet constantly. The client sends a SYN, the server replies with SYN-ACK, and the client completes with ACK. If a firewall blocks any of the three, the connection never forms, and the symptom is usually a timeout rather than an error, which is why tracing the handshake is a standard first step for a connection problem.

The Supporting Cast

A few protocols do the work that makes the rest usable. ARP resolves an IP address to a MAC address on the local segment, so a host knows where to send a frame. ICMP reports errors and powers ping and traceroute. DNS turns names into addresses, explaining how DDI services fit together. DHCP hands out addresses and gateway settings automatically.

ICMP and ARP are easy to overlook and central in practice, because a broken ARP entry or a filtered ICMP message produces symptoms that look like application bugs. The ICMP guide covers that side in more detail.

IPv4, IPv6, and Why Both Exist

IPv4 has a 32-bit address space, which ran out of public addresses years ago and forced widespread use of NAT. IPv6 has a 128-bit space, so addresses are effectively unlimited, and it removes the need for NAT in the common case. The two run side by side in dual stack networks, which means a single host usually holds both an IPv4 and an IPv6 address.

IPv6 also changes habits. It relies on private and special use ranges far less, uses link-local addressing for local discovery, and expects every LAN to be a /64. Teams that plan IPv6 using IPv4 intuition usually misjudge how large an allocation is, which is why a subnet calculator that handles both matters.

From Protocol Suite to Address Plan

TCP/IP describes how data moves. It says nothing about who owns which address, which subnet belongs to which site, or which team is responsible for a segment. Those answers live in your address plan, and they are what make the protocol suite operable rather than merely understood.

Once you can see each subnet, its gateway, and its devices in one place, the IP address management view in Obelinf turns TCP/IP from a mental model into a map you can act on.