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)
11622정성태7/23/20181271개발 환경 구성: 388. Windows 환경에서 Octave 패키지 설치하는 방법
11621정성태7/23/20181006VC++: 127. 멤버 함수에 대한 포인터를 외부에서 호출하는 방법파일 다운로드1
11620정성태8/3/20181457Graphics: 11. Unity로 실습하는 Shader (7) - Blur (평균값, 가우스, 중간값) 필터파일 다운로드1
11619정성태7/21/20181083Graphics: 10. Unity로 실습하는 Shader (6) - Mosaic Shading
11618정성태7/20/20181091개발 환경 구성: 387. 삼성 오디세이(Odyssey) 노트북의 운영체제를 새로 설치하는 방법
11617정성태7/20/2018927Team Foundation Server: 50. TFS 소스 코드 관리 기능 (5) - "Rollback", "Rollback Entire Changeset"
11616정성태7/17/2018987Graphics: 9. Unity Shader - 전역 변수의 초기화
11615정성태7/17/20181206.NET Framework: 788. RawInput을 이용한 키보드/마우스 입력 모니터링파일 다운로드1
11614정성태7/20/20181524Graphics: 8. Unity Shader - Texture의 UV 좌표에 대응하는 Pixel 좌표
11613정성태7/17/20181090Graphics: 7. Unity로 실습하는 Shader (5) - Flat Shading
11612정성태7/16/2018990Windows: 148. Windows - Raw Input의 Top level collection 의미
11611정성태8/3/20181191Graphics: 6. Unity로 실습하는 Shader (4) - 퐁 셰이딩(phong shading)
11610정성태8/3/20181001Graphics: 5. Unity로 실습하는 Shader (3) - 고로 셰이딩(gouraud shading) + 퐁 모델(Phong model) + Texture
11609정성태8/3/20181271Graphics: 4. Unity로 실습하는 Shader (2) - 고로 셰이딩(gouraud shading) + 퐁 모델(Phong model)
11608정성태7/17/20182022Graphics: 3. Unity로 실습하는 Shader (1) - 컬러 반전 및 상하/좌우 뒤집기
11607정성태8/30/20181677Graphics: 2. Unity로 실습하는 Shader
11606정성태8/14/20181843사물인터넷: 19. PC에 연결해 동작하는 자신만의 USB 장치 만들어 보기파일 다운로드1
11605정성태8/9/20181256사물인터넷: 18. New NodeMcu v3 아두이노 호환 보드의 내장 LED 및 입력 핀 사용법파일 다운로드1
11604정성태7/12/20181197Math: 47. GeoGebra 기하 (24) - 정다각형파일 다운로드1
11603정성태7/12/20181017Math: 46. GeoGebra 기하 (23) - sqrt(n) 제곱근파일 다운로드1
11602정성태7/11/20181030Math: 45. GeoGebra 기하 (22) - 반전기하학의 원에 관한 반사변환파일 다운로드1
11601정성태7/11/20181167Math: 44. GeoGebra 기하 (21) - 반전기하학의 직선 및 원에 관한 반사변환파일 다운로드1
11600정성태7/10/20181377Math: 43. GeoGebra 기하 (20) - 세 점을 지나는 원파일 다운로드1
11599정성태7/10/20181082Math: 42. GeoGebra 기하 (19) - 두 원의 안과 밖으로 접하는 직선파일 다운로드1
11598정성태7/10/2018920Windows: 147. 시스템 복구 디스크를 USB 디스크에 만드는 방법
11597정성태8/9/20181099사물인터넷: 17. Thinary Electronic - ATmega328PB 아두이노 호환 보드의 개발 환경 구성
1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...