TCP 연결 수립과 종료: SYN·FIN 상태 전이 이해하기

TCP의 신뢰성은 연결 상태를 관리하는 데서 시작된다

TCP는 전송 계층에서 동작하는 연결 지향 프로토콜이다. 데이터의 순서와 전달 신뢰성을 보장하고, 흐름 제어·혼잡 제어·오류 검출 및 복구 기능을 제공한다.

이 특성은 데이터를 보내기 전 연결을 만들고, 통신이 끝난 뒤 연결을 안전하게 닫는 절차 위에서 구현된다. 연결 수립에는 3-way handshake가, 종료에는 4-way handshake가 사용된다.

SYN과 ACK로 통신 준비 상태를 맞추는 과정

클라이언트와 서버는 연결을 열기 전에 서로가 데이터를 주고받을 수 있는지 확인하고 초기 시퀀스 번호를 교환한다.

⤢✕

클라이언트는 SYN 플래그를 1로 설정하고 초기 시퀀스 번호(ISN)를 무작위로 정해 서버로 보낸다. 이때 클라이언트 상태는 SYN_SENT가 된다.

서버는 요청을 수락하면 SYN과 ACK 플래그를 모두 1로 설정한다. 서버의 ISN은 y로 설정하고, ACK 번호에는 클라이언트 ISN에 1을 더한 x+1을 넣는다. 서버는 이 단계에서 SYN_RECEIVED 상태가 된다.

클라이언트는 서버의 응답을 확인하는 ACK를 보낸다. ACK 번호는 y+1, 시퀀스 번호는 x+1이며, 교환이 끝나면 양측은 ESTABLISHED 상태가 된다.

이 절차는 양방향 통신을 열고, 시퀀스 번호 동기화를 통해 데이터 무결성을 관리할 기준을 마련한다. 연결 당사자의 준비 상태를 확인하고 네트워크 자원을 활용하는 출발점이기도 하다.

종료 신호는 양쪽 방향에서 따로 처리된다

TCP는 양방향 데이터 흐름을 독립적으로 닫기 때문에 연결 종료가 수립보다 길어진다.

⤢✕

클라이언트가 FIN 플래그를 1로 설정해 종료를 요청하면 상태는 FIN_WAIT_1이 된다. 서버는 ACK로 이를 확인하고 CLOSE_WAIT 상태로 전환한다. 클라이언트는 ACK를 받은 뒤 FIN_WAIT_2 상태가 된다.

서버는 남은 데이터 전송을 마친 뒤 FIN을 보내고 LAST_ACK 상태가 된다. 마지막으로 클라이언트가 ACK를 전송하면 서버는 CLOSED 상태가 된다. 클라이언트는 TIME_WAIT에서 일정 시간 대기한 뒤 CLOSED로 전환한다.

TIME_WAIT는 지연된 패킷이 뒤늦게 도착해도 처리할 수 있게 한다. 일반적으로 MSL(Maximum Segment Lifetime)의 2배 시간인 약 2분 동안 유지되며, 네트워크 리소스 정리와 동일 소켓 사용 시 충돌 방지에도 관여한다.

웹과 API 통신에서 보이는 연결 제어

웹 브라우징에서는 브라우저가 웹 서버와 연결을 수립한 뒤 HTTP 요청과 응답을 교환하고, 페이지 로드가 끝나면 연결을 종료한다.

REST API 호출도 같은 흐름을 따른다. 클라이언트 애플리케이션이 API 서버와 연결을 만든 뒤 요청과 응답을 처리하고, 통신이 끝난 뒤 연결을 닫는다.

연결 수립 단계에서 발생하는 보안 문제

SYN Flooding은 공격자가 다수의 SYN 패킷을 보낸 뒤 ACK를 회신하지 않는 방식이다. 서버의 연결 큐가 포화되면 정상적인 연결 요청을 처리하지 못할 수 있다. SYN 쿠키, 방화벽 설정, 연결 타임아웃 조정이 대응책으로 사용된다.

TCP Session Hijacking은 이미 수립된 세션을 가로채는 공격이다. 시퀀스 번호를 예측해 통신 세션에 악성 패킷을 삽입하는 방식이며, TLS/SSL 사용과 시퀀스 번호 무작위화가 대응에 활용된다.

성능과 환경에 따라 달라지는 선택

TCP Fast Open(TFO)은 반복 연결에서 연결 수립 과정을 최적화한다. 첫 번째 SYN 패킷에 데이터를 포함해 왕복 시간(RTT)을 줄이며, HTTPS와 같은 암호화된 연결에서는 제한적으로 사용된다.

양쪽이 동시에 FIN을 보내는 경우에는 일반적인 종료 흐름보다 단순화된 과정이 나타날 수 있다.

⤢✕

위성 통신처럼 지연이 큰 환경에서는 handshake 자체가 성능에 큰 영향을 준다. window size 증가와 keepalive 타이머 최적화 같은 TCP 매개변수 조정으로 성능 향상을 고려할 수 있다.

모바일 네트워크에서는 배터리 소모와 데이터 사용량을 줄이기 위한 연결 관리가 중요하다. 연결 풀링(connection pooling)과 지속 연결(persistent connections)이 이 목적에 사용된다.

TCP 이후의 연결 프로토콜

QUIC은 Google이 개발한 UDP 기반 전송 프로토콜이다. 0-RTT 연결 설정을 통해 기존 TCP handshake보다 효율적으로 동작하며, HTTP/3의 기반 기술로 채택되어 웹 성능 향상에 기여한다.

TCP도 BBR(Bottleneck Bandwidth and Round-trip propagation time) 같은 혼잡 제어 알고리즘과 머신러닝 기반 네트워크 최적화 기술을 받아들이며 발전하고 있다. IoT, 5G 네트워크 등 새로운 환경에 맞춘 프로토콜 확장도 이어지고 있다.