TCP SACK(Selective Acknowledgment)란 무엇인가? 동작 방식과 핵심 이점
네트워크 통신 중 패킷 손실은 피할 수 없는 현상입니다. 하지만 손실이 발생했을 때, 이미 잘 도착한 데이터까지 다시 보내야 한다면 대역폭 낭비는 어마어마할 것입니다. 이러한 비효율을 해결하기 위해 등장한 TCP 옵션이 바로 SACK(선택적 확인 응답)입니다. 본 포스팅에서는 SACK가 어떤 방식으로 유실된 패킷만 ‘콕 집어서’ 재전송하게 만드는지 그 내부 메커니즘을 살펴보겠습니다.
1. 전통적인 누적 확인 응답(Cumulative ACK)의 한계
SACK가 없는 일반적인 TCP는 ‘누적 ACK’ 방식을 사용합니다.
- 수신 측은 ‘성공적으로 받은 연속된 마지막 바이트 + 1’의 번호를 ACK로 보냅니다.
- 예를 들어 패킷 1, 2, 3, 4, 5 중 2번이 유실되고 1, 3, 4, 5번이 도착했다면, 수신 측은 계속해서 ACK 2만 보낼 수밖에 없습니다.
- 송신 측은 수신 측이 3, 4, 5번을 받았는지 알 길이 없으므로, 2번부터 5번까지 모두 재전송하게 됩니다.
이는 고속 네트워크 환경에서 심각한 대역폭 낭비와 성능 저하를 초래합니다.
2. SACK의 동작 방식: “받은 것만 알려주기”
SACK 옵션(RFC 2018)이 활성화되면, 수신 측은 누적 ACK 번호와 별개로 이미 성공적으로 수신한 데이터 블록의 범위를 TCP 헤더 옵션 필드에 담아 보냅니다.
2.1 SACK 블록(SACK Blocks)의 구성
수신 측은 현재 비어있는 구간(Hole)을 제외하고, 성공적으로 도착한 불연속적인 데이터의 왼쪽 모서리(Left Edge)와 오른쪽 모서리(Right Edge) 시퀀스 번호를 기록합니다.
2.2 동작 시나리오
- 송신자가 패킷 1000~5000(1000단위)을 보냅니다.
- 2000번 패킷이 유실되고 1000, 3000, 4000, 5000번이 도착합니다.
- 수신자는 ACK 2000을 보내면서, SACK 옵션에 [3000-6000]이라는 정보를 추가합니다.
- 송신자는 ACK 2000을 보고 “2000번이 비었구나”라고 판단함과 동시에, SACK 정보를 보고 “3000~5000번은 잘 갔으니 2000번만 다시 보내면 되겠구나“라고 정확히 인지합니다.
3. SACK 사용 시 얻는 핵심 이점
| 비교 항목 | 기본 TCP (No SACK) | SACK 활성화 |
|---|---|---|
| 재전송 범위 | 유실된 패킷 이후 전체 | 유실된 특정 패킷만 |
| 대역폭 효율 | 낮음 (중복 데이터 전송) | 매우 높음 |
| 혼잡 제어 영향 | 불필요한 속도 저하 발생 가능 | 빠른 회복(Fast Recovery)과 결합 시 유리 |
| 복구 속도 | 느림 | 매우 빠름 |
4. SACK 활성화 조건 및 확인법
SACK는 송신 측과 수신 측 모두가 지원해야 작동합니다.
- 합의 단계: TCP 3-Way Handshake 시 ‘SACK-Permitted’ 옵션을 주고받으며 서로의 지원 여부를 확인합니다.
- OS 설정(Linux):
sysctl net.ipv4.tcp_sack값이 1이면 활성화된 상태입니다. - 분석 도구: Wireshark에서 패킷을 캡처한 후 TCP Options 필드에서
SACK혹은SLE(Left Edge),SRE(Right Edge)항목을 찾으면 실제 동작을 확인할 수 있습니다.
결론: 스마트한 재전송의 정점
TCP SACK는 네트워크의 불확실성 속에서 ‘지능적인 피드백’이 얼마나 큰 효율을 만드는지 보여주는 대표적인 사례입니다. 특히 2026년 현재처럼 무선 네트워크 사용이 빈번하고 대용량 데이터 전송이 일상화된 시대에 SACK는 선택이 아닌 필수입니다. 서버 엔지니어라면 불필요한 네트워크 비용을 줄이기 위해 SACK 옵션이 정상적으로 작동하고 있는지 반드시 점검해 보시기 바랍니다.
SACK 블록은 TCP 헤더 옵션 공간의 제한(40바이트) 때문에 최대 4개까지만 포함될 수 있습니다. 만약 패킷 유실이 그 이상으로 파편화되어 발생한다면 SACK만으로 해결이 어려울 수 있다는 점도 기억해 두면 좋습니다.