Invisible
Infrastructure.
Explore
Internet7 STOPS · 8 MINUTE READ

Send a photo while moving

Follow a fictional browser upload through mobile access, physical links, protected transport, and a receiving service.

The browser
STOP 1 OF 7 / Internet

Turn the action into an upload

Imagine a fictional web page where a user selects a photograph and chooses to upload it. The browser prepares an application request; the photograph is information to be transferred, rather than one indivisible object moving through the network. The destination and its handling of the image are application choices, separate from the physical route.

What to notice

The application prepares data for a chosen service.

Why it matters

A user action needs a defined request and destination.

Inside The browser
1 / 7
Read the complete journey
  1. 1

    Turn the action into an upload

    Imagine a fictional web page where a user selects a photograph and chooses to upload it. The browser prepares an application request; the photograph is information to be transferred, rather than one indivisible object moving through the network. The destination and its handling of the image are application choices, separate from the physical route.

    Notice: The application prepares data for a chosen service.
    Why: A user action needs a defined request and destination.

    Explore The browser
  2. 2

    Use a shared radio connection

    The phone connects through a mobile radio-access network, where equipment coordinates resources among devices. Signal conditions and available capacity both matter. The radio hop leads to transport links and core-network functions, rather than directly to every website. A visible signal indicator alone cannot establish that the complete path can carry the upload without delay.

    Notice: The first radio hop shares resources with other devices.
    Why: The phone needs managed access before its data can reach wider networks.

    Explore Mobile access & handover
  3. 3

    Keep the session useful as conditions change

    As the user moves, radio conditions and suitable serving connections may change. Mobile-network measurements and control signalling support mobility and handover where needed. The aim is service continuity, but the result depends on coverage, resources, and implementation. Our teaching route shows the roles only; it does not simulate a seamless handover or promise uninterrupted uploading.

    Notice: Control information manages a changing serving connection.
    Why: Mobility requires coordination beyond simply maintaining radio power.

    Explore Mobile access & handover
  4. 4

    Cross physical links beyond the radio hop

    The provider’s transport network may carry the data over fibre, with optical equipment translating information into signals on the link. Other physical media can also be used. These links need functioning endpoints and suitable capacity. A journey described as mobile can therefore depend heavily on fixed cables, facilities, power supplies, and interconnections farther along its path.

    Notice: A wireless start can lead into fixed optical infrastructure.
    Why: Different media connect the radio edge to the rest of the network.

    Explore Optical fibre
  5. 5

    Protect the upload to its endpoint

    For an HTTPS upload, cryptographic protection applies between the browser and the authenticated endpoint under the connection’s trust checks. Intermediate networks still forward traffic, and the receiving endpoint can process the decrypted request. Encryption protects transit within that scope; it does not decide whether the service stores, shares, or deletes the photograph after receiving it.

    Notice: The protected connection ends at a service endpoint.
    Why: Transit protection and the service’s later data practices are separate concerns.

    Explore TLS & HTTPS
  6. 6

    Deliver data despite some packet loss

    A reliable transport coordinates the transfer and can retransmit missing data while communication remains viable. Sending behaviour also responds to receiver and network limits. A momentary loss need not restart every byte, but persistent disconnection can still cause failure. The exact recovery depends on the transport, application, and changing path, none of which this journey numerically simulates.

    Notice: Acknowledgements and recovery concern missing data at the endpoints.
    Why: Best-effort packets need additional behaviour to support a complete upload.

    Explore TCP, QUIC & reliable delivery
  7. 7

    Confirm the application outcome

    The receiving service handles the request and returns an application response. A completed network transfer and a successfully accepted image are related but different outcomes: processing or storage may still fail. The browser must interpret the service’s response before displaying an appropriate result. This final dependency prevents a moving progress indicator from being mistaken for proof of permanent storage.

    Notice: The service response describes the request’s outcome.
    Why: Users need confirmation of the application result, not only network activity.

    Explore Web servers & HTTP
MAKE THE CONNECTION

Why can strong mobile signal coexist with a failed photo upload?

Reveal the explanation

Signal describes only part of radio access. Shared capacity, transport links, routing, connection recovery, and server processing or storage can still fail or delay the application.

Sources & further reading

Original explanations informed by these sources. Diagrams are conceptual; local systems differ.

  1. ETSI TR 121 915 V15.0.0: Release description, Release 15 ETSI / 3GPP · 2019-10 · Source & rights record
  2. ETSI TR 126 919 V19.0.0: Study on media handling aspects of conversational services in 5G systems ETSI / 3GPP · 2025-10 · Source & rights record
  3. Optical Fiber Glossary of Terms Corning Incorporated · Not stated · Source & rights record
  4. RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3 IETF / RFC Editor; E. Rescorla · 2026-07 · Source & rights record
  5. RFC 9293: Transmission Control Protocol (TCP) IETF / RFC Editor; W. Eddy (editor) · 2022-08 · Source & rights record
  6. RFC 9000: QUIC — A UDP-Based Multiplexed and Secure Transport IETF / RFC Editor; J. Iyengar and M. Thomson (editors) · 2021-05 · Source & rights record
  7. RFC 9110: HTTP Semantics IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
KEEP EXPLORING

Another way through the system.