The TCP/IP protocol family is the invisible foundation of everything you do as a Linux administrator or systems integrator. Whether you reach a web server, connect a Docker container to the internet or fix a network problem on an Ubuntu server — without TCP/IP nothing works.
Think of it as a huge, worldwide postal system. You write a letter (the data), hand it in at the counter (your application) and the system makes sure it arrives safely, in the right order and without losses. That is what TCP/IP does — for billions of packets per second.
TCP/IP as a postal system — the overview
┌─────────────────────┐
│ Application layer │ ← write the letter (e.g. email)
├─────────────────────┤
│ Transport layer │ ← confirm (TCP) or just send (UDP)
├─────────────────────┤
│ Internet layer │ ← plan the route (IP routing)
├─────────────────────┤
│ Network access │ ← envelope + van (Ethernet/Wi-Fi)
└─────────────────────┘
Unlike the OSI model, which describes seven theoretical layers, TCP/IP works with only four practical layers. That is why it succeeds in the datacentre and on your Linux server.
OSI vs TCP/IP — direct comparison
OSI model TCP/IP model
┌─────────────────┐ ┌──────────────┐
│ 7 Application │ │ │
│ 6 Presentation │ ────► │ Application │
│ 5 Session │ │ │
├─────────────────┤ ├──────────────┤
│ 4 Transport │ ────► │ Transport │
├─────────────────┤ ├──────────────┤
│ 3 Network │ ────► │ Internet │
├─────────────────┤ ├──────────────┤
│ 2 Data link │ │ │
│ 1 Physical │ ────► │ Net access │
└─────────────────┘ └──────────────┘
Why TCP/IP is indispensable for you as a Linux administrator
On a Linux server (Ubuntu, Debian, Arch or Rocky Linux) everything talks TCP/IP. When you run docker run and the container needs the internet, when you ssh to a remote host or when apt update suddenly hangs — TCP/IP is always underneath.
You will learn why a ping works, why port 443 is reserved for HTTPS and how you find out with a few commands why your server suddenly builds no connection.
# Quick check: shows your TCP/IP configuration immediately
ip addr show
ss -tuln
💡 Tip for beginners: Open a terminal on your Linux system now and run the two commands above. You see live how TCP/IP works on your machine. That is the best way to understand the topic — not only read, but try it immediately.
Topics you will cover
The next four sections walk you through:
- The four layers of the TCP/IP model and how data travels through them
- The most important protocols (TCP, UDP, IP, ICMP, DNS, HTTP) in detail
- Addressing, routing and current developments (IPv4, IPv6, dual-stack)
- Practical use and troubleshooting on real Linux servers
Each section contains ASCII diagrams, tables and real commands you can copy.
Who this is for
This is for you if you:
- are a systems integrator preparing for LPIC-1 or CompTIA Network+
- are a Linux administrator who looks after servers, Docker containers or networks every day
- come from Windows and want to understand why Linux networks work differently (and better)
- want clear explanations, practical examples and no empty theory
How you get the most out of it
Take a Linux system (Ubuntu 24.04 LTS or a VM) and work in parallel. Every diagram and every command is built so you can follow it immediately.
⚠️ Important: Some commands need
sudo. That is always marked clearly.
💡 Practical tip: Create a test directory and save the most important commands in a file
tcpip-cheatsheet.md. Then you have everything to hand later.
❗ Pitfall: Many beginners think TCP/IP is “only theory”. In reality you solve 80 % of all server problems once you understand this protocol family.
After this you will not only know how TCP/IP works — you will see, measure and repair it on your Linux server.
Basics and the four layers
Before the individual protocols, you need to understand how TCP/IP actually sends data through the network. The TCP/IP model is deliberately simple — only four layers instead of OSI’s seven theoretical ones. That simplification is why TCP/IP has kept the internet running for decades and why you as a Linux administrator can work with it so well.
Why four layers instead of seven?
OSI model (theory) TCP/IP model (practice)
7 Application │
6 Presentation ────────────► │ Application layer
5 Session │ (HTTP, DNS, SMTP)
4 Transport │
│ Transport layer (TCP/UDP)
3 Network ────────────► │ Internet layer (IP)
2 Data link │
1 Physical ────────────► │ Network access layer
│ (Ethernet, Wi-Fi)
Each layer has a clear job and only hands data to the layer directly below or above. That is called encapsulation — data is packed further on the way down and unpacked on the way up.
1. Network access layer
Physical transport
This lowest layer is responsible for the actual transport of bits over cable, Wi-Fi or fibre. This is where Ethernet frames, MAC addresses and Wi-Fi frames come in.
Ethernet frame (simplified)
┌──────────┬───────────┬──────────┬──────────┬────────┬───────┐
│ Preamble │ Dest MAC │ Src MAC │ Type │ Data │ CRC │
└──────────┴───────────┴──────────┴──────────┴────────┴───────┘
MAC address
Every network card has a globally unique 48-bit MAC address (for example 00:1A:2B:3C:4D:5E). It is hardware-based and not meant to change — unlike the IP address, which you can assign freely.
# Shows all network interfaces and their MAC addresses
ip link show
# Sample output on an Ubuntu server:
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 08:00:27:ab:cd:ef brd ff:ff:ff:ff:ff:ff
💡 Tip: The first three bytes of the MAC address tell you the vendor (OUI). With
ip linkyou immediately see whether you have an Intel, Realtek or Broadcom card.
Wi-Fi vs Ethernet
On Wi-Fi the same layer does the job, only with radio waves instead of electrical signals. The frame structure stays almost identical.
⚠️ Important for beginners: The network access layer does not care where the packet is going — that is the internet layer. It only knows: “This frame must go to the next device with this MAC address”.
2. Internet layer
The global navigation system
This is where the Internet Protocol (IP) comes in. This layer handles logical addressing and routing. Every packet gets a source and destination IP address.
IP packet (IPv4 header strongly simplified)
┌──────┬──────┬─────┬─────┬────────────────┬───────────────┐
│ Ver │ IHL │ TOS │ Len │ Identification │ Flags/Offset │
├──────┼──────┼─────┼─────┼────────────────┼───────────────┤
│ TTL │ Prot │ HDR │ │ Source IP │ Dest IP │
│ │ │ Cks │ │ │ │
└──────┴──────┴─────┴─────┴────────────────┴───────────────┘
Routing in practice
Your Linux server has a routing table. When you ping google.com, the kernel looks up: “Which interface and which gateway do I use for 8.8.8.8?”
# Shows the complete routing table
ip route show
# Typical output:
default via 192.168.1.1 dev enp0s3 proto dhcp metric 100
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.42
🔧 Practical example:
Imagine a Docker container that cannot reach the internet. With ip route you immediately see whether the default route is missing.
Fragmentation
If a packet is too large for the next net (MTU), it is split into smaller fragments. That usually happens with VPNs or old devices.
❗ Common error: MTU problems lead to “black hole” connections (packets vanish). With
ping -M do -s 1472 8.8.8.8you can test the maximum MTU.
3. Transport layer
Reliable or fast?
This layer provides end-to-end communication between two applications. Here you make the most important decision: TCP or UDP?
TCP vs UDP — direct comparison
Feature TCP UDP
Connection Yes (three-way handshake) No
Reliability Yes (ACK, retransmit) No
Order Guaranteed Not guaranteed
Overhead High Very low
Typical ports 22, 80/443 53, 123 NTP
TCP three-way handshake step by step
- Client sends SYN
- Server answers with SYN-ACK
- Client sends ACK
Client Server
│───SYN (Seq=100)───►│
│◄──SYN-ACK (Seq=50)─│
│───ACK (Seq=101)───►│
│ Data flows │
Ports
Every application “listens” on a port (0–65535). The first 1023 are privileged (root only).
# Shows all listening TCP/UDP ports
ss -tuln
# Example: web server + SSH + Docker
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:53 0.0.0.0:*
4. Application layer
Where you work as an admin
This is where the protocols you use directly run: HTTP, HTTPS, SMTP, DNS, SSH. This layer talks to your programs.
Data flow from top to bottom (encapsulation)
Application: GET /index.html HTTP/1.1
│
Transport: TCP packet (port 443 → 443)
│
Internet: IP packet (192.168.1.42 → 8.8.8.8)
│
Net access: Ethernet frame (MAC to MAC)
💡 Watch it live with tcpdump
You can see the whole path:
# Capture only HTTP traffic on port 80 (as root)
sudo tcpdump -i enp0s3 -nn port 80 -c 10
Why all of this matters for Linux admins
On a real server you see these layers constantly. docker ps shows you container ports, ip addr shows IP and MAC, ss -tuln shows TCP/UDP and tcpdump shows you every single packet.
🔧 Practical example:
- Open two terminals
- Terminal 1:
sudo tcpdump -i any -nn port 80 - Terminal 2:
curl -I https://admindocs.de
You see live how the four layers work together.
Once you have the four layers, the next section goes deep into the most important protocols — TCP, UDP, IP, ICMP and DNS. After that you will see every command on your Linux server with different eyes.
The most important protocols in detail
You know the four layers — now the protocols that actually do the work in those layers. As a Linux administrator you meet them every day: when you SSH to a server, when you resolve domains or when a Docker container suddenly has no connection. We go layer by layer and you learn exactly which protocol does which job when.
Transport protocols
TCP and UDP — the two faces of reliability
The transport layer is the first place you as an admin make a real decision: do I need absolute reliability or maximum speed?
TCP vs UDP — the direct practice comparison
Property TCP UDP
Setup Three-way handshake None
Errors ACK + retransmit None
Order Guaranteed Not guaranteed
Speed Slower Very fast
Overhead High (~20 B) Low (8 B)
Uses SSH, HTTP, SMTP, DBs DNS, NTP, VoIP
TCP — the reliable workhorse
TCP first builds a connection. That always happens in exactly three steps — the famous three-way handshake.
Three-way handshake in detail
Client Server
│───SYN (Seq=1000)────►│ ("Hello, I want to connect")
│◄──SYN-ACK (Seq=5000)─│ ("Hello back, I am ready")
│───ACK (Seq=1001)────►│ ("Got it, let's go!")
│ Data flows │
After the handshake every packet receipt is confirmed with an ACK. If something is lost, it is sent again automatically. That is why TCP is perfect wherever no bit may be missing.
UDP — the fast sprinter protocol
UDP just sends — no handshake, no confirmation. If a packet is lost, it is gone. That sounds risky, but it is exactly right for real-time applications.
# Shows live which ports TCP and UDP use on your server
ss -tuln | grep -E ':(22|53|80|443)'
Important well-known ports (the first 1023)
- 22 →
SSH - 53 →
DNS(UDP+TCP) - 80 →
HTTP - 443 →
HTTPS - 25 →
SMTP
# Quick check: which ports are listening right now?
sudo ss -tulp | head -10
❗ LPIC-1 exam tip: You must know ports 20/21 (
FTP), 53 (DNS), 80/443 (web) and 22 (SSH) by heart. The exam asks for them again and again.
IP — the heart of the internet layer
The Internet Protocol is the envelope of every packet. There are two versions that you run in parallel today.
IPv4 vs IPv6 — head-to-head comparison
IPv4 IPv6
192.168.1.42 2001:db8::1:42
32 bit (4.3 billion) 128 bit (340 undecillion)
Decimal with dots Hexadecimal with colons
Header 20–60 bytes Header 40 bytes (fixed)
NAT usually needed No more NAT needed
Why IPv6?
IPv4 has been exhausted for years. That is why every provider often gives you only one public IPv4 address and hides everything behind NAT. IPv6 solves that for good — every device gets its own global address.
# Shows both addresses at once
ip -4 addr show
ip -6 addr show
IPv6 in practice on Linux
Modern Ubuntu/Debian systems enable IPv6 by default. You see it immediately:
# Test: ping6 to Google
ping -6 google.com
Helper protocols
ICMP and ARP — the quiet helpers
ICMP — the diagnostic protocol
ICMP is the postman with a receipt. Ping and traceroute are based entirely on it.
Typical ICMP messages
Echo Request → "Are you there?"
Echo Reply → "Yes, here I am!"
Destination Unreachable → "Path blocked!"
Time Exceeded → "TTL expired" (traceroute uses this)
# Classic ping
ping -c 4 8.8.8.8
# Traceroute with ICMP
traceroute -I google.com
ARP — the MAC-IP translator
On the local net, IP must be translated into MAC. That is exactly what ARP does.
ARP process step by step
PC: "Who has 192.168.1.1?"
│
▼ Broadcast to everyone
Router: "I do! My MAC is 00:1A:2B:3C:4D:5E"
│
▼ ARP table is filled
# Shows the current ARP table
ip neigh show
Application protocols
DNS, HTTP/HTTPS and more
DNS — the phone book of the internet
Without DNS you would have to remember every IP address. DNS translates admindocs.de into an IP.
DNS resolution live
Browser → "Where is admindocs.de?"
│
▼ Local DNS server (usually your router)
│
▼ Root server → .de server → admindocs.de server
│
▼ Answer: 185.199.108.153
# DNS query directly on the command line
dig admindocs.de
# or short:
host admindocs.de
HTTP/HTTPS — the web protocol
Every web page runs on this. HTTPS is simply HTTP + TLS encryption.
HTTP status codes you must know:
200OK301/302Moved Permanently / Found404Not Found500Internal Server Error
Modern addition: QUIC and HTTP/3
HTTP/3 no longer runs over TCP, but directly over UDP with the QUIC protocol. Connections come up faster and packet loss hurts less. Many modern browsers and servers (including nginx) already use it by default.
# Check whether your server supports HTTP/3
curl -I --http3 https://admindocs.de
🔧 Practical example:
Open two terminals and start:
Terminal 1:
sudo tcpdump -i any -nn port 53 or port 80 or port 443 -c 20
Terminal 2:
curl -I https://admindocs.de
You see live how DNS (UDP 53), then the TCP handshake (port 443) and then the data flow.
❗ LPIC-1 exam point: You will often be asked: which protocol uses
port 53? (Answer:DNS—UDPprimarily,TCPfor large answers). Or: which protocol is connectionless? (UDP).
Once you know the most important protocols in detail, the next section is addressing and routing — how packets really travel through the internet and which current developments you can already use as an admin.
Addressing, routing and current developments
You now know which protocols work in which layer. Next is the part that is daily reality for every Linux administrator: how packets really find their way and how you deal with IP addresses, subnets and routing. This is not only theory, but the exact commands you use to solve problems on a real server.
IP addressing: IPv4 and IPv6 in detail
Every device on the network needs a unique address. IPv4 is what you probably know best — four numbers between 0 and 255, separated by dots.
IPv4 address layout using 192.168.1.42:
┌───────────────┬───────────────┐
│ Network part │ Host part │
│ 192.168.1 │ 42 │
└───────────────┴───────────────┘
Subnet mask /24 = 255.255.255.0
Subnetting simply
A /24 means: the first 24 bits are fixed (network), the last 8 bits belong to you (256 possible hosts).
For a typical home or company net that is usually enough.
# Show your current IP and subnet mask
ip addr show dev enp0s3 | grep inet
IPv6 — the future that is already here
IPv6 addresses are 128 bits long and look complicated at first.
In practice you often write them abbreviated.
IPv6 example: 2001:db8:85a3::8a2e:370:7334
Global Routing Prefix │ Subnet-ID │ Interface-ID
2001:db8:85a3 │ 0000 │ 0000:8a2e:0370:7334
Many providers today automatically hand out a /56 or /64 prefix. That means: you have millions of subnets available — no NAT needed any more.
# IPv6 addresses and routes on your system
ip -6 addr show
ip -6 route show
Dual-stack in practice
Almost all modern Linux systems run IPv4 and IPv6 in parallel. You can use both at the same time.
⚠️ Important warning: Many beginners disable IPv6 completely because “it is complicated”. That often causes problems with Google, Netflix or cloud services that prefer IPv6.
Routing
How packets really travel through the internet
Your Linux kernel has a routing table. Every packet is looked up there: “Where to?”
Routing table (simplified)
Destination Gateway Interface
0.0.0.0/0 192.168.1.1 enp0s3 ← default route
192.168.1.0/24 - enp0s3 ← local net
10.0.0.0/8 10.0.0.1 docker0 ← Docker net
# Show the complete routing table
ip route show
How routing works in several steps
- Your PC sends the packet to the default gateway (usually your router).
- The router looks in its table and forwards it.
- That repeats until the packet arrives at the destination.
# Shows you the complete path to a destination
traceroute 8.8.8.8
Fragmentation and MTU
If a packet is too large for the next net, it is split. That costs performance. That is why the right MTU setting matters.
# Check the MTU of your interface
ip link show enp0s3 | grep mtu
🔧 Practical example:
Docker automatically creates its own network with bridging.
You see it immediately:
docker network ls
ip addr show docker0
Current developments
High IPv6 adoption
More and more providers and cloud vendors go fully to IPv6. Your Ubuntu server often already gets a public IPv6 address without extra configuration.
5G and later mobile networks
Mobile networks are built entirely on TCP/IP. The low latency and high bandwidth of 5G make new applications such as edge computing possible — and you as an admin run the servers behind them.
Software-defined networking (SDN)
In large environments (Kubernetes, OpenStack) routing is no longer done only in hardware routers, but controlled in software. Tools such as Cilium or Calico use eBPF in the Linux kernel to do extremely fast routing directly in the kernel.
# Check eBPF-based network tools (e.g. in Kubernetes)
kubectl get pods -n kube-system | grep cilium
Security: IPsec and WireGuard
Modern VPNs such as WireGuard run over UDP and are extremely simple to configure. You can build a secure tunnel in under 5 minutes.
# Quick check whether WireGuard is running
ip link show wg0
❗ Common stumbling block: Many people think IPv6 is “less secure”. In reality it is more secure, because no NAT tricks are needed and you can write clean firewall rules.
💡 Immediate test: Run these commands one after another:
ip route get 8.8.8.8
ip route get 2001:4860:4860::8888
traceroute -4 8.8.8.8
traceroute -6 google.com
You see live how your system picks different paths for IPv4 and IPv6.
Once you fully understand addressing and routing, the last section is how you use all of this in practice as a Linux administrator — with real scenarios, troubleshooting and the commands that save you in the exam and on the job.
Practical application
Troubleshooting as a Linux administrator
You now have the layers, the protocols, addressing and routing. Now it gets practical: how do you use all of this on a real Linux server? As a systems integrator or Linux admin you solve 80 % of all network problems right here — with the commands you learn now.
We walk through three everyday scenarios, follow the full data flow through all four layers and then show you the complete troubleshooting toolbox with which you find every problem in minutes.
Example 1: loading a web page — the classic
You type curl https://admindocs.de or open the browser. What really happens?
Data flow step by step through all layers
- Application layer: browser/DNS request (HTTP/HTTPS)
- Transport layer: build a TCP connection (port 443)
- Internet layer: IP routing to the destination IP
- Network access layer: Ethernet frame to the router
First the browser asks the DNS server (UDP port 53). As soon as the IP is there, TCP builds the three-way handshake.
Then the HTTP data flows encrypted over TLS.
# Follow the full web request live
sudo tcpdump -i enp0s3 -nn 'port 53 or port 443' -c 30
🔧 Practical example:
You start a container and want to test whether it can reach the internet:
docker run --rm -it alpine curl -I https://admindocs.de
The container uses the Docker bridge network — you see the NAT translation in the routing table.
Example 2: sending email with SMTP
You send an email via mail or your mail client. SMTP (port 25 or 587) runs entirely over TCP.
SMTP data flow
Client ──► SMTP server (port 587)
│
▼ TCP handshake + TLS
│
▼ IP routing to the mail server
│
▼ Ethernet to the next hop
# Test an SMTP connection
telnet mail.admindocs.de 587
# or more securely:
openssl s_client -connect mail.admindocs.de:587 -starttls smtp
Why TCP is mandatory here
An email must not lose a single byte — that is why ACKs and retransmits on every packet.
Example 3: video streaming with UDP and QUIC
Netflix or YouTube often runs over UDP today (port 443 with QUIC/HTTP/3). No handshake, but extremely fast packets.
Streaming data flow
Browser ──► UDP packets (QUIC)
│
▼ No ACK — on loss just the next packet
│
▼ IP routing + Ethernet
# Detect QUIC traffic
sudo tcpdump -i enp0s3 -nn udp port 443
The browser buffers a few seconds — that is why you barely notice losses.
The complete Linux troubleshooting toolbox
Basic checks
# 1. Check IP configuration
ip addr show
ip route show
# 2. Look at connections
ss -tuln
ss -tulp | grep ssh
Diagnostic tools
# Ping (ICMP)
ping -c 4 8.8.8.8
ping -6 google.com
# Follow the route
traceroute 8.8.8.8
traceroute -6 google.com
# Capture packets
sudo tcpdump -i any -nn -c 20 port 80 or port 443
Wireshark for advanced use
Install with sudo apt install wireshark and start the graphical UI.
Filter: http or dns or tcp.port == 22.
Typical errors and their fixes
❗ “No route to host”
→ routing table missing or gateway down
ip route add default via 192.168.1.1
❗ DNS does not work
→ /etc/resolv.conf wrong
cat /etc/resolv.conf
systemctl restart systemd-resolved
❗ Port is in use
→ ss -tlnp | grep :80 shows the process
sudo kill $(sudo ss -tlnp | grep :80 | awk '{print $6}' | cut -d, -f2)
Docker-specific problems
docker network inspect bridge
ip addr show docker0
Best practices for a secure TCP/IP configuration
- Always use
ufworfirewalldand open only necessary ports - Never disable IPv6 completely
sysctlfor SYN-flood protection:
sudo sysctl -w net.ipv4.tcp_syncookies=1
💡 Everyday tip: Create a script
netcheck.sh:
#!/bin/bash
echo "=== IP ==="; ip addr show
echo "=== Routes ==="; ip route show
echo "=== Listening Ports ==="; ss -tuln
echo "=== DNS Test ==="; host admindocs.de
Make it executable with chmod +x netcheck.sh and run it on every problem.
⚠️ Most important note: Most outages do not come from the internet, but from wrong configuration on your Linux server. With the commands above you find the cause in under 2 minutes.
Once you master these scenarios and tools, you can solve every network problem on your server systematically. You are no longer a beginner — you are the admin who knows exactly what happens in the four layers.
Command Reference (Cheatsheet)
The following reference collects the essential TCP/IP commands for daily Linux work:
| Category | Command | Purpose |
|---|---|---|
| Status | ip addr show |
IPv4/IPv6 addresses and interfaces |
| Status | ip link show |
MAC, MTU, link state |
| Routing | ip route show |
IPv4 routing table |
| Routing | ip route get 8.8.8.8 |
Which path a destination takes |
| Routing | ip -6 route show |
IPv6 routes |
| Ports | ss -tuln |
Listening TCP/UDP ports |
| Ports | sudo ss -tulp |
Ports plus owning process |
| Reachability | ping -c 4 8.8.8.8 |
ICMP echo |
| Reachability | ping -6 google.com |
IPv6 echo |
| Path | traceroute 8.8.8.8 |
Hop-by-hop path |
| Path | traceroute -I google.com |
Traceroute with ICMP |
| DNS | dig admindocs.de / host admindocs.de |
Name resolution |
| Capture | sudo tcpdump -i any -nn port 443 |
Live packets |
| MTU | ping -M do -s 1472 8.8.8.8 |
Path MTU test |
| Neighbours | ip neigh show |
ARP/ND table |
| HTTP/3 | curl -I --http3 https://admindocs.de |
Check QUIC support |
Further Resources
Internal articles on admindocs.de
These pieces build on each other and match the same audience (systems integrators and Linux admins):
Suggested reading order
- OSI model
- TCP/IP (this article)
- Public vs private IP addresses
- What is a VPN
Official documentation
The real sources — short, precise and kept current:
RFC 791— Internet Protocol (IPv4)RFC 793— Transmission Control ProtocolRFC 768— User Datagram ProtocolRFC 2460— Internet Protocol, Version 6 (IPv6)RFC 1035— Domain Names (DNS)
# Quickly save all RFCs locally (for offline lookup)
mkdir -p ~/rfc && cd ~/rfc
for rfc in 791 793 768 2460 1035; do
curl -O https://www.rfc-editor.org/rfc/rfc$rfc.txt
done
Practical tools — your daily kit
These programs belong on every Linux server and every admin workstation:
Wireshark— the graphical analyser for all layerstcpdump— the command-line classic (always preinstalled)nmap— port scanner and network discoveryssandip— the modern successors of netstat and ifconfig
# Install everything in one go (Debian/Ubuntu)
sudo apt update && sudo apt install -y wireshark tshark nmap tcpdump
# On Arch Linux
sudo pacman -S wireshark-cli nmap tcpdump
Tool comparison at a glance
Tool | GUI | Fast | Beginners | Live capture
Wireshark | Yes | Medium | Very good | Perfect
tcpdump | No | Instant | Good | Perfect
ss | No | Instant | Very good | Ports only
nmap | Optional | Medium | Good | Discovery
Learning resources for the next step
- Cisco Networking Academy — free courses with practical labs
- TCP/IP Guide (tcpipguide.com) — the reference work
- Book: “Computer Networks: A Systems Approach” (available free online)
- LPIC-1 prep: chapters
109.1and109.2— exactly these TCP/IP topics
# Quick start for learning Wireshark
wireshark & # start GUI
# or in the terminal:
tshark -i enp0s3 -f "port 80 or port 443" -c 50
💡 Note: Protocols and standards keep evolving. Always use current versions of the tools and RFCs. With the resources above you are well equipped and can handle every network problem on your Linux server.
| Resource | Description | Type |
|---|---|---|
| The OSI model | Seven layers as the theoretical counterpart to TCP/IP | Article |
| Public vs private IP addresses | IPv4/IPv6, NAT and RFC 1918 | Article |
| What is a VPN? | Tunnels, WireGuard, OpenVPN and UDP vs TCP | Article |
| RFC 791 | Internet Protocol (IPv4) | RFC |
| RFC 793 | Transmission Control Protocol | RFC |
| RFC 768 | User Datagram Protocol | RFC |
| RFC 2460 | IPv6 | RFC |
| RFC 1035 | DNS | RFC |
Conclusion
The TCP/IP protocol family is the foundation of modern internet communication. The four layers — network access, internet, transport and application — work together to carry data safely, reliably and efficiently from one device to another. You have seen how Ethernet frames move bits on the lowest level, how IP packets find their way through routers, how TCP with its three-way handshake gives absolute reliability and how UDP gives speed for streaming and DNS.
You now know the most important protocols in detail: TCP and UDP with all advantages and drawbacks, IP in IPv4 and IPv6, ICMP for diagnostics, ARP for local address resolution and DNS, HTTP/HTTPS plus QUIC as a modern addition. You understand why ports such as 22, 53, 80 and 443 matter and how you follow what really happens on your Linux server with ip, ss, tcpdump and traceroute.
Especially valuable for you as an aspiring systems integrator or Linux administrator is the practical knowledge: you can now follow a page load, an email send or video streaming through all layers, debug Docker container networks and fix typical errors such as No route to host, DNS problems or MTU faults in minutes. With your own netcheck.sh and the troubleshooting commands you have a real tool for the job and the LPIC-1 exam.
⚠️ Most network problems do not arise somewhere on the internet, but directly on your server — through wrong routes, blocked ports or IPv6 configuration errors. With an understanding of TCP/IP you now see those causes clearly.
Take the time and work through the three practical examples actively. Start tcpdump, load a web page, send a test email and analyse the traffic. The more often you use the commands, the more natural the whole system becomes.
The TCP/IP protocol family has been the backbone of the internet for decades — and it will stay that. You now have the solid foundation to understand it and to master it. Use this knowledge daily on your servers, in Docker environments and when troubleshooting.