私の理解:
クライアントは、間隔 (1 秒など) ごとにサーバーにリクエストを作成します (リクエストを送信します)。
サーバー側にメッセージがある場合、サーバー側に新しいメッセージがあることをクライアントに通知するために、その情報が応答(レスポンス)にマークされます。
クライアントはメッセージをプルするリクエストをサーバーに送信し、サーバーが応答します。

リクエスト: 新しいニュースはありますか?受信されましたらご返信ください。
回答:いいえ。
リクエスト: 新しいニュースはありますか?受信されましたらご返信ください。
回答:いいえ。
リクエスト: 新しいニュースはありますか?受信されましたらご返信ください。
応答: はい、メッセージ ID は 123456 です。
リクエスト: メッセージ ID 123456 のメッセージ内容を送信してください。
応答: メッセージ ID: 123456、メッセージ テキスト: 驚きました!この女性は実際に13億人の前であんなことをしたのです…。

メッセージ送信は、サーバーがクライアントに直接送信するのではなく、クライアントをサーバーに更新することによって取得されます

以前は、確かにサーバーがローカルで直接ポートを開き、サーバーがクライアントに直接リクエストするケースもありましたが、現在ではメッセージプッシュ（通常はLAN内でのファイルや情報の転送に使用されます）に使用することはほとんどありません

セッションはサーバーに保存され、セッションの名前とIDはCookieを介してローカルに保存されます。サーバーはこれら2つを使用してサーバー側に保存されているコンテンツを取得します。

現在、一般的な解決策が 2 つあります。
1. クライアントはアクティブにポーリングします (つまり、N 回ごとにサーバーにニュースがあるかどうかを尋ねます)。
2. サーバーはアクティブにプッシュします。ソケットはバックエンド サービス間で使用され、WebSocket はバックエンド サービスとの通信に使用できます。フロントエンド

http2.0は非常にうまく処理できるので、試してみてください〜

それはインスタントであると言われており、長い接続を確立する必要があります。ソケットなど。

それが製品の多くの機能の 1 つにすぎない場合、インスタント メッセージングは​​対象者に IM に接続することを推奨します。これにより、開発費を大幅に節約できます。既存の IM プロバイダーが提供する機能は比較的包括的であり、それよりはるかに優れています。自分で開発するよりも費用対効果が高くなります。環境情報 http://www.easemob.com/