コンピューターネットワークの経験

1. OSI 7 層モデル ❤️❤️❤️❤️❤️❤️

	OSI 模型（Open System Interconnection Model）是⼀个由 ISO 提出的概念模型，
	试图提供⼀个使各种不同的的计算机和⽹络在世界范围内实现互联的标准框架。
	虽然OSI参考模型在实际中的应⽤意义并不是很⼤，但是它对于理解⽹络协议内部的运作很有帮助，
	为我们学习⽹络协议提供了⼀个很好的参考。它将计算机⽹络体系结构划分为7层，
	每层都为上⼀层提供了良好的接⼝。以下将具体介绍各层结构及功能。

2. 階層構造

1. 物理層

簡単に言えば、物理層は、元のデータがさまざまな物理メディア上で送信できることを保証します。この層は、通信エンドポイント間の機械的、電気的、および機能的機能のアクティブ化、メンテナンス、およびシャットダウンを指定し、上位層プロトコルのデータ送信用の物理媒体を提供します。この層はビット ストリームを送信します。

2. データリンク層 ❤️❤️❤️

データ リンク層 (データ リンク層) は、信頼性の低い物理メディア上で信頼性の高い伝送を提供します。この層の機能には、物理​​アドレス アドレッシング、データ フレーミング、フロー制御、データ エラー検出、再送信などが含まれます。この層では、ビット ストリームがフレーム フレームにカプセル化されます。

3. ネットワーク層 ❤️❤️❤️

ネットワーク層は、サブネット間のデータ パケットのルーティングを担当します。さらに、ネットワーク層では、輻輳制御やインターネット相互接続などの機能も実装できます。この層ではデータの単位をパケットと呼びます。

4. トランスポート層

トランスポート層はエンドツーエンド、つまりホスト間の層です。トランスポート層は、上位層のデータをセグメント化し、エンドツーエンドで信頼性の高い、または信頼性の低い伝送を提供する責任を負います。さらに、トランスポート層は、エンドツーエンドのエラー制御とフロー制御の問題も処理します。この層ではデータの単位をセグメントと呼びます。

5.セッションレイヤー❤️❤️❤️

この層はホスト間のセッション プロセスを管理します。つまり、プロセス間のセッションの確立、管理、終了を担当します。また、セッション層は、データにチェックポイントを挿入することによってデータ同期を実装し、アクセス検証やセッション管理などのアプリケーション間の通信メカニズムを確立および維持します。たとえば、ユーザー ログインのサーバー認証はセッション層によって行われます。通信が失敗した場合に、通信セッションがチェックポイントから通信を再開できるようにします。たとえば、セッション認証や再開可能なアップロードなどのセッションを確立します。

6. プレゼンテーション層

この層は主にユーザー情報の文法表現の問題を解決します。交換するデータを、特定のユーザーに適した抽象構文から、OSI システムの内部使用に適した転送構文に変換します。つまり、フォーマットされた表現および変換データ サービスを提供します。データの圧縮と解凍、暗号化と復号化はすべてプレゼンテーション層によって実行されます。たとえば、画像とビデオのエンコード ソリューション、データ暗号化などです。

7. アプリケーションレイヤー❤️❤️❤️

この層は、オペレーティング システムまたはネットワーク アプリケーションがネットワーク サービスにアクセスするためのインターフェイスを提供します。

3. 各層の伝送プロトコル、伝送単位、主要機能機器の比較

名前	転送プロトコル	送信ユニット	主な機能デバイス/インターフェース
物理層	IEEE802.1A、IEEE802.2	ビットフロー ビットフロー	光ファイバー、ツイストペア、リピータ、ハブ、ネットワークケーブルインターフェース
データリンク層	ARP、MAC、FDDI、イーサネット、Arpanet、PPP、PDN	フレームフレーム	ブリッジ、レイヤー2スイッチ
ネットワーク層	IP、ICMP、ARP、RARP	パケット	ルーター、レイヤー3スイッチ
トランスポート層	TCP、UDP	セグメント/データグラム	レイヤ4スイッチ
セッション層	SMTP、DNS	メッセージ	QoS
プレゼンテーション層	Telnet、SNMP	メッセージ	-
アプリケーション層	FTP、TFTP、Telnet、HTTP、DNS	メッセージ	-

4. TCP ヘッダーについて説明しますか? ❤️❤️❤️❤️❤️❤️❤️❤️

• シーケンス番号 32 (ビット): 送信方向のバイトストリームのバイト番号。初期シーケンス番号はランダムな初期値 (ISN) で設定され、データが送信されるたびに、シーケンス番号値 = ISN + バイト ストリーム全体のデータのオフセットになります。A -> B および ISN = 1024 と仮定すると、データの最初のセグメント 512 バイトが B に到着し、データの 2 番目のセグメントのシーケンス番号は 1024 + 512 になります。これは、ネットワーク パケットの順序が乱れている問題を解決するために使用されます。
• 確認番号（32ビット）：送信者のTCPセグメントに対する受信者の応答。その値は受信したシーケンス番号+1です。❤️
• ヘッダ長 (4 ビット): 4 バイト * ヘッダ長が何バイトあるかを示します。最大は 15、つまり 60 バイトです。
• フラグビット(6bit):
  • URG: 緊急ポインタが有効かどうかを示します。
  • ACK: 確認番号が有効かどうかをマークします (確認セグメント)。パケットロスの問題を解決するために使用されます。
  • PSH: 受信側にバッファからデータをすぐに読み取るよう要求します。
  • RST：相手に接続の再確立（リセットセグメント）が必要であることを示します。
  • SYN：コネクション（コネクションセグメント）の確立要求を示します。
  • FIN: 接続を閉じる (セグメントを切断する) ことを意味します。
• ウィンドウ (16 ビット): 受信ウィンドウ。相手（送信者）に、自分のバッファに何バイトのデータを受信できるかを知らせるために使用されます。フロー制御を解決するために使用されます。
• チェックサム (16 ビット): 受信側は CRC を使用して、メッセージ セグメント全体が破損していないかどうかをチェックします。

5. TCP スリーウェイ ハンドシェイクと手を振る❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️

1. スリーウェイ ハンドシェイク プロセス

• 初回: クライアントは、SYN ビット (SEQ_NUM = S) を含むパケットをサーバーに送信します。(ゲスト -> SYN_SEND)
• 2 回目: サーバーは、ACK、SYN ビット、ACK_NUM = S + 1、SEQ_NUM = P を含むパケットをクライアントに送信します。(サーブ -> SYN_RECV)
• 3 回目: クライアントは、ACK ビット (ACK_NUM = P + 1) を含むパケットをサーバーに送信します。(クライアント -> 確立、サービス -> 確立)

2. 4回手を振るプロセス

• 初回: クライアントは、FIN ビット、SEQ = Q を含むパケットをサーバーに送信します。(ゲスト -> FIN_WAIT_1)
• 2 回目: サーバーは、ACK および ACK_NUM = Q + 1 を含むパケットをサーバーに送信します。(サーバー -> CLOSE_WAIT、ゲスト -> FIN_WAIT_2)、ここで待機しています。
• 3 回目: サーバーは、FIN と SEQ_NUM = R を含むパケットをクライアントに送信します。(サーバー -> LAST_ACK、ゲスト -> TIME_WAIT) ここで待機中です。
• 4 回目: クライアントは、ACK ビットと ACK_NUM = R + 1 を含む最後のパケットをクライアントに送信します。(提供中 -> 閉店)

3. 握手が 3 回、手を振るのが 4 回あるのはなぜですか? ❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️

• ハンドシェイクの場合: ハンドシェイクでは、通信が中断されないように、双方が通信するときに初期化シーケンス番号を確認するだけで済みます。(3 回目のハンドシェイクの必要性: サーバーの確認が失われ、接続が切断されていないと仮定すると、クライアントはタイムアウト後に接続要求を再送信するため、サーバーは同じクライアントへの複数の接続を維持することになり、無駄な接続が発生します)資力。）
• ウェーブの場合: TCP は二重であるため、送信者と受信者の両方に FIN と ACK が必要です。ただ片方がパッシブなので4つの手を振っているように見えます。

4. TCP 接続ステータス?

• CLOSED: 初期状態。
• LISTEN: サーバーはリスニング状態にあります。
• SYN_SEND: クライアント ソケットは CONNECT 接続を実行し、SYN パケットを送信して、この状態に入ります。
• SYN_RECV: サーバーは、SYN パケットを受信し、サーバー SYN パケットを送信した後、この状態に入ります。
• ESTABLISH: 接続が確立されていることを示します。クライアントは最後の ACK パケットを送信した後にこの状態になり、サーバーは ACK パケットを受信した後にこの状態になります。
• FIN_WAIT_1: 接続を終了した側 (通常はクライアント) が FIN メッセージを送信した後に入力します。相手のFINを待ちます。
• CLOSE_WAIT: (サーバーを想定) クライアント FIN パケットを受信した後、終了ステージを待ちます。相手からの FIN パケットを受信したら、直ちに切断要求を承知したことを示す ACK パケットを返信するのが当然です。ただし、自側がすぐに切断する（FIN​​ パケットを送信する）かどうかは、クライアントに送信するデータがあるかどうかに依存し、ある場合には FIN パケットを送信する前の状態のままとなります。
• FIN_WAIT_2: 現時点では、半接続状態です。つまり、一方が接続の切断を要求し、もう一方が切断するのを待ちます。クライアントはサーバーから ACK パケットを受信しますが、サーバーから FIN パケットをすぐには受信せず、FIN_WAIT_2 状態に入ります。
• LAST_ACK: サーバーは最後の FIN パケットを送信し、最後のクライアント ACK 応答を待って、この状態に入ります。
• TIME_WAIT: クライアントはサーバーから FIN パケットを受信し、すぐに最終確認のため ACK パケットを送信し、その後の 2MSL 時間を TIME_WAIT 状態と呼びます。

5. FIN_WAIT_2、CLOSE_WAIT 状態、TIME_WAIT 状態について説明しますか?

• FIN_WAIT_2：
  • 半分閉じた状態。
  • データを送信する側は引き続きデータを受信する能力を持っていますが、データを送信する能力はもうありません。
• CLOSE_WAIT 状態:
  • 接続を受動的に閉じる側は、FIN パケットを受信した後、すぐに ACK パケットで応答し、切断要求が受信されたことを示します。
  • 接続を受動的に閉じた側にまだ送信するデータがある場合、CLOSED_WAIT 状態に入ります。
• TIME_WAIT 状態
  • 2MSL 待機状態とも呼ばれます。
  • クライアントが直接 CLOSED 状態に入った場合、サーバーが最後の ACK パケットを受信しない場合、タイムアウト後に FIN パケットを再送信しますが、このときクライアントは既に CLOSED 状態であるため、サーバーは ACK を受信せず、 ACK.RSTを受信します。したがって、TIME_WAIT 状態の目的は、最後のハンドシェイク データが相手に到達して FIN 準備の再送信がトリガーされるのを防ぐことです。
  • 2MSL 時間中は、同じソケットは使用できなくなります。そうしないと、古い接続データと混合される可能性があります (新しい接続と古い接続のソケットが同じ場合)。

6. RTO、RTT、タイムアウト再送信について説明しますか?

• タイムアウト再送信: 送信者がメッセージ送信後、長時間確認メッセージを受信しない場合、メッセージを再送信する必要があります。いくつかの状況が考えられます。
  • 送信したデータが受信側に届かず、相手が応答しませんでした。
  • 受信側はデータを受信しますが、返信処理中に ACK パケットが失われます。
  • 受信側がデータを拒否または破棄します。
• RTO: 再送信間隔は、ACK 応答が長期間受信されなかったため、最後にデータが送信されてから次の再送信までの時間です。
  • 通常、各再送信の RTO は前の再送信間隔の 2 倍であり、測定単位は通常 RTT です。例: 1RTT、2RTT、4RTT、8RTT...
  • 再送信回数が制限に達したら、再送信を停止します。
• RTT: データを送信してから相手の応答を受信するまでの時間、つまりデータグラムがネットワーク内で往復して使用される場合、サイズが不安定になります。
• その目的は、受信側が TCP ヘッダー ウィンドウ フィールドを通じて受信できるデータの最大量を送信側に通知し、送信速度が速すぎるために受信側が受信できない問題を解決することです。したがって、フロー制御はポイントツーポイント制御です。
• TCP は二重プロトコルであり、双方が同時に通信できるため、送信者と受信者はそれぞれ送信ウィンドウと受信ウィンドウを維持します。
  • 送信ウィンドウ: 送信者が送信できるデータのサイズを制限するために使用されます。送信ウィンドウのサイズは、受信者によって返される TCP セグメントのウィンドウ フィールドによって制御され、受信者は送信者に自身のバッファーを通知します。このフィールド (システム、ハードウェアなどによって制限されます) サイズ。
  • 受信ウィンドウ: 受信できるデータのサイズをマークするために使用されます。
• TCP はストリーム データであり、送信されるデータ ストリームは次の 4 つの部分に分割できます: 送信済み確認済み部分 | 送信済み未確認部分 | 未送信だが送信可能部分 | 送信不可能部分 (送信ウィンドウ = 送信済みだが非確認部分 + 未送信だが送信可能)部。受信データ フローは、受信済み | 未受信だが受信準備完了 | 未受信だが受信準備完了ではない、に分類できます。受信ウィンドウ = 受信されていませんが、部分を受信する準備ができています。
• 送信ウィンドウ内のデータは、受信側が送信したデータの一部のACK応答を受信した場合にのみ送信ウィンドウが移動し、左端が直前に確認したデータに近くなります。受信ウィンドウはデータ受信時のみ移動し、左端が連続します。

7. 輻輳制御原理

• 輻輳制御の目的は、ネットワークへの過剰なデータ注入によるネットワーク リソース (ルーター、スイッチなど) の過負荷を防ぐことです。輻輳制御はネットワーク リンク全体に関係するため、グローバル制御に属します。輻輳は輻輳ウィンドウを使用して制御されます。
• TCP輻輳制御アルゴリズム:
  • スロー スタートと輻輳の回避: 最初にネットワークの輻輳レベルをテストし、次に輻輳ウィンドウを徐々に増やします。輻輳ウィンドウは、しきい値 ssthresh に達するまで、確認応答を受信するたびに 2 倍になります。これは、スロー スタート プロセスの一部です。しきい値に達すると、輻輳ウィンドウ サイズは 1 MSS ずつ増加し、輻輳が発生した場合（タイムアウト後に確認が受信されない場合）、しきい値は元の値の半分に減らされ、線形増加が継続されます。このプロセスが渋滞回避です。
  • 最終的に、輻輳ウィンドウは安定した値に収束します。

6. フロー制御と輻輳制御を区別するにはどうすればよいですか?

• フロー制御は通信当事者間のネゴシエーションに属し、輻輳制御には通信リンクの品質が関係します。
• フロー制御では、通信当事者の両方が送信ウィンドウと受信ウィンドウを維持する必要があります。いずれの通信当事者にとっても、受信ウィンドウのサイズはそれ自体で決まり、送信ウィンドウのサイズは、TCP セグメントの TCP セグメントのウィンドウ値によって決まります。 ; 受信者の応答; 輻輳制御の輻輳ウィンドウ サイズの変更は、ネットワークの状態を検出するために一定量のデータを暫定的に送信することで適応的に調整されます。
• 実際の最終送信ウィンドウ = min{フロー制御送信ウィンドウ、輻輳ウィンドウ}。

7. TCP はどのようにして信頼性の高いデータ送信を提供しますか?

• 接続確立（フラグビット）：通信前に通信エンティティの存在を確認します。
• シーケンス番号メカニズム (シリアル番号、確認番号): データが順番に完全に到着することを保証します。
• データ検証 (チェックサム): CRC によりすべてのデータがチェックされます。
• タイムアウト再送信 (タイマー): リンク障害により受信できなかったデータが複数回再送信できるようにします。
• ウィンドウ機構 (ウィンドウ): 過剰な送信を避けるためのフロー制御を提供します。
• 輻輳制御: 上記と同じ。

8. TCPソケット対話プロセス?

• サーバ：
  • ソケットの構築->int ソケット(int ドメイン、int 型、int プロトコル);
    • ドメイン: ソケットのアドレス タイプを決定するプロトコル ドメイン。IPv4 は AF_INET です。
    • type: ソケットのタイプを指定します。SOCKET_STREAM は TCP 接続です。
    • プロトコルはプロトコルを指定します。IPPROTO_TCPはTCPプロトコルを示し、0の場合はタイプデフォルトプロトコルが自動的に選択されます。
  • ソケットとポート番号をバインド -> int binding(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
    • sockfd: ファイル記述子 fd と同様に、socket によって返されるソケット記述子。
    • addr: sockaddr 型データへのポインターがあり、バインドされた構造体変数を指します。

//IPv4的sockaddr地址结构
struct sockaddr_in{
    
    
	sa_family_t sin_family;//协议类型，AF_INET
	in_port_t sin_port;//端口号
	struct in_addr sin_addr; //IP地址
};
struct in_addr{
    
    
	uint32_t s_addr;
}

• addrlen: アドレスの長さ。
  • リスニングポート番号 -> int listen(int sockfd, int backlog);
    • sockfd; 監視される靴下説明ワード。
    • backlog: ソケットがキューに入れることができる接続の最大数。
  • ユーザーリクエストを受信 -> int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
    • ソケット: サーバーソケットの説明語。
    • addr: アドレス構造体へのポインタ。
    • addrlen: プロトコルアドレスの長さ。
    • 注: クライアント要求が正常に受け入れられると、特定のクライアントの TCP 接続を識別するための新しい記述子が返されます。
  • ソケットから文字を読み取ります -> ssize_t read(int fd, void *buf, size_t count);
    • fd: 接続記述子。
    • buf: バッファバッファ。
    • count: バッファ長。
    • 注: 0 より大きい場合は読み取ったバイト数を示し、0 を返す場合はファイル読み取りの終了を示し、0 より小さい場合はエラーが発生したことを示します。
  • ソケットを閉じる -> int close(int fd);
    • fd: accept によって返される接続記述子 (接続ごとに 1 つ)、ライフサイクルは接続サイクルです。
    • 注:socket は監視記述語であり、サーバーは 1 つだけ存在し、接続の有無を監視するために使用されます。fd は接続記述語で、各接続の動作に使用されます。
• クライアントコンピュータ:
  • ソケットの構築 -> int ソケット(int ドメイン, int タイプ, int プロトコル);
  • 指定したコンピュータに接続します -> int connect(int sockfd, struct sockaddr* addr, socklen_t addrlen);
    • sockfd クライアントの sock 記述子。
    • addr: サーバーのアドレス。
    • addrlen: ソケットアドレスの長さ。
  • ソケットに情報を書き込む -> ssize_t write(int fd, const void *buf, size_t count);
    • fd、buf、count: read と同じ意味。
    • 0 より大きい値はデータの一部またはすべてが書き込まれたことを示し、0 より小さい値はエラーを示します。
  • oscketを閉じる -> int close(int fd);
    -fd: サーバー側のfdと同じ