Introduction: Three delivery semantics
At the IP layer, hosts and routers treat packets differently depending on whether the destination identifies one receiver, a group, or everyone on a link. Those semantics are unicast, multicast, and broadcast respectively. Choosing the wrong mode wastes bandwidth (unicast fan-out), breaks scalability (broadcast storms), or fails across routed boundaries (L2 broadcast does not traverse routers).
Unicast (one-to-one)
Unicast sends an IP datagram to a single destination address (for example 192.0.2.10 or a specific global unicast IPv6). Each additional recipient requires its own packet stream and usually its own transport connection state. CDNs, HTTPS APIs, and videoconferencing backchannels are predominantly unicast because the payload or entitlement is per-user.
Scaling cost: N viewers pulling the same 8 Mb/s stream as unicast implies N × 8 Mb/s on the server egress and core—fine for small audiences, expensive at stadium scale.
Multicast (one-to-interested-many)
IPv4 multicast uses addresses in 224.0.0.0/4; receivers join groups with IGMP on LANs and PIM-SM/MSDP or vendor equivalents in the routed core. Only links with active listeners should receive copies—switches use IGMP snooping to prune flooding. Multicast is ideal for IPTV, market data feeds, and OS imaging when the network is engineered for it.
Operational reality: The public internet does not guarantee end-to-end multicast; providers often filter PIM. Multicast is primarily a controlled-domain technology (enterprise, ISP managed TV, data center fabrics). See IGMP mechanics and multicast addressing.
Broadcast (one-to-everyone on the segment)
IPv4 directed broadcast to a subnet’s all-hosts address was historically used for discovery; modern routers disable directed broadcast forwarding by default because it amplifies reflection attacks. Ethernet broadcast frames (destination FF:FF:FF:FF:FF:FF) stay on one VLAN; ARP uses broadcast-like behavior at L2. Wi-Fi often converts multicast/broadcast to unicast at reduced rates (DTIM trade-offs), which is why multicast feels “slow” on wireless.
Side-by-side comparison
| Aspect | Unicast | Multicast | Broadcast |
|---|---|---|---|
| Addressing | One unique host | Group ID (224/4) | All nodes on L2 segment |
| State | Per-flow on routers | Join/prune trees | None beyond L2 flood |
| Cross-router | Always | If PIM/RP engineered | Not for L2 broadcast |
| Wi-Fi behavior | Efficient | Often throttled | Expensive airtime |
Choosing a mode
Use unicast when payloads differ per user or when crossing the public internet without multicast contracts. Use multicast when many receivers need identical frames on infrastructure you control. Reserve broadcast-style discovery for local segments (DHCP, ARP, mDNS) and keep rates low to avoid storms.
Check your current public IP after changing streaming or VPN paths—egress changes can alter which delivery modes are available through your ISP.