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

コースの内容#

概要#

ネットワークアプリケーションのアーキテクチャは主にCS アーキテクチャとP2P アーキテクチャに分けられます。

前者はクライアント（Client）/ サーバー（Server）アーキテクチャであり、WeChat、QQ、ゲームなどが該当します。
後者はピア（Peer）ツー・ピアアーキテクチャまたはピアツーピアアーキテクチャとも呼ばれ、Thunder、Baidu Netdisk などが該当します。
- プロセス間通信では、明確な C/S がなく、要求者がクライアントであり、サービスプロバイダがサーバーです。

アプリケーションサービスの要件には、信頼性のあるデータ転送、スループット、タイミング（タイムリネス）、セキュリティが含まれます。異なるアプリケーションはネットワークサービスに異なる要件を持っており、データの損失、帯域幅の要求、タイムリネスなどが考慮されます。そのため、さまざまなアプリケーション層プロトコルとトランスポート層プロトコルが生まれました：

アプリケーション層プロトコルは、メッセージの交換タイプ、メッセージの構文、フィールドの意味、送信および応答ルールを定義します。これはネットワークプロトコルの 3 つの要素（構文、意味、同期）に似ています。
トランスポート層プロトコル
- TCP：接続指向のサービスで、信頼性のあるデータ転送を提供します。
- UDP：必要なサービスを提供しない軽量なトランスポートサービスで、信頼性のあるデータ転送を提供しません。
PS
- ソケットはアプリケーションとネットワークの間のインタフェースであり、トランスポート層の制御はトランスポート層プロトコルの選択とパラメータの設定に制限されます。
- UDP は独自の信頼性のあるデータ転送を実装できます。

WEB と HTTP プロトコル#

WEB 用語：オブジェクト、ハイパーテキストマークアップ言語 HTML、Uniform Resource Locator（URL）、WEB ページ、WEB ブラウザ、WEB サーバー（httpd、apache、tomcat）
HTTP：ハイパーテキスト転送プロトコル

HTTP の動作：リクエストメッセージ、レスポンスメッセージ
HTTP の特徴
- データの損失を心配する必要はありません
- 状態を持たないプロトコルであり、サーバーはクライアントに関連する状態情報を保存しません
- HTTP サーバーは常にオープンで、固定の IP を持っています
- CS アーキテクチャを使用します
非持続的接続と持続的接続、またはショートコネクションとロングコネクション
- HTTP はショートコネクションに属し、サーバーがリクエストに応答した後、TCP 接続を切断するように通知します。そのため、複数のオブジェクトに対しては、接続と切断が繰り返されます。
- HTTP リクエストプロセスには TCP の 3 ウェイハンドシェイクが含まれ、通常は 3 回目のハンドシェイクにリクエストが含まれ、対応するファイルが受信されるまで続きます。
リクエストメッセージ
- リクエストメソッド：
  - GET-- 取得
  - POST-- フォームの送信
  - HEAD-- テスト、接続の可否を確認し、すべてのデータを取得する必要はありません
  - PUT-- データをリモートに転送します（PUT は冪等ですが、POST はそうではありません）
  - DELETE-- リモートデータを削除します
- ヘッダフィールド名にはブラウザのタイプなどが含まれます。
レスポンスメッセージ
- フレーズは通常、ステータスコードの説明です。
- 一般的なステータスコードとフレーズ：
  - 200 OK
  - 301 Moved Permanently
  - 400 Bad Request
  - 404 Not Found
  - 505 HTTP Version Not Supported
ユーザーとサーバーのインタラクション - COOKIE
- リクエストとレスポンスメッセージの両方に COOKIE ヘッダ行が追加されます
- ユーザー側では、ブラウザが COOKIE ファイルを管理します
- サーバー側では、データベースを維持します
- 一度も jd サーバーにリクエストを送信したことのないクライアントホストは、リクエストを送信すると、サーバーが COOKIE を作成してクライアントに返します。
- 次回 jd サーバーにリクエストすると、サーバーは COOKIE に基づいて特定のデータを返します。
- PS：
  - サーバーはクライアントの行動に基づいてプロファイルを生成し、COOKIE と関連付けることができます。
  - 会社間でデータベースを共有することがあります。
WEB キャッシュ🌟
- プロキシサーバーとも呼ばれます。CDN などが該当します。
- シナリオ：大量のユーザーが特定のサーバーのデータにアクセスすると、トラフィックが多すぎてサーバーがクラッシュする可能性があります。
- 最適化プロセス：ブラウザはまず WEB キャッシュにアクセスし、必要なデータがない場合は上流にデータを検索し、最後にデータを返し、WEB キャッシュに保存します。
- 利点：クライアントのリクエスト応答時間を短縮し、データセンターの通信量を減らし、アプリケーションのパフォーマンスを向上させます。
- PS：WEB キャッシュは定期的に上流サーバーにデータの更新を要求します。

HTTPS プロトコル#

HTTPS：安全な SSL 暗号化転送プロトコル

HTTPS は HHTP 通信の中間にSSL/TLS（暗号化 / 復号化）プロセスを追加します。

HTTPS の特徴：

CA に証明書を申請する必要があり、料金がかかります。
HTTP は平文で情報を転送する一方、HTTPS は安全な SSL 暗号化転送プロトコルです。
HTTP とは完全に異なる接続方法を使用し、ポートも異なります。前者は 443 であり、後者は 80 です。

HTTP/2 プロトコル#

新機能：コネクションの再利用。同期の制約はなく、一度に複数のメッセージを転送できます。

FTP プロトコル#

FTP：ファイル転送プロトコル

ユーザーはリモートサーバーに接続し、リモートデスクトップフォルダをユーザーに表示し、ユーザーはそれを操作できます。

双方向接続- FTP の TCP 接続：

制御接続：ポート 21、長時間接続
データ接続：ポート 20、短時間接続
特徴：同時に処理する要件が高くないシナリオに適しており、ビジネスの実装を簡素化できます。

PS：個人ユーザーはあまり使用せず、通常はローカルエリアネットワークにサービスを提供します。

SMTP、POP3、IMAP プロトコル#

メール関連、最初のインターネットサービス

ユーザー A のエージェントから、自分のメールサーバーに SMTP 接続し、ユーザー B のメールサーバーに接続し、最後にユーザー B のエージェントに到達します。

メールサーバーはメールの内容が規則に適合しているかどうかをチェックします。
SMTP プロトコルはプッシュのみを担当し、最後のステップは他のプロトコルに基づいてアクティブに要求を取得します。

PS：

ユーザーホストと直接通信しません
TCP に基づいています

DNS プロトコル#

ホスト名 / ドメイン名を IP アドレスに変換します。負荷分散サービスを提供します。

ドメイン名の解決
負荷分散：同じドメインはトラフィックに応じて異なる適切な IP アドレスに変換されます。主にトラフィック分散に使用されます。

集中型 DNS の問題点：

単一障害点：小さな問題がグローバルに影響を与える可能性があります（現在、マイクロサービスが流行しており、さまざまなサービス間の結合度を減らしています）。
通信容量が大きい
遠い距離では遅延が高くなる可能性があります
メンテナンスが困難です（銀行でも同じ問題があり、システムのバージョンが低く、移行が困難です）

DNS ドメインシステム

ルート DNS サーバー、インターネット上には 13 個あり、中国には存在しません
トップレベルドメイン DNS サーバー、TLD とも呼ばれます。com、cn などが該当します
権威 DNS サーバー、テンセントなどの DNS サービスプロバイダが該当します
ローカル DNS サーバー、複数ある場合があります。ローカルエリアネットワーク、学校などが該当します

DNS 解決プロセス：

ホストからローカル DNS は再帰的です。ホストは 1 回のリクエストのみを送信し、ローカル DNS が結果を取得するまで待ちます。

ローカル DNS のリクエストは反復的です。失敗した場合は再度リクエストします。図を見て感じてください。

DNS レコード

Name：名前 / ホスト / エイリアス
Value：IP アドレス / 応答アドレス / ターゲットアドレス
Type：レコードのタイプ
TTL：ドメイン - IP の関係の有効期間、つまりローカルキャッシュの時間

一般的なタイプは次のとおりです：

自分の DNS サービスプラットフォームに DNS レコードを追加してみてください〜

PS：規範的なホスト名の可読性はやや低く、DNS records - CloudFlare を参照してください