ウィンドウ制御とACK番号について

ACK通知が連続して起こった場合最後のものだけ通知して途中のものは省略して構わない、ということなのですがこの場合なんらかの障害によってパケットの抜けが起こってしまった場合どのように検知するのでしょうか?
私の認識では受信確認応答においてACK番号を返さないことでパケットが届いていないことを送信側に伝えていると考えているのですが、この場合途中のACK番号を省略してしまうと区別がつかないように思います
よろしくお願いします。

名前: 
匿名希望
日時: 
22/12/02 21:03

コメント

匿名希望さん、こんにちは

>ACK番号を返さないことでパケットが届いていないことを送信側に伝えて
基本的に、この考え方でOKです。

少し細かくみていきましょう。

まず、途中を省略する考え方ですが
これは連続してパケットが到着した場合の話です。
連続して何個もパケットが届いたときに
一つ一つ応答を返すのは効率悪いので、
(結果的にどこまで届いたのかが相手に伝われば良いので)
途中を省略するわけです。

では、途中で抜けたらどうなるでしょう?
受信側の立場からは
しばらく待っても次が来ない、
ことになります。
実際には、
受信側はタイマを使ってパケットの間隔を計測することで、
送信動作が一休みしたことを検出します。
そうしたら、最後に受信したところまで(抜けたパケットの前まで)、
受信側からACK番号を返します。
そのACK番号によって、
送信側でどこまで届いたのか判断できます。
なので、届いたパケットの次から再送信すれば良いことになります。

ただし、TCPには、このタイマに関する規定はありません。
すると、送信側と受信側で
タイミングの違いによって行き違いが生じる可能性があります。
そして、こんなことが起こります。
受信側のタイマ値が大きく(ACK番号を返すのが遅くなる)
送信側が届いていないと誤判断してしまうことです。
その結果、送信側は、本当は受信側に届いてるのに
パケットを再送信してしまうかもしれません。
こういう場合には、受信側はシーケンス番号で
再送信したパケットを判別できますから
既に受信済みのパケットは棄てればよいだけです。
多少効率は悪いですけど
通信データがおかしくなることはありません。

ここまでが、TCPが設計された当初の基本的な考え方です。
その後、いろいろな改良が施され(主に効率面での改良です)
今は、少し違った方法をとってますが
上の基本が理解できていれば大丈夫だと思います。

もし、改良点に興味があれば、
RTT(Round Trip Time)
Fast Retransmit
SACK(Selective Acknowledgement)
といったキーワードで検索してみてください。
解説ページが見つかると思います。