TCP/IP Model Cheat Sheet

Every time you load a webpage, send an email, or stream a video, your data travels through a structured, layered process that breaks a complex job — reliably moving data across a global network of networks — into manageable, independent pieces. This structure is called the TCP/IP Model (also known as the Internet Protocol Suite).

This article serves as a comprehensive, practical cheat sheet — explaining each layer from first principles, comparing it to the more academic OSI model, and providing real command-line and configuration examples for identifying and troubleshooting each layer on real systems.

1. Why Layered Models Exist

Imagine trying to design a single, giant piece of software that handles everything from electrical signals on a cable to formatting a web page — it would be impossibly complex and impossible to change safely. Instead, networking is broken into layers, each responsible for a specific job, with clearly defined interfaces between them.

This layered approach means:

• Each layer only needs to know how to talk to the layer directly above and below it.
• Technologies at one layer (e.g., Wi-Fi vs Ethernet at the Network Access layer) can change without affecting layers above (e.g., your web browser doesn’t care whether you’re on Wi-Fi or wired Ethernet).
• Troubleshooting becomes systematic — you can isolate a problem to a specific layer rather than guessing across the whole system.

2. The Four Layers of the TCP/IP Model

flowchart TD
    A["Application Layer
(HTTP, DNS, SMTP, FTP, SSH)"] --> B["Transport Layer
(TCP, UDP)"]
    B --> C["Internet Layer
(IP, ICMP, ARP)"]
    C --> D["Network Access Layer
(Ethernet, Wi-Fi, Physical Media)"]

3. TCP/IP Model vs OSI Model

The OSI (Open Systems Interconnection) model is a more detailed, 7-layer theoretical framework often taught alongside TCP/IP. Understanding how they map to each other is essential, since real-world terminology (e.g., “Layer 2 switch,” “Layer 3 routing,” “Layer 7 firewall”) comes from the OSI model, even when working within TCP/IP-based networks.

The TCP/IP model condenses OSI’s top three layers (Application, Presentation, Session) into a single Application layer, and its bottom two (Data Link, Physical) into a single Network Access layer, reflecting how TCP/IP was designed pragmatically around actual protocol implementation rather than strict theoretical separation.

4. Layer-by-Layer Deep Dive

4.1 Network Access Layer (Layer 1/2 equivalent)

Responsible for physically transmitting raw bits across a medium (copper, fiber, radio waves) and for local addressing using MAC addresses.

Key concepts:

• Ethernet — the dominant wired LAN technology, using MAC addresses for local delivery.
• ARP (Address Resolution Protocol) — resolves an IP address to a MAC address on a local network segment (technically often grouped here or at the Internet layer, depending on the reference model).
• Switches operate primarily at this layer, forwarding frames based on MAC addresses.

Linux example — viewing MAC address and interface details:

ip link show eth0

ip link show eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff

Cisco example — viewing MAC address table on a switch:

show mac address-table

show mac address-table

4.2 Internet Layer (Layer 3 equivalent)

Responsible for logical addressing (IP addresses) and routing — determining the best path for data to travel across multiple interconnected networks.

Key protocols:

• IP (Internet Protocol) — IPv4 and IPv6, providing addressing and best-effort packet delivery.
• ICMP (Internet Control Message Protocol) — used for diagnostics and error reporting (e.g., ping, traceroute).
• ARP — often discussed here as the bridge between Layer 2 and Layer 3 addressing.
• Routers operate primarily at this layer, forwarding packets based on destination IP address.

Linux example — viewing IP configuration and routing table:

ip addr show
ip route show

ip addr show
ip route show

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50

Cisco example — viewing the routing table:

show ip route

show ip route

O    10.2.0.0/16 [110/20] via 192.168.100.2, GigabitEthernet0/1
C    192.168.100.0/30 is directly connected, GigabitEthernet0/1

O    10.2.0.0/16 [110/20] via 192.168.100.2, GigabitEthernet0/1
C    192.168.100.0/30 is directly connected, GigabitEthernet0/1

Testing connectivity at this layer:

ping 8.8.8.8
traceroute 8.8.8.8      # Linux
tracert 8.8.8.8         # Windows

ping 8.8.8.8
traceroute 8.8.8.8      # Linux
tracert 8.8.8.8         # Windows

4.3 Transport Layer (Layer 4 equivalent)

Responsible for end-to-end communication between applications running on different hosts, using port numbers to distinguish between multiple simultaneous conversations, and providing either reliable or best-effort delivery.

The TCP 3-Way Handshake:

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: SYN
    Server->>Client: SYN-ACK
    Client->>Server: ACK
    Note over Client,Server: Connection Established

Common well-known ports:

Linux example — viewing active connections and listening ports:

ss -tulnp

ss -tulnp

Netid  State    Local Address:Port   Peer Address:Port  Process
tcp    LISTEN   0.0.0.0:22           0.0.0.0:*           sshd
tcp    LISTEN   0.0.0.0:80           0.0.0.0:*           nginx

Netid  State    Local Address:Port   Peer Address:Port  Process
tcp    LISTEN   0.0.0.0:22           0.0.0.0:*           sshd
tcp    LISTEN   0.0.0.0:80           0.0.0.0:*           nginx

Cisco example — checking established sessions on a firewall (ASA):

show conn

show conn

4.4 Application Layer (Layer 5-7 equivalent)

Responsible for providing network functionality directly to end-user applications — this is the layer users and developers interact with most directly.

Linux example — testing DNS resolution:

dig example.com
nslookup example.com

dig example.com
nslookup example.com

Linux example — testing an HTTP service directly:

curl -v http://example.com

curl -v http://example.com

5. Data Encapsulation: How Data Moves Down (and Back Up) the Stack

As data moves from the Application layer down to the Network Access layer for transmission, each layer adds its own header (and sometimes trailer) information — a process called encapsulation. At the receiving end, this process happens in reverse (de-encapsulation), with each layer stripping off its corresponding header as the data moves back up the stack.

flowchart TD
    A["Application Data
(e.g., HTTP request)"] --> B["+ TCP Header = Segment"]
    B --> C["+ IP Header = Packet"]
    C --> D["+ Ethernet Header/Trailer = Frame"]
    D --> E["Bits transmitted on the wire/air"]

Understanding these terms precisely matters — in professional networking conversations, saying “packet” when you mean “frame” (or vice versa) signals a gap in foundational understanding, since each term refers to a specific layer’s unit of data.

6. Python Example: Building Layer Awareness with Sockets

This simple Python example demonstrates the Transport and Application layers directly — creating a TCP socket (Transport layer) and sending an HTTP request (Application layer) manually.

import socket

def simple_http_request(host="example.com", port=80):
    # Transport Layer: Create a TCP socket and connect
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((host, port))

    # Application Layer: Send a raw HTTP GET request
    request = f"GET / HTTP /1.1\r\nHost: {host}\r\nConnection: close\r\n\r\n"
    sock.sendall(request.encode())

    response = b""
    while True:
        data = sock.recv(4096)
        if not data:
            break
        response += data

    sock.close()
    print(response.decode(errors="ignore")[:300])  # print first 300 chars

simple_http_request()

import socket

def simple_http_request(host="example.com", port=80):
    # Transport Layer: Create a TCP socket and connect
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((host, port))

    # Application Layer: Send a raw HTTP GET request
    request = f"GET / HTTP /1.1\r\nHost: {host}\r\nConnection: close\r\n\r\n"
    sock.sendall(request.encode())

    response = b""
    while True:
        data = sock.recv(4096)
        if not data:
            break
        response += data

    sock.close()
    print(response.decode(errors="ignore")[:300])  # print first 300 chars

simple_http_request()

This example makes the layering tangible: the socket object and TCP connection represent the Transport layer doing its job (reliable, ordered delivery), while the raw HTTP text you construct and send represents the Application layer protocol running on top of it.

7. Comparison Table: TCP/IP Layer Troubleshooting Tools

8. Real-World Example: Systematic Troubleshooting Using the Model

A user reports: “I can’t access our internal website.”

Rather than guessing randomly, a systematic engineer walks the model layer by layer:

1. Network Access Layer: Is the network cable connected / Wi-Fi connected? ip link show confirms interface is UP.
2. Internet Layer: Does the device have a valid IP address, and can it reach the server’s IP? ip addr show, then ping .
3. Transport Layer: Is the specific port (e.g., 443 for HTTPS) reachable? telnet 443 or nc -zv 443.
4. Application Layer: Does DNS resolve the hostname correctly, and does the web server respond properly? dig website.internal, then curl -v https://website.internal.

This layered troubleshooting approach — moving methodically from the bottom of the stack upward (or top-down, depending on preference) — is one of the most valuable practical habits the TCP/IP model teaches, dramatically narrowing down where a fault actually lies instead of guessing.

9. Best Practices

• Always troubleshoot systematically layer by layer, rather than jumping randomly between potential causes.
• Understand the correct terminology per layer (frame, packet, segment, data) — precise language reflects and reinforces precise understanding.
• Use TCP for applications that require reliability (file transfer, web pages, email) and UDP for applications that prioritize speed and can tolerate some loss (video streaming, VoIP, DNS).
• Remember that Layer 3 devices (routers) make decisions based on IP addresses, while Layer 2 devices (switches) make decisions based on MAC addresses — critical for understanding network design and troubleshooting scope.
• When designing firewall rules or ACLs, be precise about which layer you’re filtering at (e.g., port-based = Transport layer; IP-based = Internet layer).

10. Troubleshooting Quick Reference

11. Summary

The TCP/IP Model organizes networking into four clean layers — Network Access, Internet, Transport, and Application — each with a specific responsibility, from raw physical transmission up to user-facing services. Understanding this model isn’t just academic: it provides a systematic, repeatable framework for designing networks, understanding protocols, and — most practically — troubleshooting problems methodically rather than through guesswork.

Further Reading

• RFC 1122 — Requirements for Internet Hosts (defines the TCP/IP layering)
• RFC 793 — Transmission Control Protocol
• RFC 791 — Internet Protocol
• Cisco Networking Academy: TCP/IP Model Overview
• IANA Service Name and Port Number Registry
• Linux ss Command Manual