Workermanはユーザーをどのように区別しますか

workerman自体は、ユーザー名やIDなどの一意の識別子を使用して、データベース支援アプリケーションの方法でユーザーを本質的に区別しません。 Workermanは、高性能の非同期イベント主導型フレームワークです。それはサーバーとして機能し、接続を管理し、リクエストを処理しますが、接続されたクライアントのIDについて本質的に「知りません」。 ユーザーの識別と管理は、Workermanの上に構築されたApplication Logicによって処理される責任です。 一般的なアプローチには、次のものが含まれます。

セッションIDS：

アプリケーションは、各接続クライアントの一意のセッションIDを生成し、関連するユーザーデータ（認証されている場合）とともに、データベース、キャッシュ（Re​​disやMemcachedなど）、またはワークエマンプロセス自体（小規模なアプリケーションのために）内でさえも保存できます。 クライアントからの後続のリクエストには、セッションIDが含まれているため、アプリケーションがユーザーの情報を取得できます。 認証が成功すると（ユーザー名/パスワードを使用するなど）、アプリケーションはクライアントに一意のトークンを発行します。このトークンはその後のリクエストに含まれており、アプリケーションが機密情報を絶えず送信する必要なくユーザーのIDを検証できるようにします。 JWT（JSON Web Tokens）は、これに人気のある選択肢です。

• >WebSocketsおよび一意のクライアントID：WebSocketsを使用する場合、接続自体を活用して、その接続の範囲内でユーザーを暗黙的に識別できます。ただし、これは同じユーザーからの複数の接続にわたって機能しません。さまざまな接続やセッションでユーザーを追跡する場合は、堅牢なセッション管理システムが必要になります。
• 本質的に、Workermanはインフラストラクチャを提供します。アプリケーションコードは、ユーザーの区別と管理方法を定義します。 各接続の新しいスレッドまたはプロセスを作成する代わりに、Workermanは単一のスレッド（またはスレッドの小さなプール）を使用して、イベント駆動型モデルを使用して多数の接続を同時に管理します。クライアントがデータを接続または送信すると、Workermanはイベントを登録し、ブロッキングせずに他のイベントの処理を継続します。 これは、特に重い負荷の下で、従来のスレッドベースまたはプロセスベースのサーバーよりもはるかに効率的です。
  • イベント駆動型アーキテクチャ：Workermanの効率の中核。 イベント（接続確立、データ受信、切断など）は非同期に処理され、多くのクライアントに同時に応答できるようにします。 より多くの労働者がより並行した接続を処理できますが、各労働者はリソースを消費します。
  • 接続プーリング（データベースインタラクション用）：ワークマンのコア機能の一部ではありませんが、データベースインタラクション用の接続プールを使用して（アプリケーションがデータベースと対話する場合）。ユーザーの認証と承認？
  • workerman自体は、組み込みの認証または承認メカニズムを提供していません。 これらの機能は、アプリケーションロジック内に実装する必要があります。 Workermanは単に通信層を提供するだけです。 外部認証システムと統合するか、独自のものを構築する必要があります。認証と承認をWorkermanと統合するための一般的なアプローチは次のとおりです。

  承認、ユーザーが認証されると、通常、ユーザーの役割またはアカウントに関連付けられたアクセス許可をチェックすることが含まれます。 これには、アプリケーションで定義されているアクセス制御リスト（ACLS）に対するデータベースクエリまたはチェックを含む場合があります。 基礎となる通信レイヤーを提供しますが、セッション管理の責任はアプリケーションにかかっています。 ただし、その非同期性は、適切なテクニックと組み合わされた場合、効率的なセッション管理に適しています。

  • セッションストレージメカニズムの使用：これは、データベース、キャッシュ（redis、memcached）、またはインメモリストア（小規模アプリケーション用）である可能性があります。

以上がWorkermanはユーザーをどのように区別しますかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。