0

クライアント サーバー モデルに関していくつか質問があります。私の現在のアプリケーション (または私が提案したアプリケーション) は中央サーバーを使用しており、さまざまなクライアントがそれに接続できます。

(質問に答えたいが、それについて知らない人のための O(n) の簡単な説明。Google で検索するか、次の例に従ってください。

n 個の要素を持つリストを考えてみましょう。O(1) は要素を選択するだけでよいことを意味し、O(n) は基本的に、必要なアイテムを取得するためにすべての要素 (したがって n 要素) を反復処理する必要があることを意味します。そして、O(log n) は、再帰的な細分化を行う必要がある中間の方法であり、O(n) よりもはるかに高速ですが、O(1) ほど高速ではありません。)

質問1：

ユーザーのレコードを効率的に取得するにはどうすればよいですか。ある時点でサーバーが何人のユーザーを処理する必要があるかはわかりませんが、O(1) を実装するのが合理的である場合、O(n) 操作だけでは不十分であると強く信じています。

最初の部分はログイン手順についてです。ユーザーが個人識別子 (ユーザー名/電子メール/など) とパスワードを使用してログインできるようにする予定です。この情報は、誰かがログインしようとするとサーバーに送信されます。

さらに、データベース（MySQLなど）を直接使用するのではなく、純粋に「バックアップ」の目的で使用する予定です（サーバーは、可能であればすべての情報をRAMに保存し、電源が入ったときに何も失われないようにデータベースにのみ書き込む必要があります失った）。

したがって、基本的にサーバーはクライアント データ (個人識別子だけでなく一意の ID も含む) を保存する必要があります。

私の現在のアイデア:

  1. リストに保存しますが、ユーザーの検索 (およびその情報の検証) には、並べ替えに応じて O(n) 時間がかかる場合があります。ユーザー名でアルファベット順の並べ替えを行うと、O(log n) に削減できます。 .

  2. 2 番目の提案は、UniqueID をキーとして Client[] 配列に格納することです。次に、O（1）でのアクセスが可能になるはずですが、これは理想的ですが、そのアプローチで私が抱えている問題は、ユーザーが入力してサーバーに送信する個人識別子（ユーザー名など）をどのように変換するかです.一意のID？リストのようなものを使用すると、時間は再び O(n) になります。さらに、配列のサイズが不均衡に大きくなることはありません。たとえば、ユーザー名のハッシュが理想的だとは思いませんし、一意の ID が作成されるかどうかもわかりません。

質問2：

第二に、もちろんユーザーデータも安全にしたいです。ここで、基礎となる MySQL サーバー (起動時にデータがサーバーの RAM にロードされる) が安全であると仮定します。

それでは、これらの条件を考えると、保存されたパスワード (もちろん暗号化されています) も安全なのでしょうか?

  1. サーバーに直接物理的にアクセスできるものはありません。

  2. 通信プロトコルには、パスワード情報またはパスワード情報を含むスーパーセットを取得するためのコマンドがありません。つまり、サーバーはいかなる状況下でもパスワードを提供しません。

  3. パスワードは、サーバーの RAM にある Client オブジェクトにプライベート変数として保存されます。

  4. ユーザーが入力した情報が正しいかどうかを確認するために、 Client オブジェクトには のような関数がありますclient.confirmPassword(password)。

忘れていない限り、通信プロトコルを介してのみ外部の世界に接続されているサーバーの RAM を直接読み取ることができるかという問題が基本的に解決されますか?

投稿はかなり長いことが判明しましたが、これらの質問に答えてくれる人が周りにいることを願っています:)

4

4 に答える 4

1

質問1）

ハッシュマップの使用を検討します。O（1）にアクセスできます。複数のハッシュマップを使用することもできます:

  • userById のマップ
  • userByName のマッピング

並行性があるため、さまざまなマップの実装を確認する必要があります。

質問2）

パスワードが適切に暗号化されている限り、問題ないと思います。通常の状況では、サーバーのメモリは安全であると見なされます。

おそらく、この他の質問はあなたにとって興味深いものです: パスワードをデータベースに保存する最良の方法

于 2013-05-03T17:11:31.780 に答える
1
  1. 簡単な答えは、データベースを使用することです。なぜなら、他の誰かがすでに時間をかけてデータベースを高速化し、最適化するためです。パフォーマンスに役立つキャッシングやインメモリ テーブルなどの mysql 機能を確認できます。ただし、データベースを本当に使用したくない場合は、ユーザー名をハッシュする必要があります。ユーザー名が一意である必要がある場合、適切なハッシュは常に一意の ID を提供します。他のオプションを調べることに興味がある場合は、TreeMaps などを調べることもできます。
  2. それは本当にあなたが最も心配していることに依存します. 優れたハッカーは、予想もしなかったあらゆる種類の驚くべきことを行うことができます。最善の防御策は、サーバー上で実行されている必要のないものをすべてアンインストールし、使用していないポートをすべて閉じることです。
于 2013-05-03T17:15:13.163 に答える
1

間違った理由を心配している

  1. データベース システムは複雑なシステムであるということを理解しておく必要があります。検索クエリは非常に複雑ですが、パフォーマンスは非常に高く、必要な場所で使用することを恐れる必要はありません。データベースシステムは実際にアクティブなデータベースのすべての情報をメモリに取得します...そしてそれらはキャッシュされ、サービスが閉じられるとハードドライブに書き込まれます:これはあなたがやり直そうとしていることです.
  2. MD5 と SHA1 は、パスワードの代わりに直接保存できる強力なハッシュです。これらの呼び出しは、ほとんどのプログラミング言語で見つけることができます。これらのハッシュをデータベースに保存し、ハッシュを比較できます。これは非常に安全です。

データベースやライブラリなど、ソリューションがすでに構築されているものを実行する方がはるかに簡単です。それらはパフォーマンスのために作成されており、間違った入力に対して非常に耐性があり、最悪のシナリオに対処するためのより良い方法もあります。

于 2013-05-03T17:02:39.520 に答える