코드로 재현하는 소켓 상태(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)]
위에서 소개된 상태 값들이 바로 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 상태가 아직 만료 시간이 지나지 않았어도 재활용 할 수 있도록 조치를 취한다고 합니다. (어느 문서였는지 기억이 안나서... 혹시 아시는 분 덧글 부탁드립니다.) (업데이트 2020-12-14:
C# - TIME_WAIT과 ephemeral port 재사용)
오히려 문제는 CLOSE_WAIT입니다. 이것은 상대방으로부터 close 소켓 신호를 받은 후, 자신도 close를 호출해야 하는데 그렇지 않고 넘어갔다거나 어떤 사유이던지 호출을 하지 않고 계속 소켓 자원을 보관하고 있는 것입니다. 즉 '재사용'이 불가능한 상태입니다.
그 외에, 때로는 아래의 상황처럼 래퍼 클래스의 사용을 잘못하는 경우에도 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
; https://social.msdn.microsoft.com/Forums/en-US/d20e5e67-d23c-42a5-95c5-ba80f4263546/keepalive-packets-continue-being-sent-after-client-closes-server-socket-is-closewait-client?forum=netfxnetcom
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]