V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Duluku
V2EX  ›  路由器

关于 Udp 无线发送文件,广播和单播怎么差别这么大

  •  1
     
  •   Duluku · 2017-06-29 16:24:26 +08:00 · 10804 次点击
    这是一个创建于 2490 天前的主题,其中的信息可能已经有所发展或是发生改变。

    公司有个这样的需求,想将一个文件尽快的分发给各个手机,所以我自然有想到通过 Udp 来一对多广播分发文件。但是广播的测试结果好像不太令人满意,下面是我的测试结果:


    测试的环境:

    2.4GHz 的 TP-Link TL-WVR1200, 发送端和接收端都是 Windows,Udp 发送的代码是 Java 写的。

    这里我将一个 40M 的文件拆分 4000 左右个 10K 的包,然后依次发送过去。

    发送端通过网线接入路由器, 接收端通过无线网卡接入。


    测试 1. 更改发送包的时间间隔

    修改发送端的每次发送一个 10K 包之间的时间间隔:

    loss

    间隔 3ms 之后,单播基本就不丢包了,但是广播会很好的收取大概 100 多个包之后就卡住不动了,之后偶尔收到几个,然后就再也没有了。这里是不是路由器在广播这方面有限制?


    测试 2. 更改发送端接入方式

    这里都采取发送端发送间隔 5ms 进行。

    loss2

    这里我只是将开始的发送端的有线接入改成无线接入,但是发送的单播丢包率猛增。 广播我就不奢望什么了。


    请问各位大佬,路由器 UDP 广播有什么可以设置的吗?还是要刷什么固件之类的? 甚至需要定制吗?

    ps. 不清楚具体节点应该放哪里.. 如果放错了,希望管理帮我移到合适的节点把 :)

    55 条回复    2018-04-16 11:42:37 +08:00
    Duluku
        1
    Duluku  
    OP
       2017-06-29 16:27:09 +08:00
    不过 Udp 单播的效果的确比我平常想象的好啊很多,我把发送包的大小从 10KB 提高到 50KB,包的时间间隔为 5ms,基本上都发过去了,丢包率低于 1%, 但是广播简直没法看。
    rrfeng
        2
    rrfeng  
       2017-06-29 16:27:28 +08:00   ❤️ 1
    无线信道很拥挤的,从这方面入手查一下。
    Duluku
        3
    Duluku  
    OP
       2017-06-29 16:30:28 +08:00
    @rrfeng 是的,我查过信道,2.4GHz 的信道的确拥挤,不过这里我关注的重点是单播和广播的差距非常大,单播基本上可以说是不丢包,这个差别令我比较在意。(也是因为手里没有 5G 的无线设备,拿到设备马上测试更新这个帖子)
    hjc4869
        4
    hjc4869  
       2017-06-29 16:34:54 +08:00
    一般先用广播发现设备,然后再用单播去发文件或者大量数据。
    广播一般也就那么一两个包
    rrfeng
        5
    rrfeng  
       2017-06-29 16:37:23 +08:00
    自始至终只有一个接收端吗?
    Duluku
        6
    Duluku  
    OP
       2017-06-29 16:41:10 +08:00 via iPhone
    @hjc4869 不能使用广播做文件分发吗? 虽然会丢包,但是只要丢包率低于 30%,发送端多广播几次应该基本能做到很好的分发效率吧?
    不过的确这个想法感觉比较胡来,网上也没查到相关的方法...
    Duluku
        7
    Duluku  
    OP
       2017-06-29 16:42:41 +08:00 via iPhone
    @rrfeng 暂时测试只测了一个接收端… 因为广播的丢包率太高了,所以就没测多个接收端了…
    hjc4869
        8
    hjc4869  
       2017-06-29 16:44:21 +08:00
    另外你的包太大了,目测 UDP 被分片了,加剧了丢包
    Duluku
        9
    Duluku  
    OP
       2017-06-29 16:49:32 +08:00
    @hjc4869 好的,我现在去试试将包变小点,不过大概多少合适呢,5KB ? 太小了我觉得广播的带宽就太差了,现在每个包间隔 5ms 时,广播的数据每秒不到 2MB,我觉得已经很小了,再降低单个包的大小,可能还不如 TCP 一个一个发过去呢。。
    hjc4869
        10
    hjc4869  
       2017-06-29 16:53:39 +08:00
    @Duluku UDP 传输大量数据时整个 IP 包的大小不要超过 MTU,通常也就是 1472 ( MTU 1500 字节减去 20 字节 IP 头部和 8 字节的 UDP 头部)
    hjc4869
        11
    hjc4869  
       2017-06-29 16:55:22 +08:00   ❤️ 1
    传输大量数据需要做流量控制和拥塞控制,不是每个包间隔 5ms 这么 simple 的,建议还是用 UDP 发现设备,TCP 连接+传输数据。
    Duluku
        12
    Duluku  
    OP
       2017-06-29 17:03:55 +08:00
    @hjc4869 刚刚试了试,结果是这样 ![]( )
    Duluku
        13
    Duluku  
    OP
       2017-06-29 17:04:54 +08:00
    @hjc4869 不过总是让我在意的是这个 UDP 单播的效果,UDP 单播在 5ms 的发送间隔能过做到不丢包,但是广播就丢这么多,我怎么都觉得有点不理解。。
    lan894734188
        14
    lan894734188  
       2017-06-29 17:09:32 +08:00 via Android
    还是 tcp 吧
    Duluku
        15
    Duluku  
    OP
       2017-06-29 17:15:25 +08:00 via iPhone
    @rrfeng 把接收端换了 5GHz 的无线网卡,效果没有变化…
    hjc4869
        16
    hjc4869  
       2017-06-29 17:22:03 +08:00   ❤️ 1
    @Duluku 计算一下广播产生的带宽,如果不是硬件性能问题,那么可能是被 QoS 了。为了防止广播风暴。
    Duluku
        17
    Duluku  
    OP
       2017-06-29 17:44:32 +08:00
    @hjc4869 这个我觉得很有可能,在广播的时候,接收端最开始接收包我看起来挺好的,不过接收到 100 个左右的时候,突然就卡住不再接受得到数据了。 我在路由器的 web 设置界面找找,不过感觉很有可能没有...
    xfspace
        18
    xfspace  
       2017-06-29 18:12:14 +08:00 via Android   ❤️ 2
    无线是半双工...用了 CSMA/CA,你还要用广播发文件...
    无线接入点的价格和终端数量及环境干扰都会影响到无线网络传输
    dndx
        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/
    Duluku
        20
    Duluku  
    OP
       2017-06-29 18:52:44 +08:00
    @dndx 原来如此。学到了... 多谢大佬
    chinawrj
        21
    chinawrj  
       2017-06-29 19:02:18 +08:00 via Android
    组播使用的是广播,11n 最大可以到 72m。详细可以联系我
    Duluku
        22
    Duluku  
    OP
       2017-06-29 19:15:58 +08:00 via iPhone
    @chinawrj … 这跟楼上哥们说的不一样啊。你是怎么做到的
    dndx
        23
    dndx  
       2017-06-30 03:39:22 +08:00 via iPhone
    @Duluku 他说的是组播,multicast. 跟你说的广播 broadcast 不是一个东西。
    chinawrj
        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:打很多字太累。。。
    Duluku
        25
    Duluku  
    OP
       2017-06-30 09:16:02 +08:00 via iPhone
    @chinawrj 老哥,你这波太厉害了,多谢🙏… 我得研究研究才能回复你… v2 真是个好地方
    Duluku
        26
    Duluku  
    OP
       2017-06-30 18:08:15 +08:00
    @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 单播给某个设备,其他设备监听这个网络从而获取数据呢? (这个脑洞可能有点大,实施起来可能比较难,但是理论上似乎可行),你怎么看?

    再次表示感谢!
    chinawrj
        27
    chinawrj  
       2017-06-30 18:34:01 +08:00   ❤️ 1
    1. TP-LINK 路由器可能没有这种配置,你需要一个 OpenWrt 路由器。另外真的要调试 Wi-Fi 网络的话,弄个 macbook,装上 wireshark 和 airtools 就可以抓包了(抓 802.11 包,不是以太网包)。组播地址和 MAC 地址有一种映射关系,你也可以在 wireshark 中过滤。
    2. 我记得最大可以到 72Mbps,有的路由器是可以设置的。但并不是所有的都可以。如果要给出一个可以设置的路由的话,我记得刷 tomato 路由的 broadcomm 方案是可以的。另外当时我们公司自己的 88W8864 是可以设置的。你的无线端发送失败有可能是路由器那边限制了,具体那种限制不清楚。你可以用 mtk/broadcomm/qualcomm/marvell 的方案都试试。
    3. 理论上可行。实际上需要你的手机支持 wifi   monitor 模式,然后其他手机抓到握手包(发给单播接收数据的手机的包,并且不能使用多个空间流等高级特性),然后再根据握手包和路由器无线密码算出 PTK 来解密。不过 monitor 模式依赖于系统和 wifi 驱动 /固件,如果你的手机系统不是自己编译出来,并且 wifi 模块支持 monitor 的话,还是不要尝试了。不能控制用户手机端的情况下,这种方案肯定是不可行的。

    不知道你做的具体项目,但是如果你要做文件分发的话。我可以提供一个 case 供你参考:曾经我们的客户就是用最高速率的 multcast 来发送 720P 的视频流和文件。应用场景是电子教室。总共50-60部手机,可以获得约每个手机 500KBytes 的速率(也许还能提高,但是当时的场景大概就是需要这么高的速率)。



    如果不定制路由,我觉得你可以发送数据的时候不要一起发送,错开发送就好。这样可以有效利用空中带宽。毕竟上了 802.11ac 的路由器,单播最低实测也可以到 200Mbps。一起发送,无线干扰会很严重,会有很多空域的无线退避,导致贷款利用效率下降。

    在发送协议上,可以使用 UDP,然后自己控制发送时采用的速率以及纠错功能。毕竟 TCP 的参数不太好调,而且好多系统不给权限调。
    chinawrj
        28
    chinawrj  
       2017-06-30 18:36:20 +08:00   ❤️ 1
    @Duluku
    忘记 @了,不太清楚你的具体应用场景。有问题可以再问。也许能帮上。你的组播测试失败的话,建议换个普通路由器试试吧。有的路由还开启了无线隔离,甚至连无线客户端相互访问都不可以 。
    Duluku
        29
    Duluku  
    OP
       2017-06-30 19:18:21 +08:00
    @chinawrj 非常感谢!应用场景还真就是文件分发,大概接收端设备在 40 台左右手机,发送端希望也是移动端,安卓平板之类的,空间也不算太大,类似于一个教室把,但是这个方案能不能做出来我这边还在尝试。如果能能做视频流也是很好的,如果技术做出来了,上面估计也能弄出需求出来 (哭笑) 。。我试试看继续做再回复您把! 厉害厉害!
    helijia21
        30
    helijia21  
       2017-07-01 17:31:11 +08:00
    用组播。。
    goodryb
        31
    goodryb  
       2017-07-06 13:28:43 +08:00
    公司有个这样的需求,想将一个文件尽快的分发给各个手机

    一定要用软件吗,一个 ftp 是不是就能解决这个问题
    Duluku
        32
    Duluku  
    OP
       2017-07-06 18:51:30 +08:00   ❤️ 1
    @chinawrj 搞来一个 Linksys WRT1200AC, 刷上 OpenWRT,无线组播是能收到了(不刷 OpenWRT 也无法通过无线发送组播),不过现在的组播的效果比较差,丢包率依然很高,85%以上... 有点懵逼。。 现在这个路由我特意是找的 88W8864,不过怎么上调 Udp 广播的带宽到 72Mbps 呢? 最近尝试把广播发送的时间间隔改到 20ms 左右的时候,广播那边的丢包率倒也不高(很奇怪),大概速度在 500KB 左右。。感觉很多东西都很迷茫。。。
    Duluku
        33
    Duluku  
    OP
       2017-07-06 18:52:16 +08:00
    @goodryb Ftp 还是基于 TCP 协议做的,这种分发和单播是一样的,我就是想探究看有没有别的方案嘛 :)
    chinawrj
        34
    chinawrj  
       2017-07-06 22:01:04 +08:00 via Android   ❤️ 1
    @Duluku 忘了怎么设置了。回头我找找。找个 Mac book 抓包 802.11 ,802.11 头部直接有速率的
    Duluku
        35
    Duluku  
    OP
       2017-07-07 15:42:42 +08:00
    @chinawrj 我用抓到广播了 ![microsoft-network-monitor]( )

    的确显示的是 1Mpbs,不过接下来就完全不知道怎么继续下去了... 继续尝试组播的丢包把,不知道为什么丢包那么惨...
    Duluku
        36
    Duluku  
    OP
       2017-07-17 14:10:56 +08:00
    @chinawrj 你好,公司打算有偿的方式做出这个问题,能给一个联系方式吗,或者联系我 MjY3MTM2NTY1MkBxcS5jb20=
    Duluku
        37
    Duluku  
    OP
       2017-08-02 14:45:51 +08:00
    @chinawrj 您好,能方便私下联系嘛,公司对这块的确比较重视...
    chinawrj
        38
    chinawrj  
       2017-08-04 17:32:01 +08:00
    @Duluku 你好,我的 wechat 是 cWF6cGxtMDI1Mw==
    heiher
        39
    heiher  
       2017-11-16 08:49:50 +08:00
    @chinawrj 你好,求推荐组播性能好的无线路由或 AP 设备,谢谢!
    chinawrj
        40
    chinawrj  
       2017-11-16 09:45:35 +08:00   ❤️ 1
    @heiher 额,你想做啥用啊。只要提供能调到 54Mbps 的接口的 AP 都可以啊。
    heiher
        41
    heiher  
       2017-11-16 10:03:57 +08:00
    @chinawrj 无线实时视频组播,使用了 Raptor 算法做 FEC,使用普通的 TP-LINK 天线路由实测下来链路质量实在太差,空口抓包组拆走的 802.11b/11Mbps,关闭 FEC 看接收状态图基本不能用。前辈有没有性能比较好的 AP 设备推荐呢?可以调控速率、组转单模式等等参数的,谢谢!
    chinawrj
        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
    DaveHollyland
        43
    DaveHollyland  
       2018-03-05 12:05:53 +08:00
    @chinawrj 大咖,你好!
    我这边也在做一个无线实时视频传输产品,TX 无线传输源端采用 AR1021X 802.11n 模组,采用软 AP 方式。目前也碰到 UDP 组播或广播模式下丢包严重不可用,unicast 模式下传输正常。目前联系 Qualcomm 方面,厂家回复 driver 底层中对组播或广播速率做了限定,不知是否有其他方法绕过这个限制?
    这个问题困扰我们一段时间,如果您有解决方案,我们想请你有偿解决一下。我的联系方式: [email protected]
    chinawrj
        44
    chinawrj  
       2018-03-05 13:07:54 +08:00
    @DaveHollyland 你们有 qualcomm 驱动源码吗?可能需要这个。
    DaveHollyland
        45
    DaveHollyland  
       2018-03-05 14:05:37 +08:00
    @chinawrj 驱动源码和配置文件我们手上都有,谢谢!
    chinawrj
        46
    chinawrj  
       2018-03-06 08:39:29 +08:00
    @DaveHollyland 改一下默认的广播包使用的 MCS 或者说是速率,改完之后抓包看一下 802.11 的帧头确认一下速率就 OK 了。另外内核要关闭 multicast_snooping。具体参考我上面的回复。
    DaveHollyland
        47
    DaveHollyland  
       2018-03-06 13:42:36 +08:00
    @chinawrj 谢谢指点,我们先调整实验一下。
    DaveHollyland
        48
    DaveHollyland  
       2018-03-08 14:30:44 +08:00
    @chinawrj 你好,我们的设备上没有 multicast_snooping 这个节点,我查了一下,multicast_snooping 是网桥的驱动部分,我们是项目中是两个终端设备,一个发送一个接收,都使用 linux 系统,使用 wifi 直连,使用组播传输视频,目前组播传输丢包很大,能否给一些建议?
    DaveHollyland
        49
    DaveHollyland  
       2018-03-09 14:43:27 +08:00
    @chinawrj 我们使用的是 5G 频段,限速 4M,修改限速并抓 wifi 包确认修改成功了,但是发现很多包没有发送出来,不知道是什么原因,是因为组播包的优先级低导致吗?
    chinawrj
        50
    chinawrj  
       2018-03-09 20:12:02 +08:00
    @DaveHollyland 现在 phy 层速率是多少,能够贴出来吗(截图)?另外建议在屏蔽间里面测试一下 iperf UDP 发送的乱序和丢包情况,再上你们的系统测试。
    DaveHollyland
        51
    DaveHollyland  
       2018-03-12 15:37:15 +08:00
    @chinawrj 好的,我这边抓包出现点问题,稍后贴出 802.11 的抓包图,请问方便邮件或 qq 联系吗?我的 qq:81182980
    DaveHollyland
        52
    DaveHollyland  
       2018-03-15 15:00:06 +08:00
    @chinawrj 我们现在修改组播带宽为 78M,组播丢包率为 0.1%左右,据你的经验,目前还有可能做到组播丢包率更低的水平吗?
    DaveHollyland
        53
    DaveHollyland  
       2018-04-02 20:29:50 +08:00
    @chinawrj 抓包终于搞好了!我们测试了各种速率,下图是 18M 的截图() https://img-blog.csdn.net/20180402202904253
    llljjlj
        54
    llljjlj  
       2018-04-16 11:41:52 +08:00
    @chinawrj
    我这里也遇到了相同的问题,想请教你一下。使用的 wifi 也为 AR1021X,UDP 广播也是被限制在了 1M。我的 QQ1208010091 还请帮助。
    llljjlj
        55
    llljjlj  
       2018-04-16 11:42:37 +08:00
    @DaveHollyland
    我这里也遇到了相同的问题,想请教你一下。使用的 wifi 也为 AR1021X,UDP 广播也是被限制在了 1M。我的 QQ1208010091 还请帮助。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1039 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 19:30 · PVG 03:30 · LAX 12:30 · JFK 15:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.