c++ - クライアント サーバー アーキテクトの設計方法

Question

修正サーバーを実装するために大規模なクライアント (少なくとも 10K) をサポートするためのサーバー (TCP ベース) アーキテクチャを知りたいです。私のポイントは、どのように設計するかです。開いているポートでリッスンするには? select または poll またはその他の関数を使用します。クライアントの応答を処理する方法は? 大規模な場合、クライアントごとに 1 つのスレッドを作成することはできません。応答の処理は別の実行可能ファイルにあり、IPC を介してサーバー実行可能ファイルへの要求と応答を共有する必要があります。それにはさらに多くのことがあります。誰かがそれを説明したり、リンクを提供したりしていただければ幸いです。ありがとう

Answer 1

このトピックに関する優れた情報源はThe C10K problemです。そこの寸法は少し古いように見えますが、テクニックは今日でも適用できます。

Answer 2

アーキテクチャは、クライアントの着信データで何をしたいかによって異なります。私の推測では、着信メッセージごとに何らかの計算を実行し、おそらく応答も返すでしょう。

その場合、すべての着信メッセージを受信する 1 つのメイン リスナー スレッドを作成します (実際には、ハードウェアに複数の物理ネットワーク デバイスがある場合は、デバイスごとにリスナー スレッドを使用し、それぞれが特定のデバイスをリッスンしていることを確認します)。 . マシンにある CPU の数を取得し、各 CPU のワーカー スレッドを作成し、各スレッドを 1 つの cpu にバインドします (リスナーとディスパッチャーに使用可能な cpu を残すために、作業スレッドの数は num_of_cpu-1 にする必要があります)。

各スレッドにはキューとセマフォがあり、メインのリスナー スレッドは受信データをこれらのキューにプッシュするだけです。負荷分散を実行する方法はたくさんあります (後で説明します)。

作業中の各スレッドは、与えられたリクエストを処理し、ディスパッチャーによって読み取られる別のキューに応答を置きます。

ディスパッチャー - ここには 2 つのオプションがあります。ディスパッチャーにスレッドを使用する (またはリスナーの場合はネットワーク デバイスごとにスレッドを使用する) か、ディスパッチャーを実際にリスナーと同じスレッドにするかです。両方を同じスレッドに配置すると、ソケット接続が失われたことを検出しやすくなり、スレッド同期なしで読み取りと書き込みの両方に同じ fds を使用することが容易になるため、いくつかの利点があります。ただし、2 つの異なるスレッドを使用するとパフォーマンスが向上する可能性があるため、テストする必要があります。

ロード バランシングに関する注意: これは独自のトピックです。最も簡単な方法は、すべての作業スレッドに対して 1 つのキューを使用することですが、アイテムをポップするためにスレッドをロックする必要があり、ロックによってパフォーマンスが低下する可能性があるという問題があります。（ただし、最もバランスの取れた負荷が得られます）。

もう 1 つの非常に単純な方法は、すべてのワーカーにプライベート キューを用意し、挿入時にラウンド ロビンを実行することです。X サイクルごとに、すべてのキューのサイズを確認します。一部のキューが他のキューよりもはるかに大きい場合は、次の X サイクルの間それらを除外し、再度チェックします。これは最善の方法ではありませんが、簡単に実装でき、ロックを必要とせずに負荷分散を行うことができます。

ところで、ブロックせずに 2 つのスレッド間でキューを実装する方法がありますが、これもまた別のトピックです。

お役に立てば幸いです、ガイ

Answer 3

クライアントとサーバーが安全なネットワーク上にある場合、転送が暗号化されている限り、セキュリティ面は最小限に抑える必要があります。クライアントとサーバーが安全なネットワーク上にない場合、まずサーバーとクライアントが相互に認証してから、暗号化されたデータ転送を開始します。データ転送の場合、サーバー側の認証で十分です。この認証の最後に、セッション キーを使用して暗号化されたデータ ストリーム (対称) を生成します。TFTP の使用を検討してください。TFTP は実装が簡単で、適切に拡張できます。