Wireless, mobile and the last mile
Why Wi-Fi and cellular behave differently from a wired link, how roaming changes an IP address, latency versus bandwidth, and what to expect from a mobile client.
The last mile is shared and noisy
| Property | Wired | Wi-Fi | Cellular |
|---|---|---|---|
| Medium | Dedicated | Shared with neighbours | Shared with the cell sector |
| Typical latency | Under 1 ms locally | 2-10 ms local, more under load | 20-100 ms, higher on legacy radio |
| Packet loss | Rare | Bursty when the channel is congested | Occasional, with fast recovery |
| Address stability | Stable | Stable while associated | Changes on handover or NAT rebinding |
| Jitter | Low | Moderate | High |
| Cost model | Unlimited | Usually unlimited | Often metered per megabyte |
- Wireless links retransmit at the radio layer, so a packet that reaches IP may already have been retried several times.
- Cellular connections sit behind carrier-grade NAT, so inbound connections are normally impossible without a relay.
- Radio state machines have a tail: briefly returning to a higher power state costs power and adds latency.
- Bandwidth on a shared medium is variable; a design that assumes a fixed rate will be disappointed.
Address changes and connection survival
When a device moves between networks, its address changes. Any connection bound to the old four-tuple breaks, which is why mobile clients reconnect constantly and why protocols with connection identifiers survive better.
TCP connection QUIC connection
identified by the identified by a
four-tuple connection id
address change -> the address change -> the
connection is dead; a new same logical connection
handshake is required continues on the new path- Assume every request may fail and design the client to retry idempotent operations.
- Prefer a connection that survives a path change where the protocol supports it.
- Keep request payloads small, because retrying a large upload on a metered link is expensive for the user.
- Use resumable uploads with a content range so a reconnect continues rather than restarts.
- Measure on real devices and real networks; a desktop on office Wi-Fi represents none of your mobile users.
Designing for the last mile
- Latency dominates perceived performance far more than bandwidth on wireless links.
- Fewer round trips beats smaller payloads: a chatty protocol performs worse than a larger single request.
- Aggressive timeouts fire spuriously on a high-jitter link; budget for the worst case you have measured.
- Background sync and batching avoid the radio wake-up cost of many small requests.
- Cache aggressively on the client, because the cheapest request is the one never sent.
# emulate a mobile profile before blaming the server
# Chrome DevTools: Network -> throttling -> Slow 4G
# or on Linux, add delay and loss to a test interface
tc qdisc add dev eth0 root netem delay 100ms 40ms loss 2%
tc qdisc del dev eth0 root netem💡
Test on a throttled connection with jitter and loss, not only on fast office Wi-Fi. Most performance regressions that mobile users report are round-trip and timeout problems that never appear on a low-latency link.
FAQ
Why does my mobile client reconnect so often?
The address changes when the device moves between cells or switches between Wi-Fi and cellular, which invalidates the connection. Use connection identifiers where possible and make reconnection cheap.
Is cellular latency getting better?
Yes on modern radio generations, but it remains far above wired and varies with signal quality and load. Design for the distribution, not the best case.
Related
UDP, QUIC and choosing reliability TCP in depth: handshake, windows and congestion control
Last refreshed 2026-09-18.