Webプログラミングでポーリングが受け入れられるのはなぜですか？

現在、画像のリストを表示するRuby on Railsプロジェクトに取り組んでいます。

このプロジェクトの必需品は、Webページを更新する必要なく、リアルタイムで新しい投稿を表示することです。しばらく検索した後、PubNubなどのJavaScriptソリューションとサービスに出くわしました。ただし、提供されたソリューションはどれも意味がありません。

JavaScriptソリューション（ポーリング）では、次のことが起こります。

• ユーザー1が写真のリストを表示します。
• バックグラウンドでは、JavaScriptコードがエンドポイントを1秒ごとにポーリングして、新しい投稿があるかどうかを確認しています。
• ユーザー2が新しい写真を追加します。
• 新しいサイクルがトリガーされ、新しいデータを取得するまでに50ミリ秒の遅延があります。
• 新しいコンテンツがDOMにロードされます。

これは実世界の例に翻訳すると奇妙に思えます：

• ユーザー1は、自分の机に写真の山を持っています。
• 彼/彼女は毎秒カメラマンのところへ歩いて行き、彼が新しいものを持っているかどうか尋ねます。
• 写真家は新しい写真を作成します。
• 彼/彼女が中に入るとき、彼女は写真を撮り、それを山に置くことができます。

私の意見では、解決策は次のようにする必要があります：

• ユーザー1は、自分の机に写真の山を持っています。
• 写真家は新しい写真を撮ります。
• 写真家は山まで歩いて、残りの部分と一緒に置きます。

PubNubソリューションは基本的に同じですが、今回はデータを共有するために当事者間でのインターンがあります。

言うまでもなく、両方のソリューションは、ロードするデータがない場合でもトリガーされるため、非常にエネルギーを消費します。

私の知る限り、ほとんどすべてのリアルタイムアプリケーションでこの実装方法が使用されている理由（論理）は説明されていません。

プッシュは、1人または限られた数のユーザーに適しています。

1人の写真家と1000人のユーザーが全員写真のコピーを必要とするシナリオを変更します。写真家は1000本の山まで歩かなければなりません。それらのいくつかは、ロックされたオフィスにあるか、床全体に広がっている可能性があります。または休暇中のユーザーで、現時点では新しい写真に興味がない。

写真家はいつも歩くのに忙しく、新しい写真を撮ることはありません。

基本的に：プル/ポールモデルは、リアルタイム要件が緩い多くの信頼性の低い読者に合わせて拡張できます（写真が山に到着するまでに10秒かかる場合、大したことです）。

とはいえ、プッシュモデルは多くの状況で優れています。低レイテンシが必要な場合（新しい写真が撮影されてから5秒後に必要）、または更新がまれであり、頻繁かつ予測可能なリクエストが必要な場合（写真家が1日に新しい写真を生成するときに10秒ごとに質問してください）、プルは不適切です。それはあなたが何をしようとしているかに依存します。ナスダック：プッシュ。気象サービス：プル。結婚式の写真家：おそらくプル。ニュース写真代理店：おそらくプッシュ。

WebSocketsについて言及しているのは1人だけだと本当に驚いています。サポートは基本的にすべての主要なブラウザに実装されています。

実際、PubNubはそれらを使用します。アプリケーションの場合、ブラウザはおそらく新しい写真が利用可能になるたびにブロードキャストするソケットをサブスクライブします。ソケットは写真を送信しませんが、ブラウザーが非同期でダウンロードできるようにリンクだけを送信します。

あなたの例では次のようなものを想像してください：

1. ユーザーは、今後のすべての写真について知りたいことを写真家に知らせる
2. 写真家は、スピーカーで新しい写真が利用可能であると言います
3. ユーザーが写真家に写真を求めます

これは、元のサンプルソリューションに似ています。クライアントはサーバーにデータを送信する必要がないため、ポーリングよりも効率的です（ハートビートを除く）。

また、他の人が言及したように、古いブラウザで機能する単純なポーリングよりも優れた他の方法があります（ロングポーリングなど）。

時には十分で十分です。

「リアルタイム」通信プロセスを実装するすべての可能な方法のうち、おそらくポーリングが最も簡単な方法です。ポーリング間隔が比較的長い場合（つまり、瞬時ではなく秒、分、または時間）、接続またはリソースのチェックによって消費されるクロックサイクルが実際に重要でない場合、ポーリングを効果的に使用できます。

HTTPプロトコルは、クライアントが要求を開始するものでなければならないという点で制限されています。サーバーは、クライアントの要求に応答しない限り、クライアントと通信できません。

したがって、実際の例を調整するには、次の制限を追加します。

• ユーザー2は、ユーザー1の質問に1文の返信でのみ応答でき、その後ユーザー1は退出する必要があります。ユーザー2には他の通信方法はありません。

この新しい抑制により、ポーリング以外でどのようにそれをしますか？

ポーリングが受け入れられるのはなぜですか？実際には、すべてのソリューションは実際には低レベルのポーリングであるためです！

新しい画像が利用可能になり次第サーバーが更新する場合、通常はIPアドレスが頻繁に変更され、誰かがもう興味がないかどうかわからないため、クライアントは何らかの形でキープアライブ信号、たとえば、「まだここにいる、オフラインではない」

インターネットを介して送信できるデータパケットは1つだけなので、すべてのステートフル接続（TCP / IPなど）は同じように機能します。相手がまだそこにいるかどうかはわかりません。

したがって、すべてのプロトコルにはタイムアウトがあります。エンティティがX秒以内に応答しない場合、死んでいると推定されます。したがって、データを送信せずにサーバーとクライアントの間に開いている接続しかない場合でも、サーバーとクライアントは通常のキープアライブパケットを送信する必要があります（これらの接続を開いた場合、これは低レベルで処理されます）これは最終的にポーリングとは異なりますか？

したがって、おそらく最善のアプローチはロングポーリングです。

クライアントは、サイトをロードした直後にリクエストを送信します（たとえば、写真家に「新しい写真がある場合は教えてください」と伝えます）が、新しい写真がない場合、サーバーは応答しません。リクエストがタイムアウトするとすぐに、クライアントは再度尋ねます。

サーバーに新しい画像がある場合、新しい画像の列に並ぶすべてのクライアントにすぐに応答できます。したがって、クライアントはまだオープン接続で応答を待機しており、クライアントへの接続を確立する必要がないため、新しい写真を作成した後の反応時間はプッシュよりもさらに短くなります。また、クライアントからのポーリング要求は、クライアントとサーバー間の一定の接続よりもはるかに多くのトラフィックではありません！

ポーリングの利点の1つは、メッセージが欠落した場合や何かの状態がグリッチになった場合に発生する可能性のある害を制限することです。Xが5秒ごとにYの状態を要求すると、要求または応答が失われると、Xの情報は5ではなく10秒だけになります。Yがリブートされると、Xは次のことを知ることができます。時間YはXのメッセージの1つに応答できます。Xがリブートされた場合、その後Yに何かを尋ねることは決してないかもしれませんが、Xのステータスを監視している人は、Xがリブートされたことを認識するはずです。

XがYをポーリングする代わりに、XがYに依存してその状態が変化するたびに通知し、Yの状態が変化してメッセージをXに送信したが、何らかの理由でそのメッセージが受信されなかった場合、Xはその変化に気付かない可能性があります。同様に、Yがリブートされ、Xに何かに関するメッセージを送信する理由がない場合。

場合によっては、XがYに定期的にまたは変化したときにYがそのステータスをメッセージとして自律的に送信し、Yから何も聞かずに長すぎる場合にのみXポーリングを要求することが役立つ場合があります。そのような設計は、 Xがそのメッセージの大部分を送信する必要がある（通常、Xは少なくともメッセージの受信にまだ関心があることを少なくとも時々Yに通知する必要があり、Yは関心が示されずに長すぎる場合はメッセージの送信を停止する必要があります）。ただし、このような設計では、Yを永続的に使用する必要がありますXについての情報を維持し、それをポーリングした人に返信を送信し、それが誰であったかをすぐに忘れることはできません。Yが組み込みシステムである場合、このような単純化は、より小さくて安価なコントローラーを使用できるように、メモリ要件を十分に削減するのに役立ちます。

ポーリングは、信頼できない可能性のある通信媒体（UDPやラジオなど）を使用する場合に追加の利点があります。リンク層の確認応答の必要性を大幅に排除できます。XがステータスリクエストQをYに送信し、YがステータスレポートRで応答し、XがRを聞くと、XはQが受信したことを知るためにリンクレイヤーの肯定応答を聞く必要はありません。逆に、YがRを送信すると、Xがそれを受信したかどうかを知る必要も気にする必要もありません。Xがステータスリクエストを送信し、応答がない場合、別のリクエストを送信できます。Yがレポートを送信し、Xがそれを聞かない場合、Xは別のリクエストを送信します。各要求が1回送信され、応答が返されるか返されない場合、どちらの当事者も特定のメッセージが受信されたかどうかを知る必要も気にする必要もありません。確認応答を送信すると、ステータスリクエストまたはレポートとほぼ同じ帯域幅を消費する可能性があるため、要求レポートの往復を使用することは、非請求レポートおよび確認よりも多くの費用はかかりません。Xが応答を取得せずにいくつかのリクエストを送信する場合、一部の動的にルーティングされたネットワークでは、リンクレベルの確認を有効にする必要があります（そして、リクエストでYが同様に行うように要求します）。新しいルートですが、物事が機能している場合、リクエストレポートモデルはリンクレベルの承認を使用するよりも効率的です。

問題は、不要なポーリングの量と不要なプッシュの量のバランスをとることです。

ポーリングする場合：

• この瞬間に答えが得られます。たまにしか尋ねない場合や、この瞬間にデータセットが必要な場合に適しています。
• 「コンテンツなし」という回答が返され、回線に無意味な負荷がかかる場合があります。
• ポーリングするときだけ回線に負荷をかけますが、常にポーリングするときです。

プッシュした場合：

• 回答が利用可能になったらすぐに配信するため、クライアント側ですぐに処理できます。
• このデータに関心のないクライアントにデータを配信すると、回線に無意味な負荷がかかる可能性があります。
• 新しいデータがあるたびに回線に負荷をかけますが、新しいデータがある場合のみです。

さまざまなシナリオとその短所に対処する方法には、たとえば、ポーリング間の最小時間、メインシステムから負荷を取り除くためのポーリングのみのプロキシ、または-プッシュの場合-登録して指定する規制など、いくつかのソリューションがあります必要なデータに続いて、ログオフ時に登録解除します。どちらが最適かは、一般的に言うことはできません。システムによって異なります。

あなたの例では、ポーリングは最も効率的なソリューションではありませんが、最も実用的なソリューションです。JavaScriptでポーリングシステムを作成するのは非常に簡単であり、配信側でもポーリングシステムを実装するのは非常に簡単です。画像データを配信するように作られたサーバーは、追加のリクエストを処理できる必要があります。そうでない場合、データはほとんど静的であるため、簡単にキャッシュできるため、線形にスケーリングできます。

ログイン、必要なデータの説明、最後にログオフを実装するプッシュメソッドは最も効率的ですが、平均的な「スクリプトキディ」にはおそらくあまりにも複雑であり、次の質問に対処する必要があります。ブラウザをシャットダウンしてログオフを実行できませんか？

たぶん、別のキャッシュサーバーにいくらかのお金を節約するよりも、より多くのユーザーがいる方が良いでしょう（アクセスは簡単です）？

何らかの理由で、最近では、すべての若いWeb開発者が過去の教訓を忘れてしまったようです。

1. 帯域幅が問題でした
2. 接続が断続的になる可能性があります。
3. ブラウザにはそれほど多くの計算能力がありませんでした
4. コンテンツにアクセスする他の方法がありました。Webはw3ではありません。

これらの制約に直面して、一定の双方向通信ができない場合があります。そして、OSIモデルを見ると、ほとんどの考慮事項は永続性を基礎となる接続から切り離すことを意味していることがわかります。

それを念頭に置いて、情報をプルするポーリング方法は、クライアント側の帯域幅と計算を削減するための優れた方法です。プッシュの台頭は、ほとんどの場合、クライアントが絶え間ないポーリングまたはWebソケットを実行することだけです。個人的に私が他のみんななら、私はトラフィック分析の手段としてポーリングの規則性を高く評価します。時間外のGET / POST要求はある種の中間の状況の男性に信号を送ります。