コンピュータネットワーク – トップダウンアプローチ (第 2 章学習記録)

この章ではアプリケーション層について学びます

Web アプリケーションはコンピュータネットワークの存在意義です。

Web アプリケーションのアーキテクチャ

最新の Web アプリケーションには、クライアント/サーバーアーキテクチャとピアツーピア (P2P) アーキテクチャという 2 つの主要なアーキテクチャがあります。

クライアント/サーバーアーキテクチャ(クライアント/サーバー)。サーバーと呼ばれる 1 つの常時接続ホストがあり、クライアントと呼ばれる他の多くのホストからのリクエストに対応します。

(典型的な例は Web アプリケーションです。このアプリケーションでは、常時接続の Web サーバーが (クライアントのホスト上で実行されている) ブラウザーからのリクエストを処理します。リクエストを受信すると、応答として要求されたオブジェクトをクライアントに送信します。)

この構造にはいくつかの特徴があります: クライアントは相互に直接通信せず、サーバーは固定の既知のアドレス (IP アドレス) を持ちます。

この構造を持つよく知られたアプリケーションには、Web、FTP、Telnet、電子メールなどがあります。

データセンターにある専用サーバーへの依存が最小限 (またはまったく) で、代わりにアプリケーションが断続的に接続されるホストのペア (ピア)間の直接通信を使用するP2P アーキテクチャ。このピアツーピア通信は専用サーバーを経由する必要がないため、この構造はピアツーピアと呼ばれます。

この構造の最も魅力的な特徴の1 つは、その自己拡張性です。

(たとえば、P2P ファイル共有アプリケーションでは、各ピアはファイルを要求することによってワークロードを生成しますが、各ピアはまた、ファイルを他のピアに配布することによってシステムにサービス容量を追加します)

プロセスコミュニケーション

オペレーティングシステムの用語では、実際に通信するのはプログラムではなくプロセスです。プロセスは、エンドシステム上で実行されるプログラムと考えることができます。2 つの異なるエンドシステム上のプロセスは、コンピュータネットワークを介してメッセージを交換することによって相互に通信します。送信プロセスはメッセージを生成してネットワークに送信し、受信プロセスはこれらのメッセージを受信し、エコーメッセージで応答する場合があります。

クライアントとサーバーのプロセス

ネットワークアプリケーションは、ネットワーク経由でメッセージを相互に送信するプロセスのペアで構成されます。

(Web アプリケーションでは、クライアントブラウザプロセスは Web サーバープロセスとメッセージを交換します。P2P システムでは、ファイルはあるピアのプロセスから別のピアのプロセスに転送されます)。通信プロセスの各ペアでは、2 つのプロセスのうちの 1 つがクライアント(クライアント) として識別され、もう 1 つのプロセスがサーバー(サーバー) として識別されることがよくあります。

具体的には、一対のプロセス間の通信セッションシナリオでは、通信を開始するプロセスはクライアントとして識別され、セッションの開始時に接続を待機しているプロセスはサーバーとして識別されます。

プロセスとコンピュータネットワーク間のインターフェース

ほとんどのプログラムは通信プロセスのペアで構成されており、各ペアの 2 つのプロセスが相互にメッセージを送信します。あるプロセスから別のプロセスに送信されるメッセージは、基礎となるネットワークを通過する必要があり、プロセスはソケットと呼ばれるソフトウェアインターフェイスを通じてネットワークとの間でメッセージを送受信します。

ソケットは、同じホスト内のアプリケーション層とトランスポート層の間のインターフェイスです。ソケットはネットワークアプリケーションを確立するためのプログラム可能なインターフェイスであるため、ソケットはアプリケーションプログラムとネットワーク間のアプリケーションプログラミングインターフェイス(Application Programming Interface、API) とも呼ばれ、アプリケーション開発者はソケットをアプリケーション層側ですべて制御できます。ただし、トランスポート層はそのソケットをほとんど制御できません。

プロセスのアドレス指定

あるホスト上で動作するプロセスが別のホスト上で動作するプロセスにパケットを送信するには、受信プロセスにアドレスが必要であり、受信プロセスを識別するために、次の 2 種類の情報を定義する必要があります。ホスト内 ②宛先ホスト内受信プロセスの識別子を指定します。インターネットでは、ホストは IP アドレスによって識別されます (IP アドレスは 32 ビットの量であり、ホストを一意に識別します)。受信ホストはポート番号を使用して受信プロセスを識別します。

インターネットを利用した交通サービス

インターネットは、アプリケーションにUDP と TCP という2 つのトランスポート層プロトコルを提供します。ソフトウェア開発者がインターネット用の新しいアプリケーションを作成するとき、最初に行う決定は、UDP または TCP のどちらを選択するかです。各プロトコルが最初に使用されます。アプリケーションは異なるプロトコルを提供します。サービスのコレクション。

TCPサービス

TCP サービスモデルには、接続指向のサービスと信頼性の高いデータ送信サービスが含まれます。アプリケーションがトランスポートプロトコルとして TCP を呼び出すと、アプリケーションは TCP から両方のサービスを取得できます。

接続指向サービス: アプリケーション層のデータパケットが流れ始める前に、TCP を使用すると、クライアントとサーバーがトランスポート層の制御情報を相互に交換できるようになります。このハンドシェイクプロセスにより、クライアントとサーバーは大量のパケットの到着に備えるようになります。ハンドシェイクフェーズの後、2 つのプロセスのソケット間で TCP 接続が確立されます。この接続は全二重です。つまり、両方の当事者を接続するプロセスは、この接続上で同時にメッセージを送受信できます。アプリケーションがメッセージの送信を終了したら、接続を切断する必要があります
信頼性の高いデータ配信サービス: 通信プロセスは TCP を利用して、送信されたすべてのデータをエラーなく適切な順序で配信できます。アプリケーションの一方がソケットにバイトをストリーミングする場合、TCP を利用して、バイトの損失や冗長性を持たずに、同じバイトのストリームを受信側のソケットに配信できます。

TCP プロトコルには輻輳制御メカニズムもあり、このサービスは必ずしも通信プロセスに直接的な利益をもたらすわけではありませんが、インターネット全体に利益をもたらす可能性があります。送信者と受信者間のネットワークが輻輳すると、TCP の輻輳制御メカニズムが送信プロセスを抑制します。

UDPサービス

UDP は、不要なサービスを提供せず、最小限のサービスのみを提供する軽量のトランスポートプロトコルです。

UDP はコネクションレス型であるため、2 つのプロセスが通信する前にハンドシェイクプロセスはありません。
UDP プロトコルは、信頼性の低いデータ送信サービスを提供します。プロセスが UDP ソケットにメッセージを送信するとき、UDP プロトコルはメッセージが受信プロセスに到達することを保証せず、受信プロセスに到着するメッセージも順序が崩れる可能性があります。 . 到着しました。

UDP には輻輳制御メカニズムが含まれていないため、UDP の送信者は任意の速度でデータを下位層 (ネットワーク層) に注入できます。

ここで、TCP も UDP も暗号化メカニズムを提供していないことに注意してください。送信プロセスによってソケットに送信されるデータは、ネットワークを介して宛先プロセスに送信されるデータと同じであり、平文で送信されるため、中間リンクで情報を発見することができます。したがって、TCP の拡張バージョンであるSecure Sockets Layer (SSL)が開発されました。SSL で強化された TCP は、従来の TCP が実行できることをすべて実行できるだけでなく、暗号化、データ整合性、エンドポイント認証などの主要なプロセス間のセキュリティサービスも提供します。

アプリケーション層プロトコル

アプリケーション層プロトコルは、異なるエンドシステムで実行されているアプリケーションプロセスが相互にメッセージを送信する方法を定義します。特に、アプリケーション層プロトコルは次のことを定義します。

リクエストメッセージやレスポンスメッセージなど、交換されるメッセージの種類
メッセージ内のフィールドやこれらのフィールドの記述方法など、さまざまなメッセージタイプの構文
フィールドのセマンティクス、つまり、それらのフィールド内の情報の意味
プロセスがメッセージを送信し、メッセージに応答するタイミングと方法を決定するルール

ウェブとHTTP

HTTPプロファイル

Web のアプリケーション層プロトコルは、Web の中核であるハイパーテキスト転送プロトコル(HyperText Transfer Protocol、HTTP) です。HTTP は、クライアントプログラムとサーバープログラムの 2 つのプログラムによって実装されます。クライアントプログラムとサーバープログラムは異なるエンドシステムで実行され、HTTP メッセージを交換することで会話を行います。HTTP は、これらのメッセージの構造と、クライアントとサーバーがメッセージを交換する方法を定義します。

{Web ページはオブジェクトで構成されます。オブジェクトは、HTML ファイル、JPEG グラフィックス、Java アプレットなどの単なるファイルであり、URL アドレスによってアドレス指定できます。各 URL アドレスは、ストレージオブジェクトサーバーのホスト名とストレージオブジェクトサーバーのホスト名という 2 つの部分で構成されます。オブジェクトのパス名}

HTTP は、Web クライアントが Web サーバーに Web ページを要求する方法、およびサーバーが Web ページをクライアントに送信する方法を定義します。ユーザーが Web ページをリクエストすると (ハイパーリンクをクリックするなど)、ブラウザはページに含まれるオブジェクトの HTTP リクエストメッセージをサーバーに送信し、サーバーはリクエストを受信して、これらのオブジェクトを含む HTTP 応答メッセージで応答します。 , 図に示すように。

HTTP は、そのバッキングトランスポートプロトコルとして (UDP の代わりに) TCP を使用します。HTTP クライアントは最初にサーバーとの TCP 接続を開始します。接続が確立されると、ブラウザとサーバープロセスはソケットインターフェイスを介して TCP にアクセスできるようになります (クライアントのソケットインターフェイスは、クライアントプロセスと TCP 接続の間のドアであり、サーバーのソケットインターフェイスは、サーバープロセスと TCP 接続の間のドアです。クライアントは、HTTP 要求メッセージをそのソケットインターフェイスに送信し、そのソケットインターフェイスから HTTP 応答メッセージを受信します。同様のサーバー側も同様です。クライアントがリクエストメッセージをそのソケットインターフェイスに送信すると、メッセージはクライアントの制御から外れ、HTTP に信頼性の高いデータ送信サービスを提供する TCP の制御に入ります)

サーバーは、クライアントに関する状態情報を保存せずに、要求されたファイルをクライアントに送信します。クライアントが短期間に同じオブジェクトを連続して要求した場合、サーバーは各要求に順番に応答し、前の回答. サービスは利用できなくなりました。HTTP サーバーはクライアントに関する情報をまったく保存しないため、HTTP プロトコルはステートレスプロトコル(ステートレスプロトコル)と言われます。

非永続的接続と永続的接続

クライアントとサーバーはかなりの時間枠にわたって通信します。クライアントは一連のリクエストを発行し、サーバーは各リクエストに応答します。各リクエスト/レスポンスのペアは別個の TCP 接続 (非永続接続) 経由で送信されるか、すべてのリクエストが送信されます。と応答は同じ TCP 接続 (永続的な接続) 経由で送信されます。

非永続接続HTTPのプロセス

非永続接続の場合、Web ページはサーバーからクライアントに送信されます (ページに HTML 基本ファイルと 10 個の JPEG グラフィックスが含まれており、これら 11 個のオブジェクトが同じサーバー上にあると仮定します)。

(1) HTTP クライアントプロセスは、HTTP のデフォルトポートであるポート番号 80 でサーバーへの TCP 接続を開始します。ソケットはクライアントとサーバーの両方の接続に関連付けられます

(2) HTTP クライアントは、ソケットを介して HTTP リクエストメッセージをサーバーに送信します。

(3) HTTP サーバープロセスは、ソケットを通じて要求メッセージを受信し、オブジェクトをカプセル化した HTTP 応答メッセージをクライアントに送信します。

(4) HTTP サーバープロセスが TCP に TCP 接続を切断するように通知します。

(5) HTTP クライアントが応答メッセージを受信し、TCP コネクションが切断される

上記の手順例は、サーバーがオブジェクトを送信した後に各 TCP 接続が閉じられる、つまり、接続が他のオブジェクトに対して永続化されない、非永続的接続の使用を示しています。各 TCP 接続は、要求メッセージと応答メッセージを 1 つだけ送信します。

ラウンドトリップ時間(ラウンドトリップ時間、RTT) は、短いパケットがクライアントからサーバーに送信され、再びサーバーに戻るのにかかる時間を指します。RTT には、パケット伝播遅延、中間ルーターおよびスイッチでのパケットキューイング遅延、およびパケット処理遅延が含まれます。

クライアントが HTML ベースファイルを要求してからファイル全体を受信するまでにかかる時間を見積もってください。

ユーザーがリンクをクリックすると、ブラウザはリンクと Web サーバーの間で TCP 接続を開始します。これには「3 ウェイハンドシェイク」プロセスが含まれます。つまり、クライアントは小さな TCP セグメントをサーバーに送信し、サーバーは小さな TCP セグメントを使用します。確認と応答が行われ、最後にクライアントはサーバーに確認応答を返します。

3 ウェイハンドシェイクの最初の 2 つの部分で費やされる時間には 1 RTT かかります。完了後、クライアントは HTTP 要求メッセージを TCP 接続に送信し、サーバーはこの HTTP 要求に対する HTTP 応答を作成します。これにはさらに RTT が消費されます。。

合計応答時間は、2 RTT にサーバーが HTML ファイルを送信するのにかかる時間を加えたものです。

永続的なHTTP

非永続的接続にはいくつかの欠点があります。まず、要求されたオブジェクトごとに新しい接続を確立して維持する必要があります。そのような接続ごとに、TCP バッファと TCP 変数をクライアントとサーバーの両方に割り当てる必要があり、これが Web サーバーに重大な負担をもたらします。各オブジェクトには RTT の 2 倍の配信遅延が発生します。1 回の RTT は TCP の作成に、もう 1 回の RTT はオブジェクトの要求と受信に発生します。

永続的な接続の場合、サーバーは応答を送信した後も TCP 接続を開いたままにします。後続の要求および応答メッセージは、同じクライアントとサーバー間の同じ接続を介して送信できます。HTTP のデフォルトモードでは、パイプラインによる永続的な接続が使用されます。

ユーザーとサーバーの対話: Cookie

HTTP サーバーがステートレスであることはすでにわかっていますが、Web サイトでは通常、ユーザーを識別できるようにする必要があり、そのために HTTP は Cookie を使用します。

図に示すように、Cookie テクノロジには 4 つのコンポーネントがあります: ① HTTP 応答メッセージの Cookie ヘッダー行、② HTTP 要求メッセージの Cookie ヘッダー行、ブラウザによって管理、④ Web サイトにあるバックエンドデータベース。

Cookieはユーザーを識別するために使用できます。ユーザーが初めてサイトにアクセスするとき、ユーザー ID の入力を求められる場合があります。後続のセッションでは、ブラウザは Cookie ヘッダーをサーバーに渡し、それによってサーバーに対してユーザーを識別します。したがって、Cookie はステートレス HTTP 上にユーザーセッション層を確立できます。しかし、Cookie はユーザーのプライバシーの侵害とみなされているため、その使用については依然として議論の余地があります。

ウェブキャッシュ

Web キャッシュはプロキシサーバーとも呼ばれ、元の Web サーバーに代わって HTTP 要求を満たすネットワークエンティティです。

ユーザーのブラウザは、ユーザーのすべての HTTP リクエストが最初に Web キャッシュに送られるように設定でき、ブラウザが設定されると、オブジェクトに対する各ブラウザリクエストが最初に Web キャッシュに送られます。

ブラウザがオブジェクトをリクエストしていると仮定すると、次のことが起こります。

(1) ブラウザは Web キャッシュへの TCP 接続を作成し、Web キャッシュ内のオブジェクトに HTTP リクエストを送信します。

(2) Web キャッシュは、オブジェクトのコピーがローカルに保存されているかどうかを確認し、保存されている場合は、Web キャッシュは HTTP 応答メッセージとともにオブジェクトをクライアントブラウザに返します。

(3) オブジェクトが Web キャッシュにない場合は、オブジェクトのオリジンサーバーへの TCP 接続を開きます。次に、Web キャッシュは、キャッシュとサーバー間の TCP 接続を介してオブジェクトに対する HTTP リクエストを送信し、リクエストを受信すると、元のサーバーはオブジェクトを含む HTTP 応答を Web キャッシュに送信します。

(4) Web キャッシュはオブジェクトを受信すると、コピーをローカル記憶域に保存し、そのコピーを HTTP 応答メッセージとともにクライアントのブラウザに送信します (既存のクライアントブラウザと Web キャッシュの TCP 接続を介して)。

Web キャッシュはサーバーでもありクライアントでもあることに注意してください。ブラウザからリクエストを受け取ってレスポンスを返す場合はサーバー、元のサーバーにリクエストを発行してレスポンスを受け取る場合はクライアントです。

Web キャッシュをインターネット上に展開する理由は 2 つあります。まず、Web キャッシュにより、クライアント要求に対する応答時間が大幅に短縮されます。第 2 に、Web キャッシュにより、組織のインターネットへのアクセスリンク上のトラフィックが大幅に削減されます。

インターネットの電子メール

電子メールは非同期通信メディアです。

インターネット電子メールシステムの概要を次の図に示します。

これには、ユーザーエージェント(ユーザーエージェント)、メールサーバー(メールサーバー)、シンプルメール転送プロトコル(シンプルメール転送プロトコル、SMTP) の 3 つの主要コンポーネントがあります。

一般的なメール送信プロセスは、送信者のユーザーエージェントから始まり、送信者のメールサーバーに送信され、さらに受信者のメールサーバーに送信され、ここで受信者のメールボックスに配信されます。

SMTP は、インターネット電子メールの主要なアプリケーション層プロトコルです。TCP の信頼性の高いデータ転送サービスを使用して、送信者のメールサーバーから受信者のメールサーバーにメールを送信します。

アリスがボブに簡単なメッセージを送りたいとします。

(1) アリスはメールエージェントプログラムを呼び出し、ボブのメールアドレスを提供し、メッセージを作成し、ユーザーエージェントにメッセージを送信するように指示します。

(2) アリスのユーザーエージェントはメッセージをメールサーバーに送信し、そこでメッセージキューに入れられます。

(3) アリスのメールサーバーで実行されている SMTP クライアントはメッセージキュー内のメッセージを見つけ、ボブのメールサーバーで実行されている SMTP サーバーへの TCP 接続を作成します。

(4) いくつかの最初の SMTP ハンドシェイクの後、SMTP クライアントは TCP 接続経由でアリスのメッセージを送信します。

(5) ボブのメールサーバーでは、SMTP サーバーがメッセージを受信します。次に、ボブのメールサーバーはメッセージをボブのメールボックスに置きます。

(6) ボブは都合の良いときに、ユーザーエージェントを呼び出してメッセージを読みます。

SMTP は通常、2 つのメールサーバーが地球の反対側にある場合でも、メールの送信に中間メールサーバーを使用しません。ボブのメールサーバーの電源が入っていない場合、メッセージはアリスのメールサーバーに残り、新たな試行を待ちます。つまり、メールは途中のメールサーバーに保持されません。

SMTPとHTTPの比較

どちらのプロトコルも、あるホストから別のホストにファイルを転送するために使用されます。HTTP は Web サーバーから Web クライアント (通常はブラウザ) にファイルを転送します。SMTP は、あるメールサーバーから別のメールサーバー (電子メールメッセージ) にファイルを転送します。永続的な HTTP と SMTP は両方とも使用します。ファイル転送時の永続的な接続。

2 つの違い:

(1) HTTP は主にプルプロトコル(プルプロトコル) であり、ユーザーは HTTP を使用してこれらの情報をサーバーからプルします。この TCP 接続は、ファイルを受信したいマシンによって開始されます。一方、SMTP は基本的にプッシュプロトコル(プッシュプロトコル)、つまり、送信メールサーバーがファイルを受信メールサーバーにプッシュし、この TCP接続は、ファイルを送信したいマシンとその開始によって開始されます。

(2) SMTP では、各メッセージ (本文を含む) が 7 ビット ASCII 形式である必要があります。メッセージに 7 ビット以外の ASCII 文字またはバイナリデータが含まれている場合、メッセージは 7 ビット ASCII コードに従ってエンコードされる必要があります。HTTP データにはこの制限は適用されません。

(3) 3 番目の重要な違いは、テキストとグラフィック (および場合によっては他のメディアタイプ) の両方を含むドキュメントを処理する方法です。HTTP は各オブジェクトを独自の HTTP 応答メッセージにカプセル化しますが、SMTP はすべての Message オブジェクトをメッセージ内に配置します。

メールアクセスプロトコル

SMTP がアリスのメールサーバーからボブのメールサーバーにメールメッセージを配信すると、そのメッセージはボブのメールボックスに入れられます。以下の図に示すように、アリスのユーザーエージェントは SMTP を使用して電子メールメッセージをメールサーバーにプッシュし、彼女のメールサーバー (SMTP クライアントとして機能) は SMTP を使用して電子メールをボブのメールサーバーに中継します。なぜここで 2 つのステップに分かれているのでしょうか? その主な理由は、Alice のユーザーエージェントが、Alice のメールサーバーを経由せずに、到達不能な宛先受信サーバーに到達する方法がないためです。

ボブは、ローカル PC でユーザーエージェントを実行して、どのようにして ISP のメールサーバーにメールを取得するのでしょうか?

メッセージの取得はプル操作であり、SMTP プロトコルはプッシュプロトコルであるため、ボブのユーザーエージェントは SMTP を使用してメッセージを取得できません。この問題は、ボブのメールサーバーからローカル PC にメッセージを転送する特別なメールアクセスプロトコルを導入することで解決します。現在、ポストオフィスプロトコルの第 3 バージョン(PostOffice プロトコル - バージョン 3、POP3)、インターネットメールアクセスプロトコル(インターネットメールアクセスプロトコル、IMAP)、HTTP などの一般的なメールアクセスプロトコルがいくつかあります。

上に示したように (図 2-16)、SMTP は送信者のメールサーバーから受信者のメールサーバーにメールを転送するために使用されます。また、送信者のユーザーエージェントから POP3 The Mail などの送信者のメールサーバーにメールを転送するためにも使用されます。アクセスプロトコルは、受信者のメールサーバーから受信者のユーザーエージェントにメールを配信するために使用されます。

ポップ3

POP3 は、RFC1939 で定義された非常に単純なメールアクセスプロトコルです。ユーザーエージェント (クライアント) がポート 110 でメールサーバー (サーバー) への TCP 接続を開くと、POP3 が動作し始めます。TCP 接続の確立により、POP3 は承認、トランザクション処理、更新の 3 つの段階で動作します。

IMAP

Webベースの電子メール

DNS: インターネット用のディレクトリサービス

インターネット上のホストは、人間と同じようにさまざまな方法で識別できます。ホストを識別する方法の 1 つは、ホスト名(ホスト名) を使用することですが、IP アドレスによって識別することもできます。

DNSが提供するサービス

ホストを識別するには、ホスト名または IP アドレスの 2 つの方法があります。人々は覚えやすいホスト名の識別方法を好みますが、ルーターは階層構造を持つ固定長の IP アドレスを好みます。妥協するには、ホスト名を IP アドレスに変換できるディレクトリサービスが必要です。これがドメインネームシステム(ドメインネームシステム (DNS) の主なタスク。DNS とは: ① 階層型 DNS サーバー (DNS サーバー) によって実装される分散データベース; ② ホストが分散データベースにクエリできるようにするアプリケーション層プロトコル DNS プロトコルは UDP 上で実行され、ポート 53 を使用します。

DNS は、ユーザーが指定したホスト名を IP アドレスに解決するために、HTTP、SMTP、FTP などの他のアプリケーション層プロトコルで一般的に使用されます。

例として、ユーザーのホスト上で実行されているブラウザ (つまり、HTTP クライアント) が URL www.someschool.edu/index.html をリクエストしたときに何が起こるかを考えてみましょう。ユーザーのホストが Web サーバー www.someschool.edu に HTTP リクエストメッセージを送信するには、ユーザーのホストは www.someschool.edu の IP アドレスを取得する必要があります。それは次のように行われます

(1) 同じユーザーホスト上で DNS アプリケーションを実行しているクライアント

(2) ブラウザは上記 URL からホスト名 www.someschool.edu を抽出し、このホスト名を DNS アプリケーションのクライアントに渡します。

(3) DNS クライアントはホスト名を含むリクエストを DNS サーバーに送信します。

(4) DNS クライアントは最終的に、ホスト名に対応する IP アドレスを含む応答メッセージを受信します。

(5) ブラウザが DNS から IP アドレスを受信すると、その IP アドレスのポート 80 で HTTP サーバープロセスへの TCP 接続を開始できます。

DNS は、ホスト名を IP アドレスに変換することに加えて、いくつかの重要なサービスを提供します。

ホストエイリアス複雑なホスト名を持つホストには 1 つ以上のエイリアスを持つことができ、アプリケーションは DNS を呼び出して、ホストエイリアスとホストの IP アドレスに対応する正規のホスト名を取得できます。
メールサーバーのエイリアス
負荷分散 DNSは、冗長化されたサーバー間の負荷分散にも使用されます。

DNS の動作メカニズムの概要

ユーザーのホスト上で実行されている一部のアプリケーションでは、ホスト名を IP アドレスに変換する必要があるとします。これらのアプリケーションは DNS クライアントを呼び出し、変換する必要があるホスト名を指定します。ユーザーホスト上の DNS がそれを受信すると、DNS クエリメッセージをネットワークに送信します。すべての DNS 要求および応答メッセージは、UDP データグラムを使用してポート 53 経由で送信されます。一定の時間遅延の後、ユーザーのホストコンピュータ上の DNS は、必要なマッピングを提供する DNS 応答メッセージを受信し、マッピング結果は DNS を呼び出すアプリケーションプログラムに渡されます。したがって、ユーザーホスト上でアプリケーションを呼び出すという観点から見ると、DNS はシンプルで直接的な変換サービスを提供するブラックボックスです。

DNS の単純な設計は、インターネット上ですべてのマッピングを含む DNS サーバーを 1 つだけ使用することです。この集中型設計では、クライアントはすべてのクエリを 1 つの DNS サーバーに直接送信し、DNS サーバーはすべてのクエリクライアントに直接応答しますが、この集中型設計には次の問題があります。

(1)単一障害点DNS サーバーがクラッシュすると、インターネット全体が麻痺します。

(2)通信容量単一の DNS ですべての DNS クエリを処理する必要がある

(3)長距離集中型データベース単一の DNS サーバーがすべてのクエリクライアントに「近い」ことは不可能であるため、重大な遅延が発生する可能性があります。

(4)メンテナンス単一の DNS サーバーがすべてのインターネットホストの記録を保持する必要があるため、この中央データベースが巨大になります。

したがって、DNS は分散設計スキームを採用しています。

(1)分散階層構造

スケーラビリティの問題に対処するために、DNS は階層的に編成され、世界中に分散された多数の DNS サーバーを使用します。インターネット上のすべてのホストのマッピングを持つ DNS サーバーはありません。代わりに、これらのマッピングはすべての DNS サーバーに分散されます。一般的に、DNS サーバーには、ルート DNS サーバー、トップレベルドメイン (トップレベルドメイン、TLD) の 3 種類があります。 ) DNS サーバーと権威 DNS サーバー

ルートサーバー世界中には 400 以上のルートサーバーがあり、これらのルートサーバーは 13 の異なる組織によって管理されています。ルートサーバーは TLD サーバーの IP アドレスを提供します。
トップレベルドメイン DNS サーバー すべてのトップレベルドメインおよびすべての国のトップレベルドメインに TLD サーバーがあります。TLD サーバーは、権威 DNS サーバーの IP アドレスを提供します。
権威 DNS　サーバーインターネット上にパブリックにアクセス可能なホストを持つすべての組織は、それらのホストの名前を IP アドレスにマッピングするパブリックにアクセス可能な DNS レコードを提供する必要があります。

ルート、TLD、および権威 DNS サーバーはすべて、DNS サーバーの階層構造内にあります。DNS サーバーには、ローカル DNS サーバーと呼ばれる別の重要なタイプがあります。厳密に言えば、ローカル DNS サーバーはサーバー階層に属しませんが、彼は DNS 階層にとって重要です。各 ISP にはローカル DNS サーバーがあり、ホストが ISP に接続すると、その ISP は 1 つ以上のローカル DNS サーバーの IP アドレスを持つホストの IP アドレスを提供します。

DNSキャッシュ

遅延パフォーマンスを改善し、インターネット上で送信される DNS パケットの数を減らすために、DNS はキャッシュテクノロジを広範囲に使用します。DNS キャッシュの原理は非常に単純です。リクエストチェーンで、DNS サーバーが DNS 応答を受信すると、マッピングをローカルストレージにキャッシュできます。実際、キャッシュにより、いくつかの DNS クエリを除いて、ルートサーバーはバイパスされました。

P2Pファイル配布

これまで説明してきたアプリケーションは、常時接続のインフラストラクチャサーバーに大きく依存するクライアント/サーバーモデルを使用していましたが、常時接続のインフラストラクチャサーバーへの依存を最小限に抑えた (またはまったく依存させない) p2p アーキテクチャを使用すると、断続的に接続されるホスト (ピアと呼ばれます) になります。相互に直接通信し、これらのピアはサービスプロバイダーによって所有されません。

ファイル配布のクライアント/サーバーモードでは、サーバーはファイルのコピーを各ピアに送信する必要があります。つまり、サーバーには大きな負担がかかり、多くのサーバー帯域幅を消費します。P2P ファイル配布では、各ピアは受信したファイルの任意の部分を他のピアに再送信できるため、配布プロセスにおけるサーバーを支援できます。

P2P アーキテクチャを備えたアプリケーションは自己拡張可能です。このスケーラビリティの直接の原因は、ピアがビットの消費者であるだけでなく、ビットの再配布者でもあることです。