我有一个通过 WIFI 连接到嵌入式 AP 的 android 智能手机。我正在使用在 Linux 上运行 Tshark 的笔记本电脑嗅探 WIFI 流量。我每 100 毫秒传输 5 次小型（234 字节）TCP 数据包，然后是 500 毫秒没有数据。周期性地，数据包将被忽略，强制重传。当通过 TCP 套接字传输数据时，需要一定程度的数据包重传，但这是过多的。特别是因为嗅探器接收数据包没有问题（即没有“飞行中”损坏），并且后续重新传输的数据包也被android忽略（丢弃）。
请注意：当我说“忽略”时，我的意思是我没有看到任何确认，无论是来自接收无线电 (802.11 ACK) 还是来自 Wireshark 跟踪中的接收 TCP 堆栈 (TCP ACK)。在下图中，数据包599被立即确认，而下一个数据包 (606) 被忽略，接下来的四次重传 (607-610) 也是如此。
这不会发生在 Android v4.x（4.0.4 和 4.2.2 测试）上运行的相同 APK 上，也不会发生在 iOS 上运行的类似应用程序上。在这两种情况下，都会出现预期丢弃的 TCP 数据包，然后是重传，但几乎总是立即被确认。
由于我传输的数据包没有什么特别之处，并且TCP数据包的无缝重传有望在一定程度上解决丢包问题，我怀疑许多应用程序都遇到了同样的问题，但只是接受了整体传输速率的降低，归因于较慢的转移到“WIFI 拥塞”。
就我而言，WIFI 硬件/固件解决方案（由第三方提供）因 TCP 积压过多而窒息。他们有一个带有创可贴修复的新解决方案，似乎有助于恢复，但这并不能解决现场已有的硬件问题。
我相信在 android 5.x 下有些事情发生了变化，以至于收音机会定期关闭或移出频道。由于它似乎周期性地发生，我认为这可能是由于信道扫描（期望在扫描间隔期间丢弃的任何数据包都将在无线电返回时通过重新传输来恢复）。我无法找到对 Android 频道扫描行为的明确定义（对此我有单独的帖子）。
当失败时，重传将以 4 或 5 个数据包的突发形式发生，中间有几毫秒，然后在 1 秒内没有任何内容，然后是另一个突发。通常，重传的数据包会被忽略一段时间（可能是几秒）。最终，一个重传数据包被确认，并继续下一个数据包的传输。
我注意到还发生了定期 DNS 探测（通过 DNS 查询定期探测的 URL …
