Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (kevin13@chol.net)
홈페이지
첨부 파일
 

코드로 재현하는 소켓 상태(FIN_WAIT1, FIN_WAIT2, TIME_WAIT, CLOSE_WAIT, LAST_WAIT)


아래의 글에 보면, 상태도가 잘 나와 있습니다.

TIME_WAIT vs CLOSE_WAIT
; http://kukuta.tistory.com/155

그걸 가지고 한번 이야기 해 볼까요? ^^

[그림 1: 소켓 Close 상태도(From: http://kukuta.tistory.com/155)]
tcp_disconnect_state.jpg

위에서 소개된 상태 값들이 바로 FIN_WAIT1, FIN_WAIT2, TIME_WAIT, CLOSE_WAIT, LAST_WAIT 인데요. 이번 글에서는 이 상태들을 한번 재현해 볼까 합니다.

코드 예제는 C#으로 해볼 텐데 어차피 소켓 프로그램들이 대개 비슷하기 때문에 다른 환경에서도 동일하게 적용될 수 있으니 상관없이 보셔도 될 것입니다.





1. FIN_WAIT1

FIN_WAIT1 은 소켓 서버/클라이언트 중에서 어느 쪽이든지 Close 를 호출한 측의 소켓이 진입하는 상태입니다. 일반적인 네트워크 상황에서 이 상태를 보기란 매우 어렵습니다. 왜냐하면, 이더넷에서 소켓 Close가 발생하는 순간 패킷이 상대방으로 전달되고, 그 수신측에서는 프로그램의 코드와 상관없이 운영체제 TCP 드라이버 단에서 ACK를 보내버리기 때문에 Close 메서드를 호출한 측에서는 그 신호를 받고 곧바로 FIN_WAIT2 상태로 빠지기 때문입니다.

위의 "[그림 1: 소켓 Close 상태도]" 그림에서는 "read return 0" 이라는 코드가 수행되어야 하는 것처럼 자칫 오해를 불러일으킬 수 있는데 ACK 신호는 TCP 드라이버 레벨에서 이미 처리되는 것이고 read 메서드 호출과는 상관이 없습니다. 물론, 그 상태에서 read 를 호출하게 되면 반환값이 0 으로 됩니다.

자, 그럼 이 상태를 어떻게 재현해 볼 수 있을까요?

쉽게는 ^^ 가상머신을 사용하면 됩니다. 연결이 맺어진 상태에서 (클라이언트 쪽이든) 서버 측 프로그램이 돌아가고 있는 VM 을 ACK 응답을 할 수 없도록 "Pause" 상태로 만들고 (서버 쪽이든) 클라이언트 측에서 Close 코드를 실행하면 됩니다.

예제 코드는 클라이언트 쪽에서 Close를 하도록 만들어 볼 텐데요. 간단하게 다음과 같이 구성될 수 있습니다.

==== 서버 측 ====
static void Main(string[] args)
{
    TcpListener listener = new TcpListener(6000);
    listener.Start();
    List<TcpClient> list = new List<TcpClient>();

    while (true)
    {
        TcpClient childSocket = listener.AcceptTcpClient();
        list.Add(childSocket); // GC 로 인한 Close를 막기 위해.
    }
}

==== 클라이언트 측 ====
static void Main(string[] args)
{
    TcpClient client = new TcpClient();
    client.Connect("...서버가 실행중인 IP...", 6000);

    Console.WriteLine("Press a key to close the socket...");
    Console.ReadLine();
    client.Close();

    Console.WriteLine("Press a key to exit...");
    Console.ReadLine();
}

자, 이제 서버를 VM 에서 실행한 후 netstat -ano | findstr "6000" 이라는 명령어를 실행하면 서버 측 소켓이 "LISTENING" 상태로 대기하는 것을 볼 수 있습니다.

TCP    0.0.0.0:6000           0.0.0.0:0              LISTENING       5132

그 상태에서 클라이언트 프로그램을 다른 PC(또는 VM)에서 실행시켜서 접속합니다. 그럼 서버 측과 클라이언트 측의 소켓 상태는 "ESTABLISHED" 가 추가됩니다.

=== 서버 측 소켓 상태 ===
  TCP    0.0.0.0:6000           0.0.0.0:0              LISTENING       5132
  TCP    127.0.0.1:6000         127.0.0.1:58675        ESTABLISHED     5132

=== 클라이언트 측 소켓 상태 ===
  TCP    127.0.0.1:58675        127.0.0.1:6000         ESTABLISHED     5228

이어서 서버 측 VM을 (종료가 아니라) 중지시킵니다. (Hyper-V 의 경우에는 Pause라는 메뉴가 있습니다.)

그런 다음 클라이언트 측 프로그램의 소켓을 Close 시키고 netstat 로 확인하면 FIN_WAIT_1 상태로 빠진 것을 확인할 수 있습니다.

이후, 서버 측 VM 을 활성화시키지 않으면 약 20 초 후에 FIN_WAIT_1 중인 소켓 자원은 운영체제에 의해서 해제되어 버립니다. 20초 이내에 서버 측 VM 을 활성화 시키면 FIN_WAIT_2 상태로 진행을 계속합니다.


2. CLOSE_WAIT, FIN_WAIT_2

이 2가지 상태는 같이 테스트가 될 수 있기 때문에 묶었는데요. 이 중에서 참 말도 많고, 탈도 많은 상태가 바로 CLOSE_WAIT 입니다. 사실 개념 자체는 그리 어렵지 않습니다. 양측 어느 쪽이든 먼저 Close 를 시도한 소켓은 FIN_WAIT_1 상태로 진행하지만, 그 Close를 받은 소켓 측에서는 곧바로 CLOSE_WAIT 상태로 빠집니다. CLOSE_WAIT 상태로 빠졌다는 것은 Close 수신을 받았다는 것을 ACK 했다는 것에 해당하기 때문에 ACK 신호는 Close 를 호출한 소켓으로 전달되고 그 소켓은 기존의 FIN_WAIT_1 상태에서 ACK 신호를 받으면서 FIN_WAIT_2 상태로 진행합니다.

보통은, Close 신호를 수신했으면 자신도 곧바로 소켓을 닫아야 하는 것이 정상인데요. 만약, 어떤 식으로든 Close를 하지 않으면 소켓은 계속 CLOSE_WAIT 상태에 놓이게 됩니다. (반대 측 소켓은 계속 FIN_WAIT_2 상태로 머물고.)

재현하는 코드도 간단한데요. 아래에서는 클라이언트 측에서 먼저 소켓을 Close하고, 서버 측에서는 Close를 하지 않은 경우를 보여주고 있습니다.

==== 서버 측 ====
static void Main(string[] args)
{
    TcpListener listener = new TcpListener(6000);
    listener.Start();
    List<TcpClient> list = new List<TcpClient>();

    while (true)
    {
        TcpClient childSocket = listener.AcceptTcpClient();
        list.Add(childSocket); // GC 로 인한 Close를 막기 위해.
		// ... Close 코드 없음 ...
    }
}

==== 클라이언트 측 ====
static void Main(string[] args)
{
    TcpClient client = new TcpClient();
    client.Connect("...서버가 실행중인 IP...", 6000);
    client.Close();  // 닫기 진행

    Console.WriteLine("Press a key to exit...");
    Console.ReadLine();
}


=== 서버 측 소켓 상태 ===
 TCP    0.0.0.0:6000           0.0.0.0:0              LISTENING       3096
 TCP    169.254.122.160:6000   169.254.28.164:59203   CLOSE_WAIT      3096

=== 클라이언트 측 소켓 상태 ===
  TCP    169.254.28.164:59203   169.254.122.160:6000   FIN_WAIT_2      5208

윈도우의 경우 CLOSE_WAIT 상태에 빠진 후 대상 소켓으로부터 Close 신호가 오지 않으면 2분 후에 소켓 자원을 정리해 버립니다. 즉, 위와 같은 예제 코드를 실행하면 2분 동안만 CLOSE_WAIT 상태를 확인할 수 있습니다.

참고로, 테스트는 "윈도우 8" 에서 진행했으므로 다른 버전의 윈도우 또는 운영체제에 따라서 2분이라는 숫자가 다를 수 있습니다.


3. LAST_WAIT

"[그림 1: 소켓 Close 상태도]" 를 보면 LAST_WAIT 은 소켓 Close 신호를 받은 측에서 (현재, CLOSE_WAIT 상태) 코드에서 직접 Close 함수를 부르는 시점에 CLOSE_WAIT 에서 LAST_WAIT 으로 진행하게 됩니다.

그럼, 애초의 Close 신호를 보냈던 측으로 FIN 신호가 전달되고 곧바로 ACK 신호를 보내어 소켓 종료로 이어집니다. 따라서 LAST_WAIT 상태 역시 FIN_WAIT_1 처럼 전환 속도가 워낙 빠르기 때문에 확인하는 것이 쉽지 않습니다. 물론 이번에도 VM을 이용하면 가능합니다.

코드를 먼저 볼까요?

==== 서버 측 ====
static void Main(string[] args)
{
    TcpListener listener = new TcpListener(6000);
    listener.Start();

    while (true)
    {
        TcpClient childSocket = listener.AcceptTcpClient();
        ThreadPool.QueueUserWorkItem(tcpClient_Connected, childSocket);
    }
}

static void tcpClient_Connected(object obj)
{
    TcpClient socket = obj as TcpClient;
    Thread.Sleep(5000); // 5초 후에 소켓을 닫는다.
    socket.Close();
}

==== 클라이언트 측 ====
static void Main(string[] args)
{
    TcpClient client = new TcpClient();
    client.Connect("...서버가 실행중인 IP...", 6000);
    client.Close();

    Console.WriteLine("Press a key to exit...");
    Console.ReadLine();
}

클라이언트 측에서 우선 Close 코드를 호출했고, 서버는 5초 후에 Close 를 호출하게 되어 있습니다. 따라서, 연결이 맺어지고 5초 이내에 클라이언트 측 VM 을 "Pause" 시키면 5초 후에 서버 측에서 Close를 호출한 소켓은 CLOSE_WAIT 에서 LAST_WAIT으로 변경되는 것을 확인할 수 있습니다.

실제로 이와 같은 과정을 통해서 netstat 로 확인해 보면 LAST_WAIT 상태가 "LAST_ACK" 로 표현된 것을 확인할 수 있습니다.

=== 서버 측 소켓 상태 ===
  TCP    0.0.0.0:6000           0.0.0.0:0              LISTENING       5164
  TCP    169.254.28.164:6000    169.254.122.160:49162  LAST_ACK        5164

LAST_WAIT 상태로 진입한 서버 측 소켓은 약 20초 후에 정리됩니다. (물론, 20초 이전에 중지시켰던 VM을 활성화시키면 정상적으로 소켓 정리 작업에 들어갑니다.)


4. TIME_WAIT

이전 단계에서 "LAST_WAIT" 을 확인하기 위해 VM을 중지시켰는데요. 만약, 이 때 중지를 안 시키고 상대방의 Close 신호를 받게 되면 맨 처음 Close 코드를 호출했던 측은 TIME_WAIT 상태로 빠지면서 두번째 Close를 호출했던 상대방에게 ACK 신호를 전송해서 LAST_WAIT으로 대기하고 있던 소켓의 자원을 정리할 수 있게 해줍니다.

TIME_WAIT 상태가 필요한 이유는 TIME_WAIT vs CLOSE_WAIT 글에서 이미 잘 소개하고 있는데요. 다시 설명해 보면 이렇습니다.

LAST_WAIT으로 대기하고 있는 소켓 측에 보낸 ACK 신호가 중간에 유실되는 경우가 발생할 수 있습니다. 그럼, LAST_WAIT으로 대기하고 있던 소켓 측은 다시 FIN 신호를 보내는 작업을 반복합니다. (위의 실험에 의하면 약 20초 동안 한다는 것이지요.)

그러니까, FIN 신호가 여러번 올 수 있는 상황이 발생하는 것입니다. 그런데 만약 TIME_WAIT 상태를 갖지 않고 자원을 해제해 버린 후, 곧바로 다른 클라이언트로부터 동일한 포트로 접속이 된다면? 하필 그렇게 연결 상태에 있는 소켓에 여러 번 FIN 신호가 전송되던 것이 네트워크를 돌고 돌아 수신될 여지가 발생하여 기존 접속에 문제를 일으킬 수 있게 됩니다.

그래서, 안전하게 2MSL(Maximum Segment Lifetime) 동안 TIME_WAIT 상태로 머물게 되는 것입니다. 윈도우에서의 TIME_WAIT 값은 TcpTimedWaitDelay 레지스트리 값을 통해서 변경될 수 있고 기본은 4분으로 되어 있습니다. (따라서 윈도우에서는 MSL 시간이 2분이라는 것이지요.)

TCP/IP and NBT configuration parameters for Windows XP
; http://support.microsoft.com/kb/314053

일반적으로 TIME_WAIT 은 먼저 Close를 시도한 측에서 발생합니다. 하지만 테스트하다보면 양쪽에서 TIME_WAIT이 발생하는 상황도 있는데 아마도 양쪽에서 동시에 Close를 시도하면 서로 TIME_WAIT이 걸리는 듯 합니다.

재현을 해볼까요? ^^ 먼저 서버 측에서 TIME_WAIT 이 발생하려면 아래와 같이 해줄 수 있습니다.

static void Main(string[] args)
{
    TcpListener listener = new TcpListener(6000);
    listener.Start();

    while (true)
    {
        TcpClient childSocket = listener.AcceptTcpClient();
        childSocket.Close(); // 서버 측에서 먼저 닫기 시도
    }
}

static void Main(string[] args)
{
    TcpClient client = new TcpClient();
    client.Connect(target, 6000);

    Thread.Sleep(2000);  // 클라이언트는 서버가 닫은 후 닫기 시도
    client.Close();
}

netstat 로 서버 측 PC에서 확인해 보면 TIME_WAIT 이 2분동안 살아있는 것을 볼 수 있습니다. 근데 왜 2분일까요? 분명히 위의 문서는 4분이라고 되어 있는데... 어쨌든 "윈도우 8" 에서 Hyper-V 에 얹은 VM 에서의 실험값은 이렇게 나옵니다.

이제 반대로 해볼까요?

static void Main(string[] args)
{
    TcpListener listener = new TcpListener(6000);
    listener.Start();

    while (true)
    {
        TcpClient childSocket = listener.AcceptTcpClient();
	Thread.Sleep(2000); // 클라이언트 측이 닫은 후 닫기 시도
        childSocket.Close();
    }
}

static void Main(string[] args)
{
    TcpClient client = new TcpClient();
    client.Connect(target, 6000);
    client.Close(); // 곧바로 닫기 시도
}

다시 netstat 로 확인해 보면 이번에는 서버 측 PC가 아닌 클라이언트 측 PC에 TIME_WAIT 항목이 있는 것을 확인할 수 있습니다. 재미있는 것은 이런 경우에 지속되는 TIME_WAIT 시간인데요. 테스트 한 바로는 30초 동안만 유지되고 그 이후에 자원이 정리되는 것을 볼 수 있습니다.




어느 문서에선가 읽은 기억이 나는데 TIME_WAIT 상태의 소켓은 최근의 윈도우 서버에서는 문제될 것이 없다고 알고 있습니다. TIME_WAIT으로 포트가 모두 잠식된 경우 윈도우는 자동적으로 기존 TIME_WAIT 상태가 아직 만료 시간이 지나지 않았어도 재활용 할 수 있도록 조치를 취한다고 합니다. (어느 문서였는지 기억이 안나서... 혹시 아시는 분 덧글 부탁드립니다.)

오히려 문제는 CLOSE_WAIT 입니다. 이것은 상대방으로부터 close 소켓 신호를 받은 후, 자신도 close를 호출해야 하는데 그렇지 않고 넘어갔다거나 어떤 사유이던지 호출을 하지 않고 계속 소켓 자원을 보관하고 있는 것입니다. 즉 '재사용'이 불가능한 상태입니다. 물론, 2분이라는 시간이 지나면 정리가 되지만, 사용자가 몰리는 상황에서는 그 2분이 매우 길게 느껴질 수도 있습니다.

그 외에, 때로는 아래의 상황처럼 래퍼 클래스의 사용을 잘못하는 경우에도 CLOSE_WAIT 현상을 겪을 수 있으니... 주의가 필요합니다. (테스트 결과, .NET 1.1 에만 해당했던 문제로 보입니다. .NET 4.0에서 테스트 시에는 정상적으로 종료되었습니다.)

The TcpClient Close method does not close the underlying TCP connection 
; http://support.microsoft.com/kb/821625

양측에서 Close 를 호출해 주지 않고 한 쪽만 호출하는 경우 어떤 close API를 사용했느냐에 따라 소켓 상태가 예측할 수 없게 바뀌는지는 대해서는 다음의 글에 소개되어 있습니다. (그냥 읽어두기만 하시고, 무조건 양측에서 Close를 호출할 수 있도록 하는 것이 좋습니다. ^^)

Keep-alive packets continue being sent after client closes (server socket is CLOSE_WAIT, client sock
; http://go4answers.webhost4life.com/Example/keep-alive-packets-continue-being-sent-185589.aspx







[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]





[최초 등록일: ]
[최종 수정일: 1/25/2018 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:kevin13@chol.com

비밀번호

댓글 쓴 사람
 



2013-10-17 02시35분
TIME_WAIT를 남기지 않는 세션종료 (Graceful Shutdown)
; http://kuaaan.tistory.com/118
정성태
2015-06-10 04시33분
What is TIME_WAIT state?
; http://docs.likejazz.com/time-wait/

How to handle CLOSE_WAIT state
; http://docs.likejazz.com/close-wait/
정성태
2015-08-22 02시24분
* TCP의 TIME_WAIT는 없애는 방법은?
; http://sunyzero.tistory.com/198
정성태
2016-08-14 03시17분
아래의 글은 Linux 상의 테스트라 윈도우의 상황과는 일부 맞지 않을 수 있습니다.

CLOSE_WAIT & TIME_WAIT 최종 분석
; http://tech.kakao.com/2016/04/21/closewait-timewait/
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
11658정성태8/18/20185사물인터넷: 31. 커패시터와 RC 회로파일 다운로드3
11657정성태8/18/201810사물인터넷: 30. 릴레이(Relay) 제어파일 다운로드3
11656정성태8/18/201831사물인터넷: 29. 트랜지스터와 병렬로 연결한 LED파일 다운로드1
11655정성태8/18/201826사물인터넷: 28. 저항과 병렬로 연결한 LED파일 다운로드1
11654정성태8/18/201844사물인터넷: 27. 병렬 회로의 저항, 전압 및 전류파일 다운로드1
11653정성태8/18/201828사물인터넷: 26. 입력 전압에 따른 LED의 전압/저항 변화파일 다운로드1
11652정성태8/18/201834사물인터넷: 25. 컬렉터 9V, 베이스에 5V와 3.3V 전압으로 테스트하는 C1815 트랜지스터파일 다운로드1
11651정성태8/18/201846사물인터넷: 24. 9V 전압에서 테스트하는 C1815 트랜지스터파일 다운로드2
11650정성태8/18/201842사물인터넷: 23. 가변저항으로 분압파일 다운로드1
11649정성태8/14/201869사물인터넷: 22. 저항에 따른 전류 테스트파일 다운로드1
11648정성태8/14/201878사물인터넷: 21. 퓨즈를 이용한 회로 보호파일 다운로드3
11647정성태8/8/2018145오류 유형: 476. 음수의 음수는 여전히 음수가 되는 수(절대값이 음수인 수)
11646정성태8/8/201877오류 유형: 475. gacutil.exe 실행 시 "Failure initializing gacutil" 오류 발생
11645정성태8/8/201887오류 유형: 474. 닷넷 COM+ - Failed to load the runtime.
11644정성태8/8/2018171디버깅 기술: 119. windbg - 닷넷 개발자를 위한 MEX Debugging Extension 소개
11643정성태8/12/2018172사물인터넷: 20. 아두이노 레오나르도 R3 호환 보드의 3.3v 핀의 LED 전압/전류 테스트 [1]파일 다운로드1
11642정성태8/3/201899Graphics: 19. Unity - LightMode의 ForwardBase에 따른 _WorldSpaceLightPos0 값 변화
11641정성태8/3/2018135Graphics: 18. Unity로 실습하는 Shader (10) - 빌보드 구현파일 다운로드1
11640정성태8/3/2018117Graphics: 17. Unity - World matrix(unity_ObjectToWorld)로부터 Position, Rotation, Scale 값을 복원하는 방법파일 다운로드1
11639정성태8/2/2018135디버깅 기술: 118. windbg - 덤프 파일로부터 추출한 DLL을 참조하는 방법
11638정성태8/2/2018202오류 유형: 473. windbg - 덤프 파일로부터 추출한 DLL 참조 시 "Resolved file has a bad image, no metadata, or is otherwise inaccessible." 빌드 오류
11637정성태8/1/2018113Graphics: 16. Unity - World matrix(unity_ObjectToWorld)로부터 TRS(이동/회전/크기) 행렬로 복원하는 방법파일 다운로드1
11636정성태8/1/2018114Graphics: 15. 3D 공간에서 두 점이 이루는 각도 구하기파일 다운로드1
11635정성태8/1/2018101오류 유형: 472. C# 컴파일 오류 - Your project is not referencing the ".NETFramework,Version=v3.5" framework.
11634정성태8/1/2018140.NET Framework: 790. .NET Thread 상태가 Cooperative일 때 GC hang 현상 재현 방법파일 다운로드1
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...