ブラウザとサーバー間の双方向接続を開きたい場合は、ポーリング(サーバーにハンマーをかける)またはcomet(無愛想で切断されやすい)を使用するしかありません。
なぜブラウザは単純なTCP接続を開くことができないのですか?この能力を持たないことの実際的な利点はありますか?
基礎となるプロトコル HTTP は、基本的に半二重通信プロトコルであり、ステートレスでもあり、全二重通信をサポートしていません。ただし、HTML 5 websockets では状況が変わります。Websockets は、HTML 5 仕様で検討されている新しい標準です。仕様が完成し、すべてのブラウザー ベンダーが標準を採用したら、WebSocket を使用して、ブラウザー自体を介して専用の TCP 接続を確立できます。
また、HTTP は基本的に、地理的に分散したチーム間でドキュメントを配信し、情報を共有するように設計されており、通信プロトコル自体を意図したものではないことにも留意する必要があります。
そうは言っても、全二重通信を実装できるようにするために、いくつかのメッセージングゲートウェイを構築した企業がすでにあります.
ファイアウォール。非HTTPトラフィックはファイアウォールによってブロックされることが多いため、通信用にランダムなTCPポートを開くと失敗することがよくあります。
あなたの質問への答えは基本的にノーです。ブラウザでクライアントとサーバー間の双方向接続を開くことができないという明確な利点はありません。これができない理由は単純に、ドキュメントをポーリング/取得するために開発された Web ブラウザの意図ではないからです。リッチ インターネット アプリケーションの出現により、そのような機能を持つことが望ましいものになりましたが、以前はこれがブラウザーの目標ではありませんでした。現在、ブラウザーとサーバー間の双方向通信を制御する最終的なプロトコルまたは既存のプロトコルの実装によって埋められる空白があります。この動作をさまざまな程度 (AJAX、Comet など) でシミュレートするために使用される既存の手法があり、埋め込みオブジェクト (Java、Flash、
標準が作成され、実装が続くのを待つ(または行動する)必要があります。おそらく、実装が実際に最初に行われ、新しいクロスブラウザー互換性の問題がいくつかあります:) ああ、最先端です!
何年にもわたって、Web の非常に多くの側面や要素が乗っ取られ、より豊かな体験を提供してきました。Comet は、サーバー側のプッシュを可能にするために、長期間存続する接続が悪用された 1 つの例にすぎません。もともと Web ページは、ハイパーリンクされたテキスト ドキュメントであり、今日よく目にするリッチ アプリケーションではありませんでした。当初の考えが意図していたもののハッキングと悪用は、いつの日かこれらがより標準化されるまで続くでしょう.
この機能がフラッシュを介して効果的に利用可能であることを考えると、実際のセキュリティ上の根拠はありません。しかし、最近では、そのような非標準の拡張機能を最初に実装したいと考えるブラウザはありません。さらに、スレッドを実行する簡単な方法がないため、ソケットの使用がややこしくなる可能性があります。