目次
トランスポート層プロトコル
トランスポート
層は、送信者から受信者へのデータ転送を担当します。トランスポート層プロトコルには、主に TCP プロトコルと UDP プロトコルが含まれます。
TCPプロトコル
TCPプロトコルフォーマットセグメント
TCP プロトコル形式のセグメントは次のとおりです。
各部分の意味は次のとおりです。
送信元ポート番号 (16 ビット): 送信者のポート番号を識別します。
宛先ポート番号 (16 ビット): 受信者のポート番号を識別します。
シーケンス番号 (32 ビット): 送信されるデータの順序を識別するために使用されます。
確認番号（32ビット）：受信したデータを確認するために使用されます。
データオフセット (4 ビット): TCP パケットヘッダーの長さを示します。
予約済み (6 ビット): 将来の使用のために予約されています。
フラグビット(6ビット):
- URG : このメッセージを最初に送信し、順番に送信しなくなりました。
- ACK : 確認応答。
- PSH : バッファがいっぱいになるのを待たずに、すぐにメッセージをプッシュします。
- RST : 相手側が接続の再確立を要求します。RSTフラグが付いているメッセージをリセット メッセージと呼びます。
- SYN : 接続を確立するリクエスト。SYN 識別子を運ぶものを同期メッセージと呼びます。
- FIN : ローカルエンドが閉じられることを相手に通知するFIN フラグを付けたエンドメッセージを呼び出します
ウィンドウ サイズ (16 ビット): 受信機が受け入れられるデータの量を示します。
チェックサム (16 ビット): データ送信時のエラーを検出するために使用されます。
緊急ポインタ (16 ビット): URG フラグが設定されている場合にのみ有効で、緊急データの位置を示すために使用されます。
オプション (可変長): さまざまなオプション機能をサポートするために使用されます。
TCPの原則
TCPプロトコルの原理：データ伝送の安全性を確保することを前提として、可能な限り伝送効率を向上させます。
接続管理
TCP プロトコルは、接続を確立するために3 ウェイ ハンドシェイクを使用し、切断するために4 つのウェーブ ハンドシェイクを使用します。
スリーウェイ ハンドシェイク: 送信者が接続を要求 (SYN、つまり同期メッセージを送信) -> 受信者が要求を確認 (要求を受信した後、ACK を送信、つまり応答を確認) -> 受信者が接続を要求接続 (SYN を送信) -> 送信側がリクエストを確認 (リクエスト受信後に ACK を送信):
ここでは、間隔が非常に短いため、受信側の 2 つの命令がまとめて送信されます。したがって、受信側の ACK+SYN はハンドシェイクとしてカウントされます。
手を 4 回振ります。上図の SYN を FIN (終了メッセージ) に置き換えます。ただし、受信機の ACK 命令と FIN 命令は一般に組み合わせることができないため、4 波と呼ばれます。
SYN と FIN をマージできないのはなぜですか? 主な理由は、FIN コマンドを送信する前に、受信者は送信者がリソースを閉じる (つまり、閉じる) まで待機する必要があるためです。すぐに閉じると、FIN を ACK とマージできますが、閉じるには時間がかかる場合があります。実行中 (またはまったく実行しない。実行中) の場合、FIN は明らかに ACK と組み合わせることができず、個別に送信することしかできません。(FIN が ACK とマージされる理由は、 TCP の遅延応答メカニズムによるものです。TCP の ACK コマンドはすぐには実行されず、しばらくしてから実行されます。)
なぜ 3 ウェイ ハンドシェイクが必要なのでしょうか?
3 ウェイ ハンドシェイクは、送信側と受信側の送受信機能が正常であることを確認するために行われます。A と B が音声通話を行う場合、A が最初に「聞こえますか?」と話し、このとき A が言ったことを B が聞きます (つまり、B は A のマイクが正常であり、B のイヤホンが正常であることを知っています)。B は次のように応答します。 「聞こえますか？」が届きました。」、Bは言った：「それでは、私の言ったことは聞こえますか？」、Aは聞こえる（Aは、Aのマイクが正常であること、Bのマイクが正常であること、Aのイヤホンが正常であることを知っていることを示します） 、しかし、A は依然として「聞こえる」という応答を必要とします。(B は B のマイクが正常であることを知っています)。
確実な伝送
TCP プロトコルは、シーケンス番号と確認番号を使用して、データの順序正しい送信と失われたパケットの再送信を保証し、信頼性の高い送信を実現します。各送信には ACK確認応答が必要であり、データ送信の信頼性を確保するために、送信者は ACK を受信した後でのみデータが正常に送信されたことを確認できます。送信者が受信者の ACK を受信しない場合、送信者はデータ送信が失敗したと判断し、一度再送信します。これは TCP のタイムアウト再送信メカニズムによって異なります。最大待ち時間を超えた場合、送信者がまだ受信しない場合は、再送信します。 ACK を受信すると、データが再送信されます。
もちろん、送信者が ACK を受信しない原因となる 2 つの状況があります: 送信者が送信中にパケットを失った場合 (この場合、タイムアウトして再送信することしかできません)、受信者はデータを正常に受信しましたが、返された ACK が過去に送信されたことがある（この場合、再送信はタイムアウトしない）。
ただし、TCPには自動重複排除機能があるため、つまり送信されたデータは一度しか受信できないため、タイムアウト再送機構はどのような状況でACKが受信されなかったのかを考慮しなくなりました。
順序を保証するために、TCP はデータの各バイトにシーケンス番号を付けます。ACKは、受信したデータの最大のシーケンス番号を確認し、次に受信すると予想されるシーケンス番号を返すことで、データの順序を保証します。
フロー制御
信頼性の高い送信を保証するために、TCP は多くの効率を犠牲にする必要があります。しかし、TCPプロトコルの原理は、データ伝送の安全性を確保することを前提として、伝送効率を可能な限り向上させることです。質疑応答方式に従った場合、一度に 1000 バイトを送信する場合、1000 バイトが転送されるのを待ってから 1000 バイトを転送する必要があり、この種の送信効率は明らかに非常に低くなります
。効率を向上させるために、一度に複数のデータを送信する方法を使用できます。
これにより待ち時間を効果的に短縮できますが、同時に送信されるデータの数はいくつでしょうか? TCPプロトコルヘッダにはスライディングウィンドウと呼ばれる16ビットフィールドのウィンドウサイズがあり、このウィンドウのサイズが実際には受信データバッファの残りサイズとなります。スライディング ウィンドウのサイズは、毎回転送されるデータの最大量です。スライディング ウィンドウがいっぱいになったら、ACK を送信し、バッファ内のこのデータを削除すると、バッファにスペースが残り、送信者はデータの送信を続けることができます。
受信側がデータを処理できる速度には制限があります。送信側の送信速度が速すぎると受信側のバッファがいっぱいになり、このまま送信側が送信を続けるとパケットロスが発生します。したがって、送信側がデータを送信する速度は、スライディング ウィンドウのサイズに応じて動的に調整されます (フロー制御)。
受信側は現在のバッファ サイズを TCP ヘッダーのウィンドウ サイズに入れ、ACK を通じて送信側にウィンドウ サイズを通知します。送信側はウィンドウが小さいと判断すると、送信速度を低下させます。逆に、送信速度が向上します。バッファがいっぱいの場合、返されるウィンドウ サイズは 0 です。このとき、送信側は送信を停止しますが、定期的にウィンドウ検出データ セグメントを送信するため、受信側はバッファ サイズを通知し、バッファ サイズが満たされていない場合は送信を続行します。満杯。
もちろん、フロー制御を行ってもパケットロスを100%回避できるわけではありません。
パケットロスが発生した場合はどうすればよいですか?
データが送信されていない場合、つまり 1 ～ 1000 が送信されていない場合、1 ～ 1000 のデータが受信されて ACK が返されるまで、送信者は常に受信者から「次は 1001 です」というリマインダーを受け取ります。 。複数のリマインダーの後、送信者は 1 から 1000 までのデータを再送信します。その後パケットロスがなければ正常に受信され、1~1000のデータを再送受信すると、受信側は次に受信したデータに対するACKを返します(例: 1~1000 is Lost 、以下) -upデータは正常に送信されており、このデータを受信してから5000個受信しましたが、この時点でACKは「次は5001です」と返します。
ACK のみが失われた場合は、再送せずに後続の ACK で確認できます。
輻輳制御
データ送信の開始時には、スライディング ウィンドウを使用しても、現在のネットワークの混雑状況が分からず、現在のネットワークがすでに比較的混雑している可能性があるため、大量のデータを直接送信することはできません。このとき、大量のデータが無謀に転送されるため、必然的に大量のパケットロス現象が発生します。したがって、TCP では、最初に少量のデータを送信し、現在のネットワーク状況を検出してから、徐々に送信速度を高めるスロー スタートメカニズムを導入しています。このとき、輻輳ウィンドウ
が導入されます。輻輳ウィンドウのサイズは、ネットワークの輻輳に応じて動的に変化します。その変更は、スロースタート、輻輳回避、高速再送信、高速リカバリといういくつかの段階に分かれています。
- スロー スタート: ホストがデータの送信を開始すると、最初にネットワークの輻輳を検出します。つまり、輻輳ウィンドウを徐々に増やします。通常、最初はウィンドウ サイズがメッセージ セグメントの最大 MSS (最大セグメント サイズ) 値にちょうど収まるように設定され、ACK が受信されるたびに、輻輳ウィンドウは最大 1 MSS サイズずつ増加します (各メッセージ セグメントは、確認応答があるため、ウィンドウ サイズは毎回 2 倍になります)。そのため、初期段階では、ウィンドウ サイズは指数関数的に増加します。
- 輻輳回避: 輻輳ウィンドウが特定のしきい値 (スロー スタートしきい値、ssthresh) に達すると、輻輳回避フェーズに入ります。この段階では、輻輳ウィンドウは直線的に増加します。つまり、ラウンドトリップごとに 1 MSS サイズだけ増加します。このようにして、ネットワーク輻輳の臨界値に可能な限り到達することができます。
- 高速再送信: 送信者は 3 回目の反復 ACK を受信すると、データグラムが失われたとみなし、タイムアウトを待たずにすぐに再送信します。高速再送信では、しきい値を現在の輻輳ウィンドウの半分に設定し、輻輳ウィンドウを 1 に設定して、スロー スタート フェーズに入ります。
- 高速リカバリ: 送信側が 3 回目の反復 ACK を受信すると、データグラムが失われたとみなして、この時点で高速リカバリ アルゴリズムを実行します。しきい値のサイズを調整し、現在の輻輳ウィンドウの半分に設定し、輻輳ウィンドウを新しいしきい値に 3 MSS を加えたサイズに設定し、データグラムを再送信し、ACK を受信した後、輻輳回避フェーズに再び入ります。
実際、パケット損失が発生すると、最初に高速再送信アルゴリズムが使用されてデータグラムが再送信され、次に高速回復アルゴリズムが使用されて輻輳ウィンドウのサイズが調整されます。
送信される各データグラムのサイズは、輻輳ウィンドウの最小値と、受信側からフィードバックされるウィンドウ サイズを超えることはできません。
遅延確認と便乗
スライディング ウィンドウをできるだけ大きくするために、ACK の確認応答には遅延応答が採用されています。バッファに 1k バイトを入れた場合、すぐに ACK を返すと 1k バイトのスペースが無駄になりますが、しばらく待つとこの 1k バイトが処理され、返されるウィンドウ サイズが大きくなるだけです。遅延応答メカニズムに基づいて、上記の切断のような 4 つの手を振る場合は 3 つの手を振る場合があります。(ACKは応答が遅れ、その間にcloseが実行されるため、FINはACKで応答、つまり便乗応答することができます)
エラー検出
TCP プロトコルは、チェックサムを使用してデータグラムの送信時のエラーを検出します。データグラムを送信する前に、送信者はまずデータグラムのチェックサムを計算し、メッセージのチェックサム フィールドに格納します。データを受信した後、受信者はチェックサムを再計算し、TCP メッセージ内のチェックサムと比較します。違います、送信が間違っています。
TCP例外
異常切断の場合、プロセスの終了とマシンの再起動は TCP 切断異常を引き起こさず、その後時間がなければ、最後に FIN が正常に送信されます (FIN はトランスポート層によって制御され、プロセスとは関係ありません)。 FIN 受信中 ACK はオフになります。このとき、受信側は FIN の再送を試みます。数回再送した後、接続を再充電し、それでも失敗する場合は切断します。
しかし、停電やネットワークの切断が発生した場合、送信者には FIN メッセージを送信する時間がないため、受信者は接続がまだ存在していると認識します。ただし、TCP にはハートビート パケット キープアライブ メカニズムがあり、ピアがまだ存在するかどうかを定期的に確認し、ピアが存在しない場合は接続が切断されます。
UDPプロトコル
UDP プロトコルは TCP よりもはるかに単純で、その主な利点は伝送速度の低下です。
UDPプロトコルフォーマットセグメント
UDPプロトコルの特徴
接続がありません
UDPプロトコルによる送信は接続する必要がなく、相手のIPとポート番号がわかれば送信できます。
信頼できない
UDP送信は相手が受信したかどうかを考慮しないため、一度に大量のデータを送信できます。もちろん、パケット損失の問題が発生した場合、UDP には対応する救済措置がありません。
データグラム指向
UDP の各送受信は、データグラムの形式で送受信する必要があります。このデータグラムに 100 バイトがある場合、読み取り時に一度に読み取れるのは 100 バイトだけであり、1 つずつまたは 10 バイトずつ読み取ることはできません。
サイズ制限あり
UDPで一度に送信できるデータの最大サイズは64kですが、送信データが64kを超える場合は、アプリケーション層で分割して組み立てる（64k未満に分割する）か、送信する形式で送信する方法が一般的です。次に、リンク層がパケット化とグループ化を実行します。
ネットワーク層プロトコル
ネットワーク層プロトコルは主に IP プロトコルであり、その機能はネットワーク伝送の経路を決定することです。
IPプロトコル
IP プロトコル フォーマット セクション:
version : IP のバージョン番号を識別するために使用されます。現在、IPV4 と IPV6 の 2 つのバージョンがあります。
ヘッダー長: IP プロトコルのヘッダー長を示すために使用されます。サイズは 4 バイトで、1 バイトで表現できる最大数は 1111 (つまり 15) であるため、ヘッダーの最大長は 60 バイトになります。最も一般的に使用されるヘッダーの長さは 20 バイトです。
サービスの種類: より良いサービスを得るために使用されます。3 ビットの優先フィールド (非推奨)、4 つの TOS ビット、および 0 で構成されます。4 ビット TOS はそれぞれ、最小遅延、最大スループット、最高の信頼性、最小コストを表します。これら4つは互いに矛盾しており、そのうちの1つだけを選択できます。
Type of Service フィールドは実際には使用されません。1988 年に、IETF はこのフィールドの名前をDifferentiated Servicesに変更し、再定義しました。最初の 6 ビットはDSCP (Differentiated Services Code Point)として定義され、最後の 2 ビットは予約されていました。したがって、このフィールドは現在、一般的に DS フィールドと呼ばれています。
データグラムの合計長: IP データグラム全体が占めるバイト数。
識別子: ホストによって送信されたメッセージを一意に識別します。送信するメッセージの長さがデータリンク層でサポートされる最大長を超える場合、つまり最大送信単位 (MTU) (イーサネットの場合は 1500 バイト) を超える場合、メッセージを次のように分割する必要があります。送信の場合、これらの分割された部分はすべて同じ識別子 (id) を持ち、これがメッセージであることを示します。
フラグ ビット: 最初のビットは後で使用するために予約されており、2 番目のビットはパケットのフラグメント化が許可されているかどうかを示します (1 は現時点では許可されていないことを意味し、パケット長が最大送信単位より大きい場合、パケットは破棄されます) ICMP エラーが送信者に返されます); 2 番目のビット 3 つのビットは、それが最後のフラグメントであるかどうかを示し、最後のフラグメントである場合は 1 になります。
切りくず変位：オフセットとも呼ばれます。IP フラグメンテーションの後、各部分の送信時間は同じではなく、最後の部分が最初になる可能性があるため、各フラグメントのオフセットは異なり、最終的にパケットはオフセットに従って再組み立てされます。(TCP の原理と同様)
生存時間: 宛先に到達するまでの最大ノード数 (TTL、通常 64) を示し、ノード (ルーター) が通過するたびに TTL-1、TTL が 0 の場合は宛先がまだ到着していないことを示します。ルーティングアドレッシングに問題があると考えられ（無限ループの可能性がある）、この時点でメッセージは破棄され、送信者に通知されます。
Protocol : 上位層プロトコルのタイプを示すために使用されます。
チェックサム: IP プロトコルのヘッダーをチェックして、転送が正常であるかどうかを判断します。
ソース IP : データグラムのソース IP を示す 32 ビット。
宛先 IP : 32 ビット、データグラムの宛先 IP を示します。
Option : オプションのフィールド。オプションのヘッダー形式を変更できます。ヘッダーの長さを変更する場合は、長さが 4 の倍数であることを確認する必要があります。
データリンク層プロトコル
データリンク層で最も一般的に使用されるプロトコルは、Etnernet イーサネット プロトコルです。
イーサネット
イーサネットは、物理層を含む一部のコンテンツを規定するコンピュータのローカル エリア ネットワーク技術であり、最も広く使用されているローカル エリア ネットワーク技術です。
イーサネット フレーム フォーマット:
送信元 MAC アドレスと宛先 MAC アドレスは、ネットワーク カードのハードウェア アドレスを表します (物理アドレスは工場でネットワーク カードに設定されており、変更できません)。開始点と宛先を表すために使用されます。各送信のエンドポイント。
フレーム プロトコル タイプフィールドには 3 つの値があり、それぞれ IP、ARP、RARP に対応し、
CRC : チェックサム、送信が正常かどうかを確認します。
人
MTU (Minimum Transmission Unit) は、最大伝送単位を意味します。データリンク層プロトコルが異なれば MTU も異なり、イーサネットの MTU は 1500 バイトです。
MTU の役割は、各データグラム送信のサイズを制限することであり、MTU は上位層プロトコルの送信に影響します。
ARPプロトコル
ARP プロトコルは、IP と mac の間のマッピング関係を確立します。各送信では、IP アドレスを使用して、ローカル ARP キャッシュ テーブル内の宛先 MAC アドレスを検索します。見つかった場合は、宛先 MAC アドレスに直接送信できます。見つからない場合は、宛先 MAC アドレスを見つけるためにブロードキャストします。 。