Free lesson · Computer Networking

Packets How Data Actually Travels

Easy11 min readnetworkingcomputer-networkstcp-ip

Data Does Not Travel as a Continuous Stream

When you send a message, upload a photo, or stream a video, it feels continuous - a smooth flow of data from your device to the destination. But that is an illusion maintained by the software layers above the network. Underneath, your data is chopped into small, discrete pieces called packets, and each packet travels independently across the network.

A 5 MB photo you upload to Instagram does not travel as a single 5 MB blob from your phone to Instagram's servers. It is divided into roughly 3,500 individual packets, each about 1,500 bytes. Those packets are launched into the network, where they may take different paths, arrive at different times, and even arrive out of order. The receiving side reassembles them into the original 5 MB photo, and the application never knows they were separated.

This approach - called packet switching - is the fundamental mechanism that makes the internet work. It is so important that understanding it changes how you think about every network behavior, from latency to congestion to failure recovery.

Packet Switching vs Circuit Switching

To understand why the internet uses packet switching, it helps to understand the older alternative it replaced.

Circuit Switching - The Telephone Model

When you made a phone call on the traditional telephone network, the system established a dedicated circuit between your phone and the other person's phone. A physical electrical path was reserved through a series of telephone switches, and that path remained exclusively yours for the duration of the call. Nobody else could use that capacity while your circuit was active - even during silence when no one was speaking.

Circuit switching guarantees consistent quality (the dedicated path does not fluctuate) and real-time delivery (no queuing delays), but it wastes capacity terribly. Studies of telephone conversations showed that the average call is 60% silence. That means 60% of the reserved circuit capacity is wasted on silence - capacity that could have been serving other calls.

Packet Switching - The Internet Model

The internet uses a fundamentally different approach. Instead of reserving a dedicated path, packet switching breaks data into small packets that are individually addressed and independently routed through the network. Each packet is labeled with source and destination addresses, and each router along the way makes an independent decision about where to forward it based on its routing table.

No capacity is reserved. Packets from thousands of different conversations share the same cables and routers. When a packet arrives at a router, it waits briefly in a queue (if the outgoing link is busy), gets forwarded, and the router immediately handles the next packet - which might belong to a completely different conversation between completely different devices.

This sharing is what makes the internet economically viable. A single fiber optic cable can carry packets from millions of simultaneous conversations, with each conversation using capacity only when it has data to send. During silence or idle periods, the capacity is available for other traffic. The utilization of shared links is far higher than dedicated circuits.

graph TB
    subgraph Circuit["Circuit Switching"]
        direction LR
        CA["Phone A"] ---|"Dedicated Path<br/>(reserved for<br/>entire call)"| CSW1["Switch"]
        CSW1 ---|"Dedicated"| CSW2["Switch"]
        CSW2 ---|"Dedicated"| CB["Phone B"]
    end

    subgraph Packet["Packet Switching"]
        direction LR
        PA["Device A<br/>Packets: 1,2,3"] --> PR1["Router"]
        PX["Device X<br/>Packets: A,B"] --> PR1
        PR1 -->|"Pkt 1"| PR2["Router"]
        PR1 -->|"Pkt A"| PR3["Router"]
        PR2 -->|"Pkt 1"| PB["Device B"]
        PR3 -->|"Pkt A"| PY["Device Y"]
        PR2 -->|"Pkt 2,3"| PB
    end

    style CA fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style CB fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style CSW1 fill:#c4b5fd,stroke:#a78bfa,color:#000
    style CSW2 fill:#c4b5fd,stroke:#a78bfa,color:#000
    style PA fill:#4f46e5,stroke:#4338ca,color:#fff
    style PX fill:#7c3aed,stroke:#6d28d9,color:#fff
    style PR1 fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style PR2 fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style PR3 fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style PB fill:#4f46e5,stroke:#4338ca,color:#fff
    style PY fill:#7c3aed,stroke:#6d28d9,color:#fff

This diagram compares circuit switching and packet switching. In circuit switching, Phone A connects to Phone B through two switches via a dedicated path that is reserved for the entire call duration. In packet switching, Device A sends packets 1, 2, and 3 toward Device B, while Device X sends packets A and B toward Device Y. All packets share the same routers, with Router 1 forwarding packets from both Device A and Device X to different destinations based on their addresses. The routers are shared resources, not dedicated paths.

The Trade-Off

Packet switching introduced a trade-off that circuit switching did not have: variable delay (also called jitter). Because packets share network resources and wait in queues at routers, the time each packet takes to traverse the network can vary. One packet might arrive in 20 ms, the next in 25 ms, the third in 18 ms. For data transfer (loading a web page, downloading a file), this variability is invisible - the receiving side reassembles packets in order regardless of when they arrived. For real-time applications (voice calls, video conferencing), jitter creates quality problems because the playback must be continuous even though packet arrival is not.

Modern networks handle this through jitter buffers (accumulate a few packets before starting playback to smooth out arrival variability) and Quality of Service (QoS) mechanisms that prioritize real-time traffic over bulk data transfer at the router level.

Anatomy of a Packet

A packet is not just a chunk of data. It is a chunk of data wrapped in headers that tell the network how to deliver it. The structure follows the layered model you will study in Module 1, but the basic concept is simple: headers carry addressing and control information, and the payload carries the actual data.

Header + Payload

Every packet has two parts:

Header: Contains the metadata that routers and network devices need to forward the packet correctly. At minimum, this includes the source IP address (where the packet came from), the destination IP address (where it is going), and a protocol identifier (what type of data the payload contains). Different layers add their own headers - an Ethernet header for local delivery, an IP header for routing, a TCP header for reliable delivery.

Payload: The actual data being transmitted. For a web page, the payload contains HTML content. For an API call, the payload contains JSON data. For a video stream, the payload contains a frame of compressed video.

The layered structure means that each layer's payload is the entire packet from the layer above. An HTTP message (the application-layer data) is the payload inside a TCP segment. That TCP segment is the payload inside an IP packet. That IP packet is the payload inside an Ethernet frame. This nesting-doll structure is called encapsulation, and it is one of the most elegant architectural patterns in networking.

Key Fields in an IP Packet

The IP header - the most important header for understanding how packets traverse the internet - contains these essential fields:

The TTL field deserves special attention. Each router that forwards a packet decrements the TTL by 1. When TTL reaches 0, the router discards the packet and sends an ICMP "Time Exceeded" message back to the sender. This mechanism prevents packets from circulating endlessly through routing loops. The traceroute command exploits this behavior - it sends packets with progressively increasing TTL values (1, 2, 3, ...) to discover each router along the path.

Packet Size and MTU

Packets have a maximum size determined by the MTU (Maximum Transmission Unit) of the network. For standard Ethernet networks, the MTU is 1500 bytes. This means the largest IP packet that can be sent in a single Ethernet frame without fragmentation is 1500 bytes.

The actual usable payload is smaller because of header overhead. An IP header is typically 20 bytes, and a TCP header is typically 20 bytes, leaving 1460 bytes of application data per packet (this number is called the MSS - Maximum Segment Size in TCP).

When data exceeds the MTU, one of two things happens:

Fragmentation: The IP layer splits the oversized packet into multiple fragments, each small enough to fit within the MTU. The fragments are reassembled at the destination. Fragmentation adds overhead and complexity, and modern practice avoids it whenever possible.

Path MTU Discovery (PMTUD): The sender probes the path to discover the smallest MTU along the route, then sizes all packets to fit. This avoids fragmentation entirely and is the standard approach in modern networks.

Understanding MTU matters because MTU-related problems are a surprisingly common source of mysterious networking issues. A server behind a VPN with a reduced MTU might cause connections to hang when transferring large data (small packets work fine, but packets exceeding the reduced MTU are silently dropped because PMTUD is blocked by a misconfigured firewall). These "MTU black holes" are notoriously difficult to diagnose without understanding how packet sizes interact with network infrastructure.

What Happens When Packets Go Missing

On the internet, packet loss is normal. Routers drop packets when their queues overflow during congestion. Wireless links corrupt packets due to interference. Cables can have transient errors. A typical internet connection has a packet loss rate of 0.1-2% - meaning for every 1000 packets sent, 1-20 might not arrive.

How the system handles lost packets depends on the transport protocol:

TCP handles it automatically. TCP numbers every segment and requires acknowledgments from the receiver. If the sender does not receive an acknowledgment within a timeout period, it retransmits the missing segment. TCP also uses selective acknowledgments (SACK) to retransmit only the missing segments rather than everything after the gap. From the application's perspective, TCP hides packet loss entirely - data arrives complete and in order, even if some packets had to be sent multiple times.

UDP does not handle it at all. UDP sends packets and forgets about them. If a UDP packet is lost, it is simply gone. No retransmission, no notification, no recovery. This sounds unreliable (and it is), but it is exactly what real-time applications need. In a live video call, retransmitting a lost video frame is pointless - by the time the retransmission arrives, the conversation has moved on. It is better to skip the lost frame and continue with fresh data. Applications that use UDP implement their own loss-handling logic when they need it, tailored to their specific requirements.

The choice between TCP and UDP is one of the fundamental protocol decisions in networking, and it is driven by how the application handles lost packets. You will study both protocols in depth in Modules 5 and 6.

graph TD
    subgraph PacketLoss["Packet Loss Handling"]
        direction TB
        SEND["Sender transmits<br/>Packets 1, 2, 3, 4, 5"]
        NET["Network delivers<br/>Packets 1, 2, -, 4, 5<br/>(Packet 3 lost)"]
        
        subgraph TCPResp["TCP Response"]
            TACK["Receiver ACKs 1, 2<br/>Reports gap at 3<br/>ACKs 4, 5"]
            TRETX["Sender retransmits<br/>Packet 3"]
            TRESULT["App receives<br/>1, 2, 3, 4, 5<br/>(complete, ordered)"]
        end

        subgraph UDPResp["UDP Response"]
            UDROP["Packet 3 is gone<br/>No notification"]
            URESULT["App receives<br/>1, 2, 4, 5<br/>(gap at 3)"]
        end
    end

    SEND --> NET
    NET --> TACK --> TRETX --> TRESULT
    NET --> UDROP --> URESULT

    style SEND fill:#4f46e5,stroke:#4338ca,color:#fff
    style NET fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style TRESULT fill:#4f46e5,stroke:#4338ca,color:#fff
    style URESULT fill:#7c3aed,stroke:#6d28d9,color:#fff

This diagram shows how TCP and UDP handle packet loss differently. A sender transmits packets 1 through 5, but the network loses packet 3. With TCP, the receiver acknowledges packets 1 and 2, reports the gap at packet 3, and acknowledges packets 4 and 5. The sender retransmits packet 3, and the application receives all five packets complete and in order. With UDP, packet 3 is simply gone with no notification. The application receives packets 1, 2, 4, and 5 with a gap at 3.

The Postal System Analogy

The postal system is the best real-world analogy for packet switching, and it maps surprisingly well:

Like the postal system, the internet does not guarantee that all packets arrive, that they arrive in order, or that they arrive undamaged. Guarantees - when needed - are provided by higher-level protocols (TCP) on top of the basic delivery mechanism (IP), just as registered mail adds tracking and confirmation on top of the basic postal delivery.

Interview: Understanding packets and packet switching demonstrates systems-level thinking in interviews:

"Why does video streaming use UDP instead of TCP?" - Because retransmitting lost video frames adds latency worse than the visual artifact of a missing frame. UDP lets the application decide how to handle loss rather than forcing TCP's retransmission delay.

"What causes latency in a distributed system?" - Packets traveling through multiple routers (propagation delay), packets waiting in router queues during congestion (queuing delay), routers processing packet headers (processing delay), and the time to push all the bits onto the wire (transmission delay). Understanding these four types of delay - and which one dominates in a given situation - is fundamental.

"What is the relationship between packet size and network performance?" - Larger packets are more efficient (less header overhead per byte of data) but more vulnerable to loss (losing a large packet wastes more bandwidth than losing a small one) and cause more queuing delay at routers. Understanding this trade-off helps in discussions about MTU configuration and protocol overhead.

What Comes Next

You now have a high-level understanding of how the internet works: it is a network of networks, clients send requests to servers using the request-response model, and data travels as independently routed packets. The next module - Network Models - introduces the layered frameworks (OSI and TCP/IP) that organize all of these concepts into a structured mental model. Everything you learn from Module 1 onward builds on the foundation this module has established.

Exercise: Starter: Open your browser's Network tab and load a webpage. Look at the "Size" column for a few resources. Most will be larger than the ~1460-byte maximum payload of a single TCP segment. This means each resource was split across multiple packets and reassembled by your browser. For a 100 KB JavaScript file, roughly how many packets were needed to transfer it?

Intermediate: Run ping -s 1472 google.com (Mac/Linux) or ping -l 1472 google.com (Windows). This sends a ping packet with a 1472-byte payload. Why 1472 specifically? (Hint: 1500 MTU minus 20-byte IP header minus 8-byte ICMP header = 1472.) Now try ping -s 1473 google.com - what happens when the packet exceeds the MTU? Does it fragment, or does it fail? The answer depends on whether the Don't Fragment flag is set.

Advanced: Research the "bufferbloat" problem. When router queues are very large, packets are not dropped during congestion - they are buffered, adding hundreds of milliseconds of latency. This is counterintuitive: bigger buffers should be better, right? Why does excessive buffering actually hurt network performance? Research how algorithms like CoDel and fq_CoDel address bufferbloat by intelligently managing queue depth.

Back to Computer Networking