質問: 以下、流れです。 Java クライアントアプリケーションよりHttpURLConnectionを利用して、指定のサーバー(例 http://xxxxx.com/test.php)へアクセスして、返されたデータを取得。 この処理は0.5秒毎に実行されます。 phpの処理内容は、指定のデータベースへ接続し15kbのテキストデータを取得し、取得したものをechoにて出力されるものです。 ユーザーをを100人程度で想定しているのですが、 単純計算で1秒間に30kb*100人で3MBの送信量があり、1日/30日スパンで考えるととんでもないリクエスト数と通信量になってしまい、AzureかAWSで考えているのですが高額な料金を請求されるのではないかと思っています。 ※ちなみにユーザーがデータベースへデータを送信する事はありません。あくまで受信のみを実行します。 そこで考えたのが、クラウドサーバーを経由しないアプリ同士のソケット通信を考えたのですが、パケット開放の関連で厳しいと感じました。 次に考えたのが、socket.ioなのですが、調べたのですが今一分かりませんでした。 上記の利用を想定した場合、よりコストやパフォーマンスの点など、より良くなりますでしょうか? (データベースの参照やHttpURLConnectionを必須条件という訳ではないです。ソケット通信が良い例ですが、とにかく最新のデータを効率良く取得(共有)出来ればいいと思っております。) 他に何か最善策があれば、教えて頂けますと幸いです。 よろしくお願い致します。
回答: 回答ではないですが、そもそも0.5秒に15kbを常時送受信し続ける仕様というのがどこのサーバでやるにしてもまずいと思います。送受信するデータを圧縮する、テキストデータをやめてバイナリデータにして無駄を省く、ポーリングの期間を伸ばす、またはユーザに必要のないタイミングでの送受信を控える、等の仕様を考えるべきかと思います。 あまり通信帯域を常時圧迫するようなことをするとプロバイダに目をつけられてサービスを停止させられる可能性も考えられるので、できるだけ省エネにすることをおすすめします。 あと、socket.ioで通信しても「ユーザ間の直接通信」ではないので、結局サーバへの通信量は変わりません。 もしあなたがサーバの通信量を気にして端末間の直接通信をやるのであれば、UDPホールパンチングという技術を使えばポートの問題は多少解決されます。ただし、これで通信できるのはTCPではなくUDPなので、アルゴリズムを正しく考えないとパケットロスや伝達順序に問題がでます。アプリ側でUDPの通信にIDを割り振ったりタイムスタンプを割り振ったり、受け手側がパケットロスした情報を再要求できる仕組みを考えれば、UDPでもある程度の信頼性を高めることは可能です。 【UDPホールパンチングの解説記事】 【UDPでの信頼性を高める関連記事】