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 的参数不太好调，而且好多系统不给权限调。

@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：打很多字太累。。。

没遇到过。

秒杀苹果妥妥的

看来你是买的便宜 Android。我能告诉你，你可以买个 Sony 的 Android 播放器吗？不是手机

组播使用的是广播，11n 最大可以到 72m。详细可以联系我

多信道多 AP。相信我。

@qui9090 为你的真实点赞。

@qfdk 一般来说，价格低的东西多多少少会有点让你不满意的地方（虽然价格高的有时候也是），so 看着办吧。。。

R7800。 一分钱一分货

@ihuzhou 的确素质太低。不知道怎么举报上面那个人。

欢迎来杭州。

@Lihz 没省会挺好的。说明发展均衡啊。

@Itanium 又来黑。我要举报。哈哈

@42alex 靠上海 杭州太近了

这样的确有点不厚道。一般先签 offer，过些日子再办理入职的啊。offer 应该有双方违约规定，对大家都好

@lucifer9 感谢，我研究一下。

@nuansediao 必须也算啊。然后你必须得塞卡进去，而且我试过。我这里结果是刷不了。还是得 NFC 刷