这是一个创建于 2686 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司有个这样的需求，想将一个文件尽快的分发给各个手机，所以我自然有想到通过 Udp 来一对多广播分发文件。但是广播的测试结果好像不太令人满意，下面是我的测试结果：
测试的环境：
2.4GHz 的 TP-Link TL-WVR1200, 发送端和接收端都是 Windows，Udp 发送的代码是 Java 写的。
这里我将一个 40M 的文件拆分 4000 左右个 10K 的包，然后依次发送过去。
发送端通过网线接入路由器， 接收端通过无线网卡接入。
测试 1. 更改发送包的时间间隔
修改发送端的每次发送一个 10K 包之间的时间间隔：
间隔 3ms 之后，单播基本就不丢包了，但是广播会很好的收取大概 100 多个包之后就卡住不动了，之后偶尔收到几个，然后就再也没有了。这里是不是路由器在广播这方面有限制？
测试 2. 更改发送端接入方式
这里都采取发送端发送间隔 5ms 进行。
这里我只是将开始的发送端的有线接入改成无线接入，但是发送的单播丢包率猛增。 广播我就不奢望什么了。
请问各位大佬，路由器 UDP 广播有什么可以设置的吗？还是要刷什么固件之类的？ 甚至需要定制吗？
ps. 不清楚具体节点应该放哪里.. 如果放错了，希望管理帮我移到合适的节点把 :)
 |
1
Duluku OP 不过 Udp 单播的效果的确比我平常想象的好啊很多，我把发送包的大小从 10KB 提高到 50KB，包的时间间隔为 5ms，基本上都发过去了，丢包率低于 1%， 但是广播简直没法看。
|
 |
2
rrfeng 2017-06-29 16:27:28 +08:00  1
无线信道很拥挤的，从这方面入手查一下。
|
|
3
Duluku OP @rrfeng 是的，我查过信道，2.4GHz 的信道的确拥挤，不过这里我关注的重点是单播和广播的差距非常大，单播基本上可以说是不丢包，这个差别令我比较在意。（也是因为手里没有 5G 的无线设备，拿到设备马上测试更新这个帖子）
|
 |
4
hjc4869 2017-06-29 16:34:54 +08:00
一般先用广播发现设备，然后再用单播去发文件或者大量数据。
广播一般也就那么一两个包 |
|
5
rrfeng 2017-06-29 16:37:23 +08:00
自始至终只有一个接收端吗？
|
|
6
Duluku OP @hjc4869 不能使用广播做文件分发吗？ 虽然会丢包，但是只要丢包率低于 30%，发送端多广播几次应该基本能做到很好的分发效率吧？
不过的确这个想法感觉比较胡来，网上也没查到相关的方法... |
|
8
hjc4869 2017-06-29 16:44:21 +08:00
另外你的包太大了，目测 UDP 被分片了，加剧了丢包
|
|
9
Duluku OP @hjc4869 好的，我现在去试试将包变小点，不过大概多少合适呢，5KB ？ 太小了我觉得广播的带宽就太差了，现在每个包间隔 5ms 时，广播的数据每秒不到 2MB，我觉得已经很小了，再降低单个包的大小，可能还不如 TCP 一个一个发过去呢。。
|
|
10
hjc4869 2017-06-29 16:53:39 +08:00
@Duluku UDP 传输大量数据时整个 IP 包的大小不要超过 MTU，通常也就是 1472 （ MTU 1500 字节减去 20 字节 IP 头部和 8 字节的 UDP 头部）
|
|
11
hjc4869 2017-06-29 16:55:22 +08:00 1
传输大量数据需要做流量控制和拥塞控制，不是每个包间隔 5ms 这么 simple 的，建议还是用 UDP 发现设备，TCP 连接+传输数据。
|
) |
13
Duluku OP @hjc4869 不过总是让我在意的是这个 UDP 单播的效果，UDP 单播在 5ms 的发送间隔能过做到不丢包，但是广播就丢这么多，我怎么都觉得有点不理解。。
|
 |
14
lan894734188 2017-06-29 17:09:32 +08:00 via Android
还是 tcp 吧
|
|
17
Duluku OP @hjc4869 这个我觉得很有可能，在广播的时候，接收端最开始接收包我看起来挺好的，不过接收到 100 个左右的时候，突然就卡住不再接受得到数据了。 我在路由器的 web 设置界面找找，不过感觉很有可能没有...
|
 |
18
xfspace 2017-06-29 18:12:14 +08:00 via Android 2
无线是半双工...用了 CSMA/CA，你还要用广播发文件...
无线接入点的价格和终端数量及环境干扰都会影响到无线网络传输 |
 |
19
dndx 2017-06-29 18:26:30 +08:00 via iPad 7
楼上的都没说到点子上。
最主要的问题是大多数无限适配器，广播的时候速率都会强制限制在 1Mbps，因为只有这个是所有连接的客户端都必须要支持的速率，当然丢包率会很高了。无线网络的广播因为这个基本就是个笑话。 参考： https://networkengineering.stackexchange.com/questions/1782/why-does-my-udp-broadcast-wireless-communication-is-capped-at-1mbs/ |
 |
21
chinawrj 2017-06-29 19:02:18 +08:00 via Android
组播使用的是广播，11n 最大可以到 72m。详细可以联系我
|
|
24
chinawrj 2017-06-30 08:41:25 +08:00 3
@dndx
@Duluku 802.11 只有 unicast 和 broadcast。UDP 广播以及组播在实际传输上，根据设置的不同，可以被操作系统自动转换成 unicast 和 broadcast。转成 unicast 的好处很明显： 1. 可以使用 multi stream。即多个空间流传输，能够达到无线的标称速率比如：433Mbps/866Mbps 2. 可靠性比 broadcast 高，因为每一个包对会有物理层的 ACK。 3. 可以使用 802.11n 之后的高级特性，比如 A-MPDU，A-MSDU 等。 缺点也很明显，有多个 client 的时候，每个都要这样传输一遍，很占空域时间。实际上 OpenWrt 等路由器的默认广播 /组播就是用 unicast 发送的,要想修改可以参考如下： https://wiki.openwrt.org/doc/howto/udp_multicast。 使用 multcast 发送的好处如下： 1. 路由器端对于任何一个组播或者广播包只需要发送一次 坏处： 1. 没有 ACK，容易丢包 2. 不能使用 802.11n 的高级特性。比如 A-MPDU、A-MSDU。 3. 为了保证所有的 client 都能接收到，采用了信噪比比较高的 MCS，这个时候速率可能只有 1Mbps。 我之前在芯片厂商做个 Wi-Fi 芯片固件和驱动，也支持过客户做过视频 /文件的可靠 /不可靠分发。当时的情况是一个路由器至少带 60 个人。有什么问题，可以咨询一下我。PS：打很多字太累。。。 |
|
26
Duluku OP @chinawrj 您好，我今天经过一些测试和思考，有了些想法，但是还是碰到一些问题，诚惶诚恐还是想继续问您..
1. 我使用这个 TP-Link TL-WVR1200 的路由器。多播的代码使用的是 [java.net.MulticastSocket Example]( https://examples.javacodegeeks.com/core-java/net/multicastsocket-net/java-net-multicastsocket-example/) ，在两个电脑都通过有线接入路由器的时候，多播成功，接收端能够接收到数据。但是我测试将发送端切换为无线，或者将接收端换为无线，多播就失败了，这是路由器的原因吗？ 在 TP-Link 的路由器 Web 设置页面并没有看到关于多播的有关设置，是需要使用 OpenWRT 的路由器吗? 2. Udp 广播破除 1Mbps 的限制的概率大吗？也许公司可以去定制路由器，但是最终想法是给手机分发，手机定制的概率就很低了，这种 1Mbps 的限制有没有可能提升呢？ 3.有没有可能 Udp 单播给某个设备，其他设备监听这个网络从而获取数据呢？ （这个脑洞可能有点大，实施起来可能比较难，但是理论上似乎可行），你怎么看？ 再次表示感谢！ |
|
27
chinawrj 2017-06-30 18:34:01 +08:00 1
1. TP-LINK 路由器可能没有这种配置，你需要一个 OpenWrt 路由器。另外真的要调试 Wi-Fi 网络的话，弄个 macbook，装上 wireshark 和 airtools 就可以抓包了(抓 802.11 包，不是以太网包)。组播地址和 MAC 地址有一种映射关系，你也可以在 wireshark 中过滤。
２. 我记得最大可以到 72Mbps，有的路由器是可以设置的。但并不是所有的都可以。如果要给出一个可以设置的路由的话，我记得刷 tomato 路由的 broadcomm 方案是可以的。另外当时我们公司自己的 88W8864 是可以设置的。你的无线端发送失败有可能是路由器那边限制了，具体那种限制不清楚。你可以用 mtk/broadcomm/qualcomm/marvell 的方案都试试。 3. 理论上可行。实际上需要你的手机支持 wifi monitor 模式，然后其他手机抓到握手包（发给单播接收数据的手机的包，并且不能使用多个空间流等高级特性），然后再根据握手包和路由器无线密码算出 PTK 来解密。不过 monitor 模式依赖于系统和 wifi 驱动 /固件，如果你的手机系统不是自己编译出来，并且 wifi 模块支持 monitor 的话，还是不要尝试了。不能控制用户手机端的情况下，这种方案肯定是不可行的。 不知道你做的具体项目，但是如果你要做文件分发的话。我可以提供一个 case 供你参考：曾经我们的客户就是用最高速率的 multcast 来发送 720P 的视频流和文件。应用场景是电子教室。总共５０－６０部手机，可以获得约每个手机 500KBytes 的速率（也许还能提高，但是当时的场景大概就是需要这么高的速率）。 如果不定制路由，我觉得你可以发送数据的时候不要一起发送，错开发送就好。这样可以有效利用空中带宽。毕竟上了 802.11ac 的路由器，单播最低实测也可以到 200Mbps。一起发送，无线干扰会很严重，会有很多空域的无线退避，导致贷款利用效率下降。 在发送协议上，可以使用 UDP，然后自己控制发送时采用的速率以及纠错功能。毕竟 TCP 的参数不太好调，而且好多系统不给权限调。 |
|
28
chinawrj 2017-06-30 18:36:20 +08:00 1
@Duluku
忘记 @了，不太清楚你的具体应用场景。有问题可以再问。也许能帮上。你的组播测试失败的话，建议换个普通路由器试试吧。有的路由还开启了无线隔离，甚至连无线客户端相互访问都不可以 。 |
|
29
Duluku OP @chinawrj 非常感谢！应用场景还真就是文件分发，大概接收端设备在 40 台左右手机，发送端希望也是移动端，安卓平板之类的，空间也不算太大，类似于一个教室把，但是这个方案能不能做出来我这边还在尝试。如果能能做视频流也是很好的，如果技术做出来了，上面估计也能弄出需求出来 (哭笑) 。。我试试看继续做再回复您把！ 厉害厉害！
|
 |
30
huangmiao233 2017-07-01 17:31:11 +08:00
用组播。。
|
 |
31
goodryb 2017-07-06 13:28:43 +08:00
公司有个这样的需求，想将一个文件尽快的分发给各个手机
一定要用软件吗，一个 ftp 是不是就能解决这个问题  |
|
32
Duluku OP 1
@chinawrj 搞来一个 Linksys WRT1200AC， 刷上 OpenWRT，无线组播是能收到了（不刷 OpenWRT 也无法通过无线发送组播），不过现在的组播的效果比较差，丢包率依然很高，85%以上... 有点懵逼。。 现在这个路由我特意是找的 88W8864，不过怎么上调 Udp 广播的带宽到 72Mbps 呢？ 最近尝试把广播发送的时间间隔改到 20ms 左右的时候，广播那边的丢包率倒也不高（很奇怪），大概速度在 500KB 左右。。感觉很多东西都很迷茫。。。
|
|
34
chinawrj 2017-07-06 22:01:04 +08:00 via Android 1
@Duluku 忘了怎么设置了。回头我找找。找个 Mac book 抓包 802.11 ，802.11 头部直接有速率的
|
|
35
Duluku OP @chinawrj 我用抓到广播了  ) 的确显示的是 1Mpbs，不过接下来就完全不知道怎么继续下去了... 继续尝试组播的丢包把，不知道为什么丢包那么惨... |
|
36
Duluku OP @chinawrj 你好，公司打算有偿的方式做出这个问题，能给一个联系方式吗，或者联系我 MjY3MTM2NTY1MkBxcS5jb20=
|
 |
41
heiher 2017-11-16 10:03:57 +08:00
@chinawrj 无线实时视频组播，使用了 Raptor 算法做 FEC，使用普通的 TP-LINK 天线路由实测下来链路质量实在太差，空口抓包组拆走的 802.11b/11Mbps，关闭 FEC 看接收状态图基本不能用。前辈有没有性能比较好的 AP 设备推荐呢？可以调控速率、组转单模式等等参数的，谢谢！
|
|
42
chinawrj 2017-11-17 08:43:31 +08:00 1
这个问题是这样的，现在不管你用 802.11ac 还是 802.11n ，无线组播速率（其实在 802.11 MAC 那边都是广播，当然有的路由器会用 Unicast 给每个 station 单独发组播，那个是另外一回事了。这个单独买个 unicast 发包的模式在 station 数目很多的情况下，效率就很低下了。）很多 AP 都默认设置为 1Mbps，因为速率越低，纠错性能越好，这样基本所有的路由器都能收到这个组播包。
1. 调控速率 能刷 tomato 路由的 BCM 方案都可以。Marvell 的 8864(WRT1900AC)也行，但是开源 Driver 要改一下才行。具体不方便公开讨论。问题是 WRT1900AC 的 Marvell 方案可能已经不再售卖了。 2. 组转单模式是路由器 OS 层面设置的。OpenWRT 就提供了相应的接口（其他 Linux 应该也行）。参考这个： https://wiki.openwrt.org/doc/howto/udp_multicast /sys/devices/virtual/net/br-lan/bridge/multicast_snooping |
 |
43
DaveHollyland 2018-03-05 12:05:53 +08:00
@chinawrj 大咖，你好！
我这边也在做一个无线实时视频传输产品，TX 无线传输源端采用 AR1021X 802.11n 模组，采用软 AP 方式。目前也碰到 UDP 组播或广播模式下丢包严重不可用，unicast 模式下传输正常。目前联系 Qualcomm 方面，厂家回复 driver 底层中对组播或广播速率做了限定，不知是否有其他方法绕过这个限制？ 这个问题困扰我们一段时间，如果您有解决方案，我们想请你有偿解决一下。我的联系方式： [email protected] |
|
44
chinawrj 2018-03-05 13:07:54 +08:00
@DaveHollyland 你们有 qualcomm 驱动源码吗？可能需要这个。
|
|
45
DaveHollyland 2018-03-05 14:05:37 +08:00
@chinawrj 驱动源码和配置文件我们手上都有，谢谢！
|
|
46
chinawrj 2018-03-06 08:39:29 +08:00
@DaveHollyland 改一下默认的广播包使用的 MCS 或者说是速率，改完之后抓包看一下 802.11 的帧头确认一下速率就 OK 了。另外内核要关闭 multicast_snooping。具体参考我上面的回复。
|
|
47
DaveHollyland 2018-03-06 13:42:36 +08:00
@chinawrj 谢谢指点，我们先调整实验一下。
|
|
48
DaveHollyland 2018-03-08 14:30:44 +08:00
@chinawrj 你好，我们的设备上没有 multicast_snooping 这个节点，我查了一下，multicast_snooping 是网桥的驱动部分，我们是项目中是两个终端设备，一个发送一个接收，都使用 linux 系统，使用 wifi 直连，使用组播传输视频，目前组播传输丢包很大，能否给一些建议？
|
|
49
DaveHollyland 2018-03-09 14:43:27 +08:00
@chinawrj 我们使用的是 5G 频段，限速 4M，修改限速并抓 wifi 包确认修改成功了，但是发现很多包没有发送出来，不知道是什么原因，是因为组播包的优先级低导致吗？
|
|
50
chinawrj 2018-03-09 20:12:02 +08:00
@DaveHollyland 现在 phy 层速率是多少，能够贴出来吗（截图）？另外建议在屏蔽间里面测试一下 iperf UDP 发送的乱序和丢包情况，再上你们的系统测试。
|
|
51
DaveHollyland 2018-03-12 15:37:15 +08:00
@chinawrj 好的，我这边抓包出现点问题，稍后贴出 802.11 的抓包图，请问方便邮件或 qq 联系吗？我的 qq：81182980
|
|
52
DaveHollyland 2018-03-15 15:00:06 +08:00
@chinawrj 我们现在修改组播带宽为 78M，组播丢包率为 0.1%左右，据你的经验，目前还有可能做到组播丢包率更低的水平吗？
|
|
53
DaveHollyland 2018-04-02 20:29:50 +08:00
@chinawrj 抓包终于搞好了！我们测试了各种速率，下图是 18M 的截图() https://img-blog.csdn.net/20180402202904253
|
 |
54
llljjlj 2018-04-16 11:41:52 +08:00
@chinawrj
我这里也遇到了相同的问题，想请教你一下。使用的 wifi 也为 AR1021X，UDP 广播也是被限制在了 1M。我的 QQ1208010091 还请帮助。 |
|
55
llljjlj 2018-04-16 11:42:37 +08:00
@DaveHollyland
我这里也遇到了相同的问题，想请教你一下。使用的 wifi 也为 AR1021X，UDP 广播也是被限制在了 1M。我的 QQ1208010091 还请帮助。 |
Select Language