Wired vs wireless — what Wi-Fi actually changes about the link layer

Back in the very first lesson of this domain, the four-layer model showed each layer only knowing about its own job — HTTP doesn't know or care whether it's running over Wi-Fi or fiber. That's not a simplification; it's exactly why the same web page loads correctly whether you're on Ethernet, Wi-Fi, or a phone's mobile connection. Only the link layer — the very bottom, responsible for getting a frame across one physical hop — is different between wired and wireless. Everything above it (IP, TCP/UDP, HTTP) is completely unaware of the change.

A wired Ethernet connection gives each device its own dedicated physical path to a switch — two devices sending at once simply don't collide, because they're not sharing the same wire. Wi-Fi has no such luxury: every device on the same access point shares one radio frequency. Only one device can transmit on that frequency at a time without the signals colliding and becoming unreadable.

Wi-Fi solves this with CSMA/CA (Carrier-Sense Multiple Access with Collision Avoidance): before transmitting, a device listens to check the channel is clear, and if not, waits a random short delay before trying again — collision avoidance, since actually detecting a collision after the fact (the way old shared Ethernet once did) doesn't work well over radio. This is also the direct, practical reason Wi-Fi tends to slow down as more devices join the same network: they're all taking turns on one shared channel, not each getting their own dedicated bandwidth the way wired devices do.

A wired device is "on the network" the instant its cable is plugged in. A wireless device has to explicitly associate with an access point first — authenticating (a Wi-Fi password) and negotiating a connection — before any IP-layer traffic can flow at all. Once associated, the device typically requests an IP address via DHCP, and from that point on, every mechanism already covered in this domain — ARP for the local network, DNS to resolve a name, a TCP handshake, an HTTP request — proceeds exactly as it would over a wired connection.

A slow or flaky connection that turns out fine over Ethernet almost always points at the link layer specifically — interference, distance from the access point, or too many devices contending for the same shared channel — rather than anything wrong with DNS, TCP, or the application itself. Recognizing "this is a link-layer problem, not a networking-logic problem" narrows a debugging session immediately, and is the natural capstone to everything else in this domain: whichever layer a symptom belongs to is still the fastest way to know where to actually look.