クライアント・サーバーモデル

クライアントサーバーモデルは、タスクまたはワークロードを、サーバーと呼ばれるリソースまたはサービスの提供者と、クライアントと呼ばれるサービス要求者の間で分割する分散アプリケーション構造です。[ 1 ]クライアント^とサーバーは、別のハードウェア上のコンピュータネットワークを介して通信することがよくありますが、クライアントとサーバーの両方が同じシステムに存在することもあります。サーバーホストは、 クライアントとリソースを共有する1つ以上のサーバープログラムを実行します。クライアントは通常、リソースを共有しませんが、サーバーにコンテンツまたはサービスを要求します。そのため、クライアントはサーバーとの通信セッションを開始し、サーバーは着信要求を待機します。クライアントサーバーモデルを使用するコンピュータアプリケーションの例としては、電子メール、ネットワーク印刷、World Wide Webなどがあります。

「kushagra」特性は、アプリケーション内の連携プログラムの関係を表します。サーバー コンポーネントは、1 つまたは複数のクライアントに機能またはサービスを提供します。クライアントは、そのようなサービスの要求を開始します。サーバーは、提供するサービスによって分類されます。たとえば、Web サーバーはWeb ページを提供し、ファイル サーバーはコンピュータ ファイルを提供します。共有リソースは、プログラムやデータからプロセッサやストレージ デバイスまで、サーバー コンピュータのソフトウェアや電子コンポーネントのいずれかです。サーバーのリソースを共有すると、サービスが構成されます。

コンピュータがクライアント、サーバー、またはその両方であるかどうかは、サービス機能を必要とするアプリケーションの性質によって決まります。たとえば、1 台のコンピュータで Web サーバーとファイル サーバー ソフトウェアを同時に実行して、さまざまな種類の要求を行うクライアントにさまざまなデータを提供できます。クライアント ソフトウェアは、同じコンピュータ内のサーバー ソフトウェアと通信することもできます。^{[2]データの同期などのサーバー間の通信は、}サーバー間通信またはサーバー間通信と呼ばれることがあります。

一般的に、サービスとはコンピュータ リソースを抽象化したものであり、クライアントは、サーバーが要求を処理して応答を配信する際にどのように動作するかを気にする必要はありません。クライアントは、関連するアプリケーション プロトコルに基づいて応答、つまり要求されたサービスのデータの内容と形式を理解するだけで済みます。

クライアントとサーバーは、要求応答 メッセージング パターンでメッセージを交換します。クライアントが要求を送信し、サーバーが応答を返します。このメッセージ交換は、プロセス間通信の例です。通信するには、コンピューターが共通の言語を持っている必要があり、クライアントとサーバーの両方が何を期待するかを知ることができるようにルールに従う必要があります。通信の言語とルールは、通信プロトコルで定義されます。すべてのプロトコルはアプリケーション層で動作します。アプリケーション層プロトコルは、対話の基本パターンを定義します。データ交換をさらに形式化するために、サーバーはアプリケーション プログラミング インターフェイス(API) を実装する場合があります。^[3] API は、サービスにアクセスするための抽象化レイヤーです。通信を特定のコンテンツ形式に制限することで、解析を容易にします。アクセスを抽象化することで、クロスプラットフォームのデータ交換を容易にします。^[4]

サーバーは、短期間に多数の異なるクライアントからリクエストを受信する場合があります。コンピューターは、一度に実行できるタスクの数には限りがあり、クライアントからの受信リクエストを優先順位付けして対応するために、スケジューリングシステムに依存しています。不正使用を防ぎ、可用性を最大化するために、サーバー ソフトウェアはクライアントの可用性を制限する場合があります。サービス拒否攻撃は、過度のリクエスト レートでサーバーを過負荷にすることで、サーバーのリクエスト処理義務を悪用するように設計されています。クライアントとサーバーの間で機密情報をやり取りする場合は、暗号化を適用する必要があります。

銀行の顧客がWeb ブラウザ(クライアント)を使用してオンライン バンキングサービスにアクセスすると、クライアントは銀行の Web サーバーに要求を送信します。顧客のログイン資格情報はデータベースに保存されている場合があり、Web サーバーはクライアントとしてデータベース サーバーにアクセスします。アプリケーション サーバーは、銀行のビジネス ロジックを適用して返されたデータを解釈し、その出力をWeb サーバーに提供します。最後に、Web サーバーは結果をクライアントのWeb ブラウザに返して表示します。

この一連のクライアント/サーバー メッセージ交換の各ステップでは、コンピューターが要求を処理してデータを返します。これが要求/応答メッセージ パターンです。すべての要求が満たされると、シーケンスが完了し、Web ブラウザーが顧客にデータを表示します。

この例は、クライアント サーバー モデルに適用可能な設計パターンである「関心の分離」を示しています。

サーバーサイドとは、サーバー上で実行されるプログラムや操作を指します。これは、クライアント上で実行されるクライアントサイドのプログラムや操作とは対照的です。^[5]（下記参照）

「サーバー側ソフトウェア」とは、ユーザーのローカルコンピューター、スマートフォン、またはその他のデバイスからアクセスできるリモートサーバー ハードウェア上で実行されるWeb サーバーなどのコンピューター アプリケーションを指します。操作は、クライアントでは利用できない情報や機能にアクセスする必要があるため、またはクライアント側でそのような操作を実行すると遅い、信頼性が低い、または安全でないなどの理由で、サーバー側で実行されることがあります。

クライアント プログラムとサーバー プログラムは、無料または商用のWeb サーバーやWeb ブラウザーなど、一般的に入手可能なものであり、標準化されたプロトコルを使用して相互に通信します。または、プログラマーが、相互にのみ使用できる 独自のサーバー、クライアント、および通信プロトコルを作成する場合もあります。

サーバー側の操作には、クライアントの要求に応じて実行される操作と、メンテナンスタスクなどのクライアント指向ではない操作の両方が含まれます。^{[6] [7]}

コンピュータセキュリティの文脈では、サーバー側の脆弱性や攻撃とは、クライアント側ではなく、サーバーコンピュータシステム上で発生するもの、またはクライアントとクライアントの間を指します。たとえば、攻撃者はWebアプリケーションのSQLインジェクションの脆弱性を悪用して、サーバーのデータベースのデータを悪意を持って変更したり、不正にアクセスしたりする可能性があります。あるいは、攻撃者は基盤となるオペレーティングシステムの脆弱性を使用してサーバーシステムに侵入し、サーバーの権限のある管理者と同じ方法でデータベースやその他のファイルにアクセスできる可能性があります。^{[8] [9] [10]}

SETI@homeやGreat Internet Mersenne Prime Searchなどの分散コンピューティングプロジェクトの場合、操作の大部分はクライアント側で発生しますが、サーバーはクライアントの調整、分析用データの送信、結果の受信と保存、プロジェクト管理者へのレポート機能の提供などを行います。Google Earthなどのインターネット依存のユーザー アプリケーションの場合、マップ データのクエリと表示はクライアント側で行われますが、サーバーはマップ データの永続的な保存、ユーザー クエリをクライアントに返すマップ データに解決することなどを行います。

ワールドワイドウェブの文脈では、一般的に見られるサーバーサイドコンピュータ言語には以下のものがある: ^[5]

• ASP.NET環境でのC#またはVisual Basic
• ジャワ
• パール
• PHP の
• パイソン
• ルビー
• Node.js
• 迅速

ただし、Web アプリケーションとサービスは、標準ベースの Web ブラウザーに (場合によっては中間プログラムを介して) 使用可能な形式でデータを返すことができれば、ほぼすべての言語で実装できます。

クライアント側とは、コンピュータ ネットワーク内のクライアントによって実行される操作を指します。

通常、クライアントは、ユーザーのローカルコンピューター、スマートフォン、またはその他のデバイス上で実行され、必要に応じてサーバーに接続する、 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 の場合)。

ワールドワイドウェブの文脈では、クライアント側で評価または実行される一般的なコンピュータ言語には以下のものがある: ^[5]

• カスケード スタイル シート (CSS)
• html
• JavaScript

クライアント サーバー アーキテクチャの初期の形式は、少なくともOS/360 (1964 年発表) にまで遡るリモート ジョブ エントリです。この形式では、ジョブを実行する要求があり、その出力が応答でした。

1960年代から1970年代にかけて、 ARPANET（スタンフォード研究所）を構築していたコンピュータ科学者たちは、クライアントサーバモデルを策定する際に、サーバホスト（またはサービングホスト）とユーザホスト（または使用ホスト）という用語を使用し、これらの用語は初期の文書RFC 5 ^[11]とRFC 4 ^[12]にも登場しています。この用法は1970年代半ばまで ゼロックスPARCで継続されました。

研究者がこれらの用語を使用した状況の 1 つは、Decode-Encode Language (DEL) と呼ばれるコンピュータ ネットワーク プログラミング言語の設計でした。 ^[11]この言語の目的は、1 台のコンピュータ (ユーザー ホスト) からのコマンドを受け取り、コマンドをネットワーク パケットにエンコードして、ステータス レポートをユーザーに返すことでした。別の DEL 対応コンピュータ (サーバー ホスト) はパケットを受信して​​デコードし、フォーマットされたデータをユーザー ホストに返しました。ユーザー ホスト上の DEL プログラムは結果を受け取り、ユーザーに提示します。これはクライアント サーバー トランザクションです。DEL の開発は、米国防総省がARPANET (インターネットの前身) を確立した 1969 年に始まったばかりでした。

クライアント ホストとサーバー ホストは、クライアントとサーバーとは微妙に意味が異なります。ホストとは、ネットワークに接続された任意のコンピューターのことです。サーバーとクライアントという語は、コンピューターまたはコンピューター プログラムのいずれかを指しますが、サーバー ホストとクライアント ホストは常にコンピューターを指します。ホストは多機能で多用途のコンピューターであり、クライアントとサーバーはホスト上で実行されるプログラムにすぎません。クライアント サーバー モデルでは、サーバーはサービスを提供するというタスクに専念する可能性が高くなります。

クライアントという言葉が初めて使われたのは、ゼロックスPARCのコンピュータ科学者ハワード・スタージス、ジェームズ・ミッチェル、ジェイ・イスラエルによる1978年の論文「分散ファイルシステムにおけるデータと機能の分離」である。著者らは読者のためにこの用語を注意深く定義し、ユーザーとユーザーのネットワークノード（クライアント）を区別するために使用していると説明している。^{[13] 1992年までに、}サーバーという言葉が一般的な用語になった。^{[14] [15]}

クライアントサーバーモデルでは、サーバーホストがクライアントホストよりも多くのリソースを持つ必要はありません。むしろ、このモデルでは、他のホストの共有リソースを使用して、どの汎用コンピューターでも機能を拡張できます。ただし、集中コンピューティングでは、特に、多数のリソースを少数のコンピューターに割り当てます。クライアントホストから中央コンピューターにオフロードされる計算が多いほど、クライアントホストを簡素化できます。^[16]計算とストレージについては、ネットワークリソース（サーバーとインフラストラクチャ）に大きく依存しています。ディスクレスノードは、オペレーティングシステムでさえネットワークからロードし、コンピューター端末にはオペレーティングシステムがまったくなく、サーバーへの入出力インターフェイスにすぎません。対照的に、パーソナルコンピューターなどのリッチクライアントは、多くのリソースを持ち、重要な機能についてはサーバーに依存しません。

1980年代から1990年代後半にかけてマイクロコンピュータの価格が下がり、性能が上がると、多くの組織がメインフレームやミニコンピュータなどの集中型サーバーからリッチクライアントへと計算処理を移行した。^[17]これにより、コンピュータリソースをより細かく個別化して制御できるようになったが、情報技術の管理は複雑になった。^{[16] [18] [19]} 2000年代には、Webアプリケーションは、特定のマイクロアーキテクチャ向けに開発されたアプリケーションソフトウェアに匹敵するほど成熟した。この成熟、より手頃な価格の大容量ストレージ、サービス指向アーキテクチャの出現は、2010年代のクラウドコンピューティングのトレンドを生み出した要因の1つであった。^{[20] [検証に失敗した]}

分散コンピューティングアプリケーションでは、クライアント サーバー モデルに加えて、ピアツーピア(P2P) アプリケーション アーキテクチャがよく使用されます。

クライアントサーバーモデルでは、サーバーは多くのクライアントにサービスを提供する集中型システムとして動作するように設計されることが多い。サーバーの計算能力、メモリ、ストレージ要件は、予想される作業負荷に合わせて適切に調整する必要がある。負荷分散システムやフェイルオーバーシステムは、サーバーを単一の物理マシンを超えて拡張するためによく使用される。^{[21] [22]}

負荷分散とは、サーバー ファーム内の複数のサーバー間でネットワークまたはアプリケーションのトラフィックを系統的かつ効率的に分散することと定義されます。各ロード バランサーはクライアント デバイスとバックエンド サーバーの間に配置され、受信したリクエストを受信して​​、それを処理できる利用可能なサーバーに分散します。

ピアツーピアネットワークでは、2 台以上のコンピューター (ピア) がリソースをプールし、分散システムで通信します。ピアは、非階層型ネットワーク内の同等の、つまり等力なノードです。クライアント サーバー ネットワークやクライアント キュー クライアントネットワークのクライアントとは異なり、ピアは直接通信します。^[要出典]ピアツーピア ネットワーキングでは、ピアツーピア通信プロトコルのアルゴリズムが負荷を分散し、リソースがあまりないピアでも負荷の共有に役立ちます。^[要出典]ノードが使用できなくなった場合でも、他のピアが提供している限り、その共有リソースは引き続き使用できます。理想的には、他の冗長ピアがリソースのダウンタイムを補うため、ピアは高可用性を実現する必要がありません。ピアの可用性と負荷容量が変化すると、プロトコルが要求を再ルーティングします。

クライアントサーバーとマスタースレーブはどちらも分散ピアツーピアシステムのサブカテゴリと見なされます。^[23]