TCP 옵션 필드: 현대 네트워크의 성능을 결정짓는 Window Scaling과 SACK 분석

TCP 프로토콜이 설계된 초기 인터넷 환경과 기가비트 급 데이터가 오가는 현대의 네트워크 환경은 천양지차입니다. 기본 TCP 헤더 구조만으로는 고속 대역폭과 높은 지연 시간을 가진 환경(LFN)을 감당하기 어렵습니다. 이를 보완하기 위해 등장한 것이 바로 TCP 옵션 필드입니다. 그중에서도 네트워크 처리량과 신뢰성에 결정적인 영향을 미치는 Window Scaling과 SACK에 대해 완벽히 정리해 보겠습니다.

1. TCP Window Scaling (윈도우 스케일링)

1.1 왜 필요한가? (64KB의 한계)

기본 TCP 헤더에서 윈도우 크기(Window Size) 필드는 16비트로 할당되어 있습니다. 즉, 한 번에 확인할 응답(ACK) 없이 보낼 수 있는 최대 데이터 크기가 $2^{16} = 65,535$ 바이트(약 64KB)로 제한됩니다. 대역폭이 넓고 거리가 먼(RTT가 큰) 현대 네트워크에서 64KB는 너무나 작은 크기이며, 이는 전송 속도의 치명적인 병목 현상을 유발합니다.

1.2 동작 원리 (배수 시스템)

Window Scaling 옵션(RFC 1323)은 윈도우 크기에 ‘스케일 인자(Scale Factor)’를 도입하여 이 한계를 해결합니다.

• 3-Way Handshake 과정에서 서로 사용할 스케일 값을 합의합니다.
• 스케일 인자는 최대 14까지 설정 가능하며, 이는 윈도우 크기에 $2^{shift}$를 곱하는 방식입니다.
• 최대 설정 시 $65,535 \times 2^{14}$가 되어 약 1GB까지 윈도우 크기를 확장할 수 있습니다.

2. SACK (Selective Acknowledgement, 선택적 확인 응답)

2.1 왜 필요한가? (불필요한 재전송 방지)

전통적인 TCP 확인 응답 방식은 ‘누적 ACK’입니다. 예를 들어 1~10번 패킷 중 3번만 유실되고 나머지는 다 도착했더라도, 수신측은 “3번부터 다시 줘”라고만 말할 수 있습니다(ACK 3). 송신측은 이미 잘 도착한 4~10번까지 모두 다시 보내야 하는 대역폭 낭비가 발생합니다.

2.2 동작 원리 (콕 집어서 알려주기)

SACK 옵션(RFC 2018)은 수신측이 ‘이미 성공적으로 수신한 불연속적인 블록’의 범위를 송신측에 직접 알려줍니다.

• 송신측은 SACK 정보를 바탕으로 유실된 3번 패킷만 골라서 재전송합니다.
• 불필요한 재전송을 제거하여 네트워크 혼잡을 방지하고 빠른 복구가 가능해집니다.
• 특히 패킷 유실이 잦은 불안정한 무선망이나 초고속 망에서 성능 향상 폭이 매우 큽니다.

3. Window Scaling vs SACK 요약 비교

구분	Window Scaling	SACK
핵심 목적	전송 속도(Throughput) 향상	전송 신뢰성 및 효율성 향상
해결 문제	64KB라는 윈도우 크기 제약	패킷 유실 시 중복 재전송 문제
주요 대상	고대역폭, 고지연 네트워크(LFN)	패킷 손실이 빈번한 네트워크
합의 시점	3-Way Handshake (SYN)	3-Way Handshake (SYN)

4. 실무적인 설정 및 확인 방법

대부분의 현대 운영체제는 이 옵션들을 기본적으로 활성화하고 있습니다. 리눅스 환경에서의 확인 및 설정 방법은 다음과 같습니다.

• 확인: sysctl net.ipv4.tcp_window_scaling / sysctl net.ipv4.tcp_sack
• 설정: /etc/sysctl.conf 파일에서 값을 1(활성)로 설정 후 sysctl -p 적용
• 패킷 분석: Wireshark에서 SYN 패킷의 Options 필드를 열어 ‘Window scale’, ‘SACK permitted’ 항목을 직접 확인할 수 있습니다.

결론: 보이지 않는 헤더의 힘

TCP 옵션 필드는 단순한 부가 기능이 아닙니다. Window Scaling은 네트워크의 ‘파이프’를 넓히는 역할을 하고, SACK는 그 파이프 안에서 ‘손실된 조각’을 스마트하게 메우는 역할을 합니다. 이 두 옵션의 조화 덕분에 우리는 수천 킬로미터 떨어진 서버와도 기가비트 급의 고속 통신을 누릴 수 있는 것입니다. 서버 인프라를 최적화하고자 하는 엔지니어라면, 이 옵션들이 제대로 작동하고 있는지 점검하는 것부터 시작해 보시기 바랍니다.

가끔 구형 방화벽이나 로드밸런서가 이러한 TCP 옵션을 이해하지 못해 패킷을 드랍하거나 초기화하는 경우가 있습니다. 네트워크 트러블슈팅 시 중간 장비의 호환성을 반드시 체크해야 합니다.