Loading article…
クライアント/サーバーモデルは、分散アプリケーション構造におけるメッセージングパターンの一種で、リソースまたはサービスのプロバイダー（サーバーと呼ばれる）とサービス要求者（クライアントと呼ばれる）の間でタスクまたはワークロードを分割します。[ 1 ]クライアントとサーバーは、多くの場合、別々のハードウェア上のコンピュータネットワークを介して通信しますが、クライアントとサーバーの両方が同じデバイス上にある場合もあります。サーバーホストは、1 つ以上のサーバープログラムを実行し、それらのリソースをクライアントと共有します。クライアントは通常、コンピューティングリソースを共有しませんが、サーバーからコンテンツまたはサービスを要求し、要求の一部として自身のコンテンツを共有する場合があります。したがって、クライアントはサーバーとの通信セッションを開始し、サーバーは受信要求を待ちます。クライアント/サーバーモデルを使用するコンピュータアプリケーションの例としては、電子メール、ネットワーク印刷、ワールドワイドウェブなどがあります。
サーバーコンポーネントは、1つまたは複数のクライアントに対して機能またはサービスを提供します。クライアントは、これらのサービスに対する要求を開始します。サーバーは、提供するサービスによって分類されます。たとえば、WebサーバーはWebページを提供し、ファイルサーバーはコンピュータファイルを提供します。共有リソースは、プログラムやデータからプロセッサやストレージデバイスまで、サーバーコンピュータのソフトウェアや電子コンポーネントのすべてである可能性があります。サーバーのリソースを共有することがサービスを構成します。
コンピュータがクライアント、サーバー、またはその両方であるかは、サービス機能を必要とするアプリケーションの性質によって決まります。たとえば、1台のコンピュータでWebサーバーとファイルサーバーソフトウェアを同時に実行して、異なる種類の要求を行うクライアントに異なるデータを提供することができます。クライアントソフトウェアは、同じコンピュータ内のサーバーソフトウェアと通信することもできます。[ 2 ]データの同期など、サーバー間の通信は、サーバー間通信またはサーバー間通信と呼ばれることもあります。
一般的に、サービスとはコンピュータ資源の抽象化であり、クライアントはサーバーが要求を処理し応答を配信する際の動作について気にする必要はありません。クライアントは、関連するアプリケーションプロトコルに基づいて応答を理解するだけでよく、つまり、要求されたサービスのデータのコンテンツとフォーマットを理解するだけでよいのです。
クライアントとサーバーは、リクエスト・レスポンス型のメッセージングパターンでメッセージを交換します。クライアントがリクエストを送信し、サーバーがレスポンスを返します。このメッセージの交換は、プロセス間通信の一例です。通信するには、コンピュータは共通の言語を持ち、クライアントとサーバーの両方が何を期待できるかを理解できるようにルールに従う必要があります。通信の言語とルールは、通信プロトコルで定義されます。すべてのプロトコルはアプリケーション層で動作します。アプリケーション層プロトコルは、対話の基本的なパターンを定義します。データ交換をさらに形式化するために、サーバーはアプリケーションプログラミングインターフェイス（API）を実装する場合があります。[ 3 ] APIは、サービスにアクセスするための抽象化レイヤーです。通信を特定のコンテンツ形式に制限することで、解析が容易になります。アクセスを抽象化することで、クロスプラットフォームのデータ交換が容易になります。[ 4 ]
サーバーは短時間のうちに多数の異なるクライアントからリクエストを受け取る可能性があります。コンピュータは一度に処理できるタスク数に限りがあるため、クライアントからのリクエストの優先順位付けを行うスケジューリングシステムに依存しています。不正利用を防ぎ、可用性を最大限に高めるため、サーバーソフトウェアはクライアントの可用性を制限する場合があります。サービス拒否攻撃は、サーバーに過剰なリクエストレートを送り込むことで、リクエスト処理の義務を悪用するように設計されています。クライアントとサーバー間で機密情報をやり取りする場合は、暗号化を適用する必要があります。
銀行の顧客がウェブブラウザ（クライアント）を使用してオンラインバンキングサービスにアクセスすると、クライアントは銀行のウェブサーバーにリクエストを送信します。顧客のログイン認証情報はデータベースと照合され、ウェブサーバーはクライアントとしてそのデータベースサーバーにアクセスします。アプリケーションサーバーは、銀行の業務ロジックを適用して返されたデータを解釈し、その結果をウェブサーバーに出力します。最後に、ウェブサーバーは結果をクライアントのウェブブラウザに返して表示します。
クライアントとサーバー間のメッセージ交換の一連の各ステップにおいて、コンピュータは要求を処理し、データを返します。これが要求応答型のメッセージングパターンです。すべての要求が満たされると、一連の処理は完了します。
サーバーサイドとは、サーバー上で実行されるプログラムや操作を指します。これは、クライアント上で実行されるクライアントサイドのプログラムや操作とは対照的です。
「サーバーサイドソフトウェア」とは、 Webサーバーなどのコンピュータアプリケーションを指し、ユーザーのローカルコンピュータ、スマートフォン、またはその他のデバイスからアクセスできるリモートサーバーハードウェア上で動作します。 [ 5 ]操作は、クライアント では利用できない情報や機能へのアクセスが必要な場合、またはクライアント側でそのような操作を実行すると、処理が遅くなったり、信頼性が低くなったり、安全性が損なわれたりする場合に、サーバーサイドで実行されることがあります。
クライアントプログラムとサーバープログラムは、無料または商用のWebサーバーやWebブラウザなど、一般的に入手可能なものを使用し、標準化されたプロトコルを用いて相互に通信する場合もあれば、プログラマーが独自のサーバー、クライアント、および通信プロトコルを作成し、それらが相互にのみ使用できる場合もある。
サーバー側の操作には、クライアントの要求に応じて実行される操作と、メンテナンス作業などのクライアント指向ではない操作の両方が含まれます。[ 6 ] [ 7 ]
コンピュータセキュリティの文脈では、サーバー側の脆弱性や攻撃とは、クライアント側やその中間ではなく、サーバーコンピュータシステム上で発生するものを指します。たとえば、攻撃者は、WebアプリケーションのSQLインジェクションの脆弱性を悪用して、サーバーのデータベース内のデータを悪意を持って変更したり、不正アクセスしたりする可能性があります。あるいは、攻撃者は、基盤となるオペレーティングシステムの脆弱性を利用してサーバーシステムに侵入し、サーバーの正規管理者と同様の方法でデータベースやその他のファイルにアクセスできるようになる可能性があります。[ 8 ] [ 9 ] [ 10 ]
SETI@homeやGreat Internet Mersenne Prime Searchのような分散コンピューティングプロジェクトの場合、操作の大部分はクライアント側で行われますが、サーバーはクライアントの調整、分析対象データの送信、結果の受信と保存、プロジェクト管理者へのレポート機能の提供などを担当します。Google Earthのようなインターネットに依存するユーザーアプリケーションの場合、地図データのクエリと表示はクライアント側で行われますが、サーバーは地図データの永続的な保存、ユーザーからのクエリをクライアントに返す地図データに変換することなどを担当します。
ウェブアプリケーションやサービスは、標準規格に準拠したウェブブラウザが利用できる形式でデータを返すことができれば（場合によっては中間プログラムを介して）、ほぼあらゆる言語で実装できます。
クライアント側とは、コンピュータネットワークにおいてクライアントによって実行される操作を指します。
通常、クライアントとは、 Webブラウザなどのコンピュータアプリケーションであり、ユーザーのローカルコンピュータ、スマートフォン、またはその他のデバイス上で動作し、必要に応じてサーバーに接続します。クライアント側で操作を実行する必要がある理由は、クライアント側で利用可能な情報や機能へのアクセスが必要な場合、ユーザーが操作を監視したり入力を提供したりする必要がある場合、またはサーバーがすべてのクライアントに対してタイムリーに操作を実行する処理能力を備えていない場合などです。さらに、ネットワーク経由でデータを送信せずにクライアント側で操作を実行できる場合、処理時間が短縮され、帯域幅の使用量が少なくなり、セキュリティリスクも低減されます。
サーバーがHTTPやFTPなどの標準プロトコルに従って一般的に使用される方法でデータを提供する場合、ユーザーは複数のクライアントプログラムから選択できます（例えば、最新のWebブラウザのほとんどはHTTPとFTPの両方を使用してデータの要求と受信が可能です）。より特殊なアプリケーションの場合、プログラマは独自のサーバー、クライアント、および通信プロトコルを作成することができ、それらは相互にのみ使用できます。
ネットワークを介してデータの送受信を行わず、ユーザーのローカルコンピュータ上で実行されるプログラムはクライアントとはみなされないため、そのようなプログラムの動作はクライアント側の動作とは呼ばれない。
コンピュータセキュリティの文脈では、クライアント側の脆弱性または攻撃とは、サーバー側ではなく、クライアント/ユーザーのコンピュータシステムで発生するもの、あるいは両者の間で発生するものを指します。たとえば、サーバーに暗号化されたファイルやメッセージがあり、それがユーザーのコンピュータシステムに保存されている鍵でしか復号できない場合、通常、クライアント側の攻撃が、攻撃者が復号されたコンテンツにアクセスできる唯一の機会となります。たとえば、攻撃者はクライアントシステムにマルウェアをインストールさせ、ユーザーの画面を表示したり、ユーザーのキーストロークを記録したり、ユーザーの暗号化キーのコピーを盗んだりすることができます。あるいは、攻撃者はクロスサイトスクリプティングの脆弱性を利用して、常駐型のマルウェアをインストールすることなく、クライアントシステム上で悪意のあるコードを実行することもできます。[ 8 ] [ 9 ] [ 10 ]
SETI@homeやGreat Internet Mersenne Prime Searchといった分散コンピューティングプロジェクト、そしてGoogle Earthのようなインターネット依存型アプリケーションは、主にクライアント側の操作に依存しています。これらのプロジェクトは、サーバーとの接続を開始し（Google Earthのようにユーザーからの問い合わせに応じて、またはSETI@homeのように自動的に）、データを要求します。サーバーはデータセットを選択し（サーバー側の操作）、クライアントに返送します。クライアントはデータを分析し（クライアント側の操作）、分析が完了すると、その結果をユーザーに表示したり（Google Earthのように）、計算結果をサーバーに送信したりします（SETI@homeのように）。
クライアント・サーバーアーキテクチャの初期の形態としては、少なくともOS/360 （1964年発表）にまで遡るリモートジョブエントリーがあり、リクエストはジョブの実行であり、レスポンスは出力であった。
1960年代と1970年代にクライアント・サーバモデルを策定する際、ARPANETを構築していた（スタンフォード研究所の）コンピュータ科学者たちは、サーバホスト（またはサービングホスト）とユーザーホスト（または使用ホスト）という用語を使用しており、これらは初期の文書RFC 5 [ 11 ]とRFC 4 [ 12 ]に登場します。この使用法は1970年代半ばにゼロックスPARCで継続されました。
研究者がこれらの用語を使用した文脈の 1 つは、デコードエンコード言語 (DEL) と呼ばれるコンピュータ ネットワーク プログラミング言語の設計でした。 [ 11 ]この言語の目的は、1 つのコンピュータ (ユーザー ホスト) からコマンドを受け取り、ネットワーク パケットにコマンドをエンコードしながらユーザーにステータス レポートを返すことでした。別の DEL 対応コンピュータであるサーバー ホストは、パケットを受信し、デコードして、フォーマットされたデータをユーザー ホストに返しました。ユーザー ホスト上の DEL プログラムは、結果を受け取ってユーザーに表示しました。これはクライアント サーバー トランザクションです。DEL の開発は、米国国防総省がARPANET (インターネットの前身) を設立した 1969 年に始まったばかりでした。
クライアントホストとサーバホストは、クライアントとサーバとは微妙に異なる意味を持ちます。ホストとは、ネットワークに接続されたコンピュータのことです。サーバとクライアントという言葉は、コンピュータまたはコンピュータプログラムのいずれかを指す場合がありますが、サーバホストとクライアントホストは常にコンピュータを指します。ホストは汎用性の高い多機能コンピュータであり、クライアントとサーバはホスト上で動作するプログラムにすぎません。クライアントサーバモデルでは、サーバはサービス提供というタスクに専念する傾向があります。
クライアントという言葉の初期の使用例は、1978 年に Xerox PARC のコンピュータ科学者である Howard Sturgis、James Mitchell、および Jay Israel による論文「分散ファイルシステムにおけるデータと機能の分離」に見られます。著者らは、読者のためにこの用語を丁寧に定義し、ユーザーとユーザーのネットワークノード (クライアント) を区別するためにこの用語を使用していることを説明しています。[ 13 ] 1992 年までに、サーバーという言葉は一般的に使われるようになりました。[ 14 ] [ 15 ]
クライアント/サーバーモデルでは、サーバーホストがクライアントホストよりも多くのリソースを持つ必要があるとは規定されていません。むしろ、汎用コンピュータが他のホストの共有リソースを使用することで機能を拡張できるようにします。一方、集中コンピューティングでは、少数のコンピュータに多数のリソースが具体的に割り当てられます。クライアントホストから中央コンピュータにオフロードされる計算が多いほど、クライアントホストはよりシンプルになります。[ 16 ]集中コンピューティングは、計算とストレージのためにネットワークリソース（サーバーとインフラストラクチャ）に大きく依存します。ディスクレスノードは、オペレーティングシステムさえネットワークからロードし、コンピュータ端末にはオペレーティングシステムがまったくありません。それはサーバーへの入出力インターフェースにすぎません。対照的に、パーソナルコンピュータなどのリッチクライアントは、多くのリソースを持ち、重要な機能のためにサーバーに依存しません。
1980年代から1990年代後半にかけてマイクロコンピュータの価格が下がり、性能が向上するにつれて、多くの組織は、メインフレームやミニコンピュータなどの集中型サーバーからリッチクライアントへと計算を移行しました。[ 17 ]これにより、コンピュータのリソースに対するより大きく個別化された制御が可能になりましたが、情報技術管理は複雑化しました。[ 16 ] [ 18 ] [ 19 ] 2000年代には、Webアプリケーションが特定のマイクロアーキテクチャ向けに開発されたアプリケーションソフトウェアに匹敵するほど成熟しました。この成熟、より手頃な価格の大容量ストレージ、およびサービス指向アーキテクチャの出現は、 2010年代のクラウドコンピューティングのトレンドを生み出した要因の一部でした。[ 20 ]
クライアント/サーバーモデルに加えて、分散コンピューティングアプリケーションでは、ピアツーピア（P2P）アプリケーションアーキテクチャがよく利用される。
クライアント/サーバーモデルでは、サーバーは多くの場合、多数のクライアントにサービスを提供する集中型システムとして動作するように設計されます。サーバーのコンピューティング能力、メモリ、ストレージ要件は、想定されるワークロードに合わせて適切に拡張する必要があります。負荷分散およびフェイルオーバーシステムは、サーバーを単一の物理マシンを超えて拡張するためによく使用されます。[ 21 ] [ 22 ]
ロードバランシングとは、サーバーファーム内の複数のサーバー間で、ネットワークトラフィックまたはアプリケーショントラフィックを体系的かつ効率的に分散させる仕組みのことです。各ロードバランサーはクライアントデバイスとバックエンドサーバーの間に位置し、受信したリクエストを処理可能なサーバーに分散します。
ピアツーピアネットワークでは、2 台以上のコンピュータ (ピア) がリソースを共有し、分散システムで通信します。ピアは、非階層型ネットワークにおいて同等または同等の能力を持つノードです。クライアント サーバー ネットワークやクライアント キュー クライアントネットワークのクライアントとは異なり、ピアは互いに直接通信します。[ 23 ]ピアツーピア ネットワークでは、ピアツーピア通信プロトコルのアルゴリズムが負荷を分散し、リソースが限られているピアでも負荷の共有に役立ちます。[ 24 ]ノードが利用できなくなった場合でも、他のピアがリソースを提供している限り、共有リソースは引き続き利用可能です。理想的には、他の冗長なピアがリソースのダウンタイムを補うため、ピアは高い可用性を達成する必要はありません。ピアの可用性と負荷容量が変化すると、プロトコルは要求を再ルーティングします。
分散ピアツーピアシステム [...] これは一般的なスタイルであり、一般的なスタイルとしてはクライアントサーバーとマスタースレーブのスタイルがあります。