TCP 연결 과정: 3-Way & 4-Way Handshake

3-Way Handshake

상태	설명
LISTENING	서버가 클라이언트 요청을 기다리는 중
SYN_SENT	클라이언트가 서버에 연결 요청(SYN)을 보낸 상태
SYN_RECEIVED	서버가 클라이언트의 SYN 요청을 받고 SYN-ACK를 보낸 상태
ESTABLISHED	서버와 클라이언트가 정상적으로 연결됨, 통신 중

 

4-Way Handshake

FIN_WAIT_1	클라이언트가 연결 종료 요청(FIN)을 보냈고, 서버의 응답을 기다리는 중
CLOSE_WAIT	서버가 클라이언트의 종료 요청을 받았지만, 아직 완전히 닫지 않음
FIN_WAIT_2	클라이언트가 ACK까지 보냈지만, 서버가 아직 닫지 않음
LAST_ACK	서버가 마지막 FIN을 보냈고, 클라이언트의 ACK을 기다리는 중
TIME_WAIT	클라이언트가 연결을 닫았지만, 일정 시간 동안 잔여 패킷이 있는지 확인 중
CLOSED	TCP 연결이 완전히 종료된 상태

 

 

🔍 FIN_WAIT_2 상태란?

FIN_WAIT_2는 TCP 연결 종료 과정에서 클라이언트(또는 서버)가 연결을 닫으려고 하지만, 상대방이 FIN 패킷을 보내지 않은 상태를 의미합니다.

즉, 내가(FIN 보낸 측) 종료하겠다고 했는데, 상대방이 아직 닫지 않고 있는 상태입니다.

---

🔥 FIN_WAIT_2 상태가 발생하는 과정 (TCP 종료 과정)

1️⃣ 클라이언트가 서버에 FIN(연결 종료 요청) 패킷을 보냄 → FIN_WAIT_1 상태로 전환
2️⃣ 서버가 ACK(승인) 패킷을 클라이언트에 보냄 → FIN_WAIT_2 상태로 전환
3️⃣ 이후 서버가 FIN을 보내면, 클라이언트는 TIME_WAIT으로 이동 후 종료됨
❌ 그런데 서버가 FIN을 안 보내면? FIN_WAIT_2 상태에서 계속 대기하게 됨

---

✅ FIN_WAIT_2 상태가 오래 지속되는 이유

• 서버가 소켓을 닫지 않고 유지 중
  → 서버 측 코드에서 close() 또는 shutdown()을 호출하지 않음
• 서버가 비정상 종료되었거나, 네트워크 이슈
  → 프로세스가 죽었지만, OS가 연결을 유지하려고 할 수 있음
• 클라이언트가 SO_LINGER 설정으로 즉시 종료되지 않음
  → 클라이언트가 SO_LINGER를 비활성화하면 FIN_WAIT_2가 오래 지속될 가능성이 있음

---

 

netstat -ano | findstr :포트번호

위 명령어를 쓰면 IP와 연결 상태들이 나온다.

exe 실행 파일을 만들면서 이것의 중요성에 대해 확실히 알게 되었다.