--- id: 2024-11-24-tcp-ip-structure-and-how-the-protocol-family-works slug: tcp-ip-structure-and-how-the-protocol-family-works title: "TCP/IP: structure and how the protocol family works" excerpt: "The TCP/IP protocol family: core concepts, the main protocols, addressing and routing, and how you apply them on real Linux networks." date: "2024-11-24T09:00:00+01:00" updated: "2026-03-06T10:00:00+01:00" author: name: "László Kovács" handle: "lkovacs" category: ["network"] tags: ["netzwerk", "tcp-ip", "protokolle", "linux-netzwerk", "troubleshooting", "systemintegration", "ipv4", "ipv6", "routing", "lpic-1"] toc: true reading_time: 20 --- 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** ```markdown ┌─────────────────────┐ │ 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](/en/network/the-osi-model-a-detailed-introduction-to-the-7-layers){.badge-link-text}, 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** ```markdown 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. ```bash # 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?** ```markdown 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)** ```markdown ┌──────────┬───────────┬──────────┬──────────┬────────┬───────┐ │ 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. ```bash # Shows all network interfaces and their MAC addresses ip link show # Sample output on an Ubuntu server: 2: enp0s3: 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 link` you 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)** ```markdown ┌──────┬──────┬─────┬─────┬────────────────┬───────────────┐ │ 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`?” ```bash # 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.8` you 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** ```markdown 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** 1. Client sends SYN 2. Server answers with SYN-ACK 3. Client sends ACK ```markdown 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). ```bash # 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. ```markdown 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: ```bash # 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:** 1. Open two terminals 2. Terminal 1: `sudo tcpdump -i any -nn port 80` 3. 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** ```markdown 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** ```markdown 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. ```bash # 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` ```bash # 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** ```markdown 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. ```bash # 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: ```bash # 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. ```markdown 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) ``` ```bash # 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** ```markdown 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 ``` ```bash # 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** ```markdown Browser → "Where is admindocs.de?" │ ▼ Local DNS server (usually your router) │ ▼ Root server → .de server → admindocs.de server │ ▼ Answer: 185.199.108.153 ``` ```bash # 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:** * `200` OK * `301`/`302` Moved Permanently / Found * `404` Not Found * `500` Internal 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. ```bash # Check whether your server supports HTTP/3 curl -I --http3 https://admindocs.de ``` 🔧 **Practical example:** Open two terminals and start: Terminal 1: ```bash sudo tcpdump -i any -nn port 53 or port 80 or port 443 -c 20 ``` Terminal 2: ```bash 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` — `UDP` primarily, `TCP` for 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`: ```markdown ┌───────────────┬───────────────┐ │ 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. ```bash # 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.** ```markdown 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. ```bash # 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)** ```markdown 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 ``` ```bash # 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. ```bash # 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. ```bash # 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:** ```bash 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. ```bash # 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. ```bash # 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:
```bash 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.** ```bash # 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: ```bash 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** ```markdown Client ──► SMTP server (port 587) │ ▼ TCP handshake + TLS │ ▼ IP routing to the mail server │ ▼ Ethernet to the next hop ``` ```bash # 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** ```markdown Browser ──► UDP packets (QUIC) │ ▼ No ACK — on loss just the next packet │ ▼ IP routing + Ethernet ``` ```bash # 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** ```bash # 1. Check IP configuration ip addr show ip route show # 2. Look at connections ss -tuln ss -tulp | grep ssh ``` **Diagnostic tools** ```bash # 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 ```bash ip route add default via 192.168.1.1 ``` ❗ **DNS does not work** → `/etc/resolv.conf` wrong ```bash cat /etc/resolv.conf systemctl restart systemd-resolved ``` ❗ **Port is in use** → `ss -tlnp | grep :80` shows the process ```bash sudo kill $(sudo ss -tlnp | grep :80 | awk '{print $6}' | cut -d, -f2) ``` **Docker-specific problems** ```bash docker network inspect bridge ip addr show docker0 ``` **Best practices for a secure TCP/IP configuration** * Always use `ufw` or `firewalld` and open only necessary ports * Never disable IPv6 completely * `sysctl` for SYN-flood protection: ```bash sudo sysctl -w net.ipv4.tcp_syncookies=1 ```
💡 **Everyday tip:** Create a script `netcheck.sh`:
```bash #!/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** 1. OSI model 2. TCP/IP (this article) 3. Public vs private IP addresses 4. What is a VPN Official documentation The real sources — short, precise and kept current: * `RFC 791` — Internet Protocol (IPv4) * `RFC 793` — Transmission Control Protocol * `RFC 768` — User Datagram Protocol * `RFC 2460` — Internet Protocol, Version 6 (IPv6) * `RFC 1035` — Domain Names (DNS) ```bash # 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 layers * `tcpdump` — the command-line classic (always preinstalled) * `nmap` — port scanner and network discovery * `ss` and `ip` — the modern successors of netstat and ifconfig ```bash # 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** ```markdown 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.1` and `109.2` — exactly these TCP/IP topics ```bash # 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](/en/network/the-osi-model-a-detailed-introduction-to-the-7-layers){.badge-link-text} | Seven layers as the theoretical counterpart to TCP/IP | Article | | [Public vs private IP addresses](/en/network/public-vs-private-ip-addresses-the-main-differences){.badge-link-text} | IPv4/IPv6, NAT and RFC 1918 | Article | | [What is a VPN?](/en/network/what-is-a-vpn-a-beginner-guide){.badge-link-text} | Tunnels, WireGuard, OpenVPN and UDP vs TCP | Article | | [RFC 791](https://www.rfc-editor.org/rfc/rfc791){.badge-link-text} | Internet Protocol (IPv4) | RFC | | [RFC 793](https://www.rfc-editor.org/rfc/rfc793){.badge-link-text} | Transmission Control Protocol | RFC | | [RFC 768](https://www.rfc-editor.org/rfc/rfc768){.badge-link-text} | User Datagram Protocol | RFC | | [RFC 2460](https://www.rfc-editor.org/rfc/rfc2460){.badge-link-text} | IPv6 | RFC | | [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035){.badge-link-text} | 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.