TCPはインオーダーデータ伝送をどのように実装/保証しますか？

Question

私はTCPがイン・オーダ・デリバリーをどのくらい正確に実装しているのだろうと思っていました。

が、これは

1. パケット1が送信され、受信したACKイベントのリストであると言うことができます。
2. packet2が送信され、ackが受信されませんでした。
3. packet3が送信されました。
4. packet4が送信されました。
5. ack4を受信しました。
6. ack3を受信しました。
7. ack2を受信しました。

正確に何が起こっているのかを私に説明できますか？

Answer 1

簡単な答えは、各パケットに、ストリーム内のペイロードがどこにあるかを指定するオフセット情報（シーケンス番号に見せかける）が含まれていることです。

パケット1が受信され、パケット2が受信されず、パケット3と4が受信されたとします。この時点で、受信TCPスタックは、パケット3とパケット4の内容をバッファ上でどこにコピーするかを知っていて、まだ前のデータを受信して​​いないことを知っているので、パケット1のデータを読み込み可能にしますが、パケット2が受信されるまで利用可能なパケット3または4のデータ。

送信TCPスタックは、一般に、あるパケットの肯定応答を待ってから次のパケットを送信するのではなく、特定のパケットに対する肯定応答を受信しない場合（ACKは、効率のために1つのパケットにまとめることができます。 ）、それはACKが受信されるまでそれを再送するでしょう。

イベントの正確な順序は、ネットワーク状態、TCPスタック実装、選択されたTCPポリシー、ソケットオプションなどの要因によって異なります。

Answer 2

TCPパケットが（メモリから、開始以来、バイトオフセット）シーケンス番号を持っているし、ACKメッセージは、特定のオフセットを受信したことを認める：

だからあなたのような状況になりかねません：

つまり

data 1 (10 bytes)   -> 
          <- ack (10, data1) 
data 2 (15 bytes)   -> 
data 3 (10 bytes)   -> 
data 4 (8 bytes)   -> 
          <- ack (25, data1/2/3) 
          <- ack (33, data1/2/3/4) 

、送信者はそのバッファがいっぱいである時点までの承認に関係なく送信し続けることができます（それはそれらを再送信する必要がある場合には未確認のパケットを維持しています）。

この送信と確認の間のこの「切断」は、データフローを大幅に高速化します。

受信側では、パケットが順不同で到着する可能性があり、高いレベルに何かが順番に届くまで保持されます。

例えば、data 3がdata 2の前に到着した場合、受信側はdata 2が到着するまでそれを保持し、両方が上に送られて配信されます。