핵심 인사이트 (3줄 요약)

  1. 본질: TIME_WAIT은 클라이언트가 4-Way Handshake의 마지막 대답(ACK)을 쏜 뒤에 컴퓨터 세션(소켓)을 바로 삭제하지 않고, 보통 1분에서 2분 동안 허공을 멍하니 쳐다보며 그 번호(포트)를 유지한 채 억지로 버티고 있는 최후의 보류 상태다.
  2. 목적 1 (마지막 ACK의 유실 대비): 내가 쏜 마지막 인사(ACK)가 중간에 짤려서 서버에 안 닿았다면, 서버는 "내 찐막 인사(FIN) 못 들었나?" 하고 FIN을 계속 재전송하며 죽지 못해 괴로워한다. 클라이언트가 바로 죽지 않고 TIME_WAIT으로 버티고 있어야 이 재전송된 FIN을 받고 다시 ACK를 쏴주어 서버를 편안하게 승천(CLOSED)시킬 수 있다.
  3. 목적 2 (지연 패킷 찌꺼기 처리): 방금 전 세션에서 바다를 맴돌던 지연 패킷 찌꺼기가 한발 늦게 도착했을 때, 내가 똑같은 포트 번호로 완전히 새로운 연결을 맺고 있으면 찌꺼기 패킷이 새 게임에 섞여 화면이 깨진다. TIME_WAIT은 이 낡은 포트 번호를 당분간 남들이 못 쓰게 꽉 묶어두어 과거의 망령(유령 패킷)이 새 생명에 씌이는 것을 원천 차단한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

  • 개념: TCP 세션의 연결 해제(Active Close)를 먼저 요청한 쪽이, 최종 ACK를 전송한 후 소켓 자원을 해제하기 전 2 MSL (Maximum Segment Lifetime, 보통 1~2분) 동안 유지하는 대기 상태.

  • 필요성: 클라이언트가 "오케이 잘 가!(ACK)" 하고 1초 만에 창을 꺼버렸다 치자. 문제 1. 그 마지막 ACK가 해저 케이블에서 유실됐다. 서버는 영원히 LAST_ACK 상태로 기다리며 램(RAM)을 갉아먹는 좀비가 된다. 문제 2. 클라이언트가 0.1초 만에 방금 썼던 50000번 포트로 새 접속을 열었다. 그런데 10초 전에 보냈다가 늦게 도착한 과거의 찌꺼기 패킷이 50000번 포트로 밀려 들어온다. 데이터가 완전히 짬뽕되어 깨진다. "야! 먼저 끊자고 한 놈이 끝까지 책임을 져라! 네가 마지막 인사 날렸다고 바로 퇴근하지 말고, 상대방이 확실히 셔터 내렸는지, 그리고 도로 위에 남아있는 찌꺼기 차들이 완전히 다 지나가서 사라질 때까지 문 앞에 서서 무조건 1분 이상 망봐!!!"

  • 💡 비유: TIME_WAIT은 퇴사하는 직원의 **"1달간의 인수인계 대기 기간"**과 같습니다.

    • 내가 사직서(FIN)를 냈고, 회사도 승인(FIN)했고, 나도 마지막 서명(ACK)을 했습니다.
    • 하지만 내일부터 바로 전화기를 꺼버리는 게 아닙니다. 혹시 회사가 내 마지막 서명 서류를 잃어버려서 다시 보내라고 연락 올까 봐, 또는 예전에 내가 시켜둔 택배가 뒤늦게 회사로 날아와서 엉뚱한 후임자(새 포트 할당자)가 뜯어볼까 봐, 한 달 동안은 내 자리(포트)를 아무도 못 쓰게 비워두고 혹시 모를 뒷수습을 챙겨주는 책임감 있는 유예 기간입니다.

📢 섹션 요약 비유: TIME_WAIT은 폭파 스위치를 누른 뒤 **"안전 구역에서 1분간 폭발을 눈으로 확인하는 깐깐한 폭파범"**입니다. 내가 누른 스위치(ACK)가 불발이 나서 폭탄(서버)이 안 터졌으면 다시 눌러줘야 하고, 혹시 날아오는 파편(유령 패킷)이 있으면 무사히 다 떨어질 때까지 가드 올리고 버티는 필수 대기 시간입니다.

Ⅱ. TIME_WAIT의 2대 생존 메커니즘과 실무 트러블슈팅 (Deep Dive)

1. 왜 하필 2 MSL 인가? (시간의 근거)

  • MSL (Maximum Segment Lifetime): 인터넷상에서 TCP 패킷 한 놈이 살아서 뺑뺑이를 돌 수 있는 물리적 최대 수명. (라우터의 TTL 값 등을 고려해 보통 30초~1분으로 규정).
  • 왜 곱하기 2인가?: 서버가 나한테 FIN을 보내느라 걸리는 최대 시간 1MSL + 내가 다시 서버한테 ACK를 보내느라 걸리는 최대 시간 1MSL = 도합 2 MSL (보통 60초 ~ 120초) 동안 넉넉하게 대기해야 어떤 불상사도 막을 수 있다고 설계자들(IETF)이 계산했다.
 ┌─────────────────────────────────────────────────────────────┐
 │                서버의 구원자: TIME_WAIT의 마지막 ACK 재전송         │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 나 (Active Close) ]                          [ 서버 ]      │
 │    (TIME_WAIT 상태 진입)                                      │
 │        │ ── (마지막 찐막 ACK 발송!) ─(해저 컷!)─▶ ❌ 닿지 않음!  │
 │        │                                         (LAST_ACK) │
 │        │                                                    │
 │        │ ◀── "야! 네 마지막 인사 안 왔어 다시 줘!" [FIN 재전송] ── │
 │                                                             │
 │   * 만약 내가 TIME_WAIT 안 하고 꺼졌다면?                       │
 │     서버는 대답을 평생 못 듣고 LAST_ACK 좀비로 서버 메모리 폭발함!     │
 │                                                             │
 │   * TIME_WAIT으로 멍때리고 있던 나:                             │
 │     "어이구, 아까 내 인사가 증발했구나. 옛다 다시 받아라!"           │
 │        │ ── (마지막 ACK를 다시 쏴줌!!) ───────▶ (서버 CLOSED) │
 └─────────────────────────────────────────────────────────────┘

2. 실무 대참사 (TIME_WAIT 소켓 고갈)

실무 백엔드 개발자나 인프라 엔지니어를 가장 괴롭히는 지독한 장애다.

  • 회사 웹서버의 부하를 막으려고 앞단에 Nginx 리버스 프록시나 L4 로드밸런서를 뒀다.
  • 이 Nginx 장비는 클라이언트와 통신이 끝나면 자기가 먼저 연결을 툭툭 끊는다(Active Close).
  • 초당 1만 명의 접속을 끊어버린다.
  • Nginx 장비(리눅스) 안에 TIME_WAIT 상태에 빠져서 1분 동안 소멸하지 않고 버티는 소켓(포트)이 6만 개를 꽉 채워버린다!
  • 결과: OS가 쓸 수 있는 16비트 포트 번호(65,535개)가 전부 TIME_WAIT 찌꺼기로 가득 차 버려서, 6만 1번째로 들어오는 찐 손님을 받을 빈 포트 구멍이 없어 서버 접속이 통째로 뻗어버리는 대형 사고(Port Exhaustion)가 터진다.

3. 해결책 꼼수 (커널 파라미터 튜닝)

이 찌꺼기를 치우기 위해 리눅스 갓(God) 엔지니어들은 커널 설정(sysctl)을 건드린다.

  • net.ipv4.tcp_tw_reuse = 1: "야, TIME_WAIT으로 1분 동안 놀리고 있는 포트 아깝다! 혹시 급하게 통신 들어오면 그 TIME_WAIT 포트 뺏어서 재활용(Reuse)해 버려!"
  • 이렇게 세팅하면 포트 고갈을 극적으로 막고 초당 수만 건의 접속을 처리할 수 있다. (하지만 유령 패킷이 섞일 부작용 리스크가 미세하게 있으므로 주의해서 써야 한다).

📢 섹션 요약 비유: 실무에서의 TIME_WAIT 포트 고갈은, 카페(서버)에서 커피 다 마시고 나간 손님들이 "혹시 일행이 늦게 올까 봐" 빈자리에 가방(TIME_WAIT)을 1시간 동안 올려두고 가서, 정작 문밖에 줄 서 있는 진짜 새 손님들이 앉을 의자(포트)가 1개도 남아있지 않은 미칠 듯한 병목 현상입니다. 직원이 가방을 억지로 치우는 게(Reuse 튜닝) 현실적인 해결책입니다.