TCP는 연결 지향 프로토콜이기 때문에 통신 전에 TCP 3-Way Handshake로 연결을 수립하고, 통신 종료 시에는 일반적으로 TCP 4-way handshake를 수행합니다.
TCP는 양방향 통신이므로 각 방향의 전송 종료를 독립적으로 확인합니다. 한쪽이 더 보낼 데이터가 없다고 FIN을 보내도 상대는 남은 데이터를 보낼 수 있어, 일반적인 종료 과정은 FIN → ACK → FIN → ACK로 설명합니다.
3-Way Handshake의 각 단계에서는 무엇을 주고받나요?
데이터가 없는 일반적인 연결 수립에서 클라이언트는 초기 시퀀스 번호 x를 담은 SYN을 보냅니다. 서버는 자신의 초기 번호 y와 ACK=x+1을 담은 SYN+ACK를 보내고, 클라이언트가 ACK=y+1을 보내 서버의 SYN을 확인합니다. SYN은 시퀀스 공간을 1만큼 사용합니다.
왜 SYN과 SYN+ACK 두 번만으로 연결을 수립하지 않나요?
서버도 자신의 SYN이 상대에게 도착했는지 확인해야 하기 때문입니다. 마지막 ACK로 양쪽 초기 시퀀스 번호의 교환을 확인하며, 과거 연결의 지연된 SYN을 새 연결로 오인하는 문제도 줄입니다.
4-Way Handshake에서 FIN과 ACK는 각각 무엇을 의미하나요?
FIN은 해당 방향으로 더 보낼 데이터가 없다는 뜻이고, ACK는 상대의 FIN을 받았다는 확인입니다. FIN을 받은 쪽도 아직 보낼 데이터가 있으면 계속 전송한 뒤 자신의 FIN을 보낼 수 있습니다.
연결 종료는 반드시 네 번의 패킷으로 이루어지나요?
아닙니다. 상대가 바로 종료할 준비가 되어 있으면 FIN에 대한 ACK와 자신의 FIN을 한 세그먼트에 보낼 수 있습니다. 네 번이라는 숫자보다 양방향 종료를 각각 확인한다는 원리가 중요합니다.
종료 후 TIME_WAIT은 왜 필요하며 어느 쪽에 생기나요?
일반적인 종료에서는 먼저 FIN을 보낸 쪽이 상대 FIN에 마지막 ACK를 보낸 뒤 TIME_WAIT에 들어갑니다. 마지막 ACK가 유실되어 FIN이 재전송되면 다시 ACK할 수 있어야 하고, 이전 연결의 지연된 세그먼트가 새 연결에 섞이는 것도 방지해야 합니다. 전통적인 대기 기준은 2MSL이며, 클라이언트에만 생기는 상태는 아닙니다. RFC 1337의 TIME_WAIT 설명
CLOSE_WAIT과 TIME_WAIT은 어떻게 다르며, CLOSE_WAIT이 계속 쌓이면 무엇을 확인하나요?
CLOSE_WAIT은 상대의 FIN을 받고 로컬 애플리케이션의 종료를 기다리는 상태입니다. TIME_WAIT은 종료 확인 뒤 일정 시간 남는 상태입니다. CLOSE_WAIT이 계속 누적되면 소켓·응답 스트림의 close 누락이나 처리가 끝나지 않는 코드부터 확인합니다.
서버가 갑자기 종료되거나 네트워크가 끊겨도 FIN을 주고받나요?
항상 그렇지는 않습니다. 상황에 따라 RST로 연결이 중단되거나 아무 종료 신호도 도착하지 않을 수 있습니다. 조용한 단절은 재전송 실패, timeout, TCP Keepalive나 애플리케이션 heartbeat 등으로 감지합니다.