CometD のロング ポーリング メカニズムが永続的な接続を使用するのか、メッセージがプッシュされた後に切断してから再接続するのかについて、明確な答えを見つけることができませんでした。
これが私にとって重要な理由は、現在、すべてのメッセージ (またはメッセージのバッチ) がサーバーから送信された後に切断および再接続するロング ポーリング プッシュ クライアントを使用しているためです。取り除く。すべての「プッシュ」が非常に長いリクエスト/レスポンスのように見えるため、互換性のためにこれを行うと想定しています。これは、すべてのブラウザで動作するはずです。
では、CometD のロング ポーリングは永続的で長寿命の http 接続を使用するのでしょうか? 答えが「はい」の場合、それは条件付きですか? つまり、送信されたメッセージごとに「要求/応答/再接続」にフォールバックするケース/ブラウザーはありますか?
CometD のロング ポーリングは HTTP 1.1 を使用しているため、永続的な接続が行われます。
Connectionブラウザーから CometD を使用する場合、ブラウザーは接続プールと HTTP プロトコル バージョンを管理し、CometD はすべてのメッセージの後に接続を閉じるためのヘッダーを追加しません。 poll は常に同じ接続にとどまります。
CometD Java クライアント ライブラリを使用する場合も、同じことが当てはまります。Jetty の HTTP クライアントが接続プールを管理し、デフォルトで HTTP 1.1 に設定し、接続を開いたままにします。ブラウザーとの主な違いは、Jetty HTTP クライアントはドメインごとに少数 (通常は 6 つ) の接続を許可するため、負荷テストのシミュレーションに適していることです。CometDのパフォーマンス レポートをご覧ください。
最新の CometD ドキュメントはhttp://docs.cometd.orgにあります。
「定義上、ロング ポーリングは永続的な接続を使用せずに再接続する」というのは誤りです。HTTP 1.1 は、同じ接続を介して複数のロング ポーリングを送信することが完全に可能であり、CometD はまさにそれを行います。
Connection: closeHTTP 要求または応答にヘッダーを追加するアプリケーションによって明示的に要求されない限り (CometD はこれを行いません) 、HTTP 1.1 を使用しているときにブラウザーのようなクライアントが開く/要求する/応答する/閉じる動作にフォールバックするケースについては知りません。
WebSocket を使用すると、CometD は 1 つの接続のみを永続的に開き、アプリケーションが CometD クライアントを切断して接続を閉じることを決定するまで、すべてのメッセージがその接続を介して交換されます。