How Does the Internet Work? From Cables to Packets to Pages

The Internet Is Not a Cloud

Every diagram of the internet shows a cloud. This is the single most misleading visual in all of technology education. The cloud implies something formless, distributed, ethereal. The reality is the opposite: the internet is one of the most physical, most precisely engineered systems humans have ever built.

At its lowest level, the internet is wires. Copper wires in telephone poles. Fiber optic cables buried under city streets. Enormous fiber bundles lying on the ocean floor, some as deep as 8,000 meters below sea level. Microwave links shooting between mountaintop towers. Cell tower antennas connecting phones to base stations. Your home Wi-Fi router shooting radio waves across your living room.

These wires connect to devices. Your phone. Your laptop. The server hosting this article. The DNS server that translated "melextech.dev" into an IP address. The router in your ISP's building that decided which cable your packets should travel down. The router in a data center in Virginia that forwarded those packets to the specific machine storing this file. Every single bit of data you have ever sent or received over the internet traveled through a physical medium as electrical pulses, light pulses, or radio waves.

The Physical Layer: What the Internet Is Made Of

The physical infrastructure of the internet has three tiers, each operating at a different scale.

Submarine Cables

Over 600 submarine cables cross the world's oceans, totaling roughly 1.3 million kilometers. These cables carry approximately 99% of intercontinental internet traffic. They are owned by consortia of telecommunication companies: a cable across the Atlantic might be jointly owned by AT&T, BT, Orange, and Telstra, each paying for a portion of its capacity.

A modern submarine cable is not a single wire. It is a bundle of up to 16 separate fiber optic strands, each capable of carrying terabits per second. The fibers are enclosed in copper tubing for protection, wrapped in layers of plastic and steel wire for strength, and coated in a waterproofing compound. The total diameter is about the size of a garden hose. Despite this, cables still get damaged. Ship anchors drag across them. Earthquakes snap them. Sharks have been known to bite them, though this is rarer than popularly claimed. Repair ships are dispatched to retrieve the cable, splice in a new section, and lower it back to the seafloor. A single repair operation can take weeks and cost millions of dollars.

Land Cables

On land, fiber optic cables run along roads, through underground conduits, and over utility poles. In cities, they thread through tunnels originally built for telephony. Between cities, they follow highway rights-of-way or railroad corridors. These land cables connect submarine cable landing stations to data centers and to the equipment inside ISP buildings.

Not all land connections are fiber. In rural areas, copper telephone lines (DSL) or fixed wireless links are still common. Satellite internet uses radio signals between a dish on your roof and a satellite in orbit, which then communicates with a ground station connected to the fiber network. Each technology has different characteristics for speed, latency, and reliability, but at the protocol level, they all work the same way.

Last-Mile Connections

The "last mile" is the connection between your ISP's local equipment and your device. For home internet, this is usually a coaxial cable (cable internet), a copper phone line (DSL), or a fiber optic line run directly to your home (fiber-to-the-home, or FTTH). For mobile internet, the last mile is a radio link between your phone and a nearby cell tower, which then connects to the ISP's network via fiber or microwave.

The last mile is often the bottleneck. Fiber can carry enormous bandwidth, but the coaxial cable or copper wire connecting your home has much less. This is why you might pay for "up to 500 Mbps" but actually get 350 Mbps during peak hours: the shared capacity of the last-mile infrastructure is being divided among your neighbors.

Packets: How Data Travels

The internet does not send your data as one continuous stream. It chops it into small, independent pieces called packets. This decision is fundamental to how the internet works, and understanding why it works this way is the key to understanding everything else.

Imagine you need to send a 10-megabyte photo from New York to London. If the internet used circuit switching (like old telephone networks), it would establish a dedicated path between the two cities and send the entire photo as one continuous stream. That path would be reserved for your use even during the moments when no data is actively flowing, wasting capacity.

Instead, the internet uses packet switching. Your computer splits the photo into thousands of small packets, each typically between 500 and 1,500 bytes. Each packet is labeled with a destination address and a sequence number, then sent into the network independently. Different packets from the same file might take completely different routes through the internet, depending on which links are least congested at that exact millisecond. When they all arrive at the destination, the sequence numbers tell the receiving computer how to reassemble them in the correct order.

Packet switching is more efficient than circuit switching because it allows many users to share the same physical links simultaneously. Your packets interleave with packets from thousands of other users. No single user needs a dedicated path. This shared, statistical multiplexing is what makes the internet scalable and affordable. It is also why the internet feels slower during peak hours: more users means more packets competing for the same link capacity.

Every packet carries not just data but also headers: metadata that tells each router along the way where the packet is going, where it came from, how many hops it has traversed, and what protocol it belongs to. The data payload is what you actually want to send. The headers are the addressing and handling information that gets the payload to the right place.

IPv4 Header (20 bytes)
├─ Version:          4
├─ Header Length:     20
├─ Total Length:      1,500 bytes
├─ Identification:   0xA4F2
├─ Flags:            Don't Fragment
├─ Time to Live:     64
├─ Protocol:         TCP (6)
├─ Header Checksum:  0xB82C
├─ Source IP:        192.168.1.100
└─ Destination IP:   104.21.76.45

TCP Header (20-60 bytes)
├─ Source Port:      54321
├─ Dest Port:        443
├─ Sequence Number:  1,482,937
├─ Ack Number:       0
├─ Flags:            SYN
└─ Window Size:      65,535

HTTP Request (data payload)
GET /post/how-does-the-internet-work HTTP/1.1
Host: melextech.dev
Accept: text/html

This simplified breakdown shows a real packet's structure. The IP header tells routers where to send the packet. The TCP header tells the receiving computer which connection this packet belongs to and where it fits in the sequence. The data payload is the actual HTTP request from your browser. Together, these headers add about 40-80 bytes of overhead per packet. For a 1,500-byte packet carrying a 1,400-byte payload, that is roughly 5% overhead, an acceptable trade-off for the flexibility packet switching provides.

IP Addresses and Routing

Every device connected to the internet has at least one IP address. This address serves the same function as a postal address: it uniquely identifies the destination so that routers can forward packets in the right direction. IPv4 addresses are 32-bit numbers written as four decimal numbers separated by dots, like 104.21.76.45. IPv6 addresses are 128-bit numbers written in hexadecimal, like 2606:4700:3030::ac43:8e31. The world is gradually transitioning from IPv4 to IPv6 because IPv4 has run out of addresses (about 4.3 billion possible, not enough for all devices on Earth).

But IP addresses alone are not enough to route traffic. The internet is too large for any single device to know the path to every other device. Instead, routing is hierarchical and distributed. Your home router knows how to reach your ISP. Your ISP's routers know how to reach other ISPs they have business relationships with. Those ISPs' routers know how to reach yet more networks. Each router only needs to know the next hop, not the complete path.

Routers make forwarding decisions using routing tables: databases that map destination IP address ranges to output interfaces. A simplified routing table entry might say: "Any packet destined for 104.21.76.0/24 should go out interface eth0 to the next router at 10.0.0.1." Real routing tables contain hundreds of thousands of entries and are constantly updated by routing protocols (BGP, OSPF, IS-IS) that allow routers to share information about the network topology and automatically adapt when links fail or congestion changes.

The Time to Live (TTL) field in the IP header prevents packets from circulating forever if they enter a routing loop. Each router that handles a packet decrements the TTL by one. If it reaches zero, the router discards the packet and sends an error message back to the source. This is why traceroute works: it sends packets with incrementally increasing TTL values to discover each hop along the path.

TCP: Reliable Delivery

IP handles addressing and routing, but it does not guarantee that packets arrive in order, or that they arrive at all. Packets can be dropped when links are congested, arrive out of order because they took different routes, or be duplicated by malfunctioning equipment. For web browsing, file transfers, and most other applications, this unreliability is unacceptable. You need every byte of a webpage to arrive, in the right order, with no gaps.

TCP (Transmission Control Protocol) provides this reliability on top of IP. It does this through three mechanisms.

The handshake. Before data flows, the client and server perform a three-way handshake. The client sends a SYN (synchronize) packet. The server responds with a SYN-ACK (synchronize-acknowledge). The client sends an ACK (acknowledge). Both sides now agree on initial sequence numbers and that they are ready to communicate. This handshake costs one round-trip of latency but prevents the server from doing work before confirming the client can actually receive responses.

Sequencing and acknowledgment. TCP numbers every byte of data. The receiver sends acknowledgments back to the sender confirming which bytes it has received. If the sender does not receive an acknowledgment within a timeout period, it retransmits the data. This ensures that even if packets are lost in transit, the data eventually arrives intact.

Flow control. TCP adjusts its sending rate based on how fast the receiver can process data and how congested the network is. If the receiver is a slow server or the network is busy, TCP backs off. If capacity frees up, it speeds up. This prevents fast senders from overwhelming slow receivers or congested links, which would cause widespread packet loss.

DNS: The Phonebook

Humans remember names. Computers need numbers. DNS (Domain Name System) bridges this gap. When you type melextech.dev into your browser, the browser does not know what IP address to connect to. It asks a DNS resolver, which looks up the domain in a hierarchical database and returns the corresponding IP address.

DNS resolution is itself a multi-step process that demonstrates the distributed nature of the internet. Your browser first checks its own cache. If it does not have the answer, it asks your operating system's DNS resolver. If that does not have it either, the request goes to your ISP's DNS resolver. If the ISP's resolver does not have it cached, the query travels up the DNS hierarchy: to the root nameservers (which know where to find the TLD servers), then to the .dev TLD nameservers (which know where to find the melextech.dev authoritative nameserver), then to that authoritative nameserver (which knows the actual IP address). The entire process typically takes 20-120 milliseconds.

DNS results are cached aggressively at every level. Once your ISP resolves a domain, it caches the answer for hours. Your browser caches it too. This means most DNS lookups do not actually travel all the way to the root nameservers. The cached answer is served locally in under a millisecond. DNS caching is one of the most important performance optimizations on the internet, and broken or misconfigured DNS caching is one of the most common causes of slow websites.

TLS: Encryption on the Wire

When you visit a website using HTTPS (which is nearly all of them now), the data traveling between your browser and the server is encrypted using TLS (Transport Layer Security). This means that anyone who intercepts the packets in transit, whether a rogue Wi-Fi operator, a compromised ISP, or a government surveillance system, can see that you are communicating with a particular IP address and how much data is flowing, but cannot read the actual content.

The encryption happens through a TLS handshake that occurs immediately after the TCP handshake. Your browser and the server exchange cryptographic keys, verify each other's identity using digital certificates, and agree on an encryption algorithm. All of this happens before any HTTP data is sent. After the handshake, both sides use the shared keys to encrypt and decrypt the data in each TCP segment.

HTTP: The Language of the Web

HTTP (Hypertext Transfer Protocol) is the format that web browsers and web servers use to communicate. It runs on top of TCP (and TLS for HTTPS) and defines the structure of requests and responses. A browser sends a request that includes a method (what it wants to do), a path (which resource it wants), headers (metadata about the request), and optionally a body (data being sent to the server). The server responds with a status code (whether the request succeeded), headers, and a body (the requested content).

GET /post/how-does-the-internet-work HTTP/1.1
Host: melextech.dev
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

HTTP/1.1, the version shown here, requires a separate TCP connection for each resource. Loading a page with 30 resources (HTML, CSS, images, JavaScript files) meant 30 separate TCP connections, each with its own handshake overhead. HTTP/2, introduced in 2015, solved this by allowing multiple requests and responses to be multiplexed over a single TCP connection. HTTP/3, the current standard being adopted, goes further by running over QUIC, a protocol built on UDP instead of TCP, eliminating the head-of-line blocking problem that could stall HTTP/2 connections.

The Full Journey: Start to Finish

Now let me put it all together. Here is the complete journey when you type melextech.dev/post/how-does-the-internet-work into your browser and press Enter.

Step 1: URL parsing. Your browser breaks the URL into components: the protocol (https), the domain (melextech.dev), and the path (/post/how-does-the-internet-work). It knows from the "https" prefix that it needs to use port 443 and establish an encrypted connection.

Step 2: DNS lookup. Your browser checks its DNS cache. Finding no entry, it sends a query to your operating system's resolver. That resolver checks its cache and, if needed, forwards the query up the DNS hierarchy. Within 10-50 milliseconds, the answer comes back: the IP address is 104.21.76.45.

Step 3: TCP handshake. Your browser opens a TCP connection to 104.21.76.45 on port 443. Three small packets fly back and forth: SYN, SYN-ACK, ACK. This takes roughly one round-trip to the server, typically 20-100 milliseconds depending on your distance from it.

Step 4: TLS handshake. Over the established TCP connection, your browser and the server perform the TLS handshake. The server sends its certificate. Your browser verifies it against a list of trusted certificate authorities. Both sides agree on encryption parameters and generate session keys. This adds another round-trip, roughly 20-100 milliseconds.

Step 5: HTTP request. Your browser sends the HTTP GET request through the encrypted tunnel. The request traverses multiple routers: your home router, your ISP's access network, a regional router, possibly a backbone router, and the data center's perimeter router, which delivers it to the web server. This journey takes 10-100 milliseconds depending on the number of hops and the distance.

Step 6: Server processing. The web server receives the request and passes it to the application server. The application server queries the database, assembles the HTML with all the content of this article, and generates the response. This might take 50-500 milliseconds depending on the complexity of the page.

Step 7: HTTP response. The response HTML travels back through the same path in reverse. The server sends it to its network, routers forward it hop by hop, and it arrives at your browser. Your browser receives the HTML and begins parsing it.

Step 8: Rendering. As your browser parses the HTML, it discovers references to CSS, JavaScript, images, and fonts. It issues additional HTTP requests for each of these resources. Many of these requests can be parallelized since they are independent. Some are blocked by render-blocking rules: the browser may wait for critical CSS before painting anything on screen, then wait for certain JavaScript before making the page fully interactive. The page appears progressively: first the text content, then the styling, then images loading in, then JavaScript-driven interactivity activating.

Total time from keystroke to rendered page: 100-500 milliseconds for a well-optimized site. That is faster than a blink. Behind that speed, hundreds of machines, dozens of protocols, and millions of lines of code are coordinating to make it happen.

Data Centers and Internet Exchange Points

The physical places where internet paths converge are data centers and Internet Exchange Points (IXPs).

A data center is a building (or set of buildings) purpose-built to house servers, network equipment, and supporting infrastructure like power, cooling, and security systems. Large data centers can contain tens of thousands of servers in rows of racks, consuming as much electricity as a small city. They are built in locations chosen for low risk of natural disasters, access to multiple fiber routes, affordable power, and favorable tax treatment.

An IXP is a facility where multiple networks physically interconnect. Instead of Network A paying Network B to carry its traffic across the internet backbone, they can both connect their equipment in the same building and exchange traffic directly. This is faster (fewer hops), cheaper (no transit fees), and more reliable (fewer potential failure points). Major IXPs in cities like London, Frankfurt, Amsterdam, Singapore, and San Francisco handle terabits of traffic per second and are the physical intersections where the internet's separate networks merge into one interconnected whole.

Why Some Connections Are Fast and Others Slow

Internet speed depends on multiple factors at different layers of the stack, and identifying the bottleneck requires understanding which layer is constrained.

For most web pages, the server processing time is the dominant factor, not the network. A complex page that requires multiple database queries might take a second to generate, while the network round-trip is only 30 milliseconds. This is why optimizing server-side code often has a bigger impact on perceived speed than upgrading your internet connection.

However, for bandwidth-intensive activities like video streaming or large file downloads, the physical layer becomes the constraint. A 100 Mbps connection can stream a 4K video comfortably. A 10 Mbps connection cannot, regardless of how fast the server is. The bandwidth of the slowest link in the path determines the maximum throughput.

Common Misconceptions

"The Internet Is a Single Network"

The internet is thousands of separate networks that have agreed to interconnect using IP. Your ISP's network is different from AWS's network, which is different from Google's network. They connect at exchange points using a protocol called BGP (Border Gateway Protocol) that lets them share routing information. If one network decides to stop exchanging traffic with another, traffic between them stops. This has happened multiple times in internet history, and it is why the internet cannot be "shut down" by any single entity.

"Satellite Internet Is Slow Because Satellites Are Far Away"

Radio signals travel at the speed of light. The additional distance to a satellite in geostationary orbit (35,786 km up) adds about 240 milliseconds of round-trip latency compared to a ground-based connection. This is the speed of light traveling to the satellite and back, which is physically unavoidable. Newer low-Earth-orbit satellite constellations like Starlink operate at 500-1,200 km altitude, reducing this latency to 20-50 milliseconds, comparable to ground-based connections.

"5G Is Always Faster Than 4G"

5G can be faster than 4G in ideal conditions, delivering over 1 Gbps to a stationary device. But real-world 5G performance varies enormously based on your distance from the cell tower, the number of users sharing the tower's capacity, the frequency band in use, and obstacles between you and the antenna. In practice, many 5G users see speeds comparable to good 4G connections, while some 4G connections in uncongested areas outperform congested 5G connections.

Where the Internet Is Going

Several trends are reshaping the physical and logical infrastructure of the internet.

Starlink and LEO constellations. Low-Earth-orbit satellite networks are bringing high-speed internet to areas where fiber was never economically viable: rural communities, remote islands, developing regions, ships at sea, and aircraft in flight. These systems reduce the last-mile problem to a radio link from space instead of a cable from the nearest town, fundamentally changing which parts of the world can participate fully in the internet economy.

QUIC and HTTP/3. QUIC is a new transport protocol that runs over UDP instead of TCP, combining TLS encryption with transport features in a single handshake instead of two separate ones. This eliminates the head-of-line blocking problem of HTTP/2 and significantly reduces connection setup time. HTTP/3, which runs on QUIC, is now the default in Chrome, Firefox, and most modern browsers. The transition is mostly transparent to users but represents the most significant change to internet transport since TCP itself.

IPv6 adoption. The IPv4 address space is exhausted. Regional Internet Registries stopped handing out new IPv4 blocks years ago. The transition to IPv6, which provides 340 undecillion addresses, has been slow but is accelerating. As of 2025, roughly 45% of Google's traffic uses IPv6. Many networks run both IPv4 and IPv6 in parallel, a dual-stack configuration that will likely persist for decades.

Content Delivery Networks and edge computing. The trend is pushing computation closer to users. Instead of every request traveling to a centralized data center, more processing happens at edge locations in hundreds of cities worldwide. Cloudflare Workers, AWS Lambda@Edge, and similar platforms run code in locations that may be just a few milliseconds from the user, reducing the physical distance that data must travel.

Final Verdict

The internet works because millions of independently operated networks agree to follow the same set of rules: IP for addressing and routing, TCP for reliable delivery, DNS for name resolution, TLS for encryption, and HTTP for web communication. These protocols are implemented in software running on devices connected by physical cables and radio links. Routers use destination addresses in packet headers to make forwarding decisions, passing each packet one hop closer to its destination.

There is no central authority, no main switch, no single point of control. This decentralization is both the internet's greatest strength and the source of much of its complexity. When everything works, you do not notice any of this. A page loads, a message sends, a video streams. The complexity is invisible by design, which is exactly how good infrastructure should work.

Understanding the physical reality beneath the abstractions does not make you a better programmer or a faster internet user. But it gives you the mental model to diagnose problems, make better architectural decisions, and appreciate a system that most people use every day without understanding at all.

Melalew Mengistu

Web developer and cybersecurity specialist, helping people solve technology problems through practical, accessible guidance.