문제 상황

문제

한정된 수의 port를 사용할 수 있는 client에서 일정 시간이 지난 후에 더 이상 통신을 하지 않는 현상이 발견됨.

분석

# netstat -ano | find "<server_port>" (windows)

>netstat -ano | find "11111"
	프로토콜  	로컬 주소            	외부 주소               		상태
    TCP    		127.0.0.1:11111      	 127.0.0.1:53481        	FIN_WAIT_2      28360
	TCP    		127.0.0.1:53481       	 127.0.0.1:11111        	CLOSE_WAIT      6160

해석

해설: Client는 CLOSE_WAIT상태다.

원인 분석

TCP/IP 통신에서 LOSE_WAIT 다음과 같은 경우다.
TCP/IP 통신의 종료 시점에 두 peer는 각각 active closer와 passive closer로 나뉜다. active closer는 FIN을 먼저 보내는 쪽이고, passive closer는 FIN을 받고, ACK를 보내는 쪽이다.

즉, client가 LOSE_WAIT상태에서 대기 중이라는 것은 server가 tcp 통신을 먼저 종료(FIN을 보냄)하고, client에서 그 요청에 대해 ACK를 전달하였으나, 이후 FIN을 전달하지 않았다는 뜻이다.

재현

CLOSE_WAIT을 임의로 재현하는 코드는 다음과 같다.

Server

# server
import socket

def start_server():
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.bind(('127.0.0.1', 11111))
    server.listen(5)
    print("Server started. Waiting for connections...")
    conn, addr = server.accept()
    print(f"Connection from {addr} established!")
    data = conn.recv(1024)
    print("Received:", data.decode())
    conn.shutdown(socket.SHUT_RDWR)  # Send FIN
    conn.close()
    print("Server connection closed")

if __name__ == "__main__":
    start_server()

server는 recv() 이후 연결을 끊는다.

Client

# client
import socket
import time

def start_client():
    client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    client.connect(('127.0.0.1', 11111))
    client.sendall(b'Hello, Server!')
    time.sleep(10)
    client.close()

if __name__ == "__main__":
    start_client()

client는 sendall() 이후 sleep()하여 process를 block된 상태로 둔다.

결과

wireshark - No. 24 이후 CLOSE_WAIT에서 대기하던 client가 NO. 34에서 FIN을 보내고 TCP/IP 통신을 종료

No. 34까지 10초 가량의 딜레이가 있는데, 이는 테스트 코드의 client가 10초 동안 sleep하기 때문이다.

No. 24 직후 netstat 기록

>netstat -ano | find "11111"
프로토콜  	로컬 주소          		   외부 주소               상태
	TCP    		127.0.0.1:11111        127.0.0.1:53481        FIN_WAIT_2      28360
  	TCP    		127.0.0.1:53481        127.0.0.1:11111        CLOSE_WAIT      6160

No 34 이후 netstat 기록

>netstat -ano | find "11111"
  	프로토콜  		로컬 주소           	   외부 주소               상태
    TCP  		 	127.0.0.1:11111        127.0.0.1:53481        TIME_WAIT       0

Kernel의 동작

1. 위 테스트 코드에서 client는 senall()을 호출한 후, sleep()을 호출한다. 그 상태에서 server는 shutdown()에 의해 active closer로서 FIN을 보낸다.
2. FIN을 받은 client의 kernel은 해당 TCP 연결이 정상이기에 이에 대해 ACK를 보낸다. 이후 kernel은 socket의 상태를 변경하고 (예: socket.recv() returns EOF), 이를 확인한 client가 socket.close()를 호출하기를 기다려 FIN을 보낸다.
3. 이 테스트 코드에서 client는 sleep()을 호출하고 10초 후에 socket.close()를 호출한다. 따라서 이 사이에 해당 socket은 CLOSE_WAIT 상태로 대기한다.

CLOSE_WAIT의 문제점

CLOSE_WAIT의 문제는 timeout이 없다는 점이다. 위 예시에서 active closer의 FIN에 대한 passive closer의 ACK를 받은 active closer는 FIN_WAIT2 상태가 된다. FIN_WAIT2는 linux에서 tcp_fin_timeout으로 timeout이 정해져 있어 server에서 해당 문제가 반복되더라도 port가 고갈되는 일은 발생하지 않는다. 하지만 CLOSE_WAIT은 timeout이 없어 그 상태로 무한히 대기한다.

CLOSE_WAIT의 해결 방법

1. 식상한 말이지만, 리소스 관리를 잘 하자. socket도 리소스다. 이 문제는 socket 리소스를 점유한 상태에서 해제하지 않았기에 생긴 문제다.