TCP/IP in depth: how network communication actually works

What TCP/IP is, and why the entire internet runs on it

TCP/IP isn't a single protocol — it's a protocol suite that defines how data is packaged, addressed, routed, and delivered between devices. It's named after its two most important protocols — TCP (Transmission Control Protocol) and IP (Internet Protocol) — but it actually encompasses dozens of others (UDP, ICMP, ARP, DNS, HTTP, and more) that together form a layered system.

The key idea is layering: each layer solves one specific problem and relies on the layer beneath it to work. An application doesn't need to worry about exactly how electrical signals travel over a cable — it only cares about its own data and hands it off to the layer below. This principle is the reason the same web browser can work over Wi-Fi, mobile data, or fiber without any change to its code.

The layer model: TCP/IP vs. OSI

Schools usually teach the 7-layer OSI model first. Real networks, however, run on the somewhat simpler 4-layer TCP/IP model. Both models describe the same reality, just at different levels of granularity:

Data travels top-to-bottom when being sent (encapsulation) and bottom-to-top when being received (de-encapsulation). Each layer adds its own header to the data from the layer above it — the resulting "package within a package" is called a PDU (Protocol Data Unit), and its name changes depending on the layer: segment (TCP) → packet (IP) → frame (Ethernet).

The network interface layer: MAC addresses and ARP

The lowest layer handles delivering data within a single local network segment (e.g., your home Wi-Fi). Every network device has a physically assigned MAC address (Media Access Control) — a 48-bit number written as six hexadecimal pairs, e.g. 3C:22:FB:A1:9B:04. The first half identifies the device manufacturer (OUI); the second half is a unique serial number.

The problem: an application knows the destination IP address, but the switch and network card need to know the MAC address. Translating between the two is handled by ARP (Address Resolution Protocol):

1. Device A sends a broadcast question: "Who has IP address 192.168.1.1? Send me your MAC address."
2. The device with that IP address (e.g., a router) replies via unicast with its MAC address.
3. Device A stores the result in its ARP cache for a limited time, so it doesn't have to ask again for every packet.

This trusting nature of the ARP protocol (no address is ever authenticated) is exactly what the ARP poisoning / ARP spoofing attack relies on, which we cover below in the security section.

The internet layer: IPv4 addressing and routing

The IP protocol handles delivering data between devices that may not be on the same local network — in other words, routing across the internet. An IPv4 address has 32 bits, written as four decimal numbers separated by dots (e.g., 192.168.1.25), each representing one byte (0–255).

The network part and host part, subnet mask

An IP address is split into a part that identifies the network and a part that identifies a specific host on that network. Exactly where the boundary falls is determined by the subnet mask, most commonly written today in CIDR notation — the number of bits reserved for the network part, e.g. /24.

For example, the address 192.168.1.25/24 means: the first 24 bits (192.168.1) are the network part, and the last 8 bits are for hosts in the range .0–.255. Of those, .0 is the network address and .255 is the broadcast address for that subnet — neither can be assigned to a specific device, so 254 addresses are actually usable.

Public, private, and special addresses

Not all addresses are routable on the public internet. RFC 1918 reserves ranges for private networks:

• 10.0.0.0/8 — the largest private range, common in large corporate networks
• 172.16.0.0/12 — mid-sized networks
• 192.168.0.0/16 — most common in home routers
• 127.0.0.0/8 — loopback, a device communicating with itself (127.0.0.1)

For devices with a private address to communicate with the internet, a router performs NAT (Network Address Translation) — it rewrites the source IP address of outgoing packets to its own public address and maintains a translation table for the return path.

Routing

When a packet leaves the local network, a router makes a decision based on its routing table — it compares the destination IP address against stored network prefixes and picks the most specific match (longest prefix match). A packet travels "hop by hop" through multiple routers this way until it reaches its destination network.

Every IP packet contains a TTL (Time To Live) field, which is decremented by 1 at every router it passes through. If it drops to 0, the packet is dropped and an ICMP "Time Exceeded" message is sent back. This mechanism prevents packets from circulating forever when there's a routing error, and it's also the basis of the traceroute tool.

The transport layer: TCP and UDP

The transport layer handles exactly how data "arrives" between two specific applications (not just devices), and whether the communication needs to be reliable. Two fundamentally different protocols handle this.

Ports: picking the right application

An IP address identifies a device, but many applications run on that device at once (a web server, a mail server, SSH...). Telling them apart is handled by a port — a 16-bit number (0–65,535). The combination of an IP address and a port is called a socket, and it uniquely identifies a specific connection.

TCP: reliability at the cost of overhead

TCP is a connection-oriented protocol — a connection must be established before any data transfer. It guarantees data is delivered in the correct order, detects loss and corruption, and automatically resolves both by retransmitting. You pay for this reliability with extra overhead (more headers, acknowledgments, a slower start).

Establishing a connection happens via the well-known three-way handshake:

1. SYN — the client sends the server a packet with the SYN flag set and a random initial sequence number, signaling "I want to establish a connection."
2. SYN-ACK — the server responds with its own SYN (its sequence number) and an ACK (acknowledging the client's SYN).
3. ACK — the client acknowledges the server's SYN. The connection is now established and data transfer can begin.

Client                          Server
  |----------- SYN seq=x -------->|
  |<------ SYN-ACK seq=y,ack=x+1--|
  |----------- ACK ack=y+1 ------>|
  |                                |
  |<====== data transfer (TCP) ===>|

Thanks to sequence numbers, the receiving side can reorder segments that may have arrived out of order over the network, and detect missing pieces. Flow control (using window size) prevents the sender from overwhelming a slower receiver. Congestion control, on the other hand, reacts to congestion in the network itself and dynamically slows the sending rate when packet loss is detected.

UDP: speed at the cost of guarantees

UDP (User Datagram Protocol) is the opposite of TCP — it's connectionless, and guarantees neither delivery, ordering, nor error correction. Its header is only 8 bytes (versus a minimum of 20 for TCP), so overhead is minimal. It's well suited anywhere speed matters more than perfect reliability, or where the application handles reliability itself.

The application layer: where your data lives

At the top of the model sit the protocols you actually encounter — HTTP/HTTPS for the web, DNS for translating domain names into IP addresses, SMTP/IMAP for email, SSH for secure remote access. These protocols define the format and meaning of data that the transport layer merely carries, without understanding it.

The life of a packet: an example

When you type a web address into your browser, roughly the following happens:

1. The browser (application layer) requests a DNS lookup to resolve the domain to an IP address.
2. A TCP connection is established on port 443 via the three-way handshake.
3. The HTTP request data is wrapped in a TCP segment (a TCP header is added, with the source/destination port and sequence number).
4. The TCP segment is wrapped in an IP packet (the source/destination IP address and TTL are added).
5. The IP packet is wrapped in an Ethernet frame (the source/destination MAC address of the next hop is added, discovered via ARP).
6. The frame travels over the physical medium through switches and routers — each router unwraps and re-wraps the frame, but leaves the IP packet inside untouched (only changing the TTL).
7. At the destination server, the process runs in reverse (de-encapsulation) until the application receives the original HTTP request.

Security consequences of TCP/IP's design

TCP/IP emerged in the 1970s for a trusted academic environment — security was never part of the original design. As a direct result, a whole range of attacks that network security still deals with today follow directly from its principles:

• IP spoofing — the source IP address in the header can easily be faked, because the protocol never verifies it. An attacker can therefore pose as someone else entirely.
• ARP spoofing / poisoning — since ARP replies are never verified, an attacker on the local network can convince other devices that their MAC address belongs to, say, the router, and reroute traffic through themselves (a classic Man-in-the-Middle attack).
• SYN flood — an attacker sends a massive volume of SYN packets without ever completing the handshake. The server allocates resources for half-open connections, and given enough volume, runs out of memory — a form of DoS attack that directly exploits the mechanics of the TCP handshake.
• Session hijacking — if an attacker guesses or intercepts the sequence numbers of an ongoing TCP connection, they can insert themselves into it and impersonate one of the parties.
• Packet sniffing — without encryption at a higher layer (TLS), packet contents are readable by anyone with access to the transmission path, e.g. on a shared Wi-Fi network.

Summary

TCP/IP is a 4-layer model that handles delivering data from the physical cable all the way to the application: MAC addresses and ARP at the local level, IP addressing and routing between networks, TCP/UDP for communication between specific applications, and application protocols like HTTP or DNS on top. Every layer adds its own header and relies on the one beneath it — and it's precisely in this principle of encapsulation, and in the trusting nature of the original design, that most network security risks hide, which we'll dig into in upcoming articles.