まず、このメカニズムの目的について説明します。これまで、Battlefield はこのメカニズムに 2 つの用途があることを認識していました。
まず、マルチサーバー共有セッションの問題ですが、これはユーザーの数が増えると誰もが理解できるはずです。 Web サイトが大きすぎる場合は、ログイン用の専用サーバーなどのサーバー クラスターが使用されます。ユーザーがログイン サーバーを介してログインした後、ログイン サーバーはユーザーのログイン情報セッションを保存しますが、ムービー サーバーなどの他のアクセスされたサーバーにはこのセッションがありません。その場合は、ユーザーの一意の識別子を介してこのセッションを共有する必要があります。 session - 特定のセッション 共有についてはこの記事の範囲外です。情報はご自身で確認してください。
2 番目の目的は、同じユーザーの異なるセッションを検証することですが、これは理解するのがさらに困難です。言い換えると、ユーザーがブラウザー経由で接続を要求せず、ソケットまたはその他の方法でデータを要求する場合、まずユーザーのログイン検証を実行する必要があります。検証が成功した後、セッション ID を発行します。彼は、リクエストを行うたびにこのセッション ID を保持します。このセッション ID を使用して、セッションがすでに存在するかどうかを判断します。セッションが存在する場合は、ユーザーがログインしていると見なされます...
最初の質問については、これを実現するには、セッション ID をデータベースに保存できます。この方法は比較的安全で広く使用されていますが、これは私たちの議論の範囲ではありません
2 番目の質問は実際には非常に簡単です
まず、セッション ID は検証中に生成されます。