web-dev-qa-db-ja.com

ポートが常に（1日以上）FIN_WAIT1にある場合、どうなりますか？

サーバーと通信しようとすると問題が発生します。

コマンドラインを使用する場合：

netstat -np 10.aaa.bbb.12

ここで、10.aaa.bbb.12はサーバーアドレスを示します。次の結果の抽出物が得られます。

    tcp        0     87 10.xxx.yyy.4:59438          10.aaa.bbb.12:7955          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:36100          10.aaa.bbb.12:7952          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:59422          10.aaa.bbb.12:7955          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:41678          10.aaa.bbb.12:7951          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:60999          10.aaa.bbb.12:7953          FIN_WAIT1   -                   
    tcp        0     86 10.xxx.yyy.4:59456          10.aaa.bbb.12:7955          ESTABLISHED 21203/sender   
    tcp        0     87 10.xxx.yyy.4:41694          10.aaa.bbb.12:7951          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:36084          10.aaa.bbb.12:7952          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:60966          10.aaa.bbb.12:7953          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:41711          10.aaa.bbb.12:7951          FIN_WAIT1   -                   
    tcp        0     86 10.xxx.yyy.4:32783          10.aaa.bbb.12:7953          ESTABLISHED 21269/sender   
    tcp        0     87 10.xxx.yyy.4:60983          10.aaa.bbb.12:7953          FIN_WAIT1   -                   
    tcp        0     86 10.xxx.yyy.4:41728          10.aaa.bbb.12:7951          ESTABLISHED 21225/sender   
    tcp        0     86 10.xxx.yyy.4:36118          10.aaa.bbb.12:7952          ESTABLISHED 21247/sender

FIN_WAIT1のポートはこの状態になります1日以降。理由がわかりません。

上記の状態のすべてのサーバーポートは接続を受け入れ、サーバーはコマンドを受け入れているようですが、サーバーは期待どおりに応答しません。サーバーから待機したすべての応答はタイムアウトになります。

このコマンドラインを使用して、サーバーとの接続を確認できます。

nc 10.150.224.12 7955 -w 10 <ts.txt

ファイルts.txtに、既知の特定の応答を必要とするコマンドが含まれている場合。

linuxnetworkingtcpnetwork-protocols
1
Sir Jo Black

これは、サーバーがクライアントとアクティブな接続を持ち、TCP接続をシャットダウンしたい場合に発生するようです（おそらく通常のアプリケーション層の「終了」に応答して）。サーバーはクライアントを送信します。 「FIN」ビットが設定されたパケット。この時点で、サーバーはFIN_WAIT_1状態にあります。クライアントがFINパケットを取得すると、クライアントはCLOSE_WAIT状態になり、確認応答パケットをサーバーに送り返します。 FIN_WAIT_2状態になります。

これは、クライアントがTCPソケットを正常にシャットダウンせずにドロップオフしていることを意味します。

最善の解決策は、アプリケーションを修正することです。

即時の一時的な解決策は、これを実行することです ServerFaultスクリプト ：

# record what tcp_max_orphans's current value
original_value=$(cat /proc/sys/net/ipv4/tcp_max_orphans)

#set the tcp_max_orphans to 0 temporarily
echo 0 > /proc/sys/net/ipv4/tcp_max_orphans

# watch /var/log/messages
# it will split out "kernel: TCP: too many of orphaned sockets"
# it won't take long for the connections to be killed

# restore the value of tcp_max_orphans whatever it was before. 
echo $original_value > /proc/sys/net/ipv4/tcp_max_orphans

# verify with 
netstat -an|grep FIN_WAIT1

また、/proc/sys/net/ipv4/tcp_Orphan_retriesにある tcp_Orphan_retries を設定して、これらのソケットがこの状態に留まる時間を短縮することもできます。 0の値は実際には8を意味することに注意してください。

しかし、繰り返しになりますが、最善の解決策は、アプリケーションを修正して適切に閉じることです。

3
harrymc