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)
11757정성태10/19/201820개발 환경 구성: 416. Visual Studio 2017을 이용한 아두이노 프로그램 개발(및 디버깅)
11756정성태10/19/201810오류 유형: 500. Visual Studio Code의 아두이노 프로그램 개발 시 인텔리센스가 안 된다면?
11755정성태10/19/201812오류 유형: 499. Visual Studio Code extension for Arduino - #include errors detected.
11754정성태10/19/201814개발 환경 구성: 415. Visual Studio Code를 이용한 아두이노 프로그램 개발 - 새 프로젝트
11753정성태10/19/201844개발 환경 구성: 414. Visual Studio Code를 이용한 아두이노 프로그램 개발
11752정성태10/18/201826오류 유형: 498. SQL 서버 - Database source is not a supported version of SQL Server
11751정성태10/18/201831오류 유형: 497. Visual Studio 실행 시 그래픽이 투명해진다거나, 깨진다면?
11750정성태10/18/201826오류 유형: 496. 비주얼 스튜디오 - One or more projects in the solution were not loaded correctly.
11749정성태10/18/201873개발 환경 구성: 413. 비주얼 스튜디오에서 작성한 프로그램을 빌드하는 가장 쉬운 방법
11748정성태10/18/201822개발 환경 구성: 412. Arduino IDE를 Store App으로 설치한 경우 컴파일만 되고 배포가 안 되는 문제
11747정성태10/17/201890.NET Framework: 799. C# - DLL에도 EXE처럼 Main 메서드를 넣어 실행할 수 있도록 만드는 방법파일 다운로드1
11746정성태10/15/201852개발 환경 구성: 411. Bitvise SSH Client의 인증서 모드에서 자동 로그인 방법파일 다운로드1
11745정성태10/15/201867오류 유형: 495. TFS 파일/폴더 삭제 - The item [...] could not be found in your workspace, or you do not have permission to access it.
11744정성태10/15/201844개발 환경 구성: 410. msbuild로 .pubxml 설정에 따른 배포 파일을 만드는 방법
11743정성태10/15/201855웹: 37. Bootstrap의 dl/dt/dd 조합에서 문자열이 잘리지 않도록 CSS 설정
11742정성태10/15/201853스크립트: 13. 윈도우 배치(Batch) 스크립트에서 날짜/시간 문자열을 구하는 방법
11741정성태10/15/201847Phone: 13. Android - LinearLayout 간략 설명
11740정성태10/15/201878사물인터넷: 51. Synology NAS(DS216+II)를 이용한 원격 컴퓨터의 전원 스위치 제어
11739정성태10/15/201853Windows: 151. 윈도우 10의 전원 관리가 "균형 조정(Balanced)"으로 바뀌는 문제
11738정성태10/15/201844오류 유형: 494. docker - 윈도우에서 실행 시 "unknown shorthand flag" 오류
11737정성태10/13/201864오류 유형: 493. Azure Kudu - There are 395 items in this directory, but maxViewItems is set to 299
11736정성태10/12/201875오류 유형: 492. Visual Studio 로딩 시 오류 - The 'Scc Display Information' package did not load correctly.
11735정성태10/12/201891VS.NET IDE: 129. Visual Studio - 특정 문자(열)를 개행 문자로 바꾸는 방법
11734정성태10/10/2018173Linux: 4. Synology NAS(DS216+II)에 FTDI 장치 연결 후 C#(.NET Core)으로 DTR 제어파일 다운로드1
11733정성태10/11/2018178Linux: 3. Synology NAS(DS216+II)에서 FTDI 장치를 C/C++로 제어
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...