TCP 再送信とは、損失または破損したパケットをネットワーク上で再送信することを意味します。ここで、再送信とは、次のようなプロトコルで使用されるメカニズムです。 TCP 信頼できるコミュニケーションを提供するために。ここで、信頼性の高い通信とは、データ パケットが失われたり破損したりした場合でも、プロトコルがパケットの配信を保証することを意味します。
gimp jpeg として保存
ネットワークは信頼性が低く、損失または破損したパケットの遅延や再送信は保証されません。確認応答と、破損または損失したパケットの再送信を組み合わせて使用するネットワークは、信頼性を提供します。
再送信メカニズム
ここで、再送信とは、データ パケットが失われ、確認応答の欠如につながることを意味します。この確認応答の欠如によりタイマーがタイムアウトになり、データ パケットの再送信が発生します。ここで、タイマーとは、タイマーが期限切れになる前に確認応答が受信されなかった場合、データ パケットが再送信されることを意味します。
次の再送信シナリオを考えてみましょう。
シナリオ 1: データ パケットが失われたか、エラーが発生した場合。
このシナリオでは、パケットは受信者に送信されますが、タイムアウト期間内に確認応答が受信されません。タイムアウト期間が経過すると、パケットが再送信されます。パケットが再送信されると、確認応答が受信されます。確認応答が受信されると、再送信は再度行われません。
シナリオ 2: パケットは受信したが、確認応答が失われた場合。
このシナリオでは、パケットは相手側で受信されますが、確認応答が失われます。つまり、送信側で ACK が受信されません。タイムアウト期間が経過すると、パケットが再送信されます。反対側にはパケットのコピーが 2 つあります。パケットは正しく受信されますが、確認応答が受信されないため、送信者はパケットを再送信します。この場合、再送は回避できましたが、ACK が失われたため、パケットは再送されます。
シナリオ 3: 早期タイムアウトが発生した場合。
このシナリオでは、パケットは送信されますが、確認応答の遅延または実際のタイムアウトの前にタイムアウトが発生したため、パケットは再送信されます。この場合、確認応答の遅延によりパケットが不必要に再送信されているか、実際のタイムアウトよりも早くタイムアウトが設定されています。
上記のシナリオでは、最初のシナリオは回避できませんが、他の 2 つのシナリオは回避できます。このような状況を回避する方法を見てみましょう。
送信者はどれくらい待つ必要がありますか?
送信者は ACK のタイムアウト期間を設定します。タイムアウト期間には次の 2 つのタイプがあります。
上記２つの状況を打破するには、 TCP タイムアウトを RTT (往復時間) の関数として設定します。往復時間とは、パケットが送信元から宛先に移動し、再び戻ってくるのに必要な時間です。
RTT はどうやって取得できますか?
RTT はネットワークの特性に応じて変化します。つまり、ネットワークが混雑している場合は、RTT が非常に高いことを意味します。 ACK を観察するだけで RTT を推定できます。
RTT を測定する方法を見てみましょう。
を使用します。 独自のアルゴリズム RTTを測定します。
私のコンピュータの画面はどれくらいの大きさですか
ステップ1： まず、測定します。 サンプルRTT セグメントまたは ACK ペアごとに。送信者がパケットを送信すると、パケットが送信されるタイマーがわかり、確認応答が受信されるタイマーもわかります。これら 2 つの間の時間を計算すると、次のようになります。 サンプルRTT 。
ステップ2： サンプルは 1 つだけ採取することはありません。さまざまなサンプルを取得し続け、これらのサンプルの加重平均を計算します。これが EstRTT (推定 RTT) になります。
ここで、α+β=1
αは0.8と0.9の間にあります
βは0.1と0.2の間にあります
ステップ 3: タイムアウトはEstRTTに基づいて設定されます。
タイムアウト = 2 * 推定RTT。
タイムアウトは推定 RTT の 2 倍に設定されます。これが、実際のタイムアウト係数の計算方法です。
このアプローチの欠陥
元のアルゴリズムに欠陥があります。 2 つのシナリオを考えてみましょう。
シナリオ 1。
上の図は、送信者がデータを送信することを示しており、これはオリジナルの送信と呼ばれます。タイムアウト期間内に確認応答は受信されません。したがって、送信者はデータを再送信します。データを再送信した後、確認応答が受信されます。再送信ではなく、元の送信に対して確認応答が受信されたと仮定します。元の送信の確認を取得しているため、 サンプルRTT は、最初の送信時と確認応答の受信時との間に計算されます。しかし実際には、 サンプルRTT 再送信時と確認応答時の間である必要があります。
シナリオ 2。
上の図は、送信者が元のデータ パケットを送信し、それに対して確認応答も取得することを示しています。ただし、データを再送信した後に確認応答が受信されます。確認応答が再送信に属すると仮定すると、次のようになります。 サンプルRTT 再送信時と確認応答時の間に計算されます。
上記の両方のシナリオでは、確認応答が元の送信に対するものなのか、再送信に対するものなのかがわからないというあいまいさがあります。
キャッシュをクリアする npm
上記のアルゴリズムの結論。
- ここでの ACK は送信を確認するという意味ではなく、実際にはデータを受信したことを確認することを意味します。
- 最初のシナリオを考慮すると、失われたパケットに対して再送信が行われます。この場合、ACK は元の送信に属しており、そのために SampleRTT が非常に大きくなっていると仮定します。
- 2 番目のシナリオを考慮すると、2 つの同じパケットが送信されるため、この場合は重複が発生します。この場合、ACK は再送に属し、そのために SampleRTT が非常に小さくなっていると仮定します。
上記の問題を克服するために、Karn/Partridge アルゴリズムによって簡単な解決策が提供されます。このアルゴリズムは、一度に送信されたサンプルを収集し、推定 RTT を計算する際に再送信時のサンプルを考慮しない単純なソリューションを提供します。
Karn/Partridge アルゴリズム
上記 2 つのシナリオでは再送信が発生するため、サンプル RTT を検討しました。ただし、このアルゴリズムは再送信時にサンプル RTT を考慮しません。再送信が発生したということは、この往復時間内に何かが発生したか、ネットワーク内で何らかの輻輳が発生した可能性があることを意味します。この問題を解決するために、このアルゴリズムでは再送信のたびにタイムアウトを 2 倍にします。このアルゴリズムは TCP ネットワークに実装されています。
制限
RTT の分散は考慮されていません。
上記の制限を克服するために、RTT に分散係数を導入する Jacobson/Karels アルゴリズムが開発されました。
ヤコブソン/カレルスアルゴリズム
このアルゴリズムは、 カーン/ヤマウズラ アルゴリズム。 SampleRTT とestimatedRTT の差を計算し、その差に基づいて RTT を引き上げます。
平均 RTT の計算
インターネットのデメリット
- まず、差異係数を計算します。
差分 = サンプルRTT - 推定RTT
- 次に、推定RTTを計算します。これは上記と同じ方法で計算されます。
EstRTT = EstRTT + (δ*差)
- 次に、差異係数の平均を計算します。
Dev = Dev + δ ( |Diff| - Dev)
ここで、Dev は偏差係数、δ は 0 と 1 の間の係数です。 開発者 からの分散の推定値です。 EstRTT 。
- タイムアウト値を計算するときに差異を考慮します。
どこ、 μ =1 および ɸ =4
高速再送信
タイムアウトベースの再送信戦略は非効率的です。 TCP はスライディング ウィンドウの種類のプロトコルであるため、再送信が発生するたびに、失われたパケットから送信を開始します。
パケット 0、1、2、3 を送信するとします。パケット 0 とパケット 1 は相手側で受信されるため、パケット 2 はネットワーク内で失われます。パケット 0 とパケット 1 の確認応答を受信したので、さらに 2 つのパケット、つまりパケット 4 とパケット 5 を送信します。パケット 3、4、および 5 が送信されると、パケット 1 の確認応答が TCP 確認応答として取得されます。累積されるため、受信したパケットまで順番に確認応答します。タイムアウト期間内にパケット 2、3、4、および 5 の確認応答を受信しなかったため、パケット 2、3、4、および 5 を再送信します。パケット 2 は失われていますが、他のパケット、つまり 3、4 は送信されません。 ,5 が反対側で受信されても、このタイムアウト メカニズムにより再送信されます。
このタイムアウトの非効率性はどうすれば解消できるでしょうか?
スライディング ウィンドウの下でのより良い解決策:
ギガバイトとメガバイト
n 個のパケットが失われたにもかかわらず、パケット n+1、n+2 などが受信されたとします。受信機は継続的にパケットを受信し、受信機がまだ n 番目のパケットを待っていることを示す ACK パケットを送信します。受信者が繰り返しまたは重複した確認応答を送信しています。上記の場合、パケット 2 が失われたため、パケット 1 の ACK が 3 回送信されます。この重複 ACK パケットは、n 番目のパケットが欠落しているが、後のパケットは受信されていることを示します。
上記の状況は次の方法で解決できます。
- 送信者は、n 番目のパケットが失われたという初期のヒントとして「重複 ACK」を受け取ることができるため、送信者はできるだけ早く再送信を行うことができます。つまり、送信者はタイムアウトが発生するまで待つ必要はありません。
- 送信者は、TCP で高速送信戦略を実装できます。高速送信戦略では、送信者は 3 つの重複 ACK をトリガーとして考慮し、再送信する必要があります。
TCP は 3 つの重複 ACK をトリガーとして再送信を実行します。上記の場合、パケット 1 の ACK が 3 つ受信された場合、送信者はタイムアウト期間が発生するのを待たずに、失われたパケット、つまりパケット 2 を送信する必要があります。