Why Ethernet's trick does not work on the air
Back on the wired LAN rung you met a clean rule for sharing one cable: CSMA/CD, carriers-sense multiple access with collision detection. A station listens before it speaks, and — the clever part — it keeps listening while it speaks. On a wire, your own signal and a colliding signal add up to a voltage that does not look like clean data, so the sender notices the smash within microseconds, stops, and backs off. Detection mid-send is what makes wired Ethernet fast and fair.
On the air this trick collapses for a brutally physical reason you saw in guide 1: the signal a radio receives from far away is fantastically weaker than the signal it is transmitting from its own antenna — easily a million to a billion times weaker. While a Wi-Fi radio is sending, its own outgoing blast deafens its receiver completely. It simply cannot hear a faint colliding signal arriving from across the room, the way an ear next to a fire alarm cannot hear a whisper. So a radio cannot detect a collision while sending. Full stop.
CSMA/CA: listen, wait a random beat, then speak
Since a radio cannot catch a collision in the act, Wi-Fi does the next best thing: it works hard to keep collisions from happening at all. The scheme is CSMA/CA, where the CA stands for collision avoidance. The carrier-sense half is the same as on the wire — listen first, and stay quiet if someone is already talking. The new half is what you do once the channel goes idle.
Here is the heart of it. On a wire, the instant the cable falls silent everyone pounces at once — and detection cleans up the resulting smash. On the air there is no cleanup, so Wi-Fi forbids the pounce. When the channel goes idle, each waiting station does not transmit immediately; it picks a random number of tiny time slots to count down, and only sends when its own private countdown reaches zero. Because the countdowns are random, two stations almost never hit zero on the very same slot, so they take turns instead of colliding. It is a polite room where, after a pause, everyone silently rolls dice and the lowest roll speaks first.
- Sense the channel. If it has been idle for a short fixed gap, you may proceed; if it is busy, wait until it falls quiet.
- Pick a random backoff: choose a count from a window of slots (say 0 to 15) and count it down only while the channel stays idle, freezing the counter whenever someone else talks.
- When your counter hits zero, transmit the frame.
- Wait for an acknowledgment from the receiver. Because the air is lossy, every unicast frame must be explicitly ACKed — silence is treated as failure.
- No ACK? Assume a collision or a fade, double your random backoff window, and try again. Repeated failures back off harder, the same braking instinct as TCP's careful driver.
Notice the acknowledgment. On wired Ethernet there is no link-layer ACK — a frame either collides (and the sender saw it) or arrives. On Wi-Fi the sender is blind to what happened, so the receiver must speak up: a missing ACK is the only way a sender ever learns that its frame was lost, whether to a collision or to the fading and interference you studied last time. This is why Wi-Fi retries at the link layer, hiding many losses long before TCP would ever notice.
The hidden terminal, and the RTS/CTS handshake
Carrier sense has a deep flaw on the air that a wire never has. Picture an access point in the middle, with laptop A on the left and laptop C on the right. A and C are both within range of the access point, but a wall and the distance mean A and C cannot hear each other at all. This is the hidden terminal problem. When A listens before sending, the channel sounds idle — because C is hidden from A — so A transmits. C, equally deaf to A, hears idle too and transmits. Their two signals collide at the access point in the middle, yet neither sender ever had a way to know.
Listening at the sender asks the wrong question. What matters is whether the channel is clear at the receiver, and only the receiver can answer that. So 802.11 offers an optional handshake, RTS/CTS, that lets the receiver clear the floor. Before sending a large frame, A whispers a tiny Request To Send (RTS) to the access point. The access point replies with a Clear To Send (CTS) — and crucially, everyone the access point can reach hears that CTS, including hidden C. The CTS carries a duration, and any station that hears it falls silent for exactly that long.
A -----RTS----> [AP] <----(C is hidden from A) A <----CTS----- [AP] -----CTS----> C (C hears CTS, stays quiet) A -----DATA---> [AP] A <----ACK----- [AP] RTS/CTS are tiny: a collision of two short RTS frames is cheap; a collision of two big DATA frames is what we paid to avoid.
The economics are the point. RTS and CTS frames are tiny, so even if two hidden senders' RTS frames collide, almost no airtime is wasted — and they simply back off and retry. The expensive thing, a full data frame, is only sent once the air is reserved. That said, the handshake adds overhead on every exchange, so real Wi-Fi turns RTS/CTS on only for frames above a size threshold, where the protection is worth the cost. It is an honest trade, not a free win: you spend a little airtime always to save a lot of airtime when hidden terminals would otherwise clash.
The 802.11 architecture: access points, SSIDs, association
Now zoom out from the airtime rules to the shape of a Wi-Fi network. The common setup is infrastructure mode: every device talks to a central access point (AP), and the AP relays frames between the wireless world and the wired network behind it. The AP plays a role you already know from the LAN rung — much like a switch that learns who is where — except its ports are radio channels and its clients keep moving. Devices do not talk laptop-to-laptop here; they all go through the AP, which is exactly why the hidden-terminal cure had the AP send the CTS.
How does your phone find a network to join? Each AP periodically broadcasts a little beacon announcing its SSID — the human-readable network name like "CafeWiFi". Your phone hears the beacons and shows you the list. Picking one starts association: your device exchanges a few management frames with the AP, agrees on parameters and (if secured) authenticates with the password, and the AP records your device as one of its clients. Only after associating may you send ordinary data frames. Think of it as checking in at a front desk before you are allowed to use the building.
There is a second, leaner shape worth knowing. In ad-hoc mode there is no access point at all; devices form a peer group and talk directly to one another. It is handy for a quick laptop-to-laptop link, but without a central coordinator the hidden-terminal problem bites harder and the network does not scale, which is why nearly every home, office, and cafe runs infrastructure mode. A close cousin lives in the very short range: Bluetooth, which uses its own master-and-followers structure and rapid frequency hopping to share the same crowded 2.4 GHz band for keyboards, earbuds, and watches — a different rulebook for a different job.
Why this matters all the way up to TCP
It is tempting to think of all this as low-level radio plumbing, but it leaks upward. Remember from the transport rung that classic TCP reads any packet loss as a sign of congestion and brakes hard — the careful driver slamming the pedal. On Wi-Fi, though, a lost frame is far more often a fade, a burst of interference, or a collision in the air than a sign that some router's queue is full. If those losses reached TCP, it would needlessly slow down on a link that is not actually congested.
The link-layer ACK and retry you saw earlier are partly there to hide exactly this. By retransmitting a dropped frame over the air a few times before giving up, Wi-Fi turns many quick radio losses into a small extra delay, so TCP never sees them as loss at all. It is a deliberate cover-up that mostly helps — but it is also why a weak Wi-Fi signal feels like lag rather than disconnection: under the hood the link is quietly resending, trading latency to mask the bit-error storms from guide 1.
But the cover-up is never perfect, and that crack is the bridge to the rest of this rung. When you walk out of range, when interference spikes, or when you roam between access points, losses and stalls do reach TCP, and the mismatch between wireless reality and TCP's congestion assumptions is the heart of wireless TCP performance — the subject of guide 5. First, though, guides 3 and 4 leave the unlicensed Wi-Fi band behind and step into the licensed world of cellular, where a base station, not a polite room of dice-rollers, schedules who speaks and when.