1

私はこの問題について何時間もグーグルしてきましたが、解決策が見つかりませんでした。

私は現在、 Meteor上に構築されたこのアプリに取り組んでいます。

現在のシナリオでは、Webサイトが開かれ、すべてのアセットがブラウザーにロードされた後、ブラウザーはサーバーに対して再帰的なxhr呼び出しを絶えず行います。これらの呼び出しは、25秒の定期的な間隔で行われます。

これは、ブラウザコンソールの[ネットワーク]タブで確認できます。画像の最後の行の保留中のリクエストを参照してください。

ここに画像の説明を入力してください

どこから発生したのか、ユーザーがアイドル状態のときでも自動的に呼び出されるのはなぜかわかりません。

問題は、これらの自動リクエストを無効にするにはどうすればよいですか？メニュー項目が選択されているときなど、手動でリクエストを呼び出したい。

どんな助けでも適用されます。

[アップデート]

Jan Dvorakのコメントに応えて：

検索ボックスに「e」と入力すると、「e」で始まる名前のイベントのリストが表示されます。

リクエストには、すべての有効なパラメータと次のようなペイロードが含まれます。

["{\"msg\":\"sub\",\"id\":\"8ef5e419-c422-429a-907e-38b6e669a493\",\"name\":\"event_Coll_Search_by_PromoterName\",\"params\":[\"e\"]}"]

そして、これは有効な応答です。

a["{\"msg\":\"data\",\"subs\":[\"8ef5e419-c422-429a-907e-38b6e669a493\"]}"]

このアクションのコードはここに掲載されています

しかし、自動再帰リクエストの場合、リクエストはペイロードなしで送信され、応答は文字「h」だけになります。これは奇妙なことです。ではない？どうすればこれを取り除くことができますか？

4

1 に答える 1

6

Meteor には、

ライブページの更新。

テンプレートを書くだけです。データベース内のデータが変更されると、それらは自動的に更新されます。定型的な再描画コードを書く必要はもうありません。あらゆるテンプレート言語をサポートします。

この機能をサポートするために、Meteor はバックグラウンドでサーバーとクライアントの通信を行う必要があります。

伝統的に、HTTP は死んだデータを取得するために作成されました。クライアントはサーバーに何かが必要であることを伝え、サーバーは何かを取得します。サーバーが何かが必要であることをクライアントに伝える方法はありません。その後、一部のデータをクライアントにプッシュする必要が生じました。いくつかの選択肢が生まれました：

ポーリング:

クライアントは定期的にサーバーにリクエストを送信します。サーバーは新しいデータで応答するか、すぐに「データがありません」と言います。実装は簡単で、多くのリソースを使用しません。ただし、正確にはライブではありません。ニュース ティッカーには使用できますが、チャット アプリケーションには適していません。

ポーリング頻度を上げると、更新レートは向上しますが、リソース使用量は、データ転送速度ではなく、ポーリング頻度とともに増加します。HTTP リクエストは決して安くはありません。同時に複数のクライアントからの 1 秒あたり 1 つの要求は、サーバーに大きな損害を与える可能性があります。

保留中のリクエスト:

クライアントはサーバーにリクエストを送信します。サーバーにデータがある場合は、それらを送信します。サーバーにデータがない場合は、データがあるまで応答しません。変更はすぐに取得され、必要のないときにデータが転送されることはありません。ただし、いくつかの欠点があります。

Web プロキシは、サーバーがサイレントであることを確認すると、最終的に接続を切断します。これは、送信するデータがなくても、プロキシ (および Web ブラウザー) を満足させるために、サーバーはキープアライブ応答を送信する必要があることを意味します。

ハングしているリクエストは帯域幅を (あまり) 使いませんが、メモリを消費します。最近のサーバーは複数の同時 TCP 接続を処理できるため、以前よりも問題は少なくなりました。考慮する必要があるのは、これらの要求を保持しているスレッドに関連付けられているメモリの量です。特に、接続が要求を処理する特定のスレッドに関連付けられている場合はそうです。

ブラウザには、ドメインごとおよび合計での同時リクエスト数に厳しい制限があります。繰り返しますが、これは以前よりも懸念が少なくなっています。したがって、セッションごとに 1 つの保留要求のみを使用することをお勧めします。

保留中のリクエストの管理は、応答ごとに新しいリクエストを作成する必要があるため、手動のように感じます。TCP ハンドシェイクにもある程度の時間がかかりますが、300 ミリ秒 (最悪の場合) の不応期に耐えることができます。

チャンクされた応答:

クライアントは、データ ストリームに対応するソースを持つ非表示の iFrame を作成します。サーバーはすぐに HTTP 応答ヘッダーで応答し、接続を開いたままにします。メッセージを送信するために、サーバーは<script></script>、ブラウザーが終了タグを受信したときに実行するタグのペアでメッセージをラップします。利点は、接続の再開がないことですが、各メッセージのオーバーヘッドが増えます。さらに、これには、応答が呼び出すグローバル スコープのコールバックが必要です。

また、クロスドメイン iFrame 通信には独自の問題があるため、これはクロスドメイン要求では使用できません。ここでは、サーバーを信頼する必要性も課題です。

ウェブソケット:

これらは通常の HTTP 接続として開始されますが、後で実際には HTTP プロトコルには従いません。プログラミングの観点からは、物事は可能な限り単純です。API は、クライアント側の古典的なオープン/コールバック スタイルであり、サーバーはメッセージをオープン ソケットにプッシュするだけです。各メッセージの後に何かを再度開く必要はありません。

まだ接続を開く必要がありますが、ブラウザの制限が邪魔にならないので、ここでは実際には問題ではありません。ブラウザは接続がしばらく開かれることを認識しているため、通常のリクエストと同じ制限を適用する必要はありません。

これらは理想的な解決策のように見えますが、大きな問題が 1 つあります: IE<10 はそれらを認識していません。IE8 が生きている限り、Web ソケットは信頼できません。また、ネイティブの Android ブラウザーと Opera mini も出ています ( ref. )。

それでも、IE8 (および IE9) が最終的に廃止された後は、Web ソケットが有効なようです。

表示されるのは、ライブ更新機能を実装するために使用される 25 秒のタイムアウトで要求がハングしていることです。既に述べたように、キープアライブ メッセージ ("h") は、ブラウザーが応答を受信しないと判断しないようにするために使用されます。「h」は単に「何も起こらない」という意味です。

Chrome は Web ソケットをサポートしているため、Meteor は長いリクエストへのフォールバックでそれらを使用できたかもしれませんが、率直に言って、一度実装すればハングするリクエストはまったく悪いことではありません (確かに、ブラウザーの接続制限は引き続き適用されます)。

于 2012-12-26T11:34:27.023 に答える