ウェブソケットとターンベースのゲームサーバーのロングポーリングの違い

Question

IOSゲーム用のサーバーを作成しています。ゲームはターンベースであり、サーバーがクライアントに情報をプッシュする必要があるのは、相手の動きを通知することだけです。

Websocketを使用した場合と長時間ポーリングを行った場合のパフォーマンスと実装の容易さの違いについてコメントできる人がいれば興味があります。また、websocketを使用した場合、情報を受信して他のすべてのPOSTリクエストを送信するためだけに使用する必要がありますか、またはすべての通信はwebsocketを介して行う必要がありますか？

さらに、Webクライアントの作成にも興味がある場合、Webソケットと長いポーリングの間に考慮すべき点はありますか？

Tharif · Accepted Answer

ロングポーリングとは何ですか？

従来のポーリングテクニックのバリエーションであり、サーバーからクライアントへの情報プッシュのエミュレーションを可能にします。長いポーリングでは、クライアントは通常のポーリングと同様の方法でサーバーに情報を要求します。

サーバーがクライアントに利用可能な情報を持たない場合、空の応答を送信する代わりに、サーバーはリクエストを保持し、利用可能な情報を待ちます。
情報が利用可能になると（または適切なタイムアウト後）、完全な応答がクライアントに送信されます。通常、クライアントはすぐにサーバーから情報を再要求します。そのため、サーバーは、イベントに応じてデータを配信するために使用できる待機リクエストをほとんど常に持っています。

Web/AJAXコンテキストでは、ロングポーリングはCometプログラミングとも呼ばれます。

Websocketsはどうですか？

WebSocketsは、クライアントとサーバー間の永続的な接続を提供し、両者はいつでもデータの送信を開始するために使用できます。

クライアントは、WebSocketハンドシェイクと呼ばれるプロセスを介してWebSocket接続を確立します。このプロセスは、クライアントが通常のHTTP要求をサーバーに送信することから始まります。
このリクエストにはUpgradeヘッダーが含まれており、クライアントがWebSocket接続の確立を希望していることをサーバーに通知します。

結論：

リアルタイム通信が必要な場合は、websocketsを選択できます。

しかし、ロングポーリングでは：

WebクライアントとWebサーバーの間の接続は開いたままであるため、サーバーが新しい情報を取得すると、それをクライアントにプッシュできます。その後、その要求は終了します。次に、クライアントとサーバーの間で新しい要求が行われ、サーバーからの別の更新を待ちます。 HTTP/1.1キープアライブにより、同じTCP接続は通常、複数のリクエスト全体で持続的に開かれます。