Invisible
Infrastructure.Explore
SYSTEM 03 / Information in motion

The internet

A tap on your phone becomes packets, crosses independent networks, and returns as a page you can read.

THE SYSTEM MAP

Follow the flow.

Follow a web request
SIDE LOOKUP · HELPS FIND AN ADDRESS
ALTERNATE RESPONSE · MAY SERVE INSTEAD OF ORIGIN

Conceptual web transaction. DNS is a side lookup, not a transit hop for page data. Access, routing, transport, encryption, and application functions are simplified; request and response paths can differ. Select a component to inspect it.

INSIDE THE SYSTEM

The browser

A browser coordinates requests, interprets documents, and turns received resources into the page you can see and use.

Explore this component
Read the diagram as text
  1. The browser — A browser coordinates requests, interprets documents, and turns received resources into the page you can see and use.
  2. The access network — Wi-Fi, mobile radio, fibre, cable, and other links connect a device to the wider network through a service provider.
  3. Routers & forwarding — A router moves a packet between networks using its forwarding information and the packet’s destination.
  4. Web servers & HTTP — HTTP gives browsers and services a common way to request resources and describe the resulting responses.

Supporting or alternate roles, not sequential transit stops:

Conceptual web transaction. DNS is a side lookup, not a transit hop for page data. Access, routing, transport, encryption, and application functions are simplified; request and response paths can differ.

The internet is a network of independently operated networks. Shared protocols let many physical technologies and organisations cooperate, while applications at the edges turn exchanged data into useful services.

A web visit is a good place to begin, but the web is only one use of the internet. The diagram is a map of roles rather than a literal packet itinerary: DNS is a lookup alongside a transaction, and a cache or existing connection can remove parts of the illustrated work.

ONE ACTION, STEP BY STEP

Choose your way in.

Internet7 MIN
01—

Load a page on your phone

A request across a network of networks.

7 connected steps
Internet7 MIN
02—

When a network path breaks

Redundancy helps only when it is usable.

6 connected steps
Internet7 MIN
03—

Why the second visit can be faster

The trip that does not need repeating.

6 connected steps
Internet8 MIN
04—

Send a photo while moving

Radio is the first part of a much longer trip.

7 connected steps
Internet8 MIN
05—

Why a fast link can feel slow

Separate capacity from the waiting between actions.

6 connected steps
THE COMPONENT FIELD GUIDE

Meet the parts that make it work.

Internet

The browser

A browser coordinates requests, interprets documents, and turns received resources into the page you can see and use.

Internet

The access network

Wi-Fi, mobile radio, fibre, cable, and other links connect a device to the wider network through a service provider.

Internet

DNS & domain names

The Domain Name System lets applications look up information associated with names, including addresses used to contact services.

Internet

IP addresses & packets

Internet Protocol provides packet addressing that lets information cross networks built from different physical technologies.

Internet

Routers & forwarding

A router moves a packet between networks using its forwarding information and the packet’s destination.

Internet

Network interconnection

The internet works because independently operated networks agree to exchange traffic and communicate reachable destinations.

Internet

TCP, QUIC & reliable delivery

Transport protocols coordinate communication between endpoints, including ordering, loss recovery, and control of sending rates where required.

Internet

TLS & HTTPS

TLS helps endpoints establish an authenticated, encrypted connection, protecting application data while it travels between them.

Internet

Web servers & HTTP

HTTP gives browsers and services a common way to request resources and describe the resulting responses.

Internet

Caches & content delivery

A cache stores a reusable response so later requests may avoid repeating the full trip to its original source.

Internet

Optical fibre

Optical fibre guides light signals through glass, linking equipment across buildings, cities, and oceans.

Internet

Latency & round trips

Latency describes delay. It is different from throughput, which describes how much data is transferred over time.

Internet

Mobile access & handover

A mobile network coordinates a changing radio connection with transport links and core-network functions that provide data connectivity.

Internet

Congestion & packet queues

Packets wait when a link or device cannot serve arriving traffic immediately. Queue management and sender behaviour determine what happens next.

03
Internet / Network resilience

What if a network link fails?

Interactive model

Disconnect a link, then change the alternate path’s illustrative delay. Compare reachability and delay without treating the drawn route as a speed guarantee.

Two ways across the networkPreferred route selected
ILLUSTRATIVE TOPOLOGYALL LINKS AVAILABLE AYour access networkBPreferred transitCAlternate transitDDestination network A → B → D20 ms chosen delayA → C → D40 ms chosen delay Selected pathAvailable connection
Baseline: Preferred path 20 ms · alternate path 40 ms · all links available

Two ways across the network

Scroll or use the arrow keys to explore the enlarged diagram. Close with the button or Escape. Baseline: Preferred path 20 ms · alternate path 40 ms · all links available.

01 / Change the inputs
Normal route

Can an alternate route preserve reachability while changing the assumed delay?

40ms
20 ms120 ms

This is an illustrative one-way delay for the whole path through C. Disconnect A–B to use it; it does not change whether the path exists.

02 / Read the responseSelected delay remains 20 ms. Disconnect A–B to test the 40 ms alternative.
Selected path
A → B → D
Illustrative delay
20ms one way
Destination
Connected
Traffic follows A → B → D

The selected route through B has a chosen one-way delay of 20 ms. The alternative through C is set to 40 ms. Changing that assumption does not change the selected path while A–B remains available. Real routing depends on protocols and policy; it is not simply the shortest line on this drawing.

03 / Compare A and B

TWO INPUTS. TWO CONDITIONS.

Pin the current settings as A, then change either input to test B. A stays in memory only while this page is open. Shared links include the current B inputs, never the pinned A.

No A is pinned. Enable the interactive controls, choose settings and pin them to compare.

Compare both inputs and the model response. A stays fixed until you replace or clear it; B follows the controls.
Setting or resultA · Not pinnedB · Current
Preferred connection—A–B available
Alternate path delay—40 ms
Selected path—A → B → D
Illustrative delay—20 ms one way
Destination—Connected
Inside the modelAssumptions, limits & sources

Routing references explain how an alternative can be selected; delay measurements are a different question from reachability. Here the selected path has an assigned one-way delay: 20 ms through B, or the chosen delay through C after failure. The model does not derive latency from distance, measure bandwidth or calculate page-load time.

  • The topology is invented: path A → B → D is preferred and A → C → D is available as an alternative. It does not represent providers, locations or actual links.
  • The first control changes link A–B from available to failed. All other links and both endpoints remain available.
  • After failure, routing is assumed to have converged to an allowed alternate route with sufficient capacity. Detection time, convergence, packet loss, queues and transport recovery are omitted.
  • The preferred path is assigned an illustrative one-way delay of 20 ms. The alternate path delay is a second control from 20 to 120 ms, starting at 40 ms. These are editorial values, not measurements or a geographic estimate.
  • The alternate-delay control affects the selected path only when A–B has failed. Real routing follows protocols and policy rather than necessarily choosing the lowest-delay path.
  • A surviving path means reachability under these assumptions. It does not guarantee seamless recovery, application performance or independence from shared physical dependencies.

Model references: IETF / RFC Editor; F. Baker (editor): RFC 1812: Requirements for IP Version 4 Routers · IETF / RFC Editor; Y. Rekhter, T. Li, and S. Hares (editors): RFC 4271: A Border Gateway Protocol 4 (BGP-4) · IETF / RFC Editor; W. Eddy (editor): RFC 9293: Transmission Control Protocol (TCP) · Internet Society: The Internet Way of Networking: Defining the critical properties of the Internet · IETF / RFC Editor; G. Almes, S. Kalidindi, and M. Zekauskas: RFC 2681: A Round-trip Delay Metric for IPPM

SYSTEMS WITHIN SYSTEMS

Keep following the connections.

ElectricityRouters, access equipment and servers need power. Backup supplies have finite limits.WaterConnected monitoring carries information about pumps, storage and treatment equipment.Urban railTransport networks exchange passenger information and operational data through communication systems.

Sources & further reading

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

  1. Populating the page: how browsers work MDN Web Docs / Mozilla contributors · Not stated · Source & rights record
  2. RFC 9110: HTTP Semantics IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
  3. RFC 9111: HTTP Caching IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
  4. RFC 1122: Requirements for Internet Hosts — Communication Layers IETF / RFC Editor; R. Braden (editor) · 1989-10 · Source & rights record
  5. The Internet Way of Networking: Defining the critical properties of the Internet Internet Society · 2020-09-09 · Source & rights record
  6. How the Internet Works Internet Society · Not stated · Source & rights record
  7. RFC 1034: Domain names — concepts and facilities IETF / RFC Editor; P. Mockapetris · 1987-11 · Source & rights record
  8. What Does ICANN Do? ICANN · Not stated · Source & rights record
  9. RFC 9499: DNS Terminology IETF / RFC Editor; P. Hoffman and K. Fujiwara · 2024-03 · Source & rights record
  10. RFC 4033: DNS Security Introduction and Requirements IETF / RFC Editor; R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose · 2005-03 · Source & rights record
  11. RFC 8484: DNS Queries over HTTPS (DoH) IETF / RFC Editor; P. Hoffman and P. McManus · 2018-10 · Source & rights record
  12. RFC 8200: Internet Protocol, Version 6 (IPv6) Specification IETF / RFC Editor; S. Deering and R. Hinden · 2017-07 · Source & rights record
  13. RFC 1812: Requirements for IP Version 4 Routers IETF / RFC Editor; F. Baker (editor) · 1995-06 · Source & rights record
  14. RFC 9293: Transmission Control Protocol (TCP) IETF / RFC Editor; W. Eddy (editor) · 2022-08 · Source & rights record
  15. RFC 4271: A Border Gateway Protocol 4 (BGP-4) IETF / RFC Editor; Y. Rekhter, T. Li, and S. Hares (editors) · 2006-01 · Source & rights record
  16. RFC 9000: QUIC — A UDP-Based Multiplexed and Secure Transport IETF / RFC Editor; J. Iyengar and M. Thomson (editors) · 2021-05 · Source & rights record
  17. RFC 768: User Datagram Protocol IETF / RFC Editor; J. Postel · 1980-08 · Source & rights record
  18. RFC 9114: HTTP/3 IETF / RFC Editor; M. Bishop (editor) · 2022-06 · Source & rights record
  19. RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3 IETF / RFC Editor; E. Rescorla · 2026-07 · Source & rights record
  20. Optical Fiber Glossary of Terms Corning Incorporated · Not stated · Source & rights record
  21. The Nobel Prize in Physics 2009: Information for the Public Royal Swedish Academy of Sciences · 2009 · Source & rights record
  22. RFC 2681: A Round-trip Delay Metric for IPPM IETF / RFC Editor; G. Almes, S. Kalidindi, and M. Zekauskas · 1999-09 · Source & rights record
  23. RFC 7567: IETF Recommendations Regarding Active Queue Management IETF / RFC Editor; F. Baker and G. Fairhurst (editors) · 2015-07 · Source & rights record
  24. ETSI TR 121 915 V15.0.0: Release description, Release 15 ETSI / 3GPP · 2019-10 · Source & rights record
  25. 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
  26. RFC 5681: TCP Congestion Control IETF / RFC Editor; M. Allman, V. Paxson, and E. Blanton · 2009-09 · Source & rights record