tcp_fin_wait2 timer 관련 질문드립니다.

[문연관]

netstat -an 으로 했을때 특정 서비스(소켓) 에서 FIN_WAIT_2

가 다량으로 발생합니다.

ndd get 으로 확인했을때 default 설정값인 o으로 되어 있습니다.

이럴 경우 이 소켓에 의해 다른 소켓에 tcp buffer full등을

야기해서 장애를 유발할수 있을까요?

커널에 소켓 관련 buffer 제한 값이 있나요? 있다면 확인 parameter 좀 알려주시기 바랍니다.

[한일형]

안녕하세요. 제가 가지고 있는 문서중에

다음과 같은 내용이 있네요..

참고하시기 바랍니다.

If a connection is in the FIN_WAIT_2 state it has sent out it's FIN and the other end has acknowledged it.

Unless we have done a half-close, we are waiting for the application on the other send to recognize that it has received an end-of-file notification and close its end of the connection, which sends us a FIN.

Only when the process at the other end does this close will our end move from the FIN_WAIT_2 to the TIME_WAIT state.

This means our end of the connection can remain in this state forever. The other end is still in CLOSE_WAIT state, and remains there forever, until the application decides to issue the close.



In most cases this happens if the other ends application is no longer running at all.

So there is nobody who will ever send us the FIN and we remain in the FIN_WAIT_2 state.

With this timer it is possible to close the connection willingly from our side to get rid of connections in the FIN_WAIT_2 state.

The problem lies normally on the other end of this connection, since we only wait for something to happen.

So to solve this setting a timer is not really the solution, it would be better to change the application which is not sending the FIN to us.



The value is given in milliseconds.

The minimum is 0 which means the timer is not active, we wait forever.

Even if there is no real minimum for this value, do not set it to something below 10 minutes (600000). Otherwise you could violently close connections which still are halfway active.

The maximum is not defined.

The default is set to 0.



Why should this be changed?

Since a lot of application do not send the final FIN to end the connection, it could happen that a huge amount of connection remains in the FIN_WAIT_2 state.

To have a workaround until the real problem, the application on the other end, is solved you could set this timer to something bigger than 10 minutes.



Usable commands:

Check the current value:



ndd -get /dev/tcp tcp_fin_wait_2_timeout

Set the FIN_WAIT2 timeout to 11 minutes:



ndd -set /dev/tcp tcp_fin_wait_2_timeout 660000



nddconf entry example:

TRANSPORT_NAME=tcp

NDD_NAME=tcp_fin_wait_2_timeout

NDD_VALUE=660000