目次
序文:ネットワーク アプリケーションは、コンピュータ ネットワークの存在理由です. これらのアプリケーションは、アプリケーション層でユーザーにサービスを提供します, そして、私たちの日常のニーズを満たすネットワークプログラムはすべてアプリケーション層にあります.
1. ネットワーク アプリケーション アーキテクチャ
アプリケーション層のアーキテクチャは、前述のネットワークのアーキテクチャとは異なります. ネットワークのアーキテクチャは固定されていますが, アプリケーションアーキテクチャ(アプリケーションアーキテクチャ) はアプリケーション開発者によって設計されています.
現在、主流のアプリケーション アーキテクチャは 3 つあります。
- クライアント サーバー アーキテクチャ (クライアントサーバー、C/S )
- ポイントツーポイント構造 (ピアツーピア、P2P )
- ハイブリッド構造（ハイブリッド）
1.1 クライアント/サーバーのアーキテクチャ
- クライアント: サーバーからサービスを要求するホスト
- サーバー:クライアント と呼ばれる他のホストからの要求を処理する常時接続のホスト
クライアント サーバー モデルのよく知られたアプリケーションには、Web、FTP、Telnet、および電子メールが含まれます. 典型的な例は、常時接続の Web サーバーがブラウザー (クライアント ホスト上で実行されている) からの要求を処理する Web アプリケーションです。
サーバーの機能は次のとおりです。
- サービスを提供するために7*24時間
- 永久アクセスアドレス/ドメイン名
- 多数のサーバーでのスケーラビリティ
クライアントの機能は次のとおりです。
- サーバーと通信し、サーバーが提供するサービスを使用する
- ネットワークへの断続的なアクセス
- おそらく動的IPアドレスを使用する
- 他のクライアントと直接通信しない
通常、サーバーが受信する要求が多すぎると、1 つのサーバーが過負荷になる可能性があります。このため、多数のホストを備えたデータセンター(データセンター) は、強力な仮想サーバーを作成するためによく使用されます。たとえば、Google には世界中に 30 ～ 50 のデータ センターが分散しており、各データ センターには数十万台のサーバーを配置できます。
1.2 P2Pの仕組み
P2P 構造では、サーバーへの依存が減り、アプリケーションはピアと呼ばれるホスト間で直接通信できます。
現在普及しているトラフィック集約型アプリケーションの多くは、ファイル共有 (BitTorrent など)、ピアアシスト ダウンロード アクセラレータ (Thunder など)、インターネット電話、ビデオ会議 (Skype など) などの P2P アーキテクチャです。
P2P の特徴は次のとおりです。
- 常時稼働サーバーなし
- エンド システム/ノード間の直接通信
- ノードが断続的にネットワークに接続されている
- ノードは IP アドレスを変更する可能性があります
P2P アーキテクチャの利点, そして最も魅力的な機能の 1 つ,自己スケーラビリティ. P2P ファイル共有アプリケーションでは、各ピアがファイルを要求するためにワークロードを生成しますが、各ピアはファイルを他のピアに渡し、サービス機能を追加してファイルを配布しますシステムへ
P2P アーキテクチャの欠点は、管理が難しいことです。
1.3 ハイブリッド構造
C/S構造とP2P構造の特徴を組み合わせ、それぞれの長所を生かし、短所を回避するハイブリッド構造が誕生しました。
典型的な例は、Napster です。これは、インターネット上で必要な MP3 ファイルをダウンロードできるソフトウェアです。また、自分のマシンをサーバーにして、他のユーザーにダウンロードを提供することもできます。
ナップスターの特徴は次のとおりです。
- ファイル転送はP2P構造を採用
- ファイル検索はC/S 構造を採用 - 集中型 (各ノードは独自のコンテンツを中央サーバーに登録し、各ノードはクエリ要求を中央サーバーに送信して興味深いコンテンツを見つけます)
2. プロセス通信
2.1 識別プロセス通信
オペレーティング システムの用語では、アプリケーション間の通信は、実際にはホスト上で実行されるプログラムであるプロセス間の通信です。
同じホスト上で実行されているプロセスは、プロセス間通信メカニズムとオペレーティング システムを介して相互に通信できます。
異なるホストで実行されているプロセス間のプロセス通信は、主にメッセージ交換を通じて行われます
クライアントサーバー構造で
クライアントプロセス: 通信を開始するプロセス
サーバープロセス: 通信要求を待つプロセス
P2Pファイル共有構造で
ファイルをダウンロードしたピアはクライアントとして識別されます
ファイルをアップロードしたピアがサーバーとして識別されます
2.2ソケット（ソケット）
ほとんどのアプリケーションは、通信プロセスのペアで構成され、各チーム内の 2 つのプロセスが互いにメッセージを送信します。プロセスは、ソケットと呼ばれるソフトウェアインターフェイスを介して、ネットワークとの間でメッセージを送受信します。
プロセス間通信は、ソケットを使ってメッセージを送受信することで、手紙を送るのと同じように実現します。
- 送信者はメッセージをドアの外のメールボックスに送信します (ここのドアはソケットに相当します)。
- 送信者は (ドアの外の) 伝送インフラストラクチャに依存して、メッセージを受信者がいるホストに配信し、受信者のドアの外に送信します。
- 受信者はドアの外からメッセージを受け取ります
異なるホストでプロセス間通信を実現するには、各プロセスに識別子が必要であり、各ホストに一意の IP アドレスが必要ですが、これだけではプロセスを一意に識別するには不十分です (1 つのホストに複数のプロセスが存在する可能性があります)。通信する必要があるホスト上の各プロセスにポート番号を割り当て、IP アドレス + ポート番号を使用してプロセスを識別します
IP アドレス: ホストの ID。IP アドレスはホストを一意に識別できます。
ポート番号: ホスト上のプロセスの識別。ポート番号はホスト上のプロセスを一意に識別できます。典型的な例は次のとおりです。
HTTPサーバー：80
メールサーバー：25
3. Web アプリケーションのサービス要件
コンピュータネットワークは階層構造であり、下位層は上位層にサービスを提供し、このサービスはインターフェースを通じて実現されます
私たちが採用している5層参照モデルでは、アプリケーション層の下位層がトランスポート層であり、ソケットはアプリケーションプログラムとトランスポート層プロトコル間のインターフェースであるため、アプリケーションプログラムを設計する際に選択されることがよくあります。アプリケーション プログラムの要件に応じて トランスポート層プロトコル
アプリケーションのサービス要件を、信頼できるデータ転送、スループット、タイミング、およびセキュリティの 4 つの領域に分類します。
3.1 信頼性の高いデータ伝送
前述のように、コンピューター ネットワークではパケットが失われる可能性があります。ルーターのバッファーがオーバーフローし、パケットが破損してドロップされます。また、電子メール、ファイル転送、リモート ホスト アクセス、Web ドキュメント転送、金融アプリケーションなど、一部のアプリケーションではデータ損失が許容されません。
これらのアプリケーションをサポートするには、アプリケーションの一方の側から送信されたデータがアプリケーションの他方の側に正しく完全に配信されるようにするために、いくつかの作業を行う必要があります。
プロトコルは、データ配信を保証するサービスを提供する場合、信頼できるトランスポート メカニズムを提供すると言われます。
トランスポート層プロトコルが信頼性の高いデータ転送を提供する場合、送信プロセスは、データがソケットに渡される限り、データがエラーなしで受信プロセスに到達することを完全に信頼できます。
一部のアプリケーションは、データ損失の影響を受けません. このようなアプリケーションは、 損失耐性アプリケーションと呼ばれます. 最も一般的なのは、会話型オーディオ/ビデオなどのマルチメディア アプリケーションで、一定量のデータ損失を許容できます.
3.2 スループット
利用可能なスループットは、送信プロセスが受信プロセスにビットを配信できるレートです。
2 つのプロセス間の通信は、特定のネットワーク パスに依存することが多く、このパスの帯域幅は他のセッションと共有されます. セッションが到着して終了すると、利用可能なスループットが変動します.
一部のアプリケーションでは、トランスポート層プロトコルは、特定のレートで保証された利用可能なスループットを提供できることを保証する必要があります
たとえば、インターネット電話アプリケーションが音声を 32kbps でエンコードする場合、その速度でネットワークにデータを送信し、その速度でデータを受信側アプリケーションに配信する必要があります。プロトコルがこのスループットを提供できない場合、アプリケーションはより低い速度でエンコードする必要があります。このようなスループット要件のあるアプリケーションは、帯域幅に敏感なアプリケーション(帯域幅に敏感なアプリケーション)と呼ばれます。
電子メール、ファイル転送、Web 配信など、利用可能な帯域幅に応じて利用可能なスループットを多かれ少なかれ利用するアプリケーションは、エラスティックアプリケーションと呼ばれます 。
3.3 タイミング
トランスポート層プロトコルは、タイミングの保証も提供できます。たとえば、送信者によってソケットに挿入された各ビットは、100 ミリ秒以内に受信者のソケットに到達します。
このようなサービスは、インターネット電話、仮想環境、電話会議、マルチパーティ ゲームなどのインタラクティブなリアルタイム アプリケーションにとって魅力的です。これらはすべて、有効性を確保するために厳密な時間制約のあるデータ配信を必要とします。
通話やマルチプレイヤー ゲームを行う場合、このサービスは、通話やゲームのリアルタイム性を満たすために、遅延が一定の範囲内であることを保証できます。
3.4 セキュリティ
トランスポート層プロトコルは、1 つ以上のセキュリティ サービスをアプリケーションに提供することもできます。送信プロセスと受信プロセスの間で機密性を提供し、2 つのプロセス間で何らかの方法でデータが監視されるのを防止するサービス
たとえば、送信ホストでは、トランスポート層プロトコルは送信プロセスによって送信されたすべてのデータを暗号化でき、受信ホストでは、トランスポート層プロトコルはデータが受信プロセスに配信される前に復号化できます。
3.5 一般的なネットワーク アプリケーションの要件
| 応用 | データ紛失 | 帯域幅 | 時間に敏感 |
| ファイル転送 | 失うことはできません | 弾性 | いいえ |
| Eメール | 失うことはできません | 弾性 | いいえ |
| Web ドキュメント | 失うことはできません | 弾力性 (数 kbps) | いいえ |
| インターネット電話/ビデオ会議 | 許容損失 | 音声（数kbps～1Mbps） 動画（10kbps～5Mbps） |
はい、100ms |
| オーディオ/ビデオのストリーミング | 許容損失 | 同上 | はい、数秒 |
| インタラクティブゲーム | 許容損失 | 数kbps～10kbps | はい、100ms |
| スマホメッセージ | 失うことはできません | 弾性 | はいといいえ |
4. インターネットが提供する送信サービス
インターネット (より一般的には、TCP/IP ネットワーク) は、アプリケーションに TCP と UDP の 2 つのトランスポート層プロトコルを提供します. ソフトウェア開発者として、インターネット用の新しいアプリケーションを作成する場合、最初に行う決定は、UDP または TCP を選択することです.
4.1 TCP サービス
TCP サービス モデルには、接続指向のサービスと信頼性の高いデータ転送サービスが含まれます。
接続指向
- アプリケーション層のデータ パケットが流れ始める前に、TCP により、クライアントとサーバーは相互にトランスポート層の制御情報を交換できます。これは「ハンドシェイク」と呼ばれます。
- 「ハンドシェイク」の後、2 つのプロセスのソケット間に TCP 接続が確立されます。この接続は全二重です。
- アプリケーションがメッセージの送信を終了したため、接続を削除する必要があります
信頼性の高いデータ伝送
- 通信プロセスは TCP に依存して、送信されたデータをエラーなく適切な順序で配信できます。
- TCP データ配信はバイトストリームに基づいています
さらに、TCP も UDP も暗号化メカニズムを提供していません. セキュリティを確保するために、インターネット コミュニティは TCP の拡張バージョンを開発しました — Secure Sockets Layer ( Secure Sockets Layer, SSL ), これはプロセス間のセキュリティ サービスを提供します.暗号化、データの整合性、およびエンドポイント認証を含む
4.2 UDP サービス
UDP はコネクションレスであり、信頼性の低いデータ転送サービスを提供し、データを上位層に配信するために最善を尽くすプロトコルです (つまり、データ配信の正確性は保証されません)。
プロセスがメッセージを UDP ソケットに送信する場合、UDP プロトコルはメッセージが受信プロセスに到達することを保証しません。それだけでなく、受信プロセスに到着するパケットも順不同で到着する可能性があります
TCPとUDPの関連知識をトランスポート層で詳しく紹介します
5. アプリケーション層プロトコル
アプリケーションがメッセージをソケットに送信し、ネットワーク プロセス通信を実現する方法がわかったので、次に直面する問題は、アプリケーション層プロトコルをどのように指定するかです。
ネットワーク アプリケーションは、異なるエンド システムで実行されているアプリケーション プロセスが相互にメッセージを送信する方法を定義するアプリケーション層プロトコルに従う必要があります。一部のアプリケーション層プロトコルは公開されており、これらのプロトコルは
- RFC ( Request For Comments ) で定義
- 相互運用性を許可する
- HTTP、SMTP、……
独自のアプリケーション層プロトコルがいくつかあります。
- ほとんどの P2P ファイル共有アプリケーション
アプリケーション層プロトコルの内容は、主に次のとおりです。
- メッセージ タイプ (type) - 要求メッセージ、応答メッセージ
- メッセージの構文/形式 - メッセージ内のフィールドと各フィールドの説明
- フィールドのセマンティクス - フィールド内の情報の意味
- rules - プロセスがメッセージを送信/応答するとき、プロセスがメッセージを送信/応答する方法
