One recipient, every recipient on the segment, or just the ones who asked to listen — these aren't three flavors of the same idea.
Every packet that leaves a network interface has to answer one question before anything else: who is allowed to receive this? Most traffic answers it the obvious way — one sender talking to exactly one specific receiver, the same way a web browser talks to a single web server. That's unicast, and it's the default mode for the overwhelming majority of network traffic. But two other delivery models exist because "exactly one recipient" isn't always the right answer, and they solve genuinely different problems rather than being variations on a theme. Broadcast reaches every device on the local network segment whether it wants the traffic or not. Multicastreaches only the specific group of devices that asked to be included. Treating multicast as "broadcast with a shorter guest list" is one of the most common mix-ups in networking — and it leads directly to wasted bandwidth, flooded networks, or both.
Unicast addresses a packet to one specific destination IP address. The network delivers exactly one copy to exactly one destination — nothing else on the segment is meant to act on it. Broadcast addresses a packet to a special broadcast address that means "everyone on this segment." Every device on that local network receives and processes it whether it actually needs to or not — this is exactly how ARP requests and DHCP discovery work, because the sender doesn't yet know which specific device holds the answer. Routers deliberately do not forward broadcast traffic onward to other segments, specifically so a flood of broadcasts on one subnet can't swamp an entire larger network. Multicast addresses a packet to a group — not one device, not every device. Receivers explicitly join that group using IGMP (Internet Group Management Protocol), and switches and routers use that membership information to deliver copies only to the ports and segments that actually have a group member, instead of either flooding everywhere or sending a separate unicast copy to every recipient individually.
This is where the difference stops being academic. Say a company is streaming a live all-hands video to 1,000 employees scattered across a large network. The sender doesn't want to reach literally every device on the network (that's broadcast's job), and doesn't want the overhead of a thousand individual connections either. It wants to reach exactly the 1,000 people who tuned in — and nobody else. Here's how each delivery model would actually handle it.
With 1,000 individual unicast streams, the source (and every link close to it) carries 1,000× the traffic of a single stream — the redundancy exists from the very first hop. With multicast, the source sends the data exactly once. Routers and switches that support multicast routing track which of their downstream branches actually lead to a group member, and only duplicate the packet at the point where the network genuinely forks toward multiple subscribers — often deep in the network, close to the viewers themselves, not back at the source. Nobody who didn't join the group ever sees the traffic, and nobody who did join needs their own dedicated copy sent all the way from the source. That's the entire point of having a group-membership model (IGMP) in the first place: it gives the network enough information to replicate selectively instead of either flooding blindly or replicating needlessly.
False, and the two behave nothing alike once you look at who actually receives the traffic. Broadcast reaches literally every device on the local segment whether they want the traffic or not, and it is deliberately blocked from ever crossing into other subnets by routers — it has no concept of "interested" versus "not interested," and no way to travel beyond one local network. Multicast reaches only devices that have explicitly joined a group via IGMP, can be efficiently routed across multiple network segments and routers using dedicated multicast routing protocols, and never burdens a device that has no interest in that traffic with processing it. Broadcast is "everyone gets it, and it can't leave this wire." Multicast is "only subscribers get it, anywhere in the network."They solve different problems and are built on entirely different mechanisms — multicast is not a smaller broadcast, it's a different delivery model altogether.
Explains the three fundamentally different ways a network packet can be addressed to its recipients — unicast to one specific destination, broadcast to every device on the local segment, and multicast to a subscribed group — and why confusing multicast for a smaller version of broadcast leads to real bandwidth and design mistakes.
Unicast addresses a packet to exactly one destination IP address. The network delivers exactly one copy to exactly one destination, and it is the normal mode for the vast majority of network traffic — a web browser requesting a page from a web server, an email client talking to a mail server, an SSH session to a remote host. There is no ambiguity about who should receive it and no other device on the network is expected to act on it.
Broadcast addresses a packet to a special broadcast address meaning "every device on this local network segment." Every device that receives it processes it, regardless of whether it actually needs the information — this is exactly how ARP requests ("who has this IP address?") and DHCP discovery ("is there a DHCP server out there?") work, since the sender does not yet know which specific device holds the answer. Routers deliberately do not forward broadcast traffic from one subnet to another; that boundary exists specifically to keep broadcast traffic confined to its local broadcast domain, so it cannot flood an entire larger network.
Multicast addresses a packet to a specific group of interested receivers — not every device (broadcast) and not just one (unicast). Receivers explicitly join a multicast group using IGMP (Internet Group Management Protocol), and multicast-aware switches and routers use that group membership information to deliver copies only to the segments and ports that actually have a member of the group. This avoids both extremes: flooding every device the way broadcast does, and sending a separate unicast copy to every recipient individually, which wastes bandwidth for something like a live video stream reaching thousands of viewers.
Each model is the right tool for a different delivery problem. Unicast is right when there truly is one recipient. Broadcast is right for local discovery problems where the sender does not yet know who has the answer and the audience is guaranteed to be confined to one segment (ARP, DHCP discovery). Multicast is right for one-to-many delivery to a known, opt-in group that may be spread across multiple network segments — live video/audio streaming, stock ticker feeds, and multicast-based routing protocol updates are classic examples. Reaching for the wrong one — broadcasting something that should have been multicast, or opening 1,000 unicast connections for something that should have been multicast — is a common and expensive network design mistake.
Broadcast reaches every device on the local network segment automatically, with no opt-in and no way to travel past a router. Multicast reaches only devices that have explicitly joined a group via IGMP, and — unlike broadcast — can be routed across multiple subnets by routers running multicast routing protocols. They are built on different mechanisms and solve different problems; multicast is not simply "broadcast to fewer devices."
No. Routers define the boundary of a broadcast domain and deliberately do not forward broadcast traffic from one subnet to another. This is intentional: without that boundary, broadcast traffic generated anywhere could flood an entire routed network instead of staying confined to the segment where it originated.
IGMP (Internet Group Management Protocol) is how a device tells its local network "I want to receive traffic for this multicast group." Switches and routers use IGMP membership reports to build a picture of which ports and segments actually have interested receivers, so they can forward multicast traffic selectively instead of flooding it everywhere or requiring the source to know every recipient individually.
It works, but at a steep cost: the source (and the links nearest to it) must transmit and carry 1,000 identical copies of the same data, using roughly 1,000× the bandwidth of a single stream. Multicast lets the source send the data once; the replication happens inside the network, at the points where it actually branches toward different subscribers, so no link carries more redundant traffic than necessary.
Both are broadcast. A device sending an ARP request does not yet know which device on the segment holds the IP-to-MAC mapping it needs, so it addresses the request to every device on the local segment and waits for the one holding the answer to reply (typically via unicast). DHCP discovery works the same way: a client with no IP address yet has no way to address a specific DHCP server, so it broadcasts a discovery message to the whole segment.
Try our Enterprise IT Networks Studio
More calculators, simulators, and guides for this discipline.