記事ディレクトリ
序文
現在、第24回大学院入試の準備中ですが、コンピュータ王24問のうち408問で学んだ知識をまとめて整理してみます。
Blogger ブログ記事ディレクトリ インデックス:ブログ ディレクトリ インデックス (継続的に更新)
1. トランスポート層が提供するサービス
1.1. トランスポート層の機能
トランスポート層はホストのみが持つ層です。
トランスポート層の機能:
1. トランスポート層は、プロセス間の論理通信を提供します。
- 論理通信: 表面的には 2 つのホストのプロセス間の通信ですが、実際の通信では、送信者は最初に最上位層から物理層まで段階的にカプセル化し、ビット ストリームをリンクに入れて送信します。複数の中間システムが最終的にホストに到達し、段階的にカプセル化が解除され、最後に指定されたアプリケーションがデータを要求します。
- ネットワーク層は、ホスト間の論理通信を提供します。
2. 再利用と廃棄。
- 例: WeChat と QQ によって送信されるデータは、最終的に送信 (多重化) に同じトランスポート層プロトコルを使用し、ターゲットの携帯電話は同時にトランスポート層でデータグラムを分割し、それを異なるアプリケーションに渡します。別途ご利用ください）。
3. トランスポート層は、受信したメッセージに対してエラー検出を実行します。
- ネットワーク層ステージには、IP データグラムのヘッダーをチェックするヘッダー チェックが含まれていますが、エラー検出機能がないのは、上位のトランスポート層がトランスポート層セグメントのエラー検出を行うためです。トランスポート層＋ネットワーク層では、確実な伝送機能を実現します。
- トランスポート層にはUDPとTCPが含まれており、このうちTCPは確実な伝送を保証するため、必ずしも確実な伝送が可能であるとは限りません。
1.2. トランスポート層の 2 つのプロトコル (TCP、UDP)
2 つのプロトコルは次のとおりです: TCP、UDP。前者は信頼できますが、後者は信頼できません。
TCP プロトコルと UDP プロトコルの比較:
① TCP:コネクション型伝送制御プロトコル。
- データ送信処理：データ送信前にコネクションを確立し、データ送信完了後にコネクションを解放する必要があります。ブロードキャストまたはマルチキャスト サービスは提供されません。
- TCP は信頼性の高い接続指向の送信サービスを提供する必要があるため、確認、フロー制御、タイマー、接続管理など、必然的に多くのオーバーヘッドが追加されます。
- 信頼性はありますか? 信頼性の高い、対面接続、大きな遅延。
- アプリケーションシナリオ: 大きなファイルに適しています。
② UDP:コネクションレス型ユーザーデータグラムプロトコル UDP。
- データ送信プロセス: データ送信前に接続を確立する必要はなく、UDP メッセージ受信後の確認も必要ありません。
- 信頼性: 信頼性が低く、接続されず、遅延が小さい。
- アプリケーションシナリオ: 小さなファイルに適しています。
1.3. トランスポート層のアドレス指定とポート (共通ポートの紹介)
再利用と廃棄:
复用: アプリケーション層のすべてのアプリケーションプロセスは、トランスポート層を介してネットワーク層に送信できます。分用: トランスポート層は、ネットワーク層からデータを受信した後、指定されたアプリケーション プロセスにデータを配信します。
ポート: トランスポート層の SAP、ホスト内のアプリケーション プロセスを識別するために使用されます。各アプリケーション プロセスは実行時にポート番号を持ちます。
- 主に、論理ポート/ソフトウェア ポートに分けられます。ソフトウェア ポートは、アプリケーション プロセスのポートを指します。ハードウェア ポートの場合、実際の物理世界のマザーボード上のいくつかのインターフェイスを指します。
- ポート関係: ポート番号はローカルな意味のみを持ち、インターネット上の異なるコンピューター上の同じポート間には接続がありません。
- ポート番号の長さ: 16 ビット。65536 個の異なるポートを表すことができます。
ポート番号は、サーバーのポート番号とクライアントが使用するポート番号を含む範囲に応じて分割されます。
固定アプリケーション サービスで使用される一般的なポートの一部は次のとおりです。
送信側ソケットと受信側ソケットの組み合わせは、ネットワーク内のエンドポイントを識別するために使用されます。
ソケット: ネットワーク上のホストとその上のプロセスを一意に識別します。
套接字Socket = （主机IP地址，端口号）ここで、ホスト IP アドレスはネットワーク内のホストを識別して見つけることができ、ポート番号はホスト上のプロセスを表すために使用されます。
2. UDPプロトコル
2.1. UDPの機能と特徴を理解する
UDP 機能: IP データグラム サービスに加えて、多重化、逆多重化、エラー検出機能などのいくつかの機能のみを提供します。
UDP の主な機能:
1. UDP はコネクションレス型であるため、データ送信前のオーバーヘッドと遅延が軽減されます。
2. UDP はベストエフォート配信を使用します。これは、信頼性の高い配信が保証されていないことを意味します。
- UDP プロトコルが信頼性の高い配信を保証できない場合、信頼性の高い配信はトランスポート層の上位アプリケーション層に委ねられ、信頼性の高い順次配信が保証されます。
3. UDP はメッセージ指向であり、一度に少量のデータを送信するネットワーク アプリケーションに適しています。
アプリケーション層が UDP メッセージを送信する時間に関係なく、UDP は通常どおりメッセージを送信します。つまり、一度に1 つの完全なメッセージを送信します。また、配信の信頼性が低いため、簡単にデータ損失が発生する可能性があります。送信されるデータ量が損失が発生しても大きくない 環境損失も比較的小さい。
- データが大きすぎる場合は、ネットワーク層でデータを断片化する必要があります。これは、後続のリンク層への送信のためにリンク層に MTU 要件があるためです。
- データが小さすぎてヘッダーよりも小さい場合、ネットワーク層の効率が低下します。データグラムにはできるだけ多くのデータ情報が含まれ、ヘッダーにはできる限り追加情報が含まれないことが望まれます。
4. UDP には輻輳制御がなく、多くのリアルタイム アプリケーションに適しています。
- **これは、輻輳制御がないことを意味するものではなく、ネットワークが再び輻輳した場合でも、UDP は送信側の速度を低下させないため、現時点ではこの問題は制御されません。この状況ではこの協定は良くないと思いますか？**実際にはそうではありません。UDP には輻輳制御がないため、IP 電話やビデオ会議などの多くのリアルタイム アプリケーションに適しており、ネットワーク輻輳が発生したときに一部のデータを破棄できるなど、いくつかの利点もあります。これらのリアルタイム アプリケーションではデータの過度の遅延は許容できないため、実際には多少の損失は許容されます。
- 特に深刻な輻輳状況の場合は、前方誤り訂正や失われたメッセージの再送信など、特定の是正措置が講じられます。
5. UDP ヘッダーのオーバーヘッドは8Bと小さいのに対し、TCP は 20B です。
2.2. UDPヘッダフォーマット
ヘッダー フィールドの総数は8Bに固定されており、源端口号、目的端口号、UDP长度および はすべて2B (16 ビット)UDP检验和です。
16位UDP长度: データフィールド + ヘッダーフィールドを指します。データフィールドが 7B の場合、UDP 長は 15 です。
16位UDP检验和
- ケース 1: UDP データグラム全体にエラーがあるかどうかを確認し、エラーがある場合は破棄します。
- ケース 2: 分割時 (受信側がメッセージを受信するとき、ポート番号に従って異なるプロセスに分割する必要があります) 対応する宛先ポート番号が見つからない場合、メッセージは破棄され、ICMP の「ポート」が送信者に送信されます。到達不能です」というエラー メッセージが表示されます。
2.3. UDP 擬似ヘッダーフィールドの解析
擬似ヘッダーはチェックサムを計算するときにのみ表示され、下向きに送信されたり、上向きに送信されたりしません。擬似ヘッダーは、シミュレートされた IP データグラム ヘッダーです。
源IP地址：4バイト。目的IP地址：4バイト。0: 1 バイト、オール 0、つまりヘッダーの 3 番目のフィールドはオール 0 で固定されます。- 擬似ヘッダー
17: 1 バイトでは、 UDP メッセージをカプセル化するIP データグラムヘッダーのプロトコル フィールドは 17 です。 UDP长度：2バイトUDP长度 = UDP首部8B + 数据部分长度（擬似ヘッダを除く）
2.4. 擬似ヘッダ検証 UDP ユーザーデータグラムプロセス
疑似ヘッダーを使用して UDP ユーザー データグラムにエラーがあるかどうかを確認するにはどうすればよいですか?
多くの 16 ビット文字列が接続されたもの、つまり、多くの 4 バイト コンポーネントと考えると、次の図の右半分に示すように、16 ビットごとが 1 つのグループとして並べて書き込まれます。
送信側:
1. 擬似ヘッダーを入力します。
2. チェックサムフィールドにすべてゼロを入力します。
3. データ部分をすべて 0 で埋めます (UDP データグラムは、多数の 4B 文字列が連結されたものと見なされます)。
4. 計算: 擬似ヘッダー + ヘッダー + データ部分を 2 進数の 1 の補数コードを使用して合計します。
5.合計の 1 の補数をヘッダーのチェックサム フィールドに入力します。
6. 擬似ヘッダを削除して送信します。
受信側:
1. 擬似ヘッダーを入力します。
2. 擬似ヘッダ + ヘッダ + データ部分は 2 進補数を使用して加算されます。
- 注:送信側のチェックサムは合計を計算するときにすべて 0 ですが、受信側ではチェックサムは前の合計結果の反転になります。ここでチェックサムを追加します。
3. 最終結果がすべて 1 の場合はエラーではありませんが、それ以外の場合はデータグラムが破棄されるか、アプリケーション層でエラー警告が付加されます。
合計の次の違いはチェックサム部分です。受信側では、このチェックサムは送信側のチェックサムであり、すべて 0 を使用して計算されることはなくなりました。
**最終的な合計が 1 になるのはなぜですか? **送信側で得られた最終結果が逆コードであり、検証側に投入されると、計算値+逆コード値がすべて1になることがわかります。
3.TCPプロトコル
3.1. TCP プロトコルの特性とメッセージ形式
3.1.1. TCPプロトコルの特徴
1. TCP は、コネクション指向 (仮想接続) トランスポート層プロトコルです。
- 仮想接続: トランスポート層の論理通信と同じですが、実際の物理接続ではありません。物理接続とは、データグラムに各層のヘッダーを追加して送信用のリンクに置き、受信側に送信することを指します。段階的にカプセル化を解除します。これは完全な物理接続です。TCP プロトコルを使用すると、2 つのプロセスがポイントツーポイント接続を確立したかのように見えるため、仮想接続になります。
2. 各 TCP 接続はポートを 2 つだけ持つことができ、各 TCP 接続はポイントツーポイントのみにすることができます。
3. TCP は、エラー、損失、重複がなく、順序どおりに到着する、信頼性の高い配信サービスを提供します。[信頼性と秩序、紛失したり重いものは何もありません]
4. TCP は全二重通信を提供します。
- 全二重通信では、両端が同時にデータを送受信できます。
- その特性上、TCP プロトコル接続の両端には送信バッファ (送信準備完了キュー)と受信バッファ (受信準備完了キュー)が装備されます。
发送缓存: データ送信準備完了、およびデータ送信済みだがまだ確認されていないデータ。(送信済みでまだ確認を受け取っていない一部のデータについては、タイムアウトが発生すると再送信する必要があるため、キャッシュから直接削除することはできません)接收缓存: 順番どおりに到着するが、受け入れ側のアプリケーションによってまだ読み取られていないデータ、および順番どおりに到着しないデータ。(順番に到着したデータごとに、データの順番が揃って初めて、受信側は受信バッファからデータを1つずつ取り出し、対応するプロセスに渡すことができます。)
5. TCP はバイト ストリームを重視しています
- これは、TCP がアプリケーションによって渡されたデータを単なる一連の非構造化バイト ストリームとして認識するという事実を指します。
流: プロセスに流入またはプロセスから流出する一連のバイト。
下の図に示すように、ファイルには複数のバイトが含まれているため、10 バイトをキャッシュに入れて送信を待ちます。
送信が開始されると、最初に 3 バイトが TCP セグメントを形成するために取得され、次に TCP ヘッダーがこのセグメントに追加されて完全なセグメントを形成し、送信のためにリンク上に配置されます。このため、転送されるバイト数は状況に応じて異なります。特定の状況について:
したがって、TCP プロトコルはバイト指向、つまりバイト ストリームです。
3.1.2. TCPセグメントヘッダーフォーマット
TCP セグメント ヘッダーの全体的な説明:
- TCP メッセージ セグメントは、TCP ヘッダーと TCP データ部分で構成されます。
- TCP ヘッダーのデータ ビット数は 4B の整数倍である必要があり、このとき、TCP ヘッダーは何らかのデータ (通常はすべて 0) で埋められる必要があります。
- ヘッダーには固定の 20B が含まれており、他のオプションとパディング フィールドは個別に計算されます。
以下は、TCP ヘッダーの 11 フィールドの詳細な説明です。
①～② 源端口、目的端口：それぞれ2B、つまり16ビットを占有します。
③ 序号位: 4B を占有し、TCP 接続で送信されるバイト ストリームの各バイトには順番に番号が付けられ、このセグメントで送信されるデータの最初のバイトのシーケンス番号を示します。
- 例 1 では、1、2、および 3 バイトが連続して送信され、TCP ヘッダーのシーケンス番号は 1 (送信される最初のバイト)、つまり最初のバイトであることがわかります。
- 例 2 では、4、5、6 バイトが連続して送信されることがわかります。そのため、TCP ヘッダーのシーケンス番号も 4 (送信される最初のバイト) となり、4 番目のバイトを表します。
④ 确认号: 相手の次のメッセージセグメントの最初のデータバイトのシーケンス番号を受信することを期待します。確認番号がNであれば、シーケンス番号N-1までのデータが全て正しく受信されたことを証明する。
- この確認番号はターゲット ホストを通じて送信されます。最初のメッセージで送信されたバイト数 1、2、および 3 が到着すると、ターゲットは確認メッセージ セグメントを返します。このとき、確認メッセージ セグメントのヘッダーには確認番号 = 4 が含まれています。これは、問題は次のとおりです。バイト 1、2、および 3 が受信されたことがわかり、今度はバイト 4 を受信したいと考えています。
⑤ 数据偏移（首部长度）：TCPセグメント内のデータの開始位置Jは、TCPセグメントの先頭からどれだけ離れているかを4Bビット単位、つまり1つの値が4Bとなります。
TCP セグメント長とは、次の図を指します。
単位が4Bなので、データオフセットを1111とすると、16×4B=64Bとなり、現在のTCPヘッダーは64バイト、20B固定、オプション+パディングは44Bとなります。
⑥6制御ビット：
紧急位URG: URG = 1 の場合、このメッセージ セグメントに緊急データがあることを示します。これは優先度の高いデータであり、キャッシュにキューイングせずにできるだけ早く送信する必要があります。緊急ポインタ フィールドと組み合わせて使用されます。(以下のように、送信するメッセージがキャッシュ内で複数のセグメントに分割されている場合、途中の 4 番目のセグメントのメッセージには URG=1 が含まれており、これはデータをできるだけ早く送信する必要があることを意味し、この時点で順番を待たずに前の方へ移動できます。）确认位ACK: ACK = 1 の場合、確認番号は有効です。接続が確立された後、送信されるすべてのメッセージ セグメントの ACK が 1 に設定されている必要があります。推送位PSH: PSH = 1 の場合、受信側はアプリケーション プロセスをできるだけ早く配信し、キャッシュがいっぱいになるまで待たずに上向きに配信します。(受信側で行う緊急処理のこと。下図のように、キャッシュ領域の2番目のセグメントがPSH=1の場合、メッセージセグメントの優先度が与えられ、すぐにアプリケーションに配信されます)レイヤーのプロセス)复位RST: RST = 1 の場合、TCP 接続で重大なエラーが発生したため、接続を解放してから伝送リンクを再確立する必要があることを示します。同步位YSN: SYN = 1 の場合、接続要求/リンク受諾メッセージを示します。(下の図に示すように、送信者が SYN = 1 を送信すると、受信側も SYN = 1 を返します)。终止位FIN: FIN = 1 の場合、このセグメントの送信データが送信され、接続を解放する必要があることを示します。
プッシュビットとリセットの試験について簡単に理解しましょう。
⑦ 窗口字段: このセグメントを送信する相手の受信ウィンドウ、つまり相手が現在送信できるデータ量を指します。
- 例 1: このとき、受信側が送信したメッセージ セグメント ヘッダーのウィンドウ ビットは 65536 です。この時点で送信側 A がこれを受信すると、自身の送信バッファのウィンドウ サイズを65536 に 設定します。
- 例 2: このとき、受信側 B が送信したメッセージセグメントの確認番号は 701、ウィンドウフィールドは 1000 です。このとき、送信側は自身の送信バッファを 1000 に設定し、自身の 701 ～ 1700 を送信します。バイトを受信側に送信します。スクエア B.
⑧ 校验和: ヘッダー + データをチェックし、チェック時に 12B 疑似ヘッダーを追加し、4 番目のフィールド (プロトコル フィールドに相当) は 6 です。
⑨ 紧急指针: URG = 1 の場合にのみ意味があり、このセグメント内の緊急データのバイト数を示します。
- 例：緊急ポインタが 50 の場合、TCP データ部分の 1 バイト目から 50 バイト目までが緊急データであることを意味します。
10 选项: 最大セグメント長 MSS、ウィンドウ拡張、タイムスタンプ、選択確認...
11 填充字段: オプション フィールドが 4B の整数倍でない場合は、4B の整数倍になるように入力する必要があります。
3.2. TCP 接続管理
3.2.1. TCP 接続送信の 3 段階
TCP 接続の送信には 3 つの段階があります。
TCP 接続はクライアント/サーバー方式で確立され、能動的に接続の確立を開始するアプリケーション プロセスをクライアントと呼び、受動的に接続の確立を待つアプリケーション プロセスをサーバーと呼びます。
接続時のスリーウェイ ハンドシェイク:
3.2.2. TCPコネクション確立処理
3.2.2.1. 接続時のスリーウェイハンドシェイクの詳細説明
ROUND1 : クライアントは、アプリケーション層データなしで接続要求セグメントを送信します。
SYN = 1，seq = x（随机）
- SYN = 1: 接続要求時に 1 になります。
- seq = x (ランダム): シーケンス番号ビットこのシーケンス番号はランダムに生成され、最初は任意の乱数から始めることができます。
- クライアントがサーバーから十分なメッセージ セグメントを受信していないため、ここでは確認番号が無効です。そのため、クライアントは次にサーバーからどのシーケンス番号のメッセージ セグメントを期待するのかがわかりません。この時点では、番号が無意味であることを確認します。
SYN が 1 に設定される状況は 2 つだけあり、1 つは接続要求であり、もう 1 つは接続要求の確認です。
ROUND2 : サーバーはTCP 接続にキャッシュと変数を割り当て、確認メッセージ セグメントをクライアントに返し、アプリケーション層データなしで接続を許可します。
SYN=1，ACK=1，seq=y(随机)，ack=x+1
- SYN=1: 接続要求の受け付けは 1 のままです。
- ACK=1: ACK=1 の場合、この時点では小文字の ack も有効であり、これら 2 つを一緒に使用する必要があります。
- ack=x+1: このとき、確認番号には、相手が送信すると予想されるメッセージセグメントの最初のバイトを入れる必要があります。前回クライアントが要求したシーケンス番号はセグメントが x であることを示しているため、今回サーバーが受信したい次のバイトは x+1 から始まるはずです。
- seq=y (ランダム): このとき、確認メッセージセグメントにもシーケンス番号バイトがあり、このシーケンス番号自体もホスト自体によってランダムに割り当てられます。
ROUND3 : クライアントがサーバーから確認を受信した後、接続が確立されたことをサーバーに伝えるための確認を返す必要があり、その後データを送信できます。最初の 2 つのメッセージ セグメントと異なるのは、この 3 番目のメッセージがセグメント メッセージセグメントにはデータを乗せることができ、その際に正式に送信するデータをメッセージセグメントに入れることができます。
- クライアントはTCP 接続にキャッシュと変数を割り当て、確認された確認をサーバーに返します。サーバーはデータを送信できます。
SYN=0，ACK=1，seq=x+1，ack=y+1
- SYN=0: 現在接続要求または接続要求の確認はなく、この時点では 0 です。それ以降に送信されるデータ SYN はすべて 0 です。
- ACK = 1: ACK=1 の場合、この時点では小文字の ACK も有効であり、これら 2 つを一緒に使用する必要があります。
- seq = x + 1: 送信するセグメントの最初のバイトは x+1 です。
- ack = y + 1: 前のシーケンスは y を受信することを望んでいたため、この時点で予期される次のシーケンス番号は y+1 です。
3.2.2.2. スリーウェイ ハンドシェイクで考えられる問題: フラッディング攻撃
2 番目と 3 番目のステップでは、サーバーとクライアントの両方が TCP 接続プロセスにキャッシュと変数を割り当てるため、問題が発生し洪泛攻击ます。
理由: スリーウェイ ハンドシェイクによるハッカー攻撃の問題。
攻撃の説明: SYN フラッディング攻撃は、OSI の第 4 層で発生し、TCP プロトコルの特性である 3 ウェイ ハンドシェイクを利用します。攻撃者は TCP SYN を送信します。SYN は TCP スリーウェイ ハンドシェイクの最初のパケットです。サーバーが ACK を返すと、攻撃者はそれを再確認しません。その後、TCP 接続は一時停止状態になります。半分の接続状態。サーバーが再確認を受信できない場合、攻撃者に繰り返し ACK を送信することになり、より多くのサーバー リソースが浪費されます。
- 現時点では、攻撃者は上記の繰り返しの状況を利用して、非常に多数の TCP 接続をサーバーに送信し続けます。この時点では、それぞれが 3 ウェイ ハンドシェイクを完了できないため、サーバー上でこれらの TCP 接続が送信されます。この状態では CPU とメモリが消費され、最終的にはサーバーがクラッシュし、通常のユーザーにサービスを提供できなくなる可能性があります。
syn フラッディング攻撃の解決策: セットアップしますsyn cookie。
3.2.3. TCPコネクション解放処理(4ウェーブ)
接続を閉じるときに 4 回手を振ります。
TCP 接続に参加している 2 つのプロセスのどちらかが接続を終了することができ、接続が完了すると、ホスト内の「リソース」(キャッシュと変数) が解放されます。
ROUND1 : クライアントは接続解放セグメントを送信し、データの送信を停止し、TCP 接続をアクティブに閉じます。
FIN = 1，seq = u
- FIN = 1: 接続が解放されると、FIN 終了ビットを 1 に設定する必要があります。
- seq = u: は、そのようなメッセージ セグメントの最初のバイトのシーケンス番号を指します。このメッセージ セグメントには通常データが含まれていないため、シーケンス番号でこのようなメッセージ セグメントを表すことができます。
ROUND2 : サーバーは確認メッセージセグメントを返信し、クライアントからサーバーへのこの方向の接続が解放されます。（この時は半閉状態です）
ACK = 1，seq = v，ack = u+1
- ACK = 1: この時点では ACK が有効です。
- seq = v: 以前に送信された場所によって異なります。たとえば、このサーバーによって以前に送信された最後のメッセージ セグメント、最後のバイトは v - 1、この時点では seq は 1 としてマークされます。
- ack = u + 1: 前のメッセージセグメント、前のメッセージ seq = u の確認を示します。
ホストがこのような確認メッセージ セグメントを受信した場合、ホストは通話を終了しているため、応答する必要はありません。サーバーから通話が終了したことが通知されるのを待つだけでよく、その後、ホスト間の接続が正式に確立されます。閉まっている。
注: 残りのデータもこのプロセス中に送信されます。
ROUND3 : サーバーはデータを送信した後、接続解放セグメントを送信し、TCP 接続をアクティブに閉じます。
FIN = 1，ACK = 1，seq = w，ack = u + 1
- FIN = 1: 接続の終了が要求されている限り、FIN = 1 を開始する必要があります。
- ack = u + 1: このリクエストは、接続が閉じられたサーバー フェーズ 2 の直後に送信されたため、中間クライアントは別のリクエストを送信しませんでした。この時点では、ack 応答フィールドはまだ u+1 であり、これは同じですROUND2と同様に表示を確認します。
- seq = v: 実際の状況は、2 番目のステップ以降の応答確認後にサーバーが送信するデータ量にも依存します。
ROUND4 : クライアントは確認セグメントを返信し、待機タイマーが 2MSL (最長セグメント寿命) に設定されるまで待機し、この時点で接続は完全に閉じられます。
- 2MSL は、最長のメッセージ セグメントの存続期間を指します。確認メッセージセグメントがサーバーに到達しない場合、サーバーは、この時点で接続終了要求を受信していない場合は接続終了要求を再送信します。接続終了要求が 2MSL 以内に受信された場合は、確認を再開します。
ACK=1，seq = u + 1，ack = w + 1
3.3. TCP の信頼性の高い送信
信頼性の高い送信を実現する 4 つの TCP メカニズム
方法 1: 検証
プロセス: UDP 検証と同じ、擬似ヘッダーを追加します。
- UDPプロトコルの検証方法は、送信側と受信側にヘッダを付加し、2進補数和計算方式でエラーが発生したかどうかを判定する方法と同じです。
方法 2: シリアル番号メカニズム
UDP と同様に、最終的に送信されるメッセージ セグメントは以下の TCP キャッシュ内の数バイトである可能性があり、シーケンス番号は TCP キャッシュ全体における各セグメントの最初のバイトの位置を示します。
方法 3: 確認メカニズム (シリアル番号メカニズムに基づく)
以下では、TCP キャッシュ内のメッセージの最初のセグメントがサーバーに送信されるときに、最初のセグメントが TCP キャッシュから削除されないことがわかります。
その理由は、サーバーからの確認を待ってから削除するためです。確認メッセージが受信されない場合、メッセージが失われる可能性があります。したがって、送信者は、受信者がメッセージ全体を正しく完全に受信したことをどのようにして知るのでしょうか?私たちの確認メカニズムでは、受信者がこのメッセージ セグメントを受信した後、確認メッセージ セグメントを返します。
サーバーが確認メッセージを返すとき、確認番号フィールドは 4 であることがわかります。これは、4 より前のデータが受信されたことを意味します。この時点で、送信者は TCP キャッシュの最初のセグメントを削除できます。
次に、セグメント 1、2、および 3 がある場合、中央の 2 番目のセグメントはまだ遅延しており (失われた可能性があります)、セグメント 1 と 3 は受信されています。このとき、TCP はデフォルトで累積確認を使用します。今回は、確認番号フィールドは 4 のままです。つまり、サーバーはクライアントに、4 バイト目から始まるメッセージを受信することを伝えます。
- 順次受信するとのことですが、この場合は真ん中の2セグメントが到着しておらず、3セグメントも受信できます。
このとき、クライアントはメッセージの 2 番目のセグメント、つまり 4、5、および 6 を送信します。2 番目のセグメント レポートがサーバーに送信されると、サーバーはセグメント 1、2、および 3 を受信します。次回 送信確認セグメントの確認番号フィールドは 9 です。
サーバーに正常に到着するか、または順番どおりに到着しない状況の説明:
- メッセージ セグメントは完全に順番に到着します。この時点で、受信者はこの確認を返し、次に送信するメッセージのセグメントを送信者に指示します (順序は最後のメッセージ セグメントの終わりの最後のビットに達します)。
- メッセージ セグメントが順番に到着しない場合、受信者は確認メッセージ セグメントを返します。このとき、このメッセージ セグメントは、送信者がどのメッセージを再送信する必要があるかを示すことができます (途中で到着していない最初のメッセージ セグメント) 。
方法 4: 再送信 (RTTS 加重平均往復時間、高速再送信メカニズム)
確認応答と再送のメカニズムは分離されておらず、TCP 送信側が指定された時間(再送時間) 内に確認応答を受信しない場合、送信されたメッセージ セグメントが再送されます。【タイムアウト再送】
質問1: 再送信はいつ行われますか?
- 送信者が一定の時間を超えて受信者からの確認を受け取らなかった場合、送信者は自分が送信したセグメントが失われるはずであることを知っており、この時点でセグメントをキャッシュから削除し、再送信する必要があります。 。
質問 2: 再送信時間はどのように計算しますか?
- TCPの下位層はインターネット環境であるため、送信されるパケットは高速道路のLANを経由する場合もあれば、低速ネットワークを経由する場合もあり、各IPデータグラムが選択する経路もその時々によって異なります。送信者によって送信される多くのメッセージ セグメントが異なるパスを通過するため、固定時間を設定することはできません。
- 原則: TCP は適応アルゴリズムを使用して再送信時間を動的に変更します。その後、この再送信時間は と呼ばれます。
RTTs（加权平均往返时间）つまり、最初のメッセージ セグメントを送信するときに、RTT は取得された最初のメッセージを指します。RTT (確認は、メッセージが送信された時点からわかります)最初のメッセージが送信される）、次に 2 番目の RTT が送信されるときにも RTT が発生し、最初と 2 番目の RTT に基づいて、現在のヘビーパス時間として RTT を計算できます。今後、RTT の N 番目のセグメントを送信するときに、加重平均ラウンドトリップ時間が設定され、式によって計算されます。
質問 3: タイムアウト再送信の場合、タイムアウト期間に達していない場合は待ち続けますが、タイムアウト イベントが発生する前に、送信者がセグメントを失ったかどうかをできるだけ早く知る方法はありますか。再送信？
解決策: 冗余ACK（冗余确认）、確認メカニズムに関連します。
プロセス: 予想されるシーケンス番号よりも大きいタイミング メッセージ セグメントが到着するたびに、次の予想されるバイトのシーケンス番号を示すために冗長 ACK が送信されます。
次の状況では、セグメント 1 の後に 2 が受信されないため、順序をテストできます。このとき、3、4、5 が連続して来ています。このとき、サーバーはそれらを受信します。メッセージ セグメントが受信されると、確認番号については、セグメント1の後、セグメント2が到着していないため、確認メッセージセグメントの確認番号は常に2となっていることがわかります。真ん中の 2 つのセグメントなので、冗長性の確認です。受信側は、同じシーケンス番号のセグメントを 3 つ（シーケンス番号 1 を基準にしてシーケンス番号 2 以降の連続する 3 つのセグメント）受信すると、送信したセグメント番号 2 が失われたと判断し、再送します（このとき初期のセグメントは 2 番目）。再送信効果が得られます）
-
**なぜ順番どおりに到着しないのですか? **TCP では、受信側はメッセージ セグメントを送信するための確認メカニズムを受け取らず、複数のメッセージ セグメントを連続して送信できます。
このテクノロジーは、高速再送信テクノロジーにもなります。
3.4. TCP フロー制御
3.4.1. TCP フロー制御とスライディング ウィンドウ プロセスの理由
理由: データを送信するとき、通常、データ送信速度が速くなることを望みますが、送信速度が速すぎると、受信側がデータを受信する時間がなくなり、深刻なパケット損失が発生する可能性があります。送信者の送信速度を制御するには、フロー制御が必要になります。
フロー制御:受信者が受信する時間を確保できるように、送信者の速度を下げます。
TCP は滑动窗口机制フロー制御の実装に使用されます。
スライディングウィンドウプロセス：通信プロセス中に、受信者は送信者の送信ウィンドウサイズ、つまり受信ウィンドウrwnd（受信者はメッセージセグメントのウィンドウフィールドを確認して送信者にrwndを通知します）のサイズに基づいて動的に調整します。送信側の送信ウィンドウは、受信ウィンドウ rwnd と輻輳ウィンドウ cwnd の最小値をとります。
- リソースの輻輳: ネットワークがブロックされています。これは、その時点でネットワークがネットワーク リソースを使用していて、ネットワーク リソースを持つホストが多すぎるため、ネットワーク全体で送信の遅さや転送の遅さ、キュー時間などの問題が発生したことを意味します。
- 送信側の送信ウィンドウは、受信ウィンドウと輻輳ウィンドウの最小値によって決まります。[送信ウィンドウ = 最小{受信ウィンドウ、輻輳ウィンドウ}]
送信者のウィンドウは動的に変更できます。これは受信者から返されるメッセージ セグメント (確認メッセージまたはデータ メッセージである可能性があります) によって異なります。ウィンドウ フィールドが大きい場合、送信者はより多くのメッセージを送信できることを意味します。データの場合、ウィンドウ フィールドが比較的小さい場合、送信者はより少ないデータを送信します。
- 下図に示すように、送信ウィンドウを6に設定した確認メッセージを1つずつ受信して返信します。このとき、送信者は6つのウィンドウに分割して一度に送信します。
3.4.2. TCPフロー制御の詳細な処理
A は B にデータを送信します。接続が確立されると、B は A に「My rwnd = 400 (バイト)」を伝えます。各メッセージ セグメントが 100B であり、メッセージ セグメントのシーケンス番号の初期値が 1 であると仮定します。
プロセスの詳細な説明:
1. まず、A は B に接続の確立を要求し、B はフィールド rwnd = 400 (バイト) を設定した確認メッセージ セグメントを返します。
2. ホスト A は確認メッセージ セグメントを受信し、rwnd = 400 を読み取ります。このとき、ホスト A は 400 バイトを自身の送信バッファ ウィンドウに分割します (メッセージ セグメントが 100B であるため、正確に 4 セグメントになります)。
次に、ウィンドウのサイズに応じて 4 つのメッセージ セグメントが連続して送信され、各セグメントは 100 バイトです。図によると、最初の 2 つのメッセージ セグメントはホスト B によって正常に受信されましたが、3 番目のセグメントは失われていることがわかります。
3. このとき、ホスト B は確認メッセージ セグメントを送信します。これは、201 バイトから始まるメッセージ セグメントを受信することを示し、また、この時点で受信できる現在のウィンドウが 300 バイトであることを示します。
ホスト A の送信ウィンドウは、受信側で受信されていない 201 バイトから始まり、500 バイトまでです。
4. このとき、送信側の送信ウィンドウは 300 バイトであり、201 ～ 300 バイトのメッセージセグメントはまだ確認メッセージを受信していないため、この時点では送信ウィンドウ内に残ります。次に、ホスト A がデータを送信します。 301 から始まる 3 段落目と 4 段落目の 2 つのグリッドのデータを送信できますが、この時点では送信できず、ウィンドウは最大 500 バイトまでしか開くことができません。
5. この時点では、ウィンドウの 201 ～ 300 バイトのメッセージ セグメントは停滞状態にあり、受信者からの確認を待っています。201 ～ 300 バイトのメッセージ セグメントのタイムアウトが経過した後、再送信が実行されます。
6. ホスト B は正常に受信できます。このとき、ホスト B は応答メッセージを送信します。応答メッセージは、ホスト B が受信したいメッセージ セグメントが 501 から始まり、送信ウィンドウ サイズが 100 に制限できることを示します。
7. ホスト A は 501 バイトから始まるセグメントの送信を開始しますが、ウィンドウ サイズが 100 バイトしかないため、このセグメントを送信した後は送信を続けることができません。
8. このとき、受信側ホスト B は、601 バイトから開始したいこと、送信ウィンドウ サイズが 0 であることを示す確認メッセージ セグメントを返します。
ウィンドウが 0 に設定されているため、送信者は現時点ではデータを送信できません。
追加の質問 1: ホスト A がホスト B がゼロ以外のウィンドウ通知を送信するのを待っていて、ホスト B が新しいセグメント (許可されているウィンドウ サイズは 400) を送信し、送信中に失われた場合、次の時点で何も対策がなければ、今度は、ホスト A とホスト B が常にお互いを待機することになります。このお互いを待機する状況はデッドロックに似ています。では、どうすれば解決できますか?
解決策: TCP は接続ごとに継続タイマーを設定し、TCP 接続の一方が他方からゼロ ウィンドウ通知を受信している限り、この継続タイマーが開始されます。タイマーが期限切れになると、ホスト A は検出メッセージ セグメントを送信し、ホスト B は通知メッセージを再送信します。
- 再送信された通知メッセージのウィンドウがまだ 0 である場合、ホスト A は継続タイマーをリセットします。このとき、タイマーが期限切れになる前にまだ通知確認メッセージがない場合、ホスト A は別の検出メッセージを送信します。セグメント、letホスト B がそれを再度再送信します。
3.5. TCP 輻輳制御
3.5.2. 輻輳制御とフロー制御との違いを理解する
輻輳制御とは何ですか?
- ネットワークの状態が悪く、ネットワークがブロックされているため、データの送受信速度が全体的に遅くなります。
混雑の条件: リソース需要の合計 > 利用可能なリソース
- リソースとは、ネットワーク内の一部のリンク容量 (帯域幅、リンク内の 50M 帯域幅など) を指します。多くの人がこのリンクでデータを送信し、その結果、これらの人にとってこのリンクの帯域幅が不十分になり、この時点で輻輳が発生します。同時に、スイッチング ノードのキャッシュと、ルータのプロセッサなどのスイッチング ノードのプロセッサはすべてリソースです。
ネットワーク内の特定のリソースに対する総需要が、一定期間内にそのリソースの利用可能な部分を超えると、ネットワークのパフォーマンスは当然変化します。このとき、多くのリソースが同時に不足し、次のような状況が発生します。
- ネットワーク内には同時にプロビジョニングが不足しているリソースが多数存在します -> ネットワーク パフォーマンスが低下します -> 入力負荷が増加すると、ネットワーク スループットが低下します。
輻輳制御機能：ネットワークへの過剰なデータ注入を防止します。
- このネットワーク リソースを使用してすべてのホスト間の連携を調整することで、ネットワークへの過剰なデータの注入を防ぎ、ネットワークの混雑を緩和できます。
輻輳制御とフロー制御の違い:
拥塞控制: 下図の上部が受信側、図の下側が送信側の場合、両者はこのネットワーク上のリソースを同時に使用し、同じスイッチングを行うため、両方とも受信側にデータを送信する必要があります。ノードの場合、このルーターがこのネットワークを作成します 非常にビジーであり、輻輳状態が発生する可能性もあります。受信側では、どのホストがこの輻輳状態を引き起こしているのかわかりません。送信速度が速すぎます。
流量控制：これはポイントツーポイント間のトラフィック制御の一種で、エンドツーエンドの問題で、受信側が受信したデータが遅すぎて受信できない場合、送信側が受信すべきまでになってしまいます。
概要: フロー制御はポイントツーポイントの問題です。送信側の速度が速すぎるため、受信側のバッファリングが不十分になります。輻輳制御は、主にネットワークがブロックされているため、世界的な問題です。
3.5.3. 輻輳制御のための 4 つのアルゴリズム
3.5.3.1. 輻輳制御の 4 つのアルゴリズムを理解する
4 つのアルゴリズム: スロー スタート、輻輳回避、高速再送信、高速リカバリ。
上記の 4 つは、ある状況で互いに組み合わせて使用されます。1 つは で慢开始+拥塞避免、もう 1 つの組み合わせは です快重传+快恢复。
上記のアルゴリズムを学ぶ前に、いくつかの仮定を立ててください。
1. データは一方向に送信され、反対方向には確認応答セグメントのみが送信されます (ピギーバック確認のために有効でないデータは送信されます)。
- 実際には、便乗確認も比較的一般的です。
2. 受信側には常に十分なバッファ スペースがあるため、送信ウィンドウのサイズは輻輳の程度によって異なります。
发送窗口 = Min(接受窗口rwnd，拥塞窗口cwnd)
- 受信ウィンドウ: 受信者は受け入れキャッシュに従って値を設定し、受信者の能力を反映するように相手に通知します。
- 輻輳ウィンドウ: ネットワークの現在の容量を反映する、ネットワーク輻輳の独自の推定に基づいて送信者によって設定されるウィンドウ値。
3.5.3.2. 組み合わせ 1: スロースタートと混雑回避
輻輳ウィンドウと送信ラウンドの意味を理解する
- 大学院入学試験では、アルゴリズム Ade の適用プロセスを理解する必要があり、4 つのアルゴリズムの具体的な詳細を調べる必要はありません。
縦軸は拥塞窗口cwndメッセージセグメントを表す初期値の1であり、メッセージセグメントの最大長MSS（このとき図中の4は4MSSを指し、8は8MSSを指す）を表す。増加すると、輻輳ウィンドウが変化します。
横軸は传输轮次送信ラウンドを単位として表し、メッセージセグメントのバッチを送信してその確認を受信するのにかかる時間を表します。
- 送信ラウンド: メッセージ セグメントのバッチが送信され、その確認応答が受信される時間、往復遅延 RTT。輻輳ウィンドウ内でメッセージ セグメントのバッチの送信を開始してから、輻輳ウィンドウ内でメッセージ セグメントの次のバッチの送信を開始するまでの時間。
送信ラウンドの理解:
以下のようになります。 ホスト A がホスト B にメッセージ セグメントを送信します。このとき、ホスト B はホスト A にメッセージ セグメントで応答します。これが 1 ラウンドとしてカウントされます。
ネットワークの状態が非常に良好であるため、この時点でさらにいくつかのメッセージ セグメント m2 と m3 が送信されます。このとき、ホスト B は 2 つのメッセージ セグメントを受信した後、2 つの確認を順番に返します。この場合、M3 が確認するまで、このセクションは送信第 2 ラウンドです。
このとき、送信ウィンドウは再び増加します。このときウィンドウは 4 です。この時点で 4 つのメッセージ セグメントを連続して送信できます。4 番目のメッセージ セグメントを連続して受信すると、それが 3 回目の送信とみなされます。 :
スロースタートと混雑回避の詳細なプロセス
スロースタートとは、指数関数的な成長、つまり爆発的な成長のプロセスを指します。
- 速度が遅くなる主な理由は、最初に 1 つのメッセージだけが挿入されるためであり、多くのメッセージ セグメントを最初に挿入する場合にははるかに遅くなります。
プロセス: まず、このネットワーク上でプローブを実行して、このネットワークの輻輳状況を確認します。状態が良い場合は、輻輳ウィンドウの送信側を増やし、輻輳ウィンドウを増やします。この倍数は 2 倍で、4 段階に分かれています。
①最初に**【スロースタート】を行い、1回目の送信は1MSS、2回目の送信は2MSS、3回目の送信は4MSS、4回目の送信は16MSSとなります。 、ssthresh 16 の初期値に達していることがわかります。これは、スロー スタートしきい値 ** を指します。
②この時、低速から**[輻輳回避]**まで開始しますが、これは現在注入されているメッセージセグメントが多く、すぐに輻輳が発生することが心配になるため、速度を少し落とします。このとき、前回の輻輳ウィンドウをもとに輻輳ウィンドウが1つずつ追加され、5ラウンドから12ラウンドまで毎回+1され、この時点で24MSSに達していることがわかります。
- スロー スタートしきい値: スロー スタートしきい値の初期値に達すると、速度がわずかに低下し、スロー スタートが渋滞回避に入ります。
- 渋滞回避プロセス: これは直線的な成長プロセスであり、スロー スタートのしきい値に基づいて毎回 +1 されます。
③ 24MSS に達すると、ネットワークが混雑してパケットロスが発生するため、**[スロースタート状態]** に戻り、輻輳ウィンドウが 1 に戻り、セグメント数が減少します。一瞬で24から24に増えますが、メッセージセグメントは1つに減り、以降の処理はスロースタート、1、2、4、8と実行し続け、17ラウンド目で閾値に注意してください。この時点で 12 に変更されます。
- **新しいしきい値はどのように決定されますか? **現在のネットワーク輻輳の状況に応じて、ネットワーク輻輳が発生すると、輻輳ウィンドウ/2はすぐに減少します。前回のネットワーク輻輳の輻輳ウィンドウは24であったため、この時点では24/2 = 12となり、今回は現在のしきい値は 12 です。
④**[輻輳回避]**状態に入っても、毎回+1ずつ直線的に増加し、以降の処理は同様ですが、ネットワーク輻輳が発生すると、新たな閾値が設定され、低速スタートに戻ります。
3.5.3.3. 組み合わせ 2: 高速再送信と高速リカバリ
高速再送信の登場の主な理由は、待機タイムアウトが長すぎる問題を解決するためであり、メカニズムのプロセスは次のとおりです。
- このとき、M1、2、3、4、5 の 5 つのメッセージセグメントが連続して送信され、M1 が B に送信されると、2 番目のメッセージを受信することを示す ack=2 の確認番号が返されます。 、メッセージ 2 が失われ、その後 B が M3、4、および 5 の確認メッセージ セグメント (ack=2) を受信すると、ack=2 の確認メッセージ セグメントは合計 4 つになります。最後の 3 つに基づいて同じです。 ack=2 を冗長 ack と呼び、このときホスト A は M2 メッセージを再送します。
**高速リカバリはどのように反映されますか? **下図を見るとわかるように、輻輳ウィンドウが12回で24の場合、3回の重複確認を受信した後に[高速再送信]が実行されるため、その後[高速回復状態]に移行します。輻輳ウィンドウを 1MSS に下げると、新しいしきい値まで下がりますが、この 12 しきい値の段階で [輻輳回避] を実行し、線形加算を行って増加させます。
- **閾値はどのように決定されますか? **重複確認が発生する場合ですので、この時の輻輳ウィンドウを24/2=12に設定し、迅速な復旧を行います。
**クイックリカバリとは何ですか? **これを 1 に下げる必要はありませんが、新しいしきい値 (高速再送信が発生する輻輳ウィンドウ/2) に直接下げてから、輻輳回避アルゴリズムを使用します。
図の TCP-Tahoe バージョンは廃止されました。このバージョンは、高速再送信が発生するときのものです。このとき、輻輳ウィンドウはスロー スタートの最初のフェーズ 1 に直接変更され、その後、対応する戦略が実行されます。
主催者：ロングロード日程：2023.8.7-8