1

<div>サーバー側とクライアント側の自動更新を処理することの長所と短所について疑問に思っています。私はPHPでApacheを使用していますが、次のようにJavascriptでプッシュ通知を偽造することを考えていました:

setInterval(queryDatabaseForUnreadMessages, 60000);

function queryDatabaseForUnreadMessages(){
   $.ajax({
       url: "/messages/queryDatabaseForUnreadMessages",
       success:function(data){
          $('div#littleRedCircle').html(data);
       }
   });
}

Stackoverflow が行ったような通知 (数字が入った小さな赤い円) を設定して、新しいメッセージが存在する場合に受信したことを人々に知らせたいと思います。その単純な AJAX/setInterval の組み合わせは悪い考えですか?

4

2 に答える 2

3

サーバープッシュの唯一の欠点は、実装コスト (時間、お金) です。

サーバー プッシュが最適な方法です。

  1. ユーザーの観点からすると、リアルタイム通知の方が優れています
  2. 予測可能なコストを持っています（したがって、スケーラブルです）
  3. 帯域幅の消費を削減
  4. サーバーの負荷を軽減

サーバー側のプッシュの実装コストは、実際には単一の PHP スクリプトの問題ではなく、サーバーとの深い統合が必要になるため、どれを選択するかは特定の要件によって異なります (別のスクリプトをインストールする必要がある場合があります)。 HTTP サーバー全体) と、通常は PHP で構築されていない他のソフトウェア (メッセージ キュー?) を含みます。

于 2012-06-28T15:02:32.470 に答える
2

IETF DOC より

プルとは対照的なロング ポーリング

ただし、ロングポーリングの問題は何ですか? DOC から

  1. ヘッダーのオーバーヘッド
  2. 最大レイテンシ
  3. 接続の確立
  4. 割り当てられたリソース
  5. 優雅な劣化
  6. タイムアウトとキャッシュ

私のコメントで述べたように

ロング ポーリングはリアルタイムですが、プルはほぼリアルタイムです [ポーリング間隔によって決定されます]。

プルはクライアントの帯域幅を当然のことと見なします:P

DOC に記載されているように、どちらの手法も HTTP 1.1 の永続接続をうまく利用しています。

プルは実装が簡単で、ブラウザー間で十分にサポートされています。Pushにはそれがありませんが、ライブラリは救助するためにあります;)。

于 2012-06-28T15:25:29.790 に答える