非同期TCPソケットを介してC＃サーバーに接続し、30秒ごとに1バイトを送信する（ハートビートを実装する）アプリをテストしています。約1時間後、アプリは（1バイトの）132パケットをサーバーに送信し、パケットは正常に受信されました。iPhoneアプリはサーバーに一度接続され、その後、開いた接続を介してパケットを送信しました（サーバーは何も送信しません）。使用した帯域幅を測定するためにそれを行いました。そこで、[電話]>[設定]>[一般]>[使用法]に移動すると、366KBのアップと344KBのダウンが測定されました（テスト前に統計をリセットしました）。電話にインストールされているネットに接続している他のアプリはありません。私はこれを約5回試しましたが、同様の結果が得られました。
これは自然ですか？私は132バイトしか送信しませんでしたが、使用された帯域幅は約710キロバイトでした（7.000以上のように）。TCP / IPプロトコルからの帯域幅のオーバーヘッドはそれほど多くありますか？httpヘッダーの原因である、Httpポーリングの実装で最悪の結果になると思います。
いいえ、Safariやメールなどの帯域幅を使用して更新などをチェックしているものは他にあります。パケットごとに3Kを上下に移動することはできません。
また、サーバーから http (plain/text =1 で応答する asp.net httphandler) を介して 1 バイト (約) を取得することもテストしました。http ヘッダーがあるため、この方法ではより多くの帯域幅が使用されると思います。しかし、Iphone デバイスをテストした結果、サーバーからの各 1 バイトの要求 (すべての http ヘッダーを含む) のコストは約 3.5kb であることが報告されました。直接 tcp ソケットを使用した場合の各パケットの平均コスト (5kb - 7kb) と比較すると、さらに少なくなります。
送受信される各パケットのオーバーヘッドと、接続をセットアップまたは破棄するための追加のオーバーヘッドがあります。多くの小さなパケットを送信すると、多くの TCP オーバーヘッドが発生し、ソケットの反対側で受信されるバイトを測定するだけでは、オーバーヘッドは含まれません。より少なくしたい場合は、UDP に切り替えて、自分で接続を維持する複雑さに対処してください。
さらに、バックグラウンドで帯域幅を使用する追加の OS プロセスが存在する可能性があります。最良の結果を得るには、すべてのメール/カレンダー/プッシュ通知を無効にします。
Wi-Fi 接続を使用している場合は、別のコンピューターでWiresharkを使用して、iPhone との間のすべてのトラフィックをキャプチャすることができます。このようにして、余分な帯域幅が使用されているもの/場所を知ることができます。