0

TCPを使用するアプリケーションの動作に戸惑っています。インターネット全体のTCP接続の一方の端にあるアプリケーションがソケットでclose（）を呼び出すと、close（）が返されます。ただし、もう一方の端では、ソケットのwrite（）は、TCP接続が閉じられていることを示していません。ちなみに、この動作はTCP仕様と矛盾しています。アクティブなclose（）は、TCP接続のもう一方の端から確認応答を受信しない限り（具体的には、アクティブな端のTCP状態は遷移できません）、戻るべきではありません。もう一方の端から適切な応答を受信しない限り、TIME_WAIT_1の値-その時点で、もう一方の端のwrite（）はエラーを返します）。

誤動作している侵入防止システム（IPS）がTCP接続の両端の間にあるときに、この動作を確認しました。IPSの製造元はこの問題に取り組んでいます。

この動作が発生する可能性のある他の状況はありますか？

私の環境はUnix、C、ONC RPC、およびソケットです。

4

1 に答える 1

0

プロトコルの状態遷移と API の動作を混同しています。RFC には、close() API がアプリケーションに戻れず、プロトコル アクションが非同期で進行するという記述はありません。これは、Sockets API でデフォルトで行われていることとまったく同じです。送信する保留中のデータがソケット送信バッファーにあり、受信側が遅い場合、FIN が送信されるまでに任意の時間がかかる可能性があります。これは、ソケット オプション SO_LINGER を使用してリンガー タイムアウトを設定することで変更できます。これにより、すべてのデータがフラッシュされるか、タイムアウトが期限切れになるまでブロックが閉じられますが、実際にはほとんど使用されません。

于 2013-03-01T21:37:28.507 に答える