1. アプリケーション層プロトコルの原理
1.1. ネットワークアプリケーションのアーキテクチャ
考えられるアプリケーション アーキテクチャ:
- カスタマーサービスエリアモード（C/S）
- 不均等モデルは主にサーバーベースであり、スケーラビリティが不十分です。
- 例: Web アプリケーション
- ピアツーピア モデル (P2P)
- 自己拡張性。
- 例:雷
- ハイブリッド: クライアント/サーバーおよびピアツーピアのアーキテクチャ
- ナップスター：
- ホストはリソースを中央サーバーに登録します
- ホストは中央サーバーにリソースの場所を問い合わせます。
- 例:インスタント メッセージング (チャット ルーム) :
- ナップスター：
プロセスコミュニケーション
プロセス: ホスト上で実行されるアプリケーション
- 形式：ソケットAPI （ソース言語）の下位層が提供するサービスを介してアクセス
- アドレス: 対応するホスト レベルの SAP
アドレス指定: どのアドレス (IP)、ポート
1.2、ソケット(ソケット)
プロセスはソケットにメッセージを送信するか、ソケットからメッセージを受信します。
TCP ソケット: (ローカル IP とポート、相手側の IP とポートを表します)
- 接続指向サービス (TCP) を使用するアプリケーションの場合、ソケットは 4 タプルのローカルで意味のある識別子です。
- 4 タプル: (送信元 IP、送信元ポート、宛先 IP、宛先ポート)
- セッションを一意に指定します (TCP ソケットは実際には2 つのプロセス間のセッション関係を表します)
- アプリケーションはこのフラグを使用してリモート アプリケーション プロセスと通信します。
- 送信されるすべてのメッセージでこれらの 4 タプルを指定する必要はありません。
- オペレーティング システムを使用してファイルを開くと OS がファイル ハンドルを返すのと同じように、このファイル ハンドルは、将来、ファイルのディレクトリ名とファイル名を使用する代わりに使用されます。
- シンプルで管理が簡単
- したがって、情報を転送する必要があるのは渡すことだけです
- データ、ソケット
UDPソケット：
- UDP サービス、2 つのプロセス間の通信には事前の接続確立は必要ありません
- 各メッセージは独立して送信されます
- 前後のメッセージは異なる分散プロセスに送信されます。
- したがって、このアプリケーション エンティティの識別子を識別するには整数のみを使用できます。
- このメッセージは別の分散プロセスに送信される可能性があるため、
- 層間インターフェースを通過する情報の最小サイズ
- UDP ソケット: ローカル IP、ローカル ポート
- ただし、メッセージを送信する場合は、相手の IP とポートを提供する必要があります。
- メッセージを受信するとき: トランスポート層は相手の IP とポートをアップロードする必要があります
- したがって、情報を送信するには次の 3 つのものを渡す必要があります。
- ソケット、データそのもの、相手のアドレス（IPとポート）
トランスポート層によってアプリケーション層に提供されるパフォーマンス指標:
- レイテンシ、スループット、データ損失率、セキュリティ
-
TCP と UDP はどちらもクリア テキストで送信されるため、セキュリティは提供されません。
-
したがって、送信が安全である場合、トランスポート層サービスのセキュリティは SSL プロトコルを通じて実行される必要があります。
- アプリケーションは、TCP 通信を使用する SSL ライブラリを使用します。
- SSL
- TCP 上に実装され、暗号化された TCP 接続を提供します
- プライバシー
- データの整合性
- エンドツーエンド認証
- SSLソケットAPI
- アプリケーションは、プレーン テキストをソケットに渡すための API を提供し、インターネット経由で送信するために SSL で暗号化します。
2、WEBとHTTP
HTTP のバージョン 1.0 は、非永続的な HTTP 接続です。
1.1 以降、HTTP 接続は永続的な HTTP 接続に変更されました。
2.1. HTTP リクエストメッセージ: 80 (デフォルトポート)
- 2 種類のリクエスト メッセージ: リクエストとレスポンス。
- HTTPリクエストメッセージ:
- アスキー
- リクエストライン（GET、POST）
2.2、FTP：21
ftp: ファイル転送プロトコル
デュアルチャネル接続、帯域外 (コマンド送信) と帯域内 (データ送信) の 2 つの TCP 接続で実行される、ステートフル プロトコル
2.3、メール：25
SMTPプロトコル:メールボックスサーバー
- メールボックス内のユーザーに送信された電子メールを管理および維持する
- 出力メッセージキューには保留中の電子メールメッセージが保持されます
- メールサーバー間のSMTPプロトコル
- 電子メールメッセージを送信する
- クライアント: 送信メールサーバー
- サーバー：受信メールサーバー
送信の 3 段階:
- 握手
- 応答メッセージ
- 閉鎖
- SMTP は永続的な接続を使用します
- SMTP では、メッセージ (ヘッダーと本文) が 7 ASCII でエンコードされている必要があります。
- SMTP サーバーは CRLE を使用し、CRLE がメッセージの末尾を決定します
3、DNS
UDP:57
ドメイン名解決システム
DNS によって解決される問題:
- 名前の付け方;
- 解析方法;
- メンテナンス方法;
DNS の主な考え方:
- 階層的なドメインベースの命名スキーム
- 複数の分散データベースで名前から IP アドレスへの変換が完了
- ポート 53 の UDP で実行されているアプリケーション サービス
- コアのインターネット機能ですが、アプリケーション層プロトコルとして実装されています
- ネットワークエッジでの複雑な処理
DNS の主な目的:
- ホスト名とIPアドレスの変換(名前/IP変換)を実装します。
- その他の目的
- ホストエイリアスから正規名への変換
- メールサーバーのエイリアスをメールサーバーの正式名に変換
- 負荷分散
DNS の一般的な作業プロセスは次のとおりです。
- アプリケーションがリゾルバーを呼び出す
- パーサーは、クエリ メッセージ (UDP セグメントにカプセル化された) をクライアントとしてネーム サーバーに送信します。
- ネームサーバーは応答メッセージ (名前/IP) を返します
- ドメイン名のクエリ方法
- 再帰クエリ
- 反復クエリ
- 再帰クエリ
4.P2Pアプリケーション
4.1. 純粋な P2P アーキテクチャ
- 常時稼働しているサーバーは存在しない (または非常に少数)
4.2. ファイル配布: C/S と P2P
- 非構造化P2P
- 一元化されたディレクトリ
- 完全に分散
- ハイブリッド
- DHT (構造化) P2P
- ハッシュ表
- 樹形
5. TCPソケットプログラミング
5.1. ソケットプログラミング
- アプリケーション プロセスは、トランスポート層によって提供されるサービスを使用してメッセージを交換し、アプリケーション プロトコルを実装してアプリケーションを実装します。
- TCP/IP: アプリケーション プロセスはソケット API を使用してトランスポート プロトコルにアクセスします。
- 場所: インターフェース上の SAP (ソケット) 方法: ソケット API
- ソケット: 分散アプリケーションプロセス間のドア、トランスポート層プロトコルによって提供されるエンドツーエンドのサービスインターフェイス
5.2. TCPソケットプログラミング
サーバーが最初に実行され、接続が確立されるまで待機します。
- サーバープロセスが最初に実行されている必要があります
- ウェルカムソケットを作成する
- ローカルポートとバンドルされています
- ウェルカムソケットでのユーザー接続の受信待機をブロックする
クライアントはサーバーとの接続をアクティブに確立します
- クライアントのローカル ソケットを作成します (ローカル ポートに暗黙的にバインドされます)。
- サーバープロセスのIPアドレスとポート番号を指定してサーバープロセスに接続します
- クライアントから接続要求が来たとき
- サーバーはクライアントからのリクエストを受け入れ、ブロック待機を解除し、新しいソケットを返し、クライアントと通信します。
- サーバーが複数のクライアントと通信できるようにします
- 送信元 IP と送信元ポートを使用して、異なるクライアントを区別します。
- 接続 API 呼び出しが有効な場合、クライアントはサーバーとの TCP 接続を確立します。
ソケット構造
ソケットの相互作用
黑色的代表UCP交互的过程，红色的代表应用报文交互的过程
2 つのプロセスは同じポートを保護できますが、2 つのプロセスのソケットは異なります。
- ソケットの本質は、4 タプル構造のメモリ空間アドレスです。
- ソケットで表される 4 つのタプルは、ターゲット ip/ソース ip/ターゲット ポート/ソース ポートです。
UDPソケットプログラミング
UDP ソケット交換。通信を確立する前にハンドシェイクは必要ありません。接続は直接確立できます。
