UDP广播/组播 vs 单播行为（丢包）

Question

UDP广播/组播 vs 单播行为（丢包）

9

我有一个嵌入式设备（源），它通过UDP数据包以20毫秒（约330字节）的块发送音频数据流。由于UDP/IP开销，网络容量为大约16kBps（实际上略高）。该设备运行lwIP堆栈（v1.3.2），使用H&D Wireless的WiFi解决方案（HDG104，WiFi G-mode）连接到WiFi网络。目标（接收器）是一台安装Windows Vista的PC，也使用USB WiFi dongle（WiFi G-mode）连接到WiFi网络。我正在运行一个程序来监视丢失的数据包数量。同时，我还在运行Wireshark直接分析网络流量。此时没有其他客户端主动通过网络发送数据。

当我使用广播或组播发送数据时，会丢失许多数据包，有时高达15%。然而，当我切换到使用UDP单播时，数据包丢失的数量微不足道（＜2%）。

我期望使用UDP时可能会丢失数据包（对于我的音频应用程序来说这是可以接受的），但是为什么广播/组播和单播之间的性能差异如此之大？

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

- djbuijs

2个回答

1

Multicast没有确认数据包，所以不会重传丢失的数据包。这很有道理，因为有许多接收者，它们不能同时回复（空气就像同轴以太网一样共享）。如果它们都使用某种退避方案按顺序发送确认，那么会占用所有带宽。

UDP流媒体在数据包丢失时是一个众所周知的挑战，通常使用某种前向纠错方式来解决。最近出现了一类称为喷泉码（如Raptor-Q）的编码，特别适用于数据来源同时存在多个不可靠的情况下的数据包丢失问题。（例如：覆盖区域的多个WiFi接入点）

- Bjarne Vinkelhake

谢谢你的补充，非常有趣。我们曾考虑前向纠错，但我还没有看过Raptor-Q。问题之一是对于我的应用程序，允许的延迟时间小于300毫秒。大多数情况下，当出现问题时，您会得到一串丢失的数据包，这使得纠错变得困难。对我们来说，解决方案变得相当简单：大多数专业接入点都支持组播到单播转换的功能。您仍会丢失一些数据包，但不会像以前那样频繁。 - djbuijs

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- djbuijs · Accepted Answer

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

引用自http://www.wi-fiplanet.com/tutorials/article.php/3433451 802.11（Wi-Fi）标准指定支持多播作为异步服务的一部分。例如，无线笔记本电脑或PDA（而不是接入点）等802.11客户端站通过在仅针对接入点的802.11单播数据帧中发送多播数据包来开始多播传递。如果数据帧中没有发现错误，则接入点会向源站发送802.11确认帧。如果发送帧的客户端没有收到确认，则会重新发送该帧。使用多播时，从无线客户端到接入点的数据路径包括传输错误恢复。当使用单播数据帧传输时，802.11协议确保基础架构和自组网配置之间的稳定性。接入点从客户端接收单播数据帧后，将数据（源客户端想要进行多播的数据）作为多播帧进行传输，其中包含一个群组地址作为预期接收者的目的地。每个目标站都可以接收该帧；但是，它们不会用确认做出响应。因此，多播不能确保完整，可靠的数据流。多播缺少确认意味着应用程序发送的某些数据可能无法到达所有目标位置，并且没有成功接收的指示。然而，这对于一些应用程序来说可能是可以的，特别是其中数据中断的情况下也可以接受的应用程序，例如控制阀监视器的持续遥测流可能会错过状态更新。

这篇文章有更多的信息： http://hal.archives-ouvertes.fr/docs/00/08/44/57/PDF/RR-5947.pdf 多播实现（在WiFi MAC层）的一个非常有趣的副作用是，只要你的接收器是有线的，你就不会遇到任何问题（由于接收器端的确认，这实际上是一个单播连接）。但是，在WiFi接收器（如我的情况）中，数据包丢失很大，对于音频来说完全无法接受。