- それは信頼できない言及されたときに、フロントリンク層を述べ、エラー検出のためのエラーは、エラー検出は、MACフレームです。ベストエフォートは、信頼性の高い伝送を保証するものではありませんネットワーク層について話しました。下は、この問題を回避しようとしているが、問題は、すべての後に避けられない、究極の信頼性が利きダウンは、トランスポート層に落ちます。
TCPの信頼性の高い伝送
完全に理想化された信頼性の高い伝送
- 仮定1：リンクは理想的な伝送チャネルが、送信されたデータはエラーでもないが、失われることはありません。
- 仮定2：送信者に関係なく、どのように高速なデータ伝送速度の、受信機は常に受け入れ、速やかにホスト（フロー制御の問題）を投入するのに十分な時間です。
- しかし、実際にはこれら2つの仮定を実現することは不可能です。
第二に、停止と待機プロトコルARQ
- 「ストップを待っている」他の当事者（いないことを確認し確認のため、待ち時間の送信を停止するために、各送信にパケットを終了しています
重传）。伝送に確認応答パケットを受信した後 - 二重全二重通信、即ち、送信側が受信側です。（便宜の議論のためにここで、我々は唯一のための肯定応答を受信した送信データAと送信データBを考えます
A叫做发送方，B叫做接收方） - エラー検出が間違って後の受信データが見つかった場合にA、Bへの送信データBの後、データは破棄されます。Aは、一定の期間を待った後にデータを再送信する（再送タイムアウトを、後ろにこの時間設定はどのように言うだろう）。
错误的几种可能:
1.送信されたデータが失われたり、遅くさ
2.データが間違って送信された
3 Bを肯定応答が失われた又は遅れて返信
4肯定応答が失われた
A、5の結果は、同じ4つの場合であるので、没収期間限りでBへの確認応答フレームは、再送信をタイムアウトします- 呼ば確認再送メカニズムを使用して
自动重传ARQBが再送信が自動的に行われ、Aの要求再送信する必要がないことを意味し、。 优点：シンプル缺点：低チャネル使用率
チャネル使用率：
- ここで、T Dは、トランスポート遅延です。チャネル使用率が非常に低いので、多くの時間は、上の待機に費やされています。
- 質問：なぜTであるD /合計時間は？？？？
第二に、伝送線路連続ARQプロトコル----
- 問題ARQチャネル利用率を解決するために、
- 送信パイプラインは、パケット送信が互いの確認応答を待つ必要がなく、連続して送信されたパケットのみを複数送信することです。大幅チャネル利用率を向上させます。
ワークス
窗口受信者が送信者にバインドされ、どのように多くのパケットの送信元の制約のみを送信することができます
累積確認
- 受信者は、一般的に使用し
累计确认、受信したパケットの確認応答を送信することによって、1を持っていない方法を、ではなく按序列到达的最后一个分组发送确认、それはこの意味：パケットが正しく受信されるまで、すべてのパケットを。 优点：簡単には、再送を持っていない後半の損失を確認するために、タイムリーに実装します缺点：すべての情報パケットが正しく送信者に受信者が受信した反映されない（例えば、送信者が最初の三つのグループを除いて、100パケットを送信した、他のグループは、受信者だけが、その後、受信者に正常に到達しています2つのパケットが97個のパケットが到着後ろに、送信者が誤ってその最初の2つのグループを信じていますので、それは、成功を反映することはできません（確認番号は、3次の番号は、パケット3を受信することが期待されて表して）手前側に到着し、送信を伝えます到着したので、彼らは非常に無駄なパケット3-100を再送信します。）（もちろん、この問題はすることができます选择确认SACK解決）- バック-N-Goの（
回退N）、（3-100）必要がNを介して送信戻って再送パケットを渡されたことを示し
- バック-N-Goの（
修正方案：选择确认SACK:- 受信機は、バイトの離散的な数の系列を受信し、それがバック肯定応答を送信し、不連続及び連続高速ブロック境界情報受信機に伝えます。
- TCPヘッダープラス「のオプション部分
允许SACK」オプション、および両側には、事前に合意しなければなりません - 4バイトの境界を示しているが、最大で40のバイトが、費やされる選択部分のヘッダ部分の長さは8バイトのブロックが費やされる（数値範囲は4バイトである）、したがってのみ示すことができ4バイト境界情報ブロック（全体ではないが、40バイトを占めます）。
具体的な実現TCP信頼性の高い輸送
- - TCP接続の各端部は二つのウィンドウで提供されなければならない
发送窗口と接收窗口（それが全二重であるため）。2つのポートが、多くの場合、動的に変化します - 使用するTCP信頼性の高い輸送機構が
字节的序号制御されています。すべての数値は、メッセージフィールドに基づいていないTCPに基づいています - 往復時間RTT TCP接続が固定されていません。再送時間の最も合理的な推定値を生成するために特定のアルゴリズムを使用する必要があります。
まず、送信バッファ - アプリケーションプロセスの送信元TCP送信バッファに書き込まれたバイトのストリーム
- 送信側の送信ウィンドウの通常一部のみ
- 最初に保存されて送信されたが受け取らなかった、それが可能なの再送（紫節）であります
第二に、受信バッファ
- 受信側のプロセスの適用は、受信バッファからTCPバイトストリームを読み出します
- 受信したバイトがキャッシュから（紫色）を省略することができる
3、の三点を強調すべきです
- ウィンドウは常に（一定のタイムラグがあるため、遅れがないがた????として大きなとしてではない）ウィンドウBとして大きなとして送信し、受信していません
- TCPフラグは、データが誤ったプロセスの数に達する方法を指定しません。通常、最初は確かにバイトのキャッシュを待つために店に到着します。
- TCPは、受信機が持っている必要があります必要と
累计确认伝送のオーバーヘッドを減らすことができ、：機能（蓄積しやすいゴーバック-Nを決定注）
第四に、受信機が確認応答を送信
- 適切な場合、彼らは、道に沿って送られたピギーバック肯定応答を送信するためのデータを持っている場合、受信者であってもよい、確認応答を送信することができます。しかし、また、二つのことに注意を払う必要があります。
- 受信者が不当に確認応答を送信延期すべきではない、送信者は、そうでない場合は、不必要な再送信につながります。（未手遅れ確認、送信側は受信側が再送データの前に待機します、すべての送信ウィンドウを送信してきました。）
- ほとんどのアプリケーションはめったに両方向に同時にデータを送信しないので、実際に便乗することは、多くの場合は発生しません
第五に、どのように選択するタイムアウト再送時間RTO
