How data travels across the internet
Follow the same 2,400 bytes from packets to an application. Change the conditions where they matter.
The simulator could not load. Keep assets/network-model.js and assets/network-guide.js alongside this guide. The explanations below still work.
One message, several pieces.
The same numbered pieces stay with us throughout the journey.
Inspect individual packet events
Optional close-up of this same transfer. Playback advances one event per beat, not in proportion to modeled time.
Ready to inspect this transfer.
Sender A
Four pieces of 600 bytes, plus headers
Router queue
A = your data · dashed B = other traffic
Shared outgoing link
Travelling after transmission
Receiver A → application
Arrived, waiting for earlier bytes
Available to the app
Lost attempts: none
Smaller pieces. More headers.
Your application’s data travels in pieces. Each packet carries useful payload plus a header with delivery information.
2,400 bytes → four 600-byte payloads, each with an illustrative 40-byte header.
2,400 B payload + 160 B headers = 2,560 B before competing traffic and retries.
Smaller packets take shorter turns, but repeat more headers.
Packets, segments, frames, and messages?
Applications define messages. TCP carries a byte stream in segments; IP carries packets; links carry frames. A TCP write need not equal a segment or a read. Applications must mark message boundaries. UDP preserves datagram boundaries.
A1/A2 label data groups, not TCP message numbers. Real maximum transmission units (MTUs) limit packet sizes. Both delivery models here use an illustrative 40-byte header, not exact real-world overhead.
Transmit bits. Then travel.
Putting all a packet’s bits onto the link takes time. After its last bit leaves, another packet can transmit while the first keeps travelling.
Then 60 ms of one-way travel
More capacity moves more bits per second. It does not make them travel faster.
Why do file downloads and tiny replies feel different?
Tiny reply (240 B): 20 ms transmission + 60 ms travel = 80 ms.
Small file (240,000 B): 20,000 ms transmission + 60 ms travel = 20,060 ms.
These ideal one-hop estimates use the current capacity and travel time but omit headers, queueing, setup, and other hops. They are not this transfer’s measured duration. Increasing capacity helps the large file more; reducing travel time helps both.
The slider is one-way propagation, not round-trip time. Real application throughput can be below link capacity. Busy buffers can drop packets; our loss toggle is a controlled failure, not simulated buffer overflow.
Arrived does not always mean available.
TCP delivers ordered bytes. If a piece is missing, later bytes can arrive at the receiver but wait before reaching the application.
Arrival order so far
None yetReleased to the application so far
None yetTCP adds recovery and ordering. Bare UDP leaves those decisions to the application.
What is simplified about recovery here?
A2 is lost once. The TCP-style retry joins the router queue 1,000 ms after A2’s first transmission ends. Real TCP uses acknowledgments, adaptive loss detection, flow control, and congestion control. Setup and ACK traffic are omitted here. Persistent failure can still end a TCP connection.
Delaying A1 is a controlled out-of-order case, not a claim that every packet takes a random route. The event inspector shows actual arrival and release times for the same run.
Does UDP mean unreliable apps—or always faster?
No. Applications can add recovery, ordering, security, and congestion control. QUIC runs over UDP and adds these capabilities with separate ordered streams. HTTP/3 uses QUIC; loss on one stream need not block another. Network delay still applies.
Complete, or in time?
This is the outcome of the same transfer—not another scenario. Replay it above to see the application receive data. A file needs every byte; audio also needs data before its playback deadline.
- Delivery
- TCP-style ordered stream
- A2 loss
- Off
- A1 delay
- Off
Every byte matters.
A complete file needs all 2,400 bytes. Missing data prevents completion.
Link settings: 600-byte payloads · 96 kbit/s · 60 ms one-way travel · no competing traffic.
The right delivery behavior depends on what the application needs.
What do these audio deadlines represent?
All numbered chunks are ready initially. Chunk 1 is due at 300 ms, then one every 150 ms. Deadlines are invented and anchored to this burst—not a full live call. Changing packet size changes the toy chunk boundaries and count, not a realistic audio encoding.
Data must be released to the app by its deadline, not merely arrive at the receiver. Real media also needs security, congestion handling, and jitter buffers. Missing audio may be concealed, recovered, or skipped.
Does delivery prove an app saved or read the data?
No. A TCP acknowledgment confirms transport receipt—not processing, saving, or human reading. Chat needs complete messages plus application-level receipts. Applications must also arrange datagrams into the right order when using bare UDP.
Step 1 of 5 · Make packets.