UDP广播/多播与单播行为（丢弃的数据包）

我有一个嵌入式设备（源），它通过UDP数据包以20ms（=大约330字节）的方式发送（音频）数据流。因此，网络容量相当低，约为16kBps（由于UDP/IP开销，实际容量稍高）。设备正在运行lwIP堆栈（v1.3.2），并使用H&D Wireless（HDG104，WiFi G模式）的WiFi解决方案连接到WiFi网络。目的地（接收器）是一台Windows Vista PC，它也使用USB WiFi加密狗（WiFi G模式）连接到WiFi网络。电脑上正在运行一个程序，允许我监视丢弃的数据包的数量。我还运行Wireshark来直接分析网络流量。此时，没有其他客户端通过网络主动发送数据

当我使用广播或多播发送数据时，许多数据包被丢弃，有时高达15%。但是，当我切换到使用UDP单播时，丢弃的数据包数量可以忽略不计（<2%）

使用UDP，我希望数据包被丢弃（这在我的音频应用程序中是可以的），但是为什么我看到广播/多播和单播在性能上有如此大的差异呢

---

我的路由器是WRT54GS（FW v7.50.2），PC（接收器）使用trendnet TEW-648UB网络适配器，在WiFi G模式下运行。

这似乎是一个众所周知的WiFi问题：

引自

802.11（Wi-Fi）标准规定支持作为异步服务一部分的多播。802.11客户端站，例如无线膝上型计算机或PDA（不是接入点），通过在802.11单播数据帧中发送仅指向接入点的多播分组来开始多播传送。如果在数据帧中未发现错误，则接入点以发送到源站的802.11确认帧进行响应

如果发送帧的客户端没有收到确认，则客户端将重新传输帧。对于多播，从无线客户端到接入点的数据路径的分支包括传输错误恢复。当使用单播数据帧传输时，802.11协议确保基础设施和特殊配置中站点之间的可靠性

在从客户端接收到单播数据帧之后，接入点将数据（发起客户端想要多播的数据）作为多播帧发送，该多播帧包含作为预期接收者的目的地的组地址。每个目的站都可以接收帧；然而，他们并没有做出回应因此，多播无法确保完整、可靠的数据流

缺少多播确认意味着应用程序发送的某些数据可能无法到达所有目的地，并且没有成功接收的迹象。不过，对于某些应用程序来说，这可能没什么问题，尤其是那些数据存在缺口的应用程序。例如，来自控制阀监视器的连续遥测流可能会不时错过状态更新

本文提供了更多信息：

---

多播实现（在WiFi MAC层）的一个非常有趣的副作用是，只要您的接收器是有线的，您就不会遇到任何问题（由于接收器端的确认，这实际上是单播连接）。但是，对于WiFi接收器（如我的情况），数据包丢失是巨大的，对于音频来说是完全不可接受的。

多播没有ack数据包，因此不会重新传输丢失的数据包。这是非常有意义的，因为有许多接收器，它们不可能都同时应答（空气就像同轴以太网一样共享）。如果他们都使用某种退避方案按顺序发送ack，这将占用您所有的带宽

---

丢包的UDP流是一个众所周知的挑战，通常使用某种类型的前向纠错来解决。最近，一类称为喷泉码（fountain codes）的代码，如Raptor-Q，显示了解决数据包丢失问题的前景，特别是当同时存在多个不可靠的数据源时。（例如：覆盖一个区域的多个wifi接入点）

感谢您的添加，这非常有趣。我们考虑了前向纠错，但我没有研究Raptor-Q。一个问题是，对于我的应用程序，允许的延迟小于300ms。大多数情况下，当出现问题时，您会收到一系列丢失的数据包，这使得纠错变得困难。我们的解决方案非常简单：大多数专业接入点都支持从多播到单播的转换功能。您仍然会丢失一些数据包，但不会丢失那么多。