Introduction to Computer Networks: OSI Model, TCP/IP, and Practical Troubleshooting

Introduction

Computer networks move data between devices using layered protocols. Each layer handles a specific part of the communication — from the physical electrical signal to the application data. Understanding these layers helps you diagnose connectivity issues, interpret error messages, and design systems that communicate reliably.

This guide covers the OSI and TCP/IP models with practical equivalents, demonstrates diagnostic tools (ping, traceroute, curl, nc, dig, ss, nslookup) with real output and explanations, walks through an HTTP request from browser to server with packet-level detail, explains network topologies and hardware roles, and provides a troubleshooting flowchart for common network problems. Each section includes commands you can run immediately to observe the concepts in action on your own network.

OSI Model vs TCP/IP Model

flowchart LR
    subgraph OSI["OSI Model (7 layers)"]
        L7["7. Application<br/>HTTP, DNS, SMTP"]
        L6["6. Presentation<br/>TLS, SSL"]
        L5["5. Session<br/>RPC"]
        L4["4. Transport<br/>TCP, UDP"]
        L3["3. Network<br/>IP, ICMP"]
        L2["2. Data Link<br/>Ethernet, WiFi"]
        L1["1. Physical<br/>Fiber, Radio"]
    end

    subgraph TCPIP["TCP/IP Model (4 layers)"]
        A["Application (5-7)<br/>HTTP, DNS, TLS"]
        T["Transport (4)<br/>TCP, UDP"]
        I["Internet (3)<br/>IP, ICMP"]
        L["Link (1-2)<br/>Ethernet, WiFi"]
    end

    OSI --> TCPIP

Practical Equivalents

Each layer has a concrete tool for inspection:

OSI Layer Protocol Mapping

Each OSI layer maps to specific protocols and addressing schemes. Understanding this mapping helps isolate which layer a problem belongs to:

Key insight: A problem at Layer 3 (no route to host) looks identical to Layer 2 (bad cable) from the application’s perspective — both produce “connection timeout.” Systematic bottom-up testing eliminates the physical and data link layers before investigating routing.

Data Flow: HTTP Request Walkthrough

When you visit https://example.com, the complete path involves seven distinct steps across all layers. Here is the full sequence with timing estimates and packet sizes:

Step 1 — DNS Resolution (Application/Presentation):
  Browser checks local cache → queries resolver (192.168.1.1:53)
  → Root DNS → .com TLD → example.com authoritative
  Response: A record 93.184.216.34 (TTL: 60s)
  Packet size: ~50-100 bytes UDP, ~1-100ms depending on cache state

Step 2 — TCP Three-Way Handshake (Transport):
  Client → Server: SYN (seq=x)                    [Size: 40-44 bytes]
  Server → Client: SYN-ACK (seq=y, ack=x+1)      [Size: 40-44 bytes]
  Client → Server: ACK (seq=x+1, ack=y+1)        [Size: 40-44 bytes]
  Total: 3 packets exchanged, ~1.5 round trips

Step 3 — TLS 1.3 Handshake (Presentation):
  Client → Server: ClientHello (supported ciphers, key share)
  Server → Client: ServerHello + Certificate + ServerFinished
  Client → Server: ClientFinished
  Total: 2 round trips (TLS 1.3 reduces from 4 in TLS 1.2)
  Overhead: ~2-5 KB of handshake data

Step 4 — HTTP Request (Application):
  Client → Server: GET / HTTP/1.1, Host: example.com
  Request size: ~200-800 bytes (headers + optional body)
  Method, path, headers are all Layer 7 constructs

Step 5 — HTTP Response (Application):
  Server → Client: HTTP/1.1 200 OK, Content-Type: text/html
  Response size: typically 2-50 KB for initial HTML page

Step 6 — IP Routing (Network):
  Packets traverse: Client → Home Router → ISP Gateway → Backbone → Server
  Each hop decrements TTL, performs routing table lookup
  Path length: 5-15 hops, ~10-100ms total propagation time

Step 7 — Frame Transmission (Data Link + Physical):
  Each packet wrapped in Ethernet frame with source/dest MAC addresses
  Transmitted as electrical/optical signals on the physical medium
  Frame size: 64-1518 bytes (standard Ethernet MTU of 1500)

Total latency (uncached, TLS 1.3): 3-4 round trips ≈ 30-200ms
Total bytes transferred: ~5-15 KB for the initial connection setup

Diagnostic Commands with Example Output

ping: Basic Reachability and RTT

# Send 5 ICMP echo requests
ping -c 5 8.8.8.8

# Output:
# PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
# 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.3 ms
# 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=11.8 ms
# 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=12.1 ms
# 64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=13.0 ms
# 64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=11.5 ms
#
# --- 8.8.8.8 ping statistics ---
# 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
# rtt min/avg/max/mdev = 11.544/12.140/13.027/0.535 ms

• 0% packet loss: No network issues
• >1% loss: Possible congestion or failing hardware
• RTT < 50ms: Good latency for most applications
• RTT > 200ms: Noticeable lag, check geographic distance

traceroute: Path to Destination

# Trace the network path
traceroute -n 8.8.8.8

# Output:
# traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
#  1  192.168.1.1    1.2 ms   1.1 ms   1.3 ms     ← home router
#  2  10.0.0.1       5.4 ms   5.2 ms   5.5 ms     ← ISP gateway
#  3  72.14.212.34   8.1 ms   8.3 ms   7.9 ms     ← ISP backbone
#  4  108.170.252.1  9.2 ms   9.5 ms   9.4 ms     ← Google edge
#  5  8.8.8.8        11.2 ms  11.5 ms  11.0 ms    ← destination

• Each hop is a router between you and the destination
• * * * means no response (may be filtered)
• High latency at one hop may indicate congestion
• TTL (Time To Live) starts at 255 and decrements per hop; the final TTL in ping output shows initial TTL minus hop count
• * * * at intermediate hops may be routers configured to not respond to ICMP (common on ISP infrastructure)

dig: DNS Resolution

# Query DNS for a domain
dig +short example.com
# 93.184.216.34

# Full response with details
dig example.com
# Shows: query time, authoritative server, TTL, IP address

# Trace the full resolution chain
dig +trace example.com
# Shows: root → .com TLD → example.com authoritative

curl: HTTP Debugging

# Show full HTTP request/response headers
curl -v https://example.com

# Output (key lines):
# *   Trying 93.184.216.34:443...
# * TCP_NODELAY set
# * Connected to example.com (93.184.216.34) port 443 (#0)
# * TLS 1.3 handshake completed
# > GET / HTTP/1.1
# > Host: example.com
# > User-Agent: curl/8.4.0
# >
# < HTTP/1.1 200 OK
# < Content-Type: text/html

nc (netcat): Port Connectivity

# Check if a port is open
nc -zv example.com 443
# Connection to example.com (93.184.216.34) port 443 [tcp/https] succeeded!

# Test UDP port
nc -zv -u 8.8.8.8 53
# Connection to 8.8.8.8 port 53 [udp/domain] succeeded!

ss: Socket Statistics

# List all listening TCP ports with processes
ss -tlnp

# State    Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
# LISTEN   0       128     0.0.0.0:22           0.0.0.0:*          users:(("sshd"))
# LISTEN   0       511     0.0.0.0:80           0.0.0.0:*          users:(("nginx"))
# LISTEN   0       511     0.0.0.0:443          0.0.0.0:*          users:(("nginx"))

# Show established connections with timers
ss -to
# ESTAB    0       0       192.168.1.5:22       10.0.0.1:45678     timer:(keepalive,12sec)

# Display socket memory usage
ss -tm
# skmem:(r0,rb373760,t0,tb87040)
# r/t = receive/transmit queue, b = buffer size in bytes

• -t: TCP sockets, -l: listening only, -n: numeric addresses, -p: show process
• Recv-Q > 0: Data queued but not consumed by application (possible slow reader)
• Send-Q > 0: Data queued but not acknowledged (possible network congestion)

nslookup: Legacy DNS Lookup

# Basic A record lookup
nslookup example.com
# Server:         192.168.1.1
# Address:        192.168.1.1#53
#
# Non-authoritative answer:
# Name:   example.com
# Address: 93.184.216.34

# Query specific record type (MX)
nslookup -type=MX example.com
# example.com  MX preference = 10, mail exchanger = mail.example.com

# Query a specific nameserver
nslookup example.com 8.8.8.8
# Uses Google DNS instead of default resolver

• Server line: Shows which DNS resolver answered (typically your local router or ISP)
• Non-authoritative answer: The resolver cached the result rather than querying the authoritative server
• No response or timeout: DNS server unreachable — check network connectivity or /etc/resolv.conf

Troubleshooting Flowchart

flowchart TD
    A[Website not loading] --> B{Can you ping the server?}
    B -->|No| C[Run traceroute]
    C --> D{All hops reachable?}
    D -->|No| E[Network issue at failing hop]
    D -->|Yes| F[Firewall blocking ICMP]

    B -->|Yes| G{Can you curl the URL?}
    G -->|No| H{Port open?}
    H -->|No| I[Service not running / firewall blocking port]
    H -->|Yes| J[TLS cert issue?]
    J -->|Yes| K[Certificate expired or untrusted]
    J -->|No| L[Application-level error — check server logs]

    G -->|Yes| M[It works!]
    M --> N[Add monitoring to detect recurrence]

Network Topologies

Network topology describes how devices are physically or logically connected. The choice affects fault tolerance, performance, and cost:

Star Topology

All devices connect to a central switch. This is the dominant topology in modern Ethernet networks.

        ┌───────────┐
        │  Switch   │
        └─────┬─────┘
     ┌───────┼───┬───────┐
     │       │   │       │
  ┌──┴──┐ ┌──┴──┐ ┌──┴──┐ ┌──┴──┐
  │ PC  │ │ PC  │ │ PC  │ │ PC  │
  └─────┘ └─────┘ └─────┘ └─────┘

• Advantages: Simple, easy to troubleshoot, single device failure does not affect others
• Disadvantages: Central switch is a single point of failure
• When to use: Office LANs, data centers, home networks

Mesh Topology

Every device connects to multiple others, providing redundancy. Full mesh scales poorly (n×(n-1)/2 links); partial mesh is common in backbone networks.

• Advantages: High fault tolerance, multiple paths for load balancing
• Disadvantages: Expensive cabling, complex configuration
• When to use: WAN backbones, wireless mesh networks, data center spine-leaf fabrics

Hybrid Topology

Most real networks combine topologies. A typical enterprise uses star for access, mesh for backbone:

Core routers (full/partial mesh) → Distribution switches (star) → Access switches (star) → End devices

• When to use: Virtually all enterprise networks larger than a single floor or building

Network Hardware

Understanding the role of each device type is critical for designing and troubleshooting networks:

How They Work Together

Internet → Router → Firewall → Switch → AP (wireless clients)
                                → Switch → Servers

The router connects your network to the internet (Layer 3). The firewall filters traffic (Layer 3-4). Switches connect devices within the LAN (Layer 2). Access points bridge wireless clients to the wired network. Each device operates at a specific layer and passes traffic up or down the stack.

Common Network Issues

TCP vs UDP: Transport Layer Protocols

The transport layer provides two fundamentally different delivery models. Choosing between them affects every aspect of application design:

# Check which transport protocol a service uses
ss -tlnp  # TCP listening ports
ss -ulnp  # UDP listening ports

# DNS uses UDP by default, falls back to TCP for large responses
dig +short example.com @8.8.8.8
# Uses UDP port 53 (8 byte header, fast)

# HTTP uses TCP port 80/443
curl -v https://example.com
# Uses TCP port 443 (connection setup, reliable delivery)

Selection rule: Use TCP when data integrity matters more than speed (web pages, file transfers, databases). Use UDP when low latency is critical and occasional loss is acceptable (video calls, live streaming, gaming).

IPv4 vs IPv6: Network Layer Addressing

IPv6 adoption reached ~45% of global traffic in 2026, but many networks still run dual-stack (both protocols simultaneously):

# Check which IP versions your system supports
ip addr show | grep "inet "   # IPv4 addresses
ip addr show | grep "inet6 "  # IPv6 addresses

# Test IPv4-only connectivity
curl -4 https://example.com

# Test IPv6-only connectivity
curl -6 https://example.com

# Check if DNS resolves to both A and AAAA records
dig example.com A +short
dig example.com AAAA +short

Dual-stack operation: Most modern networks run both IPv4 and IPv6. When you visit https://example.com, your OS tries IPv6 first (Happy Eyeballs algorithm), falling back to IPv4 if IPv6 is slow or unreachable. This ensures connectivity regardless of which protocol is functional on the path.

Network Classification by Scope

Networks are classified by geographic scope and purpose. Understanding these categories helps choose the right technology for each use case:

Selection rule: Use the smallest scope that meets your requirements. PAN for peripherals, LAN for buildings, MAN for metro connectivity, WAN for geographic distribution. Overscoping increases cost and complexity.

Conclusion

A solid understanding of network layers, diagnostic tools, and hardware roles is essential for anyone working with computer networks. The OSI model provides a mental framework, the TCP/IP model reflects real implementation, and tools like ping, traceroute, dig, curl, and ss let you inspect each layer in practice. When issues arise, systematic isolation — starting from the physical layer and working up — resolves the majority of connectivity problems without guesswork.

Whether you are configuring a home router, debugging a cloud application timeout, or designing a multi-site enterprise network, the same layered approach applies. Master the fundamentals covered here, and you will be equipped to handle most network scenarios you encounter in practice.

Resources

• RFC 1122 — Requirements for Internet Hosts — TCP/IP protocol stack
• tcpdump Man Page — Packet capture reference
• Wireshark Display Filters — Protocol inspection
• Cloudflare Learning Center — Network protocol explanations
• IBM Learn: Networking — Networking fundamentals
• DigitalOcean Networking Tutorials — Practical networking guides