TCP Fast Open(TFO)은 어떤 왕복 시간을 줄이는가
TCP Fast Open은 서버 쿠키를 얻은 뒤 다음 연결의 SYN에 데이터를 실어 한 번의 RTT를 줄일 수 있습니다. 단, 실험 RFC의 기능·재전송·보안 한계를 함께 설명합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
TCP Fast Open(TFO)은 TCP의 초기 연결 구간에 애플리케이션 데이터를 실어 보낼 수 있도록 설계된 방식입니다. IETF RFC 7413은 이 방식이 적합한 경우 기존 3-way handshake 뒤에 보내던 데이터를 더 일찍 전송해 최대 한 번의 왕복 시간(RTT)을 아낄 수 있다고 설명합니다. 그러나 RFC는 Experimental 분류이며 인터넷 표준 트랙 문서가 아닙니다. 모든 연결에서 지연이 줄거나 서버가 항상 데이터를 즉시 처리한다고 보장하지 않습니다.
일반 TCP와 TFO의 차이
보통 TCP에서는 클라이언트가 SYN을 보내고 서버의 SYN-ACK을 받은 뒤 ACK를 보내 연결을 성립시킵니다. 그 이후 애플리케이션 데이터가 전달됩니다. 짧은 요청에서는 연결을 여는 데 필요한 한 번의 RTT가 전체 응답 대기에서 큰 비중을 차지할 수 있습니다. TFO는 이미 유효한 서버 쿠키를 가진 클라이언트가 데이터와 쿠키를 함께 SYN에 담아 보내고, 서버가 이를 받아들이면 handshake가 끝나기 전에 응답을 보낼 수 있도록 합니다.
이는 RTT를 없애는 새로운 전송 계층 전체가 아니라 TCP 초기 교환에서 데이터 시점을 앞당기는 최적화입니다. RFC 초록은 조건이 맞을 때 표준 TCP보다 최대 한 RTT를 절약할 수 있다고 표현합니다. 실제 체감은 연결 재사용 여부, 요청 크기, 네트워크 경로, 서버 지원과 중간 장비 동작에 달려 있습니다. 이후의 통신은 정상 TCP 연결처럼 이어집니다.
쿠키는 첫 연결에서 받고 다음 연결에 재사용한다
첫 TFO 시도 전에는 클라이언트가 빈 쿠키 옵션을 담은 SYN을 보내 쿠키를 요청합니다. 서버가 지원하면 SYN-ACK의 Fast Open 옵션으로 쿠키를 돌려줍니다. 클라이언트는 이를 보관하고 다음 연결에서 SYN과 함께 보냅니다. 서버가 쿠키를 검증하면 SYN 안의 데이터가 애플리케이션에 전달될 수 있고, 응답도 handshake가 끝나기 전에 시작될 수 있습니다.
따라서 새 서버에 처음 연결할 때마다 곧바로 한 RTT가 절약되는 것은 아닙니다. 쿠키 발급용 첫 왕복이 필요하고, 쿠키는 서버가 만료시킬 수 있습니다. 작은 요청이 SYN에 들어맞는지도 중요합니다. 데이터가 확인되지 않거나 Fast Open 옵션이 경로에서 처리되지 않으면 클라이언트는 ACK에서 데이터를 다시 보내거나 일반 handshake로 전환할 수 있습니다. RFC는 cookie 요청의 실패·시간초과 경로를 기록하고 같은 경로에서 무한 재시도하지 않도록 설계합니다.
애플리케이션은 재전송 가능성을 견뎌야 한다
SYN의 데이터는 연결이 완전히 성립하기 전에 서버 애플리케이션에 도달할 수 있습니다. 중복 SYN이나 재전송 등 드문 상황에서는 애플리케이션이 같은 초기 데이터를 두 번 받을 가능성이 생깁니다. RFC는 이 의미 변화와 데이터 재생 가능성을 명시하고, 중복 실행을 견딜 수 없는 작업에는 TFO를 사용하지 말라고 주의를 줍니다.
예를 들어 읽기 요청처럼 반복돼도 결과가 크게 달라지지 않는 작업과, 중복 처리 시 결제·주문이 두 번 일어날 수 있는 작업은 위험이 다릅니다. 요청 처리를 멱등하게 설계하거나 중복 판별을 하는 것은 애플리케이션 책임입니다. “handshake보다 먼저 보낸다”는 장점만 보고 모든 요청 데이터를 허용해서는 안 됩니다.
서버 설정·경로 호환성과 보안 한계
RFC 7413은 TFO를 기본으로 무조건 켜지 말고 애플리케이션이 서비스 포트별로 명시적으로 요청하도록 규정합니다. 서버는 쿠키를 검증하고 대기 중인 Fast Open 요청의 수를 제한해야 합니다. 유효한 쿠키가 있어도 SYN 데이터 처리는 CPU·메모리 자원을 소비할 수 있어, 과도한 요청은 자원 고갈 위험을 만듭니다. 제한을 넘으면 서버는 새 TFO 요청을 일시적으로 일반 TCP로 낮춰 서비스의 기본 연결을 유지할 수 있습니다.
방화벽, NAT, 로드밸런서 등 중간 장비가 SYN 옵션이나 SYN 데이터를 버릴 수도 있습니다. 이런 경로에서는 이득이 사라지거나 재전송 지연이 생길 수 있습니다. 초기 혼잡 창과 패킷 크기도 실제 전송에 영향을 줍니다. 적용 전에는 대상 네트워크와 서버에서 호환성·장애 동작을 확인해야 합니다.
전문가 관점: 프로토콜 설계와 운영 상태를 구분
IETF의 RFC 7413은 2014년 12월 문서로, 쿠키 교환, 데이터 수락, 재생 가능성, 자원 제한과 fallback을 규정하는 Experimental 프로토콜 설명입니다. LWN의 2012년 기술 기사는 당시 리눅스 구현 흐름과 API를 설명하는 역사적 맥락 자료로 읽었습니다. 그 글의 2012년 배포 현황을 오늘날 모든 운영체제의 지원 상태로 인용하지 않습니다. 실제 도입 여부는 현재 사용하는 커널·라이브러리·서버의 문서와 측정으로 확인해야 합니다.
요약하면 TFO는 재방문 경로에서 적합한 작은 요청의 첫 데이터 시점을 당길 수 있지만, 프로토콜 상태·요청의 재실행 안전성·경로 호환성을 함께 시험해야 하는 선택적 최적화입니다.