Network · 완벽 가이드 Ch.2 Section 2.2

TCP 3-way / 4-way Handshake — 완벽 가이드 Ch.2 Section 2

SYN → SYN-ACK → ACK로 연결을 수립하고, FIN → ACK → FIN → ACK로 종료합니다. 왜 3-way인지, TIME_WAIT이 왜 필요한지를 인터랙티브 시각화로 완전히 이해합니다.

2026년 3월 29일 · 약 13분 읽기

Q. "TCP 3-way handshake를 설명하고, 왜 2-way가 아닌지 말씀해주세요."

예상 꼬리질문

답변 가이드

"TCP는 데이터 전송 전 반드시 3-way handshake(SYN → SYN-ACK → ACK)를 수행하여 양측의 초기 시퀀스 번호(ISN)를 합의하고 연결을 수립합니다."

"2-way로는 충분하지 않은 이유는 half-open 연결 때문입니다. 세 번째 ACK로 서버는 클라이언트가 자신의 SYN-ACK를 수신했음을 확인합니다."

"연결 종료는 4-way handshake(FIN → ACK → FIN → ACK)가 필요합니다. TCP는 전이중(Full-Duplex) 방식이라 양방향 채널을 각각 독립적으로 닫아야 하기 때문입니다."

"마지막 ACK 이후 클라이언트는 TIME_WAIT 상태로 2*MSL(약 120초) 대기합니다. 마지막 ACK 유실 대비와 이전 연결의 지연 패킷 혼동 방지가 목적입니다."

인터넷 뱅킹에서 계좌 이체를 요청할 때, 당신의 브라우저와 은행 서버는 데이터를 주고받기 전에 먼저 악수를 합니다.

"나 지금 연결할 준비됐어." — SYN
"나도 준비됐어, 네가 준비됐다는 거 확인했어." — SYN-ACK
"나도 네가 준비됐다는 거 확인했어." — ACK

이 세 번의 교환이 TCP 3-way handshake입니다. 단순해 보이지만, 이 과정에는 네트워크 신뢰성의 핵심이 담겨 있습니다.

1. 3-way Handshake — 연결 수립의 3단계

꼬리질문: "3-way handshake 각 단계에서 주고받는 패킷을 설명해주세요"

TCP 연결을 수립하려면 클라이언트와 서버가 서로의 초기 시퀀스 번호(ISN, Initial Sequence Number)를 알아야 합니다. 시퀀스 번호는 데이터의 순서와 수신 확인에 사용되는 핵심 값입니다.

SYN 단계에서 클라이언트는 임의의 ISN을 생성합니다. ISN이 랜덤인 이유는 보안 때문입니다. 예측 가능한 ISN은 TCP Session Hijacking 공격에 취약합니다.

재생 버튼을 누르거나 단계 버튼을 클릭해 각 단계를 확인해 보세요.

재생 버튼을 누르거나 단계 버튼을 클릭해 각 단계를 확인하세요

C
ClientLISTEN
S
ServerLISTEN

2. 왜 2-way가 아닌 3-way인가?

꼬리질문: "왜 2-way handshake로는 안 되나요? half-open 연결이 무엇인가요?"

이 질문은 단순히 "규칙이 그래서"가 아니라, 무엇이 잘못될 수 있는지를 설명할 수 있어야 합니다.

2-way로 하면 SYN-ACK가 유실됐을 때 서버는 "연결이 수립됐다"고 판단하지만 클라이언트는 모르는 half-open 연결이 발생합니다. 세 번째 ACK가 이 문제를 해결합니다.

탭을 전환하며 2-way와 3-way의 차이를 확인해 보세요.

SYN-ACK가 유실되면 서버만 연결을 수립했다고 착각합니다

C
ClientLISTEN
S
ServerLISTEN

3-way가 필요한 이유 요약

양방향 ISN 검증

클라이언트가 서버 ISN을 ACK해야 양방향 신뢰성 보장

half-open 방지

세 번째 ACK로 서버가 클라이언트 수신 능력 확인

오래된 SYN 구분

이전 연결의 지연 SYN이 도달해도 안전하게 처리

3. 4-way Handshake — 연결 종료의 4단계

꼬리질문: "4-way handshake를 설명하고, 왜 3-way가 아닌지 말씀해주세요"

TCP는 전이중(Full-Duplex) 통신입니다. 클라이언트→서버, 서버→클라이언트 두 방향의 채널이 독립적으로 존재합니다. 연결을 끊을 때도 각 방향을 따로 닫아야 합니다.

연결 수립 시에는 서버의 SYN과 ACK를 하나로 합칠 수 있었지만, 연결 종료 시에는 합칠 수 없습니다. 서버가 클라이언트의 FIN을 받은 후에도 아직 보낼 데이터가 남아 있을 수 있기 때문입니다.

재생 버튼으로 4단계 흐름과 TIME_WAIT 타이머를 확인해 보세요.

TCP는 전이중(Full-Duplex) 방식 — 양방향 채널을 각각 독립적으로 닫아야 합니다

C
ClientESTABLISHED
S
ServerESTABLISHED

4. TIME_WAIT — 왜 즉시 닫지 않는가?

꼬리질문: "TIME_WAIT 상태에서 포트가 고갈되면 어떻게 해결하나요?"

마지막 ACK를 보낸 후 클라이언트는 즉시 포트를 닫지 않고 2*MSL(Maximum Segment Lifetime, 리눅스 기본값 60초 → 총 120초) 동안 대기합니다.

두 가지 이유가 있습니다. 첫째, 마지막 ACK가 유실될 경우 서버의 재전송 FIN을 처리하기 위해서입니다. 둘째, 이전 연결의 지연 패킷이 새 연결에 끼어드는 것을 방지하기 위해서입니다.

대용량 트래픽 서버에서 TIME_WAIT가 수만 개 쌓이면 포트 고갈이 발생할 수 있습니다. SO_REUSEADDR, tcp_tw_reuse, HTTP Keep-Alive로 해결합니다.

탭을 전환하며 TIME_WAIT가 필요한 두 가지 이유를 확인해 보세요.

마지막 ACK가 유실되면 서버의 재전송 FIN을 처리할 수 없습니다

2*MSL 타이머 (데모)2 × MSL = 약 120초

이 시간 동안 동일한 {IP:Port} 조합의 포트를 재사용할 수 없습니다

5. 비정상 종료 — RST 패킷

꼬리질문: "RST 패킷은 어떤 상황에서 발생하나요?"

FIN을 통한 정상 종료와 달리, RST(Reset) 패킷은 연결을 즉각 강제 종료합니다. 버퍼에 남은 데이터를 버리고 양측 모두 즉시 CLOSED 상태로 전환합니다.

TIME_WAIT 없이 즉각 종료되므로 포트 고갈 문제를 피할 수 있지만, 데이터 손실 위험이 있어 정상적인 상황에서는 사용하지 않습니다.

카드를 클릭해 각 시나리오의 패킷 흐름을 확인해 보세요.

카드를 클릭해 각 시나리오의 패킷 흐름을 확인하세요

Client→Server:SYN (port 99999)
Server→Client:RST← 해당 포트 없음

서버에 99999번 포트가 열려 있지 않습니다. OS가 즉시 RST로 응답하며 연결을 거부합니다. 포트 스캐닝 시 RST 응답으로 닫힌 포트를 구분합니다.

FIN vs RST 비교

구분FIN (정상 종료)RST (강제 종료)
종료 방식Graceful (정상)Abortive (강제)
버퍼 처리모두 전송 후 종료즉시 폐기
상대방 응답ACK 필요즉시 CLOSED
TIME_WAIT있음 (2*MSL)없음
패킷 수4개 (FIN, ACK, FIN, ACK)1개 (RST)
사용 상황정상적인 연결 종료오류·강제 종료·비정상

면접 체크리스트

이 항목들을 자신 있게 설명할 수 있다면 TCP Handshake 질문은 준비 완료입니다.

  • - 3-way handshake: SYN → SYN-ACK → ACK, 각 단계의 Seq/Ack 값 변화
  • - 2-way가 아닌 이유: half-open 연결 방지, 양방향 ISN 검증
  • - 4-way handshake: FIN → ACK → FIN → ACK, Half-Close 개념
  • - TIME_WAIT: 마지막 ACK 유실 대비 + 이전 패킷 혼동 방지, 2*MSL
  • - RST: 즉각 강제 종료, FIN과의 차이 (버퍼 처리, TIME_WAIT 없음)
  • - ISN 랜덤화: Session Hijacking 방지 (RFC 6528)

참고 자료

의견을 들려주세요

서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.

0 / 1000