Bits on Wires and Waves: The Physical Layer

How do 1s and 0s actually travel through copper cables, fiber optics, and WiFi? This tutorial demystifies the physical layer of networking - the actual signals that carry your Rails responses across the world. You'll understand what's really happening in those Ethernet cables and WiFi signals.

Physical Layer Electrical Signals Fiber Optics WiFi Radio Waves Binary Encoding Bandwidth Latency by piyushagarwal5050

The Question You Never Asked

Every time someone hits your Rails app, something magical happens. Your server generates HTML, JSON, whatever - and somehow it arrives on someone's phone in Tokyo, a laptop in Berlin, a desktop in São Paulo.

But how?

Not "how does HTTP work" or "how does routing work" - I mean, how does the actual stuff get there? Your response is just data - 1s and 0s. How do those travel through a cable? Through the air? Across an ocean?

This is the physical layer. It's the foundation everything else stands on. And once you see it, you'll never look at an Ethernet cable the same way again.

Let's Start With a Thought Experiment

Imagine you need to send a message to your friend across a field. You have a flashlight. How would you do it?

You'd probably do something like: flashlight ON means 1, flashlight OFF means 0. Flash it in patterns. Your friend watches and decodes.

Congratulations - you just invented digital communication.

That's literally what's happening in every cable and wireless signal. We're just flashing lights (or electrical pulses, or radio waves) really, really fast.

Copper Cables: Electricity as Messenger

The Ethernet cable plugged into your server? It's got copper wires inside. Copper conducts electricity. And here's the trick:

Voltage = Information

  • Higher voltage = 1
  • Lower voltage = 0

(The actual encoding is more sophisticated, but this is the mental model.)

Your network card does this:
```
Data to send: 01001000 01101001 (that's "Hi" in ASCII)

Translates to: low-high-low-low-high-low-low-low low-high-high-low-high-low-low-high
↓ ↓
Electrical pulses racing down the wire at ~2/3 the speed of light
```

The wire doesn't "know" it's carrying a greeting. It's just conducting electrical patterns. The network card on the other end reads the voltage changes and reconstructs the bytes.

The speed limit: Modern Ethernet can pulse billions of times per second. A 1 Gbps connection? That's 1 billion voltage transitions per second. Your "Hi" (16 bits) takes 0.000000016 seconds to transmit.

Fiber Optics: Light as Messenger

Copper has a problem - electrical signals weaken over distance and pick up interference. For long distances (like undersea cables connecting continents), we use light.

Fiber optic cables are thin glass tubes. Inside, a laser pulses:
- Light on = 1
- Light off = 0

The light bounces down the glass tube through total internal reflection (the same physics that makes a swimming pool look shiny from underwater). It can travel hundreds of kilometers with minimal signal loss.

Your Rails response leaving a data center:
┌─────────────────────────────────────────────────────────────┐
│  LASER: on-off-on-on-off-off-on-off...                      │
│         ════════════════════════════▶                       │
│         Light pulses at 186,000 miles/second                │
│         bouncing through glass thinner than a human hair    │
└─────────────────────────────────────────────────────────────┘

When you load a website hosted in another country, your data probably crossed an ocean through one of these:

Undersea Fiber Optic Cables (simplified):

  🌎 ─────────────═══════════════════════───────────── 🌍
     California                                    London

  That ═══ is a bundle of glass fibers on the ocean floor.
  Your HTTP response literally travels as pulses of light
  through glass tubes under the Atlantic.

There are about 400 of these cables crisscrossing the world's oceans right now. They carry 99% of intercontinental internet traffic.

WiFi: Invisible Flashlights

No wires? No problem. We use radio waves.

Your WiFi router is essentially a very fast, invisible flashlight broadcasting in all directions. It oscillates electromagnetic waves at specific frequencies (usually 2.4 GHz or 5 GHz).

What 2.4 GHz means:
The wave oscillates 2,400,000,000 times per second.

          /\    /\    /\    /\
         /  \  /  \  /  \  /  \    ← This pattern, 2.4 billion times/sec
        /    \/    \/    \/    \

To encode 1s and 0s, we modify properties of this wave:
- Change the height (amplitude): bigger wave = 1, smaller = 0
- Change the timing (phase): shifted wave = 1, unshifted = 0

- Change the frequency: slightly faster = 1, slightly slower = 0

Modern WiFi uses all of these simultaneously to pack more data into each transmission.

Your phone's WiFi chip is essentially doing this:
1. Receive electromagnetic waves from the router
2. Decode the wave modifications back into 1s and 0s
3. Hand those bytes up to the next layer

The "air" between your phone and router is carrying your Rails response as invisible light.

The Speed of Everything

Here's what blows my mind. When you click a link:

Medium What Carries Data Speed
Copper (Ethernet) Electrical pulses ~200,000 km/s
Fiber Optic Light pulses ~200,000 km/s
WiFi Radio waves 300,000 km/s

These are all significant fractions of the speed of light. Your request to a server in London (let's say 8,000 km away) takes about 40 milliseconds just for the signal to get there - and that's mostly because it bounces through multiple routers and switches, not because light is slow.

This is latency - the time it takes for a signal to travel. No matter how much bandwidth you have, you can't beat physics.

Bandwidth vs Latency: The Highway Analogy

These two concepts confuse people, so let's nail them down:

Bandwidth = How wide is the highway?
- More lanes = more cars at once = more data per second
- Measured in bits per second (Mbps, Gbps)
- Your "100 Mbps connection" means 100 million bits can flow per second

Latency = How long is the highway?
- Distance from A to B = time to arrive
- Measured in milliseconds (ms)
- A request to a nearby server: ~10ms. To another continent: ~100-200ms

Here's the thing: you can't improve latency by adding bandwidth.

Scenario: Sending 1 bit to a server 1000km away

With 1 Mbps:   ──────●─────────────────▶  Arrives in ~5ms (speed of light)
With 1 Gbps:   ──────●─────────────────▶  Arrives in ~5ms (still speed of light!)

The bit doesn't go faster. You can just send MORE bits simultaneously.

This is why your Action Cable WebSocket connections care so much about proximity. Real-time features need low latency - and the only way to get that is being physically closer to your users.

Connecting Back to Your World

Remember Action Cable? When you broadcast a message to a channel:

ActionCable.server.broadcast("chat_#{room.id}", message: "Hello!")

Here's what happens at the physical layer:

  1. Server → Ethernet cable: Your server's network card converts "Hello!" to electrical pulses
  2. Data center switch: Pulses hit a switch, get routed to the right outbound cable
  3. Fiber backbone: Converted to light pulses, shot across fiber optic cables
  4. User's ISP: Light converted back to electricity, routed to their neighborhood
  5. WiFi router: Converted to radio waves, broadcast into the air
  6. Phone's WiFi chip: Radio waves decoded back to bytes
  7. Browser: "Hello!" appears on screen

Your five-character string traveled as electricity → light → radio waves → and back to bytes. Across potentially thousands of kilometers. In under 100 milliseconds.

That's the physical layer. Everything else - TCP, HTTP, WebSockets, Rails - is just agreeing on what patterns of 1s and 0s mean.

The Mental Model to Keep

┌─────────────────────────────────────────────────────────────┐
│  YOUR RAILS APP                                             │
│  render json: { status: "ok" }                              │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼ (bytes)
┌─────────────────────────────────────────────────────────────┐
│  PHYSICAL LAYER                                             │
│                                                             │
│  Copper:  ⚡ voltage pulses in wires                         │
│  Fiber:   💡 light pulses in glass                          │
│  WiFi:    📡 radio waves in air                             │
│                                                             │
│  All just different ways to represent 1s and 0s            │
└─────────────────────────────────────────────────────────────┘

Challenge: Trace Your Own Request

Next time you load your app:

  1. Open DevTools → Network tab
  2. Look at the "Time" column for any request
  3. That time includes: physical transmission (speed of light), processing (server), and everything in between

Try hitting a server in a different country. Notice how latency jumps by 50-200ms? That's literally the time it takes light to cross an ocean and come back.

You can't code your way around physics. But now you understand the physics.

Next up: We've got 1s and 0s moving through wires and air. But how does your data find its way across a network of billions of devices? That's where IP addresses and packets come in - the internet's postal system.

Questions & Answers

Q&A

Q: How many messages can a wire carry simultaneously?

At the most fundamental level, a single wire carries one sequence of electrical pulses at a time. You can't send two separate pulse trains down the same conductor simultaneously—they'd interfere.

However, there are clever techniques:
- Time-division multiplexing: Interleave bits from different messages rapidly, so all appear to transmit "simultaneously"
- Multiple wire pairs: Gigabit Ethernet uses all 4 pairs in an Ethernet cable simultaneously

Short answer: one wire, one bitstream—but we parallelize with multiple wires and interleave with time-division.

Q: How is one message's pulse distinguished from another?

The physical layer doesn't distinguish messages at all—it's just a dumb pipe of bits.

The distinction happens one layer up—the data link layer (Ethernet). Each message gets wrapped in a "frame" with:
- Preamble: Bit pattern saying "a new frame is starting"
- MAC addresses: Who sent it, who it's for
- CRC checksum: Error detection

At the physical layer, it's one long stream of bits. Structure and meaning come from higher layers.

Q: What's the difference between bandwidth and transmission rate? Between latency and propagation delay?

Bandwidth ≈ Transmission Rate (with nuance)

Historically, bandwidth meant the range of frequencies a medium can carry (measured in Hz). Over time, it colloquially evolved to mean "data capacity"—so "100 Mbps bandwidth" means transmission rate. In practice, people use them interchangeably.

Latency ≠ Propagation Delay (latency is broader)

Latency is the total time from "I sent this" to "they received it." It's composed of four delays:

Total Latency = Propagation + Transmission + Processing + Queuing

1. PROPAGATION DELAY
   Signal traveling through the medium (speed of light)
   Fixed by physics: distance ÷ signal speed

2. TRANSMISSION DELAY
   Time to push all bits onto the wire
   = packet size ÷ transmission rate

3. PROCESSING DELAY
   Routers/switches examining headers, making decisions

4. QUEUING DELAY
   Waiting in buffers behind other packets
   Highly variable—this is what makes latency "spiky" under load

Propagation delay is one component. "Latency" means the whole sum.

Q: The bandwidth vs latency example—can you clarify with a larger payload?

Scenario: Sending 2 Gb to a server 1000 km away

At 1 Gbps bandwidth:
  Transmission time: 2 Gb ÷ 1 Gbps = 2 seconds
  Propagation delay: 1000 km ÷ 200,000 km/s = 5 ms
  Total: 2.005 seconds

At 1 Mbps bandwidth:
  Transmission time: 2 Gb ÷ 1 Mbps = 2000 seconds
  Propagation delay: 5 ms (same physics)
  Total: 2000.005 seconds

The first bit arrives after 5ms. The last bit arrives after (transmission time + 5ms). Bandwidth affects how long you spend pushing bits onto the wire. Distance affects how long each bit takes to travel. They're independent.

What if there's a bottleneck in the middle?

Source (1 Gbps) → Backbone → Dest ISP Edge → Dest Server (500 Mbps)

The times overlap, not add sequentially. The destination ISP edge starts forwarding immediately as bits arrive, but can only send at 500 Mbps. Data queues up:

t=0        Source starts sending
t=5ms      First bit arrives at dest ISP edge, forwarding begins
t=2.005s   Last bit arrives at dest ISP edge (source done)
           But only 1 Gb forwarded so far, 1 Gb still in buffer
t=4.005s   Buffer drained, last bit reaches dest server

Total: ~4.005 seconds

The formula: End-to-end time = (Data size ÷ Bottleneck bandwidth) + Propagation delay

The bottleneck bandwidth is the narrowest pipe in the path. Everything else can be faster, but data flows only as fast as the slowest link.

Q: Does the backbone have a limit?

Yes. A major backbone route might carry tens to hundreds of Tbps—but this is shared by millions of users simultaneously.

When backbone is the bottleneck (congestion):
- Queuing delay increases (packets wait in router buffers)
- Packet loss occurs (buffers overflow, packets dropped)
- Everyone sharing that link slows down

Why backbone congestion is rare but real:
- ISPs overprovision (keep links under 50-70% utilization)
- But: submarine cable cuts, major events, DDoS attacks, peak hours can saturate links

Usually your last-mile connection is the bottleneck. Sometimes the backbone. Rarely the server itself. The end-to-end speed is always determined by the narrowest pipe at that moment.

Q: Undersea cables? Isn't air (satellites) used? How deep? Who controls them?

Why cables over satellites:
- Geostationary satellites (35,786 km up): ~240ms minimum latency
- Transatlantic cable: ~30ms latency
- Modern undersea cables carry 200+ Tbps—satellites can't compete

The cables:
- Depth: 4-8km in deep ocean, buried in trenches near coasts
- Diameter: Garden hose width deep-sea, thicker near shore for armor
- Length: Thousands of kilometers (MAREA cable: 6,600 km Virginia→Spain)

Who controls them:
- Historically: Telecom consortiums
- Increasingly: Big tech (Google owns/co-owns 16+ cables; Meta, Microsoft, Amazon too)
- Installation by specialized cable ships; takes years of planning, $200-300M+

When cables break (sharks, earthquakes, anchors), repair ships grapple them from the seafloor, splice, and re-lay—can take weeks.

Q: Doesn't encoding/decoding at each step consume significant time?

Yes, but dedicated hardware (ASICs) makes it shockingly fast:
- NIC encoding/decoding: tens of nanoseconds
- Switch forwarding: 1-5 microseconds
- Router processing: 10-100 microseconds

10-20 hops might add 1 millisecond total processing overhead. Compare to 40ms propagation delay crossing an ocean—processing is relatively small.

The bottleneck is almost always propagation delay (speed of light) and queuing delay (waiting behind other packets), not encoding/decoding.

Q: Why on/off for fiber but wave-property-modification for WiFi, if both are electromagnetic?

The environment is radically different:

Fiber: Controlled, shielded (light trapped in glass), no interference, point-to-point. Signal stays clean → simple on/off works.

Radio: Open air shared by everyone, constant interference, multipath (bouncing off walls). Signal degrades unpredictably → needs robust encoding.

Simple on/off in radio would be fragile. Instead:
- Phase-shift keying: Detect wave shift patterns, not just presence/absence
- Multi-carrier (OFDM): Split across many frequencies; if one gets interference, others survive
- Error correction: Redundant bits to reconstruct corrupted data

Analogy: Fiber = talking in a soundproof room (simple yes/no works). Radio = shouting across a crowded party (need repetition, patterns, context clues).