web-dev-qa-db-ja.com

実サーバーのプッシュオーバーhttpはありますか?

私はそれを偽造する方法、ポーリング(または長いポーリング)があることを知っていますが、サーバーにブラウザに接続して情報をプッシュさせる方法はありますか?

どちらのポーリングオプションもサーバー上のリソースを浪費し、サーバーによってはサーバーをロックする可能性があります(Apacheやiisなど)。

多くのサイトが長いポーリングを使用して、httpを介してサーバー側のプッシュメカニズムを偽造しているようです。真のプッシュプロトコルをブラウザに組み込んだほうがいいのではないでしょうか。

(偽のまたはその他の)情報をWebブラウザーにプッシュするサーバーフレンドリーなオプションはありますか?

17
Justin808

私はそれを偽造する方法、ポーリング(または長いポーリング)があることを知っていますが、サーバーにブラウザに接続して情報をプッシュさせる方法はありますか?

クライアントからサーバーへの接続を最初に確立する必要があります。サーバーがWebクライアントに接続する方法はありません。

どちらのポーリングオプションもサーバー上のリソースを浪費し、サーバーによってはサーバーをロックする可能性があります(Apacheやiisなど)。

そのとおりです。 頻繁なポーリングは非効率的です。これが、持続的接続のあるプッシュの世界に移行する理由の1つです。 WebSocketはこれに最適なソリューションになります。私は、ホストされたリアルタイムWebSocketソリューションである Pusher で働いています。このテクノロジーは、リソースとリアルタイム通信の問題に対する最善のソリューションであると信じているコミュニティによって推進されています。

多くのサイトが長いポーリングを使用して、httpを介してサーバー側のプッシュメカニズムを偽造しているようです。真のプッシュプロトコルをブラウザに組み込んだほうがいいのではないでしょうか。

はい、それが私たちが今WebSocketを持っている理由です。 Webブラウザに対するHTTPソリューションは、最終的にはハックであり、ブラウザ間で一貫して(同じように)機能しません。

(偽のまたはその他の)情報をWebブラウザーにプッシュするサーバーフレンドリーなオプションはありますか?

  • HTTP Long-Polling:サーバーが新しい情報を取得するまで接続は開いたままになります。 注:これは、新しい情報の要求が完全に時間の無駄になる可能性がある標準のポーリングとは異なります。
  • HTTPストリーミング:これはおそらくあなたが探している解決策です(HTTPの質問に答えます)。この手法を使用すると、HTTP Long-Pollingの場合のように接続を閉じて再度開くことなく、接続を開いたままにし、サーバーからクライアントに新しい情報を既存の接続にプッシュできます。
  • HTTP/2サーバープッシュ:サーバーからクライアントにプッシュするためのもう1つの標準化されたメカニズム。これらは「プッシュ応答」と呼ばれ、ブラウザはこれらをキャッシュする場合があります。
  • WebSockets:単一のTCP Webブラウザー(または任意のWeb)内の接続を介した完全な双方向および全二重通信クライアント)。

関連情報とリソース:

  1. サーバー送信イベント( EventSource API )は、HTTPロングポーリングとHTTPストリーミングの標準化と考えることができます。
  2. HTTP/2サーバープッシュ
30
leggetter

いいえ。

お使いのブラウザは着信接続をリッスンしません。

また、それができるようにしたくありません。そのままで十分なエクスプロイトがあります。

1
Brian Roach

他の人が述べたように、サーバーがクライアントの要求なしにクライアントに接続することは不可能です(通常のHTTPで)。

しかし、Push notificatinonsのクリーンなソリューションを探している場合は、 Server-Sent Events を見てください。これは通常のHTTPであり、HTTP1.1をサポートするほとんどのブラウザーとシームレスに連携します。

SSEは、プッシュ通知の主要なメカニズムである一方向(サーバー->クライアント)でのみ機能します。クライアント->サーバー通信の場合、いつでもAjaxを使用できます。私はこれを要約しました Webアプリのリアルタイム通信のためのどの技術ですか?

0
Robert Zaremba

Adobe FlexなどのRIAテクノロジーを使用している場合は、Flexバージョンの「サーバープッシュ」(AMFメッセージング)がサーバープッシュの定義に適合すると思います。

もちろん、基本的なajax-y(ハッキー)ポーリング方法も実行できますが、強制されない限り理由はありません。

0
Manius

何も「偽造」する必要はありません。 Flashには、見事に機能する非常に優れた、肉付きの良いSocketオブジェクトがあり、Webページと通信する小さなFlashアプリを作成できるため、サーバーとの通信以外にFlashで何もする必要はありません。 (HTMLでページを作成したい場合)。もちろん、サーバー側のソケットリスナーが必要ですが、それらを一緒に使用するのも非常に簡単です。全体を実装する方法についてのオンラインのドキュメントがたくさんあります...これが私が見つけた最初の例です(あまり詳しく調べていませんでしたが、うまく機能するようです)。 http://www.giantflyingsaucer.com/blog/?p=205

0
Yevgeny Simkin

WebSocket( http://en.m.wikipedia.org/wiki/WebSocket を参照)は実際のプッシュだと思うので、答えは次のようになります。ブラウザーによって異なります。幅広い互換性が必要な場合、今日できる最善の方法は、実行しているブラウザーで使用可能な最良のプロトコルを選択するJavaScriptライブラリーです(例: https://github.com/ffdead/jquery-graceful-websocket )。しかし、サーバーフレンドリーが必要であり、複数のプロトコルをサポートすることはサーバーフレンドリーではありません。現在の最先端技術は、ブラウザ間で機能するクールなことを行うことはエンジニアリング集約的であるということです。

0
Matthew Kane

質問された時から技術が進歩したのかもしれません...私は何か他のものを探しているこれに出くわしました。

WebPushはほとんどのブラウザーで使用可能であり、サーバーからブラウザーに情報を送信するいくつかのプッシュ通知プロバイダーがあります。 Safariのようないくつかのブラウザーを除いて、通知が到着したときに呼び出され、クライアント側のブラウザーで何らかのアクションを実行できるハンドラーを開発できます。

0
Neeraj Krishna