Google C2DM (プッシュ) tcp 接続がポート 5228 を使用していることに気付きました。一部のファイアウォールが 80 443 以外のポートをブロックしていることも知っています (htttp と https のため)。これにより、多くのユーザーがマーケットを使用できないと不満を漏らしています。たとえば、会社のwifiを使用して電話でアプリまたはGTalk。
ここで私の質問は、Google が永続的な TCP 接続にポート 443 または 80 を選択しなかったのはなぜですか?
Google C2DM (プッシュ) tcp 接続がポート 5228 を使用していることに気付きました。一部のファイアウォールが 80 443 以外のポートをブロックしていることも知っています (htttp と https のため)。これにより、多くのユーザーがマーケットを使用できないと不満を漏らしています。たとえば、会社のwifiを使用して電話でアプリまたはGTalk。
ここで私の質問は、Google が永続的な TCP 接続にポート 443 または 80 を選択しなかったのはなぜですか?
Google が 80 または 443 の代わりに 5228 を使用することを選択した可能性がある理由はいくつか考えられます。
まず、ほとんどの場合 (ただし、すべてではない)、5228 は問題 (ブロック) にはなりません。これは、デバイスが移動中の場合にプッシュ通知が主に使用されるためです。これは、このポートをブロックせず、ファイアウォールで保護されていない携帯電話のデータ接続を使用していることを意味します。
第 2 に、ファイアウォールが存在する可能性がある環境 (企業内の WiFi など) の場合、http トラフィックが何らかの方法でプロキシまたは制御される可能性があります。C2DM は標準の HTTP プロトコルに依存しておらず、長時間の接続であることが期待されています。これは、80/443 で実行すると、これらの環境で問題が発生する可能性があることを意味します。
第 3 に、これらのサービスは C2DM のリリース前に 5228 を使用していた可能性が高く、それを変更する明確な理由はありませんでした。
私の経験に基づいて、デフォルトとして 5228 を使用し、それ以外の場合は 443 にフォールバックしようとするのが理想的だったと思います (5228 が機能しないときに 443 が機能するシナリオは間違いなく多くあるため)。少なくとも 443 の場合、プロトコルは通常暗号化されるため、ポート 80 の場合よりもデータが変更される可能性は低くなります。ただし、接続が 443 で途中で終了する可能性は依然としてあります。ただし、このリスクはどのネットワーク環境にも存在し、試行しても失敗することはありません。
別の注意として、443 で C2DM を有効にすることは、Google が考えているよりも困難だった可能性があります。これは、分散フロントエンド サーバーが 80/443 トラフィックを HTTP として具体的に処理する方法を知っている可能性が高く、大幅な再作業が必要になるためです。 C2DM を処理します。
C2DM トラフィックのトラフィック レベルを簡単に監視できるように、別の標準ポートを取得したかったのではないかと思います。
それらは単独ではなく、Apple はプッシュ実装についてもまったく同じことを行っています。