An Introduction to TCP/IP

Every time you load a web page, send an email, or SSH into a remote machine, TCP/IP is doing the heavy lifting underneath. Understanding it is not optional for anyone who works with Linux systems — it explains why commands behave as they do, why firewalls are written the way they are, and why troubleshooting stops being guesswork once you know the layers involved. This guide walks through the core concepts with enough depth to be useful and enough brevity to stay approachable.

What TCP/IP Actually Is

TCP/IP is not a single protocol — it is a suite of protocols that together handle how data is addressed, routed, and delivered between machines. The name comes from its two most important members: the Transmission Control Protocol (TCP) and the Internet Protocol (IP). Every other protocol in the suite — UDP, ICMP, DNS, and others — builds on the same foundation.

The suite is organized into four conceptual layers. Think of them as a stack: each layer hands work up or down to the layer adjacent to it.

• Link layer — physical and logical delivery on a single network segment (Ethernet, Wi-Fi, etc.).
• Internet layer — addressing and routing packets across networks using IP addresses.
• Transport layer — end-to-end communication between processes, using TCP or UDP.
• Application layer — the protocols your programs speak directly: HTTP, SSH, DNS, SMTP.

When your browser fetches a page, data travels down the stack on your machine (application → transport → internet → link) and back up the stack on the server. Each layer wraps the payload from the layer above in its own header — a process called encapsulation.

IP Addresses and Subnets

An IP address identifies a host on a network. IPv4 addresses are 32-bit numbers written as four decimal octets separated by dots: 192.168.1.42. IPv6 addresses are 128-bit, written in hex groups: 2001:db8::1. Both are in active use on modern Linux systems.

A subnet mask (or prefix length in CIDR notation) tells the system which part of the address identifies the network and which part identifies the host. For example, 192.168.1.0/24 means the first 24 bits are the network — hosts in that subnet run from 192.168.1.1 to 192.168.1.254, with .0 reserved as the network address and .255 as the broadcast address.

To see your current IP addresses on Linux:

ip addr show

Output will vary, but you will see entries like inet 192.168.1.42/24 for IPv4 and inet6 fe80::1/64 for link-local IPv6. The older ifconfig command is deprecated; use ip from the iproute2 package instead.

How Routing Works

When your machine sends a packet, the kernel checks its routing table to decide where to send it. If the destination is on the same subnet, the packet goes directly to that host. If not, it goes to the default gateway — typically your router — which forwards it toward the destination.

ip route show

Look for the line starting with default via — that is your gateway IP. Every packet destined for an address not in any local subnet goes there first.

At the link layer, IP addresses are resolved to hardware (MAC) addresses using ARP (Address Resolution Protocol) on IPv4, or NDP (Neighbor Discovery Protocol) on IPv6. Your machine broadcasts "who has 192.168.1.1?" and the gateway replies with its MAC address. The kernel caches these mappings.

ip neigh show

TCP vs UDP

The transport layer gives you two main choices, and picking the wrong mental model causes real confusion when debugging.

TCP (Transmission Control Protocol) is connection-oriented and reliable. Before any data flows, the two endpoints complete a three-way handshake:

1. Client sends SYN — "I want to connect."
2. Server replies SYN-ACK — "Acknowledged, ready."
3. Client sends ACK — "Connection established."

TCP tracks every byte sent, retransmits lost segments, reorders out-of-order arrivals, and manages flow control. HTTP, SSH, SMTP, and most application protocols use TCP because correctness matters more than raw speed.

UDP (User Datagram Protocol) is connectionless. It fires packets and forgets them — no handshake, no acknowledgement, no retransmit. DNS queries, video streaming, VoIP, and online games often use UDP because latency matters more than guaranteed delivery, and the application can handle its own error correction (or tolerate some loss).

Ports and Sockets

An IP address identifies a machine; a port identifies a specific process on that machine. Ports are 16-bit numbers (0–65535). Well-known ports are standardized: SSH is 22, HTTP is 80, HTTPS is 443, DNS is 53. Ports 1024 and above are available for general use; on Linux, binding ports below 1024 requires elevated privileges (or the CAP_NET_BIND_SERVICE capability).

A socket is the combination of IP address + port + protocol. A TCP connection is uniquely identified by the four-tuple: source IP, source port, destination IP, destination port. This is why a single server can hold thousands of simultaneous connections on port 443 — every connection has a different source IP or source port.

To see active connections and listening sockets on your system:

ss -tulnp

Flags: -t TCP, -u UDP, -l listening, -n numeric ports, -p show process. The older netstat is deprecated; ss from iproute2 is its modern replacement.

ICMP and Basic Diagnostics

ICMP (Internet Control Message Protocol) lives at the internet layer and carries control messages — not application data. The two tools you will use most are built on ICMP.

ping sends ICMP Echo Request packets and waits for Echo Reply responses. It confirms basic reachability and round-trip time:

ping -c 4 9.9.9.9

traceroute (or tracepath, which needs no root) maps the path packets take to a destination, showing each router hop and its latency:

tracepath 9.9.9.9

If ping succeeds but a higher-level service does not, the problem is above the internet layer. If ping fails, check routing, firewalls (ICMP is often rate-limited or blocked), or physical connectivity first.

DNS: Turning Names into Addresses

Humans use hostnames; IP requires numeric addresses. DNS (Domain Name System) is the distributed database that translates one to the other. When you type linuxjunkies.com into a browser, your system asks a resolver (usually configured in /etc/resolv.conf or managed by systemd-resolved) which queries the DNS hierarchy on your behalf.

To query DNS directly from the command line:

resolvectl query linuxjunkies.com

Or with the classic tools (still useful for scripting):

dig linuxjunkies.com A
nslookup linuxjunkies.com

DNS runs over UDP port 53 for most queries (falling back to TCP for large responses or zone transfers). If name resolution is broken but IP connectivity is not, check /etc/resolv.conf, the status of systemd-resolved, and whether UDP/53 is blocked by a firewall.

systemctl status systemd-resolved

Verification: Tracing a Full Connection

The best way to confirm you understand the stack is to watch a real connection happen. Open two terminals.

In the first, capture traffic on your primary interface (substitute eth0 or wlan0 for your interface name):

sudo tcpdump -i eth0 -n host 9.9.9.9

In the second, make a DNS query over TCP to force a visible connection:

dig +tcp @9.9.9.9 example.com

In the tcpdump output you will see the three-way handshake (SYN, SYN-ACK, ACK), the DNS query and response, and the connection teardown (FIN, ACK). Every concept in this guide is visible in that trace.

Troubleshooting Basics

• No connectivity at all: Check ip addr show for a valid address. If the interface shows DOWN, bring it up with ip link set eth0 up or check your network manager service (systemctl status NetworkManager or systemctl status systemd-networkd).
• Can ping gateway, cannot reach internet: Your default route may be missing (ip route show), or the gateway itself has no upstream. Check DNS separately — it is often mistaken for a routing problem.
• DNS fails, IP connectivity works: Test with a raw IP to confirm (curl -I http://9.9.9.9). Then check /etc/resolv.conf and systemd-resolved status.
• Port unreachable / connection refused: "Connection refused" means the host is reachable but nothing is listening on that port. "No route to host" or timeout suggests a firewall or routing issue. Use ss -tulnp on the server to confirm the service is actually listening.
• Diagnosing firewall rules: On modern systems check nft list ruleset, firewall-cmd --list-all (Fedora/RHEL), or ufw status verbose (Ubuntu/Debian).