5. トランスポート層 (3) TCP

3.0 TCP 機能の補足

3.1 TCPセグメントヘッダー形式

3.2 TCP接続管理

3.4.1 受信ウィンドウ、輻輳ウィンドウ、送信ウィンドウの関係

3.4.2 スロースタートと混雑回避

3.4.3 高速再送信と高速リカバリ

3.0 TCP 機能の補足

TCP は 1 対 1 の全二重の信頼性の高い通信を提供し、通信の両側のアプリケーションプロセスがいつでもデータを送信できるようにします。このため、TCP 接続の両端には、一時的にデータを保存するための送信バッファと受信バッファが装備されています。双方向通信データ。
TCP はバイトストリームを重視しており、アプリケーションプログラムと TCP の間の対話は一度に 1 つのデータブロック (さまざまなサイズ) ですが、TCP はアプリケーションプログラムから渡されたデータを一連の非構造化バイトストリームとしてのみ扱います。
UDP メッセージの長さは送信者のアプリケーションプロセスによって決まり、TCP メッセージセグメントの長さは受信者によって与えられるウィンドウ値と現在のネットワークの輻輳レベルによって決まります。アプリケーションプロセスによって TCP キャッシュに送信されたデータブロックが長すぎる場合、TCP は送信する前に短い部分に分割します。短すぎる場合、TCP はセグメントを形成して送信する前に十分なバイトが蓄積されるまで待機することもできます。外。
IP ヘッダーのプロトコルフィールド: TCP=6、UDP=17。

3.1 TCPセグメントヘッダー形式

送信元ポート番号と宛先ポート番号:それぞれ 2B を占有します。ポートはトランスポート層とアプリケーション層の SAP です。トランスポート層の多重化および逆多重化機能は、ポートを通じてのみ実現できます。
シリアル番号: 4B を占め、合計 2^32 のシリアル番号。TCP 接続によって転送されるバイトストリーム内の各バイトには、連続した番号が付けられます。シーケンス番号フィールドの値は、このセグメントで送信されるデータの最初のバイトのシーケンス番号を指します。
確認番号: 4B を占めます。これは、相手の次のメッセージセグメントから受信されると予想される最初のデータバイトのシーケンス番号です。確認番号＝Ｎの場合は、シーケンス番号Ｎ－１までのデータが全て正しく受信されたことを意味する。(データリンク層のバックオフ N フレームプロトコルの累積確認応答 ACK は、N と N の両方が正しく受信されたことを示します)
データオフセット (ヘッダー長) : 4 ビットを占め、TCP セグメント内のデータの先頭が TCP セグメントの先頭からどのくらい離れているかを示します。単位は 4B です。TCP ヘッダーの最大長は 60B です。これは、IP データグラムのフラグメンテーションで使用されるデータオフセットではなく、TCP ヘッダーの長さであることに注意してください。
確認ビット ACK : 確認番号フィールドは ACK=1 の場合のみ有効で、ACK=0 の場合は確認番号フィールドは無効です。TCP では、接続の確立後、送信されるすべてのメッセージセグメントの ACK が 1 に設定されている必要があると規定しています。
同期ビット SYN : SYN=1 の場合、接続要求メッセージまたは接続受諾メッセージであることを示します。SYN=1,ACK=0 の場合は接続要求メッセージであることを示し、相手が接続に同意する場合は応答メッセージに SYN=1,ACK=1 を使用する必要があります。
終了ビット FIN (終了) : FIN=1 の場合、このメッセージセグメントの送信者のデータが送信され、送信接続を解放する必要があることを示します。
ウィンドウ: 2B を占有します。ウィンドウ値は、受信者が送信者に送信ウィンドウを設定させるための基礎となります。たとえば、確認番号が 701、ウィンドウフィールドが 1000 であるとします。これは、このメッセージセグメントの送信側がまだバイトシーケンス番号701 ～ 1700、合計 1000Bの受信バッファスペースを持っていることを示します。
チェックサム: 2B を占有チェックサムフィールド検証の範囲には、ヘッダー部分とデータ部分が含まれます。チェックサムを計算するとき、TCP セグメントの前に 12B 擬似ヘッダーが追加されます。
Padding ：ヘッダ全体の長さが4Bの整数倍になるように設定されるフィールド
予約ビット: 将来の使用のために予約されていますが、現時点では 0 に設定する必要があります。
緊急ビット URG : URG=1 の場合、緊急ポインタフィールドが有効であることを示します。
緊急ポインタ：2Bを占有します。このセグメントに緊急データが何バイトあるかを示します (緊急データはセグメントデータの先頭にあります)。
プッシュビット PSH (プッシュ): 受信側 TCP は、PSH=1 のメッセージセグメントを受信し、キャッシュ全体がいっぱいになるまで待ってから上向きに配信するのではなく、できるだけ早く受信側アプリケーションプロセスに配信します。
リセットビット RST (Reast ): RST=1 の場合、TCP 接続で重大なエラー (ホストクラッシュまたはその他の理由) が発生したことを示し、接続を解放し、その後トランスポート接続を再確立する必要があります。
オプション。長さは可変です。TCP は当初、最大セグメント長MSS というオプションを 1 つだけ指定していました。MSS は、TCP セグメント内のデータフィールドの最大長です。

注: メッセージセグメントのシーケンス番号は、そのデータ部分の最初のバイトの番号です。

3.2 TCP接続管理

注: 胡科大学の Gao Jun 教師は、以下の部分について完璧なビデオ解説を持っていますが、重要な点だけを個人的なメモに記録し、後で補足できるようにしています。

3.2.1 3 メッセージハンドシェイク

SYN メッセージセグメント (接続要求メッセージまたは接続受諾メッセージ) はデータを伝送できませんが、シーケンス番号を消費します。
通常の TCP 確認応答セグメントはデータを伝送できますが、データを伝送しない場合、シーケンス番号は消費されません。3 メッセージハンドシェイクの 3 番目のセグメントにデータが含まれていない場合、TCP クライアントプロセスによって送信される次のデータセグメントのシーケンス番号は依然として X+1 です。

3.2.2 手を振る 4 つのメッセージ

TCP 接続に参加している 2 つのプロセスのどちらも、接続の解放を要求できます。

TCP では、終了フラグ FIN が 1 に等しい TCP メッセージセグメントは、データを運ばない場合でもシーケンス番号を消費することを規定しています。
終了した待機 1 状態は、TCP クライアントがデータを送信していないが、TCP サーバーはまだデータを送信している可能性があることを示します。
サーバーがシャットダウン待機状態になると、TCP 接続は半クローズ状態になり、TCP クライアントはデータを送信できなくなりますが、TCP サーバーは引き続きデータを送信できます。

3.3 TCP フロー制御と確実な送信

データリンク層の信頼できる伝送メカニズムは、トランスポート層における TCPの信頼できる伝送メカニズムと多くの類似点がありますたとえば、ウィンドウメカニズム、確認、再送信 (タイムアウトまたは冗長 ACK) が使用されます。

したがって、TCP の信頼性の高い送信は比較メモリに適しています。

TCP は、メッセージセグメントではなく、送信されたバイトストリーム (つまり、バイト番号) に基づいて構築されるシーケンス番号を使用します。TCP のウィンドウサイズは、シーケンス番号の数を指定します。GBN と SR はウィンドウ番号です。
TCP はデフォルトで累積確認応答を使用します。これは GBN と同じです。ただし、GBN はエラー後にすべてのフレームを再送信する必要がありますが、TCP はエラーシーケンス番号で構成されるメッセージセグメントのみを再送信します(順序が崩れたメッセージはキャッシュされます)。さらに、TCP は SACK 選択確認オプションを提供しており、この時点では TCP は SR と非常によく似ています。TCP のエラー回復メカニズムは、GBN プロトコルと SR プロトコルを組み合わせたものとみなすことができます。
TCP はメッセージセグメントの確認応答メカニズムを採用しており、バイトごとに確認応答を送り返すのではなく、メッセージセグメントの 1 バイトを送信した後に確認応答が返されます。
データリンク層のバックオフ N フレームプロトコルの累積確認応答 ACK は、N と N の両方が正しく受信されたことを示します。TCP 確認 N はN-1 であり、N-1 より前のものは正しく受信されています。
TCP サーバーは、確認応答メッセージセグメントを蓄積することで受信ウィンドウのサイズを調整することで、送信側のフローを制御します。

受信ウィンドウ値が 0 の場合でも、ゼロウィンドウ検出セグメント、確認応答セグメント、および緊急データを伝送するセグメントは受け入れられる必要があります。

3.4 TCP輻輳制御

通信サブネットにおいて、過剰なデータパケットによって引き起こされるネットワークパフォーマンスの低下現象は、輻輳と呼ばれます。

ネットワーク層で輻輳制御を実装する方法は、明示的フィードバックです。現在、インターネット制御メッセージプロトコル (ICMP) の最新の規制では、ソース抑制メッセージ、つまり明示的なフィードバックは使用されなくなりました。

TCP では、輻輳制御は主に暗黙的なフィードバックを使用してトランスポート層で実装されます。

フロー制御は、受信者が時間内にデータを受信できるように、送信者がデータを送信する速度を抑制することです。
輻輳制御はグローバルな問題であり、ネットワーク内のすべてのホスト、ルーター、およびネットワーク伝送機能の低下を引き起こすすべての要因が関係します。リソースを追加するだけでは輻輳の問題は解決されません。