WiFi UDP unicast vs. multicast speed

Solution 1:

Any kind of multicast/broadcast over Wi-Fi is going to be slow because Wi-Fi requires multicasts and broadcasts to be sent at a kind of "lowest common denominator" transmission speed.

UDP has nothing to do with it. The only reason UDP gets mentioned is because UDP is capable of being multicast or broadcast. TCP, in contrast, is strictly point-to-point; it can only be unicast. So it's not a UDP vs. TCP thing, it's a multicast/broadcast vs. unicast thing.

Unicasts of any kind (TCP, UDP, or otherwise) will likely be transmitted over Wi-Fi at much higher rates than multicasts or broadcasts of any kind.

Good 802.11n or 802.11ac implementations can achieve unicast TCP throughputs of 70% or even barely 80% of the PHY rate. Of course, the PHY rates can vary widely depending on what flavors of 802.11n or 802.11ac your APs and clients support, how clean the channel is, the distances involved, etc.

802.11g and earlier don't support frame aggregation and thus aren't as efficient. They usually get a little less than 50% efficiency, or maybe a little more than 50% if they support a vendor-proprietary form of frame pseudo-aggregation ("frame bursting").

In all cases, UDP unicasts can get a few percent higher efficiency than TCP because whereas TCP is designed to go as fast as possible without compounding congestion, UDP-based protocols can try to go as fast as possible even if they make congestion worse. So even a well-implemented, finely-tuned TCP stack may occasionally back off in the face of congestion and packet loss, whereas UDP will blast continuously.

If you have high-quality 802.11n or 802.11ac gear and aren't seeing 70-80% efficiency (that is, TCP-over-IPv4 throughputs of 70-80% of the 802.11 PHY rate that you're getting given your RF conditions), then you probably have a buggy TCP stack or need to do some TCP tuning. TCP window size tuning is the first thing to look at. Consider setting a 2 MiB TCP window size.