必要に応じてパケットを遅延させることで、人為的なネットワーク状態をエミュレートしようとしています (エミュレートされているアプリケーションは Java アプリケーションです)。
私が直面している問題は、アプリケーションが ACK をしばらく受信していないことを検出し、再送信することです。これは両端で発生し、核分裂反応を引き起こします。パケットが順不同で受信され、最終的に一方が RST パケットを送信します。
絶対にそうならないようにしたい。どうすればこれを回避できますか?
ありがとう
更新: 一部の Wireshark キャプチャ セッション イメージ: http://db.tt/fav2sRgLおよびhttp://db.tt/zGXwMubk
パケットを 1 秒以上保持しているように聞こえますが、これはネットワーク ランドでは非常に長い時間であり、TCP が満足するものではありません。結果として生じる失敗のカスケードは、TCP に期待できるものとほとんど同じです。
しかし、最初に、そのタイプの遅延が本当にエミュレートしたいものかどうかを検討する必要があります. パケットがパスを通過するのにかかる時間 (一方向)、往復の時間 (往復)、およびアプリケーションが処理して応答するのにかかる時間 (ネットワーク スタックとは無関係) には大きな違いがあります。 ）。
私はネットワーク統計とエミュレーションに関するいくつかの記事を書いています。
免責事項: 私は、代替トランスポート プロトコルを作成する会社で働いています。
解決策は、エミュレーションの目的によって異なります。
ワイヤ レベルの忠実度が必要な場合は、TCP スタック全体を制御してタイミングを管理する必要があります。代わりに、ソケット レベルで動作をシミュレートする場合は、ストリームを変更しない長さ 0 のセグメントで応答することにより、ACK ストームを防ぐことができます。
明らかに、TCP セグメントは引き続き存在しますが、ペイロードが含まれていないだけです。
フレームが順不同で送信されるという観察結果は、かなりのバッファリングを含む環境を示唆しているため、興味深いものです。ルーティングされた WAN を介してテストを行っていますか、それとも単一の LAN セグメントでテストを行っていますか?
到着していないパケットの再送信は、TCPが行うことです。十分に順不同の遅延到着 (特に ACK) は、同期の安全マージンを吹き飛ばし、中止します。