How Data Travels Across the Internet: The Journey of a Packet

What Problem Does Packet Switching Solve?

Diagram 1

1. Massive waste of resources: If you are reading a webpage, you are not constantly sending or receiving data. You read for 30 seconds, then click a link. During those 30 seconds of silence, your dedicated circuit just sits there, completely unused, but no one else can use it either.
2. Expensive and inflexible: Setting up a dedicated circuit between every pair of computers that might want to communicate? Imagine the cost. Imagine the complexity. It simply did not scale.
3. Single point of failure: If any part of your dedicated circuit got damaged or went down, your entire connection was toast. In a military context (where the internet was born), this was unacceptable. What if a city got attacked and took out key communication lines?
4. Slow setup time: Establishing a circuit could take seconds or even minutes. For quick, bursty data transfers, this overhead was ridiculous.

Real World Analogy

How Does Packet Switching Work?

1. Break data into packets: Your email, video stream, or file download gets divided into small chunks (typically 1,500 bytes or less)
2. Add addressing information: Each packet gets wrapped with headers containing source and destination addresses
3. Send independently: Packets get released into the network and travel independently
4. Route dynamically: Each router along the way decides the next best hop for that packet
5. Reassemble at destination: The receiving computer collects all packets and puts them back in the correct order

Diagram 2

• Efficiency: Network links are shared among many users. When you are not sending data, someone else can use that bandwidth.
• Resilience: If a router fails, packets automatically route around the failure. No single point of failure.
• Scalability: Adding new computers to the network is trivial. They just need an address.
• Speed: No setup time required. Start sending packets immediately.

1. Statistical multiplexing: Multiple data streams share the same physical links. The network buffers packets briefly at each router and forwards them as capacity allows.
2. Store and forward: Routers receive entire packets, check for errors, and then forward them. This allows error detection at each hop.
3. Best effort delivery: The network tries its best to deliver packets but makes no guarantees. Higher level protocols (like TCP) handle reliability.
4. Decentralized routing: No central authority controls the network. Each router makes independent decisions based on local information.

The Evolution of Data Transfer

How We Got Here: A Historical Journey

Diagram 3

• IP handles addressing and routing (getting packets from A to B)
• TCP handles reliability, ordering, and error correction (making sure data arrives intact)

Diagram 4

• 1990: 313,000 hosts
• 1995: 6.6 million hosts
• 2000: 93 million hosts

• CDNs (Content Delivery Networks): Cache content closer to users
• Multicast: Send one packet to many recipients simultaneously
• QoS (Quality of Service): Prioritize certain types of traffic
• IPv6: Expand the address space from 4.3 billion to 340 undecillion addresses

• Edge computing: Process data closer to the source
• HTTP/3 and QUIC: Reduce latency by improving how packets are handled
• 5G networks: Deliver gigabit speeds to mobile devices
• Submarine cables: 99% of intercontinental traffic travels through undersea fiber cables

Diagram 5

Visualizing How Packets Travel

• What happens: The application (browser) generates the data that needs to be sent
• Why it happens: Applications do not deal with packets directly. They work with logical data streams
• State change: HTTP request created → Ready to be packetized

• What happens: Data divided into packet sized chunks (usually 1,500 bytes or less to fit in an Ethernet frame)
• Why it happens: Networks have a Maximum Transmission Unit (MTU). Packets must fit within this limit
• State change: Continuous data stream → Discrete packets

Diagram 6

• Source port (your browser's random port, like 54321)
• Destination port (web server's port, usually 80 or 443)
• Sequence number (which piece of data is this?)
• Checksum (for error detection)

• Source IP address (your computer's IP, like 192.168.1.100)
• Destination IP address (web server's IP, like 93.184.216.34)
• Time to Live (TTL) - maximum number of hops before the packet dies
• Protocol (TCP, UDP, etc.)

• Source MAC address (your network card's physical address)
• Destination MAC address (your router's MAC address)
• What happens: Each layer adds its own header with addressing and control information
• Why it happens: Each layer has different responsibilities and needs different information
• State change: Raw data → Fully addressed packet ready for transmission

• What happens: Physical transmission of bits onto the network medium
• Why it happens: Digital data needs to become a physical signal to travel across wires or air
• State change: Digital packet → Physical signal on the wire

Diagram 7

• What happens: Router examines destination IP and consults routing table
• Why it happens: Routers connect different networks. They need to determine the next hop toward the destination
• State change: Packet enters router → Packet forwarded to next hop

1. Your home router
2. ISP's local router
3. ISP's regional router
4. Internet backbone router
5. Tier 1 network router
6. Destination ISP's router
7. Web server's local router
8. Web server

• What happens: Packet traverses multiple routers, each forwarding it closer to the destination
• Why it happens: No single router knows the complete path. Each router only knows the next best hop
• State change: Multiple router hops → Packet approaches destination network

Diagram 8

• What happens: Final router delivers packet to destination host
• Why it happens: Packet has reached its destination network
• State change: Packet in transit → Packet delivered to destination machine

1. Strip Ethernet header (Layer 2)
2. Strip IP header (Layer 3)
3. Strip TCP header (Layer 4)
4. Deliver payload to application (web server software)

• What happens: Each layer strips its header and passes data up to the next layer
• Why it happens: Headers were added for transmission. Now we need the original data back
• State change: Packet with headers → Original application data

• What happens: Server generates response and sends it back as packets
• Why it happens: Request/response cycle completes
• State change: Request received → Response sent

Diagram 9

• What happens: Complete response reassembled and displayed to user
• Why it happens: User requested a webpage, now they see it
• State change: Packets received → Webpage displayed

The Anatomy of a Packet

Diagram 10

• Destination MAC address (6 bytes): Physical address of next device
• Source MAC address (6 bytes): Physical address of current device
• EtherType (2 bytes): What protocol is inside? (Usually IP)

• Version (4 bits): IPv4 or IPv6
• Header length (4 bits): How long is this header?
• Type of Service (8 bits): Priority and QoS hints
• Total length (16 bits): Size of entire packet
• Identification (16 bits): Which fragments belong together?
• Flags and fragment offset (16 bits): For reassembling fragments
• Time to Live (8 bits): Maximum hops before death
• Protocol (8 bits): What is inside? (TCP = 6, UDP = 17)
• Header checksum (16 bits): Error detection for the header
• Source IP address (32 bits): Where did this come from?
• Destination IP address (32 bits): Where is this going?

• Source port (16 bits): Application port on sender
• Destination port (16 bits): Application port on receiver
• Sequence number (32 bits): Position in data stream
• Acknowledgment number (32 bits): Next expected byte
• Data offset (4 bits): TCP header length
• Flags (12 bits): SYN, ACK, FIN, RST, etc.
• Window size (16 bits): Flow control
• Checksum (16 bits): Error detection
• Urgent pointer (16 bits): Rarely used
• Options (0-40 bytes): Optional extensions

• Ethernet MTU: 1,500 bytes
• Minus IP header: 20 bytes
• Minus TCP header: 20 bytes
• Maximum TCP payload: 1,460 bytes

• Frame Check Sequence (FCS): CRC checksum of the entire frame

How Routers Make Decisions

Diagram 11

Destination Network    Next Hop         Interface    Metric
0.0.0.0/0             203.0.113.1      eth0         1      (default route)
192.168.1.0/24        0.0.0.0          eth1         0      (directly connected)
10.0.0.0/8            198.51.100.1     eth2         5      (via gateway)

• Source MAC: Router's MAC address
• Destination MAC: Next hop's MAC address

1. Its directly connected networks
2. The next hop toward other networks
3. A default route for everything else (usually "send it upstream")

Dynamic Routing and Network Changes

Diagram 12

• RIP (Routing Information Protocol): Simple, distance vector, maximum 15 hops
• OSPF (Open Shortest Path First): Link state, builds complete topology map, fast convergence
• EIGRP (Enhanced Interior Gateway Routing Protocol): Cisco proprietary, hybrid approach

• BGP (Border Gateway Protocol): How ISPs exchange routing information, incredibly complex, runs the entire internet

Why This Matters

Real World Impact

1. Break video into small chunks (typically 4-10 seconds each)
2. Encode each chunk at multiple quality levels
3. Store chunks in CDN servers close to users
4. Send chunks as packets over the regular internet
5. Player buffers packets and adapts quality based on network conditions

• Serves 230+ million subscribers
• Uses packet switching with adaptive bitrate streaming
• Handles network congestion gracefully (quality drops instead of rebuffering)
• Cost effective (shares internet infrastructure with everyone else)

1. Debug network issues faster: When you see "packet loss" in your monitoring, you know exactly what is happening and where to look.
2. Optimize application performance: You can make smart decisions about:
   • Payload sizes (avoid packet fragmentation)
   • Request batching (reduce overhead from headers)
   • Protocol selection (TCP for reliability, UDP for speed)
3. Design better architectures: You understand:
   • Why microservices on the same local network perform better
   • Why ChatOps needs UDP (real time, bursty traffic)
   • Why CDNs improve performance (fewer hops, less latency)
4. Estimate costs and capacity: You can calculate:
   • Bandwidth requirements based on packet rates
   • Infrastructure needs for scaling
   • Cost of data transfer between cloud regions

Trade Offs and Gotchas

When Packet Switching Shines

1. Bursty traffic patterns: Web browsing, API calls, file transfers—anything where you send data intermittently. Sharing bandwidth is incredibly efficient here.
2. Many to many communication: When you need any computer to potentially talk to any other computer. Circuit switching could never scale to billions of devices.
3. Resilience is critical: Networks need to survive failures gracefully. Packet switching automatically routes around problems.
4. Cost efficiency matters: Sharing infrastructure dramatically reduces costs. The entire internet exists because packet switching made it affordable.
5. Flexible bandwidth needs: Different applications need different amounts of bandwidth at different times. Packet switching allocates bandwidth dynamically.

When Packet Switching Struggles

1. Real time voice/video with strict latency requirements: While we have made it work (VoIP, Zoom), packet switching introduces variable latency. Circuit switching provided more predictable latency for traditional phone calls.
2. Constant, high bandwidth streams: If you genuinely need a constant 10 Gbps connection between two points 24/7, a dedicated circuit might actually be more efficient (though you are probably using dedicated fiber, which still uses packet switching under the hood).
3. Ultra low latency trading systems: High frequency trading firms sometimes use dedicated circuits or specialized networks because every microsecond matters.
4. Critical infrastructure: Some industrial control systems use dedicated connections because the unpredictability of packet switching is unacceptable for life safety systems.

Common Mistakes and Misconceptions

• Why it happens: It feels logical that packets would follow a fixed route
• Impact: Confusion when debugging network issues or seeing different latencies
• Reality: Each packet is routed independently. Different packets in the same data stream can take different paths. Routers make forwarding decisions based on current network conditions.
• How to see it: Use traceroute multiple times to the same destination. You will often see different paths.

• Why it happens: It seems like something this complex must have central coordination
• Impact: Misunderstanding how network failures and routing changes work
• Reality: The internet is completely decentralized. No one owns or controls it. Each Autonomous System (AS) makes its own routing decisions. This is why the internet is so resilient but also why fixing problems can be complex.
• How it works: BGP allows different networks to advertise routes and make independent forwarding decisions.

• Why it happens: More data per packet means less overhead, right?
• Impact: Actually causes worse performance due to fragmentation and increased loss probability
• Reality: Networks have MTU limits (typically 1,500 bytes). Packets larger than the MTU get fragmented, which introduces overhead and reliability issues. If any fragment is lost, the entire packet must be retransmitted.
• How to avoid: Use Path MTU Discovery or stick to safe payload sizes (1,400 bytes or less for TCP).

go
//  WRONG: Sending huge packets
func sendData(data []byte) {
    // Sending 64KB at once will cause fragmentation
    conn.Write(data) // data is 65536 bytes
}

//  RIGHT: Chunking data appropriately
func sendDataChunked(data []byte) {
    maxChunkSize := 1400 // Safe size that avoids fragmentation
    for i := 0; i < len(data); i += maxChunkSize {
        end := i + maxChunkSize
        if end > len(data) {
            end = len(data)
        }
        chunk := data[i:end]
        conn.Write(chunk)
    }
}

• Why it happens: In testing, local networks rarely drop packets
• Impact: Applications crash or hang when deployed to real internet conditions
• Reality: The internet drops packets regularly. 0.1% to 1% packet loss is normal. Your application must handle this gracefully. TCP handles retransmission automatically, but you still need timeouts and error handling.
• How to fix: Always set appropriate timeouts. Test your application with network simulation tools that introduce packet loss.

go
//  WRONG: No timeout
conn, err := net.Dial("tcp", "example.com:80")
if err != nil {
    return err
}
// If the network has issues, this hangs forever
data, err := io.ReadAll(conn)

//  RIGHT: Set reasonable timeouts
conn, err := net.DialTimeout("tcp", "example.com:80", 5*time.Second)
if err != nil {
    return err
}
conn.SetDeadline(time.Now().Add(30*time.Second))
data, err := io.ReadAll(conn)

• Why it happens: People use these terms interchangeably
• Impact: Wrong optimization strategies, disappointed users
• Reality:
  • Bandwidth: How much data you can transfer per second (like pipe width)
  • Latency: How long it takes for a packet to travel from source to destination (like pipe length)
  • You can have high bandwidth but high latency (fat pipe, but long)
  • You can have low bandwidth but low latency (thin pipe, but short)
• Why it matters:
  • For file downloads: Bandwidth matters most
  • For video calls and gaming: Latency matters most
  • For web browsing: Both matter (latency for initial request, bandwidth for content)

• Why it happens: More buffering seems like it should always help
• Impact: High latency even on fast connections
• Reality: Routers and network devices buffer packets in queues. If buffers are too large, packets can sit waiting for seconds even on a gigabit connection. This creates artificial latency.
• How to fix: Use modern queue management algorithms (like CoDel or fq_codel) and appropriate buffer sizes.

• Why it happens: TCP provides ordered delivery, so people assume packets arrive in order
• Impact: Confusion when working with UDP or examining packet captures
• Reality: IP does not guarantee ordering. Packets can arrive out of order. TCP reorders them before delivering to your application, but if you use UDP or examine raw packets, you will see reordering.
• How to handle: If using UDP, add sequence numbers in your application protocol and handle reordering yourself.

Performance Considerations

Security Considerations

Comparison with Alternatives

How Does Packet Switching Stack Up?

• When it shines: Constant, predictable traffic like traditional phone calls
• Why we moved away: Incredibly wasteful for bursty data traffic, expensive, inflexible
• Modern use: Still used in some telecom backbones, but even voice is moving to VoIP (packet switched)

• When it shines: Delay tolerant applications like email
• Key difference: Stores entire messages at each hop instead of forwarding immediately
• Why we do not use it for real time: Too much latency from storing complete messages
• Modern use: Email, SMS, some IoT applications

• When it shines: Need some guarantees but want better efficiency than circuit switching
• Key difference: Establishes a path through the network, but shares links via statistical multiplexing
• Why it is not dominant: More complex than pure packet switching, internet grew without it
• Modern use: MPLS is common in ISP and enterprise networks for traffic engineering

Summary

• Packet switching revolutionized networking: By breaking data into small, independently routed packets, we created a network that is efficient, resilient, and scalable. This fundamental innovation made the internet possible.
• Packets are self contained units: Each packet carries addressing information, data, and error checking bits. They travel independently, potentially taking different paths, and get reassembled at the destination.
• The internet is decentralized: No single entity controls routing. Each router makes independent forwarding decisions based on local information. This distributed approach is why the internet is so robust.
• Evolution never stops: From ARPANET's four nodes to today's billions of devices, the core concepts remain the same, but we continually optimize for speed, scale, and new use cases.
• Understanding packets matters: Whether you are debugging network issues, optimizing application performance, or designing distributed systems, knowing how packets flow through the internet gives you superpowers.

Next Steps

• Read: Learn about TCP's reliability mechanisms and UDP's speed advantages. Understand how routing protocols like BGP keep the internet running.
• Practice: Use tools like tcpdump, wireshark, traceroute, and mtr to observe real packets in flight. Capture and analyze packets from your own applications.
• Build: Create a simple packet sniffer in Go. Build a load balancer that distributes packets across multiple servers. Implement a basic chat application using UDP to understand packet ordering challenges.

Resources

• RFC 791: Internet Protocol - The original IP specification
• A Brief History of the Internet (Internet Society)
• How Routing Works - Router requirements RFC
• Wireshark Network Analysis - Book by Laura Chappell
• Related DevSwiftTools blogs: TCP/IP deep dive, UDP explained, HTTP protocols