WIFI 経由で組み込み AP に接続している Android スマートフォンがあります。Linux で Tshark を実行しているラップトップで WIFI トラフィックを盗聴しています。小さな (234 バイト) TCP パケットを 100 ミリ秒ごとに 5 回転送し、その後 500 ミリ秒のデータなしで転送しています。定期的にパケットが無視され、再送信が強制されます。TCP ソケットを介してデータを転送する場合、ある程度のパケット再送信が予想されますが、これは過剰です。特に、パケットがスニファーによって問題なく受信されるため (つまり、「飛行中」の破損がないため)、その後の再送信されたパケットも Android によって無視 (ドロップ) されます。
注意: 「IGNORED」と言うときは、受信無線 (802.11 ACK) から、または Wireshark トレースで TCP スタック (TCP ACK) の受信から、確認応答が表示されないことを意味します。下の画像では、データ パケット599はすぐに確認応答されますが、次のデータ パケット (606) は無視され、次の 4 回の再送信 (607 ～ 610) も無視されます。
これは、Android v4.x (テスト済みの 4.0.4 および 4.2.2) で実行されている同じ APK や、iOS で実行されている同様のアプリケーションでは発生しません。どちらの場合も、予期されるドロップされた TCP パケットがあり、その後に再送信が続きますが、ほとんどの場合、すぐに ACK が返されます。
私が転送しているパケットについて特別なことは何もなく、パケット損失に対処するために TCP パケットのシームレスな再送信がある程度期待されているため、多くのアプリケーションがこの同じ問題に苦しんでいると思われますが、全体的な転送速度の低下を単純に受け入れて、 「WIFI混雑」への転送が遅くなります。
私の場合、(サードパーティが提供する) WIFI ハードウェア/ファームウェア ソリューションは、過剰な TCP バックログが発生して詰まります。彼らは、回復に役立つように見える応急処置を備えた新しいソリューションを持っていますが、それはすでに現場にあるハードウェアの問題を解決していません.
ラジオが定期的にシャットダウンされるか、オフチャンネルにシフトされるように、Android 5.xで何かが変更されたと思います。定期的に発生しているように見えるため、これはチャネル スキャンが原因である可能性があります (スキャン間隔中にドロップされたパケットは、無線が戻ったときに再送信によって回復されることを期待して)。Android チャネル スキャン動作の明確な定義を見つけることができませんでした (それについては別の投稿があります)。
失敗すると、数ミリ秒間隔で 4 または 5 パケットのバーストで再送信が行われ、その後 1 秒間何も送信されず、その後に別のバーストが続きます。通常、再送信されたパケットはしばらく無視されます (数秒かかる場合もあります)。最終的に、再送信パケットが確認され、送信は次のパケットで続行されます。
また、定期的な DNS プローブが行われていることにも注意しました (DNS クエリを介して定期的にプローブされる URL のリストを以下に示します)。一部はインストールされたアプリケーションである場合もあれば、オペレーティング システムである場合もあります (たとえば、「connectivitycheck.android.com」は、AP が実際にインターネット接続を提供しているかどうかを確認するために使用される可能性がありますが、私の場合はそうではありません)。
android.clients.google.com
android.googleapis.com
clients3.google.com
cmdts.ksmobile.com
connectivitycheck.android.com
graph.facebook.com
mtalk.google.com
px.demdex.net
weather.ksmobile.com
px.demdex.net エントリが私の注意を引いたのは、これが誰を表しているのかわからなかったからです。アドビであることが判明しました。私が知らなかった積極的に調査しているコードのビットが明らかにあり、私の問題が純粋に Android の問題であることを確認するために、Nexus 4 スマートフォンを出荷時設定にリセットし、WIFI 通信の問題に関係している可能性のある初期化オプションを拒否しました ( Google 位置情報サービスとして、オフのときでも WIFI を使用できるようにするなど）。TCP パケットは引き続きドロップされます。
Android側では、私は以下を持っています： - 場所を「デバイスのみ」（GPS）に設定 - WIFI「スキャンは常に利用可能」を無効にしました - ソケットが開いているときはいつでもアプリ内で「WIFI_MODE_FULL_HIGH_PERF」ロックを取得しました。- アプリが通信を開始するとソケットが開かれ、アプリが終了するまで開いたままになります。しばらくの間 (現在 3 秒間) パケットが表示されない場合、アプリはソケットを閉じて新しいソケットを開き、通信を強制的に再確立しようとします。
IWifiManager の「setAllowScansWithTraffic()」関数を発見しました。これは、スキャンの明示的な制御 (リストからその可能性を削除するため) を提供するように思えますが、これを実装するのは難しいようで、私の一部にはなりませんでした。アプリ （？）。IWifiManager は、Android の実装者が独自の WIFI マネージャー (OS) サービスを構築するためのスタブを提供するものであり、アプリ レベルでの使用を意図したものではないと考えています。
入力/提案をいただければ幸いです。
アップデート
「チャネル スキャン」の可能性を追跡している間、テスト対象のハードウェアが WIFI チャネル 8 で動作している間に、パケット スニファを使用して WIFI チャネル 3 で ACK パケットをログに記録しました。Android のバグを開いた