基本的な考え方
- プロセス: ホスト上で実行されるプログラム。ホストには同時に複数のプロセスを含めることができます。
- ネットワークメッセージ交換による通信
- P2P では、プロセスはクライアントまたはサーバーのいずれかになります。
- ペアのプロセスのうち、プロセスを開始する側がクライアントであり、接続を待っている側がサーバーです。
- ソケット：アプリケーションプロセスとトランスポート層を接続するインターフェース（API）
- 開発者はアプリケーション層で API に関するすべてを制御できます
- トランスポート層に対する選択肢と制御はほとんどありません
- プロセスのアドレス指定
- ホスト識別: IP アドレス
- さまざまなプロセスの識別子:ポート番号
- HTTP：80
- HTTPS：443
- メール(SMTP)：25
- POP3: 110
- 異なるホスト間のプロセス通信の基礎: IP + ポート番号
- アプリケーション層プロトコル: パブリック プロトコル (HTTP) + プライベート (P2P)
トランスポート サービスのネットワーク要件
- 100% 信頼性の高いデータ送信が必要: ファイル転送、Telnet
- 特定のデータ損失を許可する: VoIP
- 弾性帯域幅アプリケーション: 電子メール
- 最小帯域幅要件を持つアプリケーション: ライブストリーミング
インターネットトランスポート層サービス
TCPサービス
- Cilent/Serverプロセス間の接続
- 信頼性の高い伝送 - ただし遅延保証や帯域幅保証はありません
UDPサービス
- 接続なし、ベストエフォート、保証なし
- ハンドシェイクなし、防火構成により簡単にブロックされる
Webアプリケーションの構造
- C/S (クライアント/サーバー) アーキテクチャ: サーバーは常にオンラインであり、クライアントはサーバー経由でのみ通信できます。
- P2P アーキテクチャ: ノード IP は可変で、ネットワーク アクセスは断続的で、ノードは直接通信できます。
- P2P 構造では、ノードは同時にクライアント プロセスとサービス プロセスになることができます。
- C/S+P2P ハイブリッド構造: ファイル検索-C/S、ファイル転送 P2P
HTTP
基本的な考え方
- HTTP (ハイパーテキスト転送プロトコル): ハイパーテキスト転送プロトコル、アプリケーション層プロトコル
- Web ページ = HTML ファイル + 複数のオブジェクト (画像、テキスト、音楽など)
- TCP接続に基づく
- ステートレス プロトコル- サーバーは、クライアントによって行われた過去のリクエストに関する情報を一切保持しません。
- URL(Uniform Resource Locator):Uniform Resource Locator
- URL 形式: スキーム://ホスト:ポート/パス、プロトコル;//ホスト名:ポート/ファイル パス
HTTP接続
- RTT (往復時間) - C/S 間で微小なデータ パケットを送信する場合の往復時間
- Web ページ ファイルのリクエストに必要な時間 - 2RTT + ファイル転送時間
- 最初の RTT はハンドシェイク フェーズの最初の 2 つのステップです
- 2 番目の RTT は、ハンドシェイク フェーズ + リクエスト + レスポンスの 3 番目のステップです。
- 非永続的な接続:
- TCP 接続の確立 - 要求 1 - 応答 1 - TCP 接続の切断 - TCP 接続の確立 - 要求 2 - 応答 2 - TCP 接続の切断
- 永続的な接続:
- TCP 接続の確立 - 要求 1 - 応答 1 - 要求 2 - 応答 2 - TCP 接続の終了
HTTPメッセージ
HTTPリクエストメッセージ
- 構成: リクエスト行 + ヘッダー + メッセージ本文
- HTTP1.0リクエストメソッド
- POSTメソッド：情報はBodyに格納されます
- GETメソッド：情報はURLフィールドに格納されます
- HEAD: Serve の応答メッセージはヘッダーのみを返します
- HTTP1.1 の新しいメソッド:
- PUT: メッセージ本文のファイルを URL で指定されたパスにアップロードします
- DELETE: URL フィールドで指定されたファイルを削除します
HTTP応答メッセージ
- 構成: ステータス行 + ヘッダー + メッセージ本文
- ステータスコード: リクエストの処理ステータスを示します。
- 200 0K: リクエストは成功し、返された応答メッセージに情報が含まれています。
- 301 Moved Permanently: 要求されたオブジェクトは永続的に移動されました
- 400 Bad Request: リクエストはサーバーによって理解できません
- 404 Not Found: 要求されたドキュメントはサーバー上にありません。
クッキー技術
- コア機能: HTTP のステートレス特性を解決する
- ストレージ：
- ブラウザには Cookie ファイルがあります (ローカル ストレージ用)
- リソースサーバーのデータベースにはCookieファイルがあります（Cookieの検証に使用されます）
- HTTP リクエスト メッセージのヘッダーに Cookie フィールドがあります (リクエスト時にもたらされます)。
- HTTP 応答メッセージのヘッダーに cookie という単語が含まれています (応答時にこれを持ち込んでください)
- 機能: ローカルに保存され、応答を要求するときにヘッダー フィールドに表示されます。
- Cookie のようなテクノロジー、セッションおよびトークンのメカニズム
Webキャッシュ/プロキシサーバーテクノロジー
基本的な考え方
- コア機能: Web キャッシュを確立し、顧客がリソース サーバーにアクセスせずにリソースを迅速に取得できるようにします (プロキシ内に対応するリソースがある場合)。
- キャッシュがヒットした場合 - プロキシ サーバー = サーバー + クライアント
- 応答時間を短縮し、サーバーの負荷を軽減し、トラフィック伝送を削減し、効率を向上させます。
条件付きGETメソッド
- 機能: キャッシュ サーバー内のリソースの適時性を確保します。
- 実装: キャッシュがヒットすると、プロキシ サーバーはヘッダーに If-Modified-Since フィールドを含む GET リクエストをリソース サーバーに送信します。
- リソースが最新の場合: リソース サーバーは応答ヘッダーのみを返します。
- リソースが最新でない場合: リソースサーバーはレスポンスヘッダー+レスポンスボディを返します。
メールアプリ
メール転送プロトコル - SMTP
- SMTP (Simple Mail Transfer Protocol)、TCP ベース、ポート 25
- 特徴：
- メールサーバー間の通信
- TCP + 長時間接続に基づく
- サーバー = クライアント + サーバー
- 電子メール メッセージは 7 桁の ASCII コードで構成されている必要があります
- 中継サーバーを使わず、太平洋をまたがる2台のサーバーでも直接通信
- 他の
- 送信の 3 段階: ハンドシェイク、送信、シャットダウン
- コマンド: ASCII テキスト
- 応答: ステータス コード + ステートメント
- メッセージは CRLF.CRLF (CR=キャリッジリターン、LF=ラインフィード) で終わります。
- SMTP と HTTP:
- HTTP: プル プロトコル。各オブジェクトは独立した応答メッセージにカプセル化されます。
- 2 つの応答にカプセル化されたテキスト + グラフィック ファイルに応答します
- SMTP: プッシュ プロトコル (プッシュ)、複数のオブジェクトが同じメッセージに入れられます。
- メッセージにカプセル化されたテキスト + グラフィック ファイルに応答します
- SMTP メッセージには 7 ビット ASCII エンコードの使用が強制され、HTTP には制限がありません。
- どちらもコマンド/応答対話モードを使用し、コマンドとステータス コードは ASCII コードです。
- HTTP: プル プロトコル。各オブジェクトは独立した応答メッセージにカプセル化されます。
- SMTP メッセージ ヘッダー形式: From+To+Subject (オプション)
メールアクセスプロトコル
- ユーザーエージェントがサーバー側メールにアクセスするためのプロトコル (SMTP トランスポートプロトコルを区別)
ポップ3
- POP3 (ポスト オフィス プロトコル - バージョン 3): TCP、ポート 110 に基づくポスト オフィス プロトコルの 3 番目のバージョン
- 作業段階: 認可、トランザクション処理、更新
- 認可: ユーザー エージェント (ブラウザ) は、ユーザー名とパスワードをクリア テキストでサーバーに送信します。
- トランザクション処理: 電子メールをローカルにダウンロード
- 更新：ダウンロード後にサーバー内の既読メールを自動削除するなど、サーバーのメールステータスを更新します。
- デメリット: セッション情報が保持されず、複数のデバイスを使用するのが不便
IMAP
- IMAP (インターネット メール アクセス プロトコル): インターネット メール アクセス プロトコル
- セッション情報の維持: マルチデバイスの問題を解決する
HTTP
- HTTP を使用してブラウザおよびメール サーバーと通信してメールを取得しますが、メールの送信には SMTP を使用します。
DNS
基本的な考え方
- DNS (ドメイン ネーム システム): UDP に基づくドメイン ネーム サービス システム、ポート 53
- 機能: IP アドレスを置き換えて記憶しやすくします (携帯電話のアドレス帳サービスに似ています)
- HTTP、SMTP、FTP はすべて DNS サービスに基づいています
動作メカニズム
- 基本原理: 下から上にレイヤーごとにクエリを実行し、キャッシュ メカニズムをセットアップできます (高度な DNS サーバーにアクセスせずに)
- 階層型、分散型
DNSメッセージ
- メッセージ構造
P2Pファイル配布
- P2P (ピアツーピア): ポイントツーポイント伝送
- Web/メール/DNSはいずれもCilent/Server構造を採用しており、P2Pにより同等のプロトコル伝送を実現します。
- アーキテクチャ図: u はアップロード速度、d はダウンロード速度、F はファイル サイズを表します。
C/Sアーキテクチャ VS P2Pアーキテクチャ ファイル転送
- ファイル サイズは F、Us はサーバーのアップロード速度、dmin は最小ダウンロード速度、N クライアントです。
- C/S アーキテクチャ:
- NF/Us は、サーバーが合計 NF サイズのデータを N 個のクライアントにアップロードするのにかかる時間を示します。
- F/dmin は最も遅いクライアントのダウンロード時間を表します。
- 2 つの最大値を取る
- P2P アーキテクチャ:
- F/U は、サーバーが少なくとも 1 つの完全なコピー (さまざまなクライアントに分散している可能性があります) をアップロードする必要があることを意味します。
- F/dmin は最も遅いクライアントのダウンロード時間を表します。
- 最後の項目は、合計ファイル トラフィックが NF/合計アップリンク速度であることを示します。
- ユーザー数が増加するにつれて (特定の条件下で)、P2P アーキテクチャの利点がますます明らかになります。
BitTorrent - P2P プロトコル
- リクエスト - 希少性の原理 - 近傍数が最も少ないパーツをリクエストします
- レスポンス - インセンティブアルゴリズム - 高速アップロードと高速ダウンロード
HTTPストリーミングとCDN
HTTPストリーミング
- ストリーミング ビデオ - アプリケーションは受信したビデオを再生し、ビデオの後続のフレームをキャッシュします。
- DASH (Dynamic Adaptive Streaming over HTTP): HTTP 動的適応ストリーム
- DASH では、ビデオは異なるビットレートで異なるバージョンにエンコードされます。お客様は、帯域幅の条件に基づいて、適切なビットレートでビデオを動的に再生します。
- サーバーは、異なるバージョンがあることを示す通知ファイルを送信します。
CDN
- CDN (Content Distribution Network): コンテンツ配信ネットワーク
- コア: DNS を使用したリダイレクト
- 動作の仕組み
- ①ユーザーはWebページwww.NetCinema.comにアクセスします。
- ②ユーザーはローカルDNSにDNSクエリリクエストを送信します。
- ③ローカルDNSが権威サーバーに問い合わせを行うと、権威サーバーはCDN範囲内にあることを検知して自身のIPを返さず、CDN範囲内で排他的に問い合わせるためのDNS権威サーバーを返します。
- ④ローカルDNSは新しく取得したDNSサーバーにリクエストを送信します。
- ⑤ローカルDNSはCDNコンテンツを取得したサイトサーバーを返します
- ⑥ユーザーと専用コンテンツ配信サーバーがダウンロードリクエストを送信
