슬라이딩 윈도우편집자 확인

윈도우 크기는 슬라이딩 윈도우 프로토콜의 핵심 매개변수로, 송신 측이 확인 응답을 기다리지 않고 한 번에 전송할 수 있는 데이터의 최대 양을 정의한다. 이 크기는 바이트 단위로 표현되며, 수신자의 버퍼 상태와 네트워크 상황에 따라 동적으로 변할 수 있다. 윈도우 크기는 흐름 제어의 기본 메커니즘으로 작동하여, 빠른 송신자가 느린 수신자를 압도하는 것을 방지한다.

흐름 제어는 수신 측의 처리 능력을 고려한 데이터 전송률 조절 과정이다. 수신 측은 자신의 수신 버퍼에 남아 있는 가용 공간을 TCP 헤더의 '윈도우 크기' 필드에 담아 확인응답 세그먼트와 함께 송신 측에 알린다. 송신 측은 이 공지된 윈도우 크기 내에서만 새로운 데이터를 전송할 수 있다. 이를 통해 수신 버퍼가 가득 차서 데이터가 손실되는 오버플로우 상황을 예방한다.

윈도우 크기는 고정되지 않고 통신 과정에서 지속적으로 조정된다. 수신 애플리케이션이 버퍼의 데이터를 읽어 처리하면 가용 공간이 늘어나고, 이는 이후의 확인응답을 통해 송신 측에 새로운 윈도우 업데이트로 전달된다. 반대로 버퍼가 거의 가득 차면 윈도우 크기는 줄어들어 송신률을 낮춘다. 극단적으로 가용 공간이 0바이트가 되면 제로 윈도우 상태가 되어 송신이 일시 중단된다.

따라서 윈도우 크기와 흐름 제어는 단순한 전송 제한이 아니라, 수신자의 상태에 기반한 적응형 제어 시스템이다. 이는 신뢰성 있는 데이터 전송을 보장하면서도 링크 대역폭을 효율적으로 활용할 수 있는 기반을 제공한다.

시퀀스 번호는 TCP 세그먼트 내 데이터의 각 바이트에 할당된 고유한 식별자이다. 송신 측은 데이터를 보낼 때 각 세그먼트의 헤더에 해당 세그먼트 첫 번째 데이터 바이트의 시퀀스 번호를 기록한다. 이를 통해 수신 측은 분할되어 도착하거나 순서가 바뀐 세그먼트도 올바른 순서로 재조립할 수 있다.

확인 응답 번호는 수신 측이 성공적으로 수신한 데이터의 다음 바이트 위치를 알려주는 피드백 메커니즘이다. 예를 들어, 수신 측이 시퀀스 번호 1000으로 시작하는 500바이트의 데이터를 정상 수신했다면, 확인 응답 번호 1500을 송신 측에 보낸다. 이는 "1500번 바이트까지 정상 수신했으니, 다음에는 1500번 바이트부터 보내라"는 의미이다.

시퀀스 번호와 확인 응답 번호는 슬라이딩 윈도우의 동작을 가능하게 하는 핵심 요소이다. 송신 측은 확인 응답을 받은 데이터는 윈도우에서 벗어난 것으로 간주하고 윈도우를 앞으로 이동시켜 새로운 데이터를 전송할 수 있다. 이 과정에서 데이터의 누락이나 중복 없이 신뢰성 있는 전송이 보장된다.

이러한 번호 체계는 3-way handshake 과정에서 초기 시퀀스 번호가 교환되며 설정된다. 또한, 확인 응답은 별도의 ACK 세그먼트로 보낼 수도 있고, 데이터를 실어 보내는 세그먼트에 함께 실어 보낼 수도 있다[1].

TCP 연결에서 데이터 흐름을 관리하는 두 가지 핵심적인 윈도우가 존재한다. 바로 송신 윈도우와 수신 윈도우이다. 이 두 윈도우는 서로 독립적으로 운영되며, 수신자의 처리 능력과 네트워크 상태에 따라 동적으로 변화한다.

송신 윈도우는 송신 측이 확인 응답을 기다리지 않고 한 번에 전송할 수 있는 데이터의 양을 정의한다. 이 윈도우 내의 데이터는 세그먼트로 나누어 전송되며, 윈도우의 시작점은 이미 확인 응답을 받은 데이터의 시퀀스 번호이다. 윈도우의 끝점은 시작점에 윈도우 크기를 더한 값으로, 이 범위를 벗어난 데이터는 아직 전송할 수 없다. 송신 윈도우의 크기는 수신 윈도우의 크기와 혼잡 윈도우의 크기 중 더 작은 값에 의해 결정된다[2].

수신 윈도우는 수신 측의 TCP 버퍼에 남아 있는 가용 공간을 바이트 단위로 나타낸다. 이 값은 수신 측이 송신 측에게 정기적으로 알려주며, TCP 헤더의 '윈도우 크기' 필드를 통해 전달된다. 수신 애플리케이션이 버퍼에서 데이터를 읽어가면 가용 공간이 늘어나고, 이에 따라 수신 윈도우의 크기도 커진다. 반대로 데이터가 도착하여 버퍼에 쌓이면 윈도우 크기는 줄어든다. 수신 윈도우의 주요 목적은 수신자의 처리 속도보다 빠르게 데이터가 도착하여 버퍼가 오버플로우되는 것을 방지하는 것이다.

두 윈도우의 관계는 다음과 같이 요약할 수 있다.

송신자는 수신자로부터 받은 최신의 수신 윈도우 크기 값을 바탕으로 자신의 송신 윈도우를 조정한다. 따라서 효율적인 데이터 전송을 위해서는 수신자가 적시에 윈도우 업데이트 메시지를 보내 가용 공간을 알려주는 것이 중요하다.

송신자는 시퀀스 번호를 기준으로 송신 윈도우 내에 있는 데이터를 전송할 수 있다. 윈도우는 이미 전송되었지만 확인 응답을 받지 못한 데이터와 아직 전송되지 않은 데이터를 포함한다.

수신자가 데이터를 성공적으로 수신하고 처리하면, 확인 응답 번호와 함께 새로운 수신 윈도우 크기를 담은 ACK 세그먼트를 보낸다. 확인 응답 번호는 다음으로 기대하는 시퀀스 번호를 나타내며, 이 번호까지의 모든 데이터가 정상 수신되었음을 의미한다. 송신자는 이 확인 응답 번호를 받으면, 윈도우의 시작 경계를 해당 번호로 이동시킨다. 이로 인해 확인 응답된 데이터는 윈도우에서 벗어나고, 새로운 공간이 윈도우에 추가되어 추가 데이터 전송이 가능해진다. 이 과정을 '윈도우가 슬라이딩(미끄러지듯 이동)한다'고 표현한다.

윈도우 슬라이딩 과정은 수신자의 처리 능력에 따라 동적으로 조절된다. 수신자의 버퍼 여유 공간이 줄어들어 윈도우 크기가 작아지면, 송신자는 그에 맞춰 전송 속도를 늦춘다. 반대로 수신 버퍼에 공간이 생겨 윈도우 크기가 커지면, 송신자는 더 많은 데이터를 연속적으로 전송할 수 있다. 이는 흐름 제어의 핵심 메커니즘이 된다.

이러한 슬라이딩 과정을 통해, TCP는 한 번에 여러 세그먼트를 전송하고 확인 응답을 기다리지 않고도 지속적인 데이터 전송을 가능하게 하여 네트워크 활용도를 극대화한다.

혼잡 윈도우는 네트워크 혼잡을 제어하기 위해 송신 측이 유지하는 또 다른 가변 크기의 윈도우이다. 이 윈도우의 크기는 수신 윈도우와 함께 실제 데이터 전송량을 결정하는 핵심 요소가 된다. 송신 측은 수신 측이 통지한 수신 윈도우 크기와 자신이 추정한 혼잡 윈도우 크기 중 더 작은 값만큼만 데이터를 전송할 수 있다[5].

혼잡 윈도우의 크기는 네트워크 상태에 따라 동적으로 변화한다. 초기에는 작은 값(보통 1개의 MSS 크기)에서 시작하여, 패킷 손실 없이 확인 응답이 성공적으로 돌아올 때마다 지수적으로 증가한다. 이 단계를 슬로우 스타트라고 부른다. 혼잡 윈도우가 특정 임계값에 도달하면, 증가 속도가 선형적으로 바뀌는 혼잡 회피 단계로 진입한다.

패킷 손실이 발생하면, 이는 네트워크 혼잡의 신호로 해석된다. 타임아웃이 발생하거나 중복 ACK가 연속으로 수신되면, 송신 측은 혼잡 윈도우 크기를 급격히 줄인다. 이후 새로운 슬로우 스타트나 혼잡 회피 단계를 시작하여 네트워크에 다시 적응한다. 이 동적 조정 메커니즘을 통해 TCP는 네트워크 자원을 공정하게 공유하면서도 높은 처리량을 유지할 수 있다.

혼잡 윈도우는 네트워크의 혼잡 상태를 추정하여 동적으로 결정되는 송신 측의 윈도우 크기이다. 송신자는 수신자로부터 통지된 수신 윈도우 크기와 자신이 계산한 혼잡 윈도우 크기 중 더 작은 값을 실제 사용 가능한 윈도우 크기로 삼는다. 이는 수신자의 처리 능력과 네트워크 경로의 수용 능력을 모두 고려하여 데이터 전송 속도를 조절하기 위함이다.

슬로우 스타트는 TCP 연결이 시작되거나 타임아웃으로 인한 패킷 손실이 발생한 후에 적용되는 알고리즘이다. 초기 혼잡 윈도우 크기는 보통 1개의 MSS로 설정된다. 송신자는 매 확인 응답을 정상적으로 수신할 때마다 혼잡 윈도우 크기를 지수적으로 증가시킨다. 구체적으로, 매 RTT마다 윈도우 크기가 두 배가 된다. 이 과정은 윈도우 크기가 사전에 설정된 슬로우 스타트 임계값에 도달하거나 패킷 손실이 감지될 때까지 계속된다.

혼잡 회피 단계는 슬로우 스타트 임계값에 도달한 후 시작된다. 이 단계에서는 더 이상 지수적 증가를 하지 않고, 매 RTT마다 혼잡 윈도우 크기를 선형적으로 1 MSS만큼 증가시킨다. 이는 네트워크가 포화 상태에 가까워졌을 때 과도한 패킷 전송으로 인한 혼잡을 예방하기 위한 조심스러운 접근 방식이다. 만약 패킷 손실이 발생하면, 송신자는 슬로우 스타트 임계값을 현재 혼잡 윈도우 크기의 절반으로 낮추고, 다시 슬로우 스타트 단계부터 전송을 재개한다.

TCP 헤더의 윈도우 크기 필드는 16비트로 구성되어 있으며, 수신 호스트가 현재 수용할 수 있는 데이터의 양을 바이트 단위로 송신 호스트에게 알리는 역할을 한다. 이 값은 확인 응답 번호 필드와 함께 사용되어, 수신 측이 다음에 받기를 기대하는 데이터의 시작 지점과 함께 현재의 수신 버퍼 여유 공간을 명시한다. 필드의 최대값은 2^16 - 1인 65,535바이트로, 이는 초기 TCP 설계에서의 한계였다.

이 16비트 제한은 고대역폭·고지연 네트워크 환경에서 성능 병목 현상을 초래할 수 있다. 예를 들어, RTT가 100ms이고 윈도우 크기가 65,535바이트인 경우, 이론적 최대 처리량은 초당 약 5.2Mbps로 제한된다[7]. 현대 네트워크는 기가비트 수준의 대역폭을 가지므로, 이 제한을 극복하기 위한 확장 메커니즘이 필요하게 되었다.

이 필드의 값은 흐름 제어의 핵심 변수로 동적으로 변한다. 수신 애플리케이션이 데이터를 소비하여 버퍼 공간이 생기면, 수신 측은 ACK 세그먼트를 보낼 때 이 윈도우 크기 필드의 값을 증가시켜 새로운 여유 공간을 알린다. 반대로 버퍼가 가득 차면 윈도우 크기는 0이 되어 송신을 일시 중지시킨다. 이 동적 조정을 통해 빠른 송신자가 느린 수신자를 압도하는 것을 방지한다.

TCP 연결에서 수신 측은 자신의 수신 버퍼에 남은 공간을 윈도우 크기 필드로 알려 송신 측의 데이터 전송 속도를 조절한다. 이때 수신 버퍼에 가용 공간이 없는 상태, 즉 윈도우 크기가 0이 된 상황을 제로 윈도우라고 한다. 제로 윈도우 상태에서는 송신 측이 새로운 데이터를 보낼 수 없으며, 전송을 일시 중지한다.

송신 측은 제로 윈도우 상태에서도 주기적으로 제로 윈도우 프로브라는 작은 세그먼트를 보내 수신 측의 버퍼 상태를 확인한다. 이 프로브 패킷은 1바이트의 새 데이터를 포함하거나, 순번이 재전송되는 데이터일 수 있다. 수신 측은 여전히 버퍼 공간이 없으면 윈도우 크기 0으로 다시 응답한다. 가용 공간이 생기면, 수신 측은 윈도우 업데이트 세그먼트를 보내 새로운 윈도우 크기를 알린다. 윈도우 업데이트는 확인응답(ACK) 번호가 이전과 동일하고, 데이터를 수반하지 않는 순수한 ACK 세그먼트로 전송된다.

이 메커니즘은 수신 측의 처리 능력을 초과하는 데이터 전송으로 인한 버퍼 오버플로우를 방지한다. 또한, 수신 측이 윈도우 업데이트 패킷을 분실했을 경우를 대비해, 송신 측은 이후에 도착하는 데이터에 대한 일반적인 ACK를 통해도 간접적으로 윈도우가 열렸음을 감지하고 전송을 재개할 수 있다.

TCP 헤더의 윈도우 크기 필드는 16비트로, 최대 윈도우 크기를 65,535바이트(64KB)로 제한한다. 고속 네트워크 환경에서 이 제한은 대역폭 지연 곱을 충분히 활용하지 못해 성능 병목 현상을 초래할 수 있다. 윈도우 스케일링 옵션은 이 문제를 해결하기 위해 RFC 1323에서 정의된 TCP 옵션이다.

이 옵션은 TCP 3방향 핸드셰이크 과정에서 협상된다. SYN 세그먼트에 윈도우 스케일링 옵션을 포함시켜 송신 가능한 윈도우 크기의 스케일링 계수(shift count)를 제안한다. 상대방이 이를 수용하는 SYN-ACK 세그먼트로 응답하면, 실제 윈도우 크기는 '헤더의 윈도우 크기 필드 값 * 2^스케일링 계수'로 계산된다. 스케일링 계수는 최대 14까지 가능하여, 이론상 최대 윈도우 크기는 약 1GB(65,535 * 2^14)까지 확장된다.

윈도우 스케일링의 적용은 TCP 타임스탬프 옵션과 함께 고속 장거리 네트워크에서 특히 중요하다. 이를 통해 롱 패턴 네트워크에서도 송신 측이 수신 측의 처리 능력을 초과하지 않으면서 링크의 대역폭을 효율적으로 채울 수 있다. 대부분의 현대 운영체제는 기본적으로 이 기능을 지원하거나 활성화한다.

선택적 확인응답은 TCP의 슬라이딩 윈도우 프로토콜 성능을 향상시키기 위한 중요한 확장 옵션이다. 기존의 누적 확인응답 방식은 수신자가 연속된 데이터의 마지막 바이트만을 확인응답 번호로 알려주기 때문에, 일부 세그먼트가 손실되면 그 이후의 올바르게 수신된 세그먼트들도 모두 재전송 대상이 되는 문제가 있었다. SACK은 이 비효율성을 해결하기 위해 수신자가 손실된 구간을 제외하고 실제로 수신에 성공한 데이터 블록의 정보를 송신자에게 추가로 알려주는 메커니즘이다.

SACK 옵션은 TCP 헤더의 옵션 필드를 사용하며, 수신자는 ACK 세그먼트에 SACK 옵션을 포함시켜 송신자에게 전달한다. 이 옵션에는 하나 이상의 SACK 블록이 포함되며, 각 블록은 수신된 데이터의 시작과 끝 시퀀스 번호를 쌍으로 나타낸다. 예를 들어, 수신자가 시퀀스 번호 1000-1999, 3000-3999의 데이터는 받았지만 중간의 2000-2999 구간은 손실된 경우, SACK 옵션을 통해 1000-1999와 3000-3999 블록을 알린다. 이를 통해 송신자는 손실된 2000-2999 구간만을 선택적으로 재전송할 수 있다.

SACK의 동작은 다음과 같은 절차로 이루어진다.

1. 연결 설정 단계에서 양측 호스트는 TCP 헤더의 옵션을 통해 SACK 허용(SACK-Permitted) 옵션을 교환하여 SACK 사용을 협상한다.

2. 데이터 전송 중 수신 측은 누적 확인응답 번호(ACK 번호)와 함께, 수신된 불연속 데이터 블록에 대한 SACK 정보를 포함시킨다.

3. 송신 측은 이 SACK 정보를 바탕으로 자신의 송신 버퍼를 관리하며, 손실로 판단된 데이터 세그먼트만을 재전송한다.

SACK의 도입은 네트워크 혼잡 상황에서 특히 효과적이다. 여러 세그먼트가 연속적으로 손실되더라도 수신자는 각각의 수신된 데이터 블록을 정확히 보고할 수 있으므로, 송신자는 한 번의 왕복 시간(RTT) 내에 여러 손실을 한꺼번에 복구할 가능성이 높아진다. 이는 빠른 재전송 및 빠른 회복 알고리즘과 결합될 때 전체적인 혼잡 제어의 효율성을 크게 높인다. 그러나 SACK 옵션은 TCP 헤더의 길이를 증가시키며, 모든 TCP 구현체가 이를 지원하는 것은 아니다.