How Ethernet Actually Works, Explained From the

A former Microsoft engineer is doing 23-minute Ethernet deep-dives on YouTube in 2024, and the comment section is full of people saying it finally clicked. That's not a story about YouTube. That's a story about how badly networking education has failed people for thirty years.

Dave, of the Dave's Garage channel, opens with a declaration of intent that I find genuinely refreshing: "I don't mean in a buzzword or certification pathway. I mean actual understanding." He then spends the better part of half an hour making good on that promise, tracing a single message — "hello from Dave" — from a socket call all the way down to the physical signal on the wire and back up again. The structure is the argument: understanding comes from following one thing through its complete journey, not from memorizing definitions in isolation.

The video is good. I'll say that plainly. But it's good the way a well-maintained road is good — you don't notice the decades of engineering decisions underneath it. And some of those decisions are worth slowing down for.

The MAC/IP distinction that keeps tripping people up

Dave's most useful contribution is probably the cleanest explanation I've seen of why the MAC address in a frame leaving your computer is almost never the MAC address of the server you're actually talking to. If the destination is on the same local network, the frame goes directly to that machine. If it isn't — if you're talking to something in Frankfurt or Northern Virginia — the destination MAC in that frame belongs to your router, sitting a few feet away. The IP address carries the ultimate destination across continents. Ethernet just answers the more immediate question: who gets it next.

He proves the point with Wireshark captures: local traffic where the destination IP and destination MAC both belong to the same machine, then internet traffic where the destination IP belongs to a remote server but the destination MAC still belongs to the local gateway. It's the kind of before-and-after that makes the abstract concrete.

Before that frame can even be built, though, the machine needs to know which MAC address belongs to the local IP it's targeting. That's the job of ARP — the Address Resolution Protocol. Dave describes it well: a broadcast to the entire local network asking "who has this IP address?", followed by a reply from whoever owns it, followed by the operating system caching that mapping so it doesn't have to ask again immediately. As Dave puts it in the video, ARP is "a small but essential dictionary translating local IPv4 addresses into Ethernet addresses." Without it, you can know exactly where an IP packet needs to go and still be unable to build the local frame to move it one hop further.

Four layers, one packet, and why the nesting matters

The encapsulation model — application data wrapped in a TCP segment, wrapped in an IP packet, wrapped in an Ethernet frame — is not a new explanation. But Dave's framing of it as nested structures, "each belonging to a different layer and each answering a different question," is worth holding onto. The application doesn't need to understand Ethernet. Ethernet doesn't need to understand the English sentence it's carrying. The switch doesn't need to know which process owns the socket. The cable knows nothing at all.

That separation is why the whole thing scales. It's also why "packet" has become a word that technically means three different things depending on which layer you're talking about — TCP segment, IP packet, Ethernet frame — and nobody revokes your networking privileges for conflating them, but the conflation does cost you when something breaks.

The overhead numbers Dave cites are instructive: 15 bytes of application text accompanied by 14 bytes of Ethernet header, 20 bytes of IPv4 header, and at least 20 bytes of TCP header, plus the frame check sequence. That's not waste. It's addresses, port numbers, sequence information, and error detection — the administrative entourage that makes delivery reliable enough to be taken for granted.

The collision history section — and what it actually felt like

Here's where Dave's framing is accurate but slightly too tidy. He explains that early Ethernet placed multiple computers on a shared medium, that collisions were routine, and that CSMA/CD — Carrier Sense Multiple Access with Collision Detection — was the protocol's answer: listen before transmitting, stop and emit a jam signal if you detect a collision, wait a random interval, try again.

The randomness was essential, as Dave notes. Fixed retry intervals would just resynchronize the collisions. So Ethernet used binary exponential backoff — each successive collision doubled the range of possible wait times, making it increasingly unlikely that the same two stations would choose the same moment to retry.

What this explanation doesn't quite convey is how genuinely miserable a hub-based network was under load. A hub repeats every incoming signal to every port. Every device on it shares one collision domain. Put enough traffic on that segment and throughput collapses — not because anything is broken, but because the protocol is doing exactly what it was designed to do, and the design was optimized for sparse traffic on a shared medium. Switches fixed this by learning which MAC address lives on which port and forwarding frames only where they needed to go, giving each connection its own private full-duplex path. The transition from hubs to cheap switches in the late 1990s was one of those infrastructure shifts that felt incremental at the time and was only obviously transformative in retrospect.

The minimum frame size of 64 bytes survives from that era. Dave explains why: a transmitter needed to still be sending when a collision signal from the furthest possible point on the network made it back. Too short a frame, and you might finish transmitting before learning you'd collided, incorrectly assuming success. That constraint is gone in practical terms — modern switched Ethernet barely has collisions to detect — but the format carries the scar.

Dave calls this design elegant, and in a certain light it is. It's also the kind of elegance that took years of real-world failure to arrive at, and which required cheap switches to finally make the collision-avoidance machinery largely ceremonial.

What Wireshark doesn't show you

The section on Wireshark's limitations is, frankly, the part most tutorials skip, and Dave doesn't skip it. The preamble and start frame delimiter — the alternating-bit pattern that lets the receiver lock onto the sender's timing before the actual frame begins, per the IEEE 802.3 spec and confirmed in the video — are invisible in a standard capture. The frame check sequence, a four-byte cyclic redundancy check at the tail end of every frame, is stripped by the network adapter before the operating system ever sees it.

More usefully: Wireshark may report a bad TCP checksum on an outgoing packet that was actually transmitted correctly, because modern adapters compute and append the checksum after the operating system hands the packet off. The capture happens before the hardware finishes its work. As Dave puts it in the video: "A packet capture is not an omniscient recording of networking reality. It's an observation made from one particular vantage point inside the machine."

That's the thing about well-designed systems — they keep their internals to themselves, which is wonderful until you need to debug them and you can't see the relevant parts.

TCP segments, IP fragments, and why the distinction matters

Dave draws a clear line between TCP segmentation and IP fragmentation, and it's a line worth drawing. When TCP sends more data than fits in a single Ethernet frame, it doesn't ask Ethernet to chop up a giant packet — it divides the byte stream into segments sized to fit before they become IP packets at all. On a typical IPv4 Ethernet network with a 1500-byte MTU, TCP subtracts the IP and TCP header overhead and arrives at a maximum segment size of 1460 bytes.

IP fragmentation is the other mechanism, where an oversized IP packet gets split into fragments that travel separately and must be reassembled at the destination — with the caveat that if even one fragment is lost, the whole original packet is generally unrecoverable. On IPv6 networks, routers are prohibited from fragmenting packets at all; that burden falls entirely on the sending host, which is expected to discover the usable path MTU and size its transmissions accordingly.

When you watch a large file transfer in Wireshark, what you're seeing is TCP segmentation: many frames, each carrying one segment, each addressed individually, each validated by the receiver. The application sees none of this. It called send, and the machinery arranged the details.

There's a version of this video's subject — the invisibility of foundational infrastructure — that applies everywhere in computing. DNS is probably the cleaner example: every domain name lookup happening before every connection, the entire system quietly mediating between human-readable names and machine-routable numbers, completely invisible until it isn't. When DNS breaks, it breaks everything, and most people's first instinct is to call their ISP and complain that the internet is down. Ethernet at least has a blinking light. DNS doesn't even give you that.

Dave's garage is doing the work that networking textbooks have historically been too proud to do. Follow one message. Watch what happens. Then tell me the definitions.

Mike Sullivan covers technology for BuzzRAG.