11

クライアントは最初にソケットを閉じます。サーバーからのデータがあまりない場合、tcp 接続のシャットダウンは次のように問題ありません。

FIN -->
   <-- ACK
   <-- FIN, ACK
ACK -->

サーバーがデータの送信でビジー状態の場合:

FIN -->
    <-- ACK,PSH
RST -->

そして、サーバー接続は CLOSE_WAIT 状態になり、長時間そこにとどまります。

ここで何が問題なのですか？クライアント関連またはサーバー関連? これは、ローカル ソケットの Redhat5 で発生します。

この記事では、「RST」が送信される理由について説明していますが、サーバー接続が CLOSE_WAIT のままになっている理由がわからず、FIN を送信していません。

[編集] 最も重要な情報を無視しました。これは qemu の slirp ネットワーク エミュレーションで発生します。密接な接続を処理するための slirp バグの問題のようです。

4

3 に答える 3

2

これは、クライアントが読み取りを完了していない未読データがストリームに残っていることを意味します。

オプションを使用して強制的にオフにすることができSO_LINGERます。Linuxの関連ドキュメント(ここでオプション自体も参照) と、Win32 の [対応する関数はこちら2] です。

開いたままになっているのはサーバー側なので、サーバー側で無効にすることができますSO_LINGER。

于 2009-12-16T09:31:49.583 に答える
0

これはqemuの既知の欠陥です。

于 2010-01-07T12:27:32.773 に答える
0

サーバーがソケットを閉じていない可能性があります。これは、"lsof" を使用して、TCP ソケットを含むそのプロセスによって開かれているファイル記述子を一覧表示することで簡単にわかります。修正は、プロセスが終了したときに常にソケットを閉じるようにすることです（エラーの場合などでも）

于 2009-12-16T23:12:14.237 に答える