문서의 각 단락이 어느 리비전에서 마지막으로 수정되었는지 확인할 수 있습니다. 왼쪽의 정보 칩을 통해 작성자와 수정 시점을 파악하세요.

흐름 제어 기법 | |
분류 | |
목적 | 데이터 흐름의 효율적 관리 및 네트워크 혼잡 방지 |
주요 방식 | |
관련 계층 | |
핵심 개념 | 윈도우 크기, ACK (확인 응답), 버퍼 관리 |
상세 정보 | |
정의 | 송신자와 수신자 간의 데이터 전송 속도를 조절하여 수신자의 처리 능력을 초과하지 않도록 하는 기법 |
필요성 | |
정지-대기 (Stop-and-Wait) | |
슬라이딩 윈도우 (Sliding Window) | 수신자의 윈도우 크기 내에서 여러 프레임을 연속적으로 전송하여 효율성을 높인 방식 |
신호 기반 흐름 제어 | 수신자가 XON/XOFF 등의 제어 신호를 보내 흐름을 제어하는 방식 |
구현 예시 | TCP (전송 제어 프로토콜)의 혼잡 제어 및 흐름 제어 메커니즘 |
관련 프로토콜 | |
버퍼링 역할 | 수신 측 버퍼가 가득 차면 송신을 일시 중지하도록 신호 전달 |
혼잡 제어와의 차이 | 흐름 제어는 '점대점' 수신자 문제, 혼잡 제어는 '네트워크 전체'의 트래픽 과부하 문제 해결 |

흐름 제어는 데이터 통신에서 송신 측이 수신 측의 처리 능력을 초과하는 속도로 데이터를 전송하지 않도록 조절하는 메커니즘이다. 이 기법은 주로 OSI 모델의 전송 계층이나 데이터 링크 계층에서 구현되며, 신뢰성 있는 데이터 전달을 보장하는 핵심 요소 중 하나이다.
흐름 제어의 기본 목적은 수신자의 버퍼 오버플로를 방지하는 것이다. 송신자가 너무 빠른 속도로 데이터를 보내면, 수신자의 버퍼가 가득 차 추가 데이터를 수용할 수 없게 된다. 이로 인해 데이터 손실이 발생하고, 불필요한 재전송이 증가하며, 전체 네트워크 효율이 저하된다. 흐름 제어는 이러한 문제를 사전에 예방한다.
주요 흐름 제어 방식에는 정지-대기 프로토콜과 슬라이딩 윈도우 프로토콜이 있다. 정지-대기 방식은 한 번에 하나의 데이터 프레임만 전송하고 확인 응답을 기다리는 단순한 방법이다. 반면, 슬라이딩 윈도우 방식은 확인 응답을 기다리지 않고 여러 프레임을 연속적으로 전송할 수 있어 효율성이 높다. 슬라이딩 윈도우는 다시 Go-Back-N ARQ와 선택적 재전송 ARQ로 세분화된다.
흐름 제어는 네트워크의 혼잡 제어와 밀접한 관련이 있지만, 서로 다른 문제를 해결한다. 흐름 제어가 송신자와 수신자 간의 속도 불일치(점대점 문제)를 다룬다면, 혼잡 제어는 네트워크 전체의 트래픽 과부하 문제를 관리한다. 현대의 TCP/IP 프로토콜 스택에서는 TCP가 수신 윈도우 필드를 통해 흐름 제어를 수행하며, 이는 슬라이딩 윈도우 원리를 기반으로 한다.

데이터 통신에서 흐름 제어는 송신자가 수신자보다 빠른 속도로 데이터를 전송하여 수신자의 버퍼가 오버플로우되는 것을 방지하는 메커니즘이다. 수신자의 처리 능력이나 버퍼 공간을 초과하는 데이터 전송은 패킷 손실을 초래하고, 이는 결국 불필요한 재전송을 유발하여 네트워크 효율을 저하시킨다. 따라서 흐름 제어는 데이터가 안정적이고 효율적으로 전달될 수 있도록 송신 측과 수신 측 간의 데이터 전송 속도를 조절하는 역할을 한다.
흐름 제어의 주요 목표는 수신자의 처리 능력에 맞춰 송신 속도를 조절하여 패킷 손실을 방지하는 것이다. 이는 수신 측의 버퍼 오버플로우를 막고, 네트워크 자원의 낭비를 줄이며, 전체적인 데이터 전송의 신뢰성을 높인다. 또한, 송신자와 수신자 간의 속도 불일치로 인한 문제를 해결함으로써 데이터 링크 계층이나 전송 계층에서 안정적인 전이중 통신을 가능하게 한다.
흐름 제어는 혼잡 제어와 구분되는 개념이다. 흐름 제어가 송신자와 수신자 두 종단 시스템 간의 속도 조절에 초점을 맞춘다면, 혼잡 제어는 네트워크 전체의 트래픽 과부하를 관리하는 데 목적이 있다. 두 메커니즘은 종종 함께 작동하여 네트워크 성능을 최적화한다. 효과적인 흐름 제어는 처리율을 향상시키고 지연을 줄이며, TCP와 같은 프로토콜에서 데이터 전송의 효율성을 보장하는 핵심 요소가 된다.

정지-대기 프로토콜은 가장 기본적인 형태의 흐름 제어 기법이다. 송신 측이 하나의 데이터 프레임을 전송한 후, 수신 측으로부터 해당 프레임에 대한 긍정 응답 신호를 기다리는 방식으로 동작한다. 응답을 받기 전까지는 다음 프레임을 전송하지 않고 정지 상태로 대기한다. 만약 사전에 설정된 시간 내에 응답이 도착하지 않거나, 수신 측에서 오류를 감지하여 부정 응답 신호를 보내면, 송신 측은 동일한 프레임을 다시 재전송한다.
이 프로토콜의 동작 과정은 다음과 같은 단계로 이루어진다.
1. 송신 측이 프레임 0을 전송한다.
2. 송신 측은 프레임 0에 대한 응답을 기다리며 대기한다.
3. 수신 측이 프레임 0을 오류 없이 수신하면, 긍정 응답 신호를 송신 측으로 보낸다.
4. 송신 측이 긍정 응답을 받으면, 다음 프레임인 프레임 1을 전송한다.
5. 만약 프레임에 오류가 있거나 응답이 손실되면, 송신 측은 타임아웃 후 프레임 0을 재전송한다.
정지-대기 프로토콜의 주요 특징은 구현이 단순하고, 수신 측의 버퍼 요구사항이 최소화된다는 점이다. 수신 측은 한 번에 하나의 프레임만 처리하면 되므로 복잡한 버퍼 관리가 필요하지 않다. 그러나 매 프레임마다 응답을 기다려야 하기 때문에 전송 효율이 매우 낮다는 근본적인 단점을 가진다. 특히 전송 지연이 큰 광역 통신망에서는 채널 이용률이 현저히 떨어진다.
장점 | 단점 |
|---|---|
구현이 매우 간단하다. | 전송 효율이 낮다. |
수신 측 버퍼가 하나만 필요하다. | 긴 전송 지연 시 채널 이용률이 급격히 감소한다. |
신뢰적인 데이터 전송을 보장한다. | 대역폭을 효율적으로 사용하지 못한다. |
이러한 비효율성 때문에 정지-대기 프로토콜은 현대의 고속 네트워크에서는 거의 사용되지 않는다. 그러나 그 개념은 더 발전된 슬라이딩 윈도우 프로토콜의 기초를 이루며, 교육적 목적으로 흐름 제어와 오류 제어의 기본 원리를 설명하는 데 자주 활용된다.

슬라이딩 윈도우 프로토콜은 정지-대기 프로토콜의 비효율성을 극복하기 위해 개발된 효율적인 흐름 제어 방식이다. 송신 측이 수신 측의 확인응답을 기다리지 않고, 미리 정의된 윈도우 크기만큼의 여러 프레임을 연속적으로 전송할 수 있게 한다. 이 윈도우는 송신 버퍼에서 전송 가능하거나 전송 대기 중인 프레임들의 범위를 정의하며, 확인응답을 받은 프레임에 따라 윈도우가 '슬라이드'하여 앞으로 이동한다. 이 방식은 링크의 대역폭을 더 효율적으로 활용하여 전송 지연을 줄이고 처리량을 크게 향상시킨다.
슬라이딩 윈도우 프로토콜의 핵심 매커니즘은 윈도우의 관리에 있다. 송신 측은 윈도우 내의 프레임들을 순차적으로 전송하고, 수신 측은 올바르게 수신된 프레임에 대해 확인응답을 보낸다. 수신 측의 확인응답을 받으면, 송신 측은 윈도우를 해당 프레임 수만큼 앞으로 이동시켜 새로운 프레임을 전송할 수 있는 공간을 만든다. 수신 측 역시 자신의 수신 윈도우를 유지하여, 어떤 순서의 프레임을 수신할 준비가 되어 있는지를 송신 측에 알린다. 이 과정에서 오류가 발생한 프레임을 처리하는 방식에 따라 주로 두 가지 변형 프로토콜이 사용된다.
프로토콜 | 오류 처리 방식 | 특징 |
|---|---|---|
오류 발생 지점부터 모든 프레임 재전송 | 구현이 간단하지만, 오류 시 효율이 떨어짐 | |
오류난 특정 프레임만 선택적 재전송 | 효율적이지만, 버퍼 관리와 구현이 복잡함 |
이 표와 같이, Go-Back-N ARQ는 오류가 발생한 프레임 이후에 전송된 모든 프레임을 다시 보내는 방식이다. 반면, 선택적 재전송 ARQ는 오류가 발생한 특정 프레임만을 선택적으로 재전송 요청한다. 선택적 재전송은 네트워크 효율성은 높지만, 수신 측에서 프레임들을 순서대로 재조립하기 위한 별도의 버퍼와 로직이 필요하여 구현 복잡도가 증가한다. 두 방식 모두 슬라이딩 윈도우의 기본 원리를 바탕으로 하여, 단일 프레임씩 전송하는 방식보다 우수한 성능을 제공한다.
Go-Back-N ARQ는 슬라이딩 윈도우 프로토콜의 한 방식으로, 송신자가 오류가 발생한 프레임부터 이후 모든 프레임을 재전송하는 방법을 사용한다. 이 기법에서 송신자는 수신자의 긍정응답을 기다리지 않고 송신 윈도우 크기만큼 연속적으로 프레임을 전송할 수 있다. 수신자는 순서대로 도착한 프레임만을 정상적으로 수신하며, 순서가 틀어지거나 오류가 발생한 프레임이 도착하면 그 이후의 모든 프레임을 폐기한다.
수신 측은 오류를 감지하면 마지막으로 정상 수신한 프레임 번호에 대한 부정응답을 보내거나, 일정 시간 동안 응답이 없을 경우 타임아웃이 발생한다. 송신 측은 부정응답을 받거나 타임아웃이 발생하면, 해당 프레임 번호부터 현재 송신 윈도우 내의 모든 프레임을 다시 전송한다. 예를 들어, 송신 윈도우 크기가 4이고, 프레임 2에서 오류가 발생했다면, 송신자는 프레임 2, 3, 4, 5를 모두 재전송한다.
이 방식의 주요 특징과 장단점은 다음과 같다.
특징 | 설명 |
|---|---|
구현 복잡도 | 수신 측의 버퍼 관리가 간단하다. 순차적인 수신만을 요구하기 때문이다. |
대역폭 효율성 | 오류 발생 시 불필요한 재전송이 많아질 수 있어, 선로 지연이 크거나 오류율이 높은 환경에서는 효율이 떨어진다. |
적용 환경 | 비교적 낮은 오류율과 짧은 지연을 가진 네트워크에 적합하다. |
Go-Back-N ARQ는 정지-대기 프로토콜에 비해 전송 효율이 높지만, 선택적 재전송 방식에 비해는 불필요한 재전송으로 인해 효율이 낮을 수 있다. 따라서 이 방식은 수신 측의 구현을 단순화하는 대신, 네트워크 자원을 추가로 소모할 수 있는 트레이드오프를 가진다.
선택적 재전송 ARQ는 슬라이딩 윈도우 프로토콜의 한 방식으로, 오류가 발생한 프레임만을 선택적으로 재전송하는 기법이다. 이 방식은 Go-Back-N ARQ와 달리 수신 측이 순서에 맞지 않게 도착한 정상적인 프레임들을 버리지 않고 버퍼에 임시 저장한다. 송신 측은 부정 응답(NAK)을 받거나 타임아웃이 발생한 특정 프레임만을 재전송한다. 모든 정상 수신된 프레임에 대해 긍정 응답(ACK)을 보내며, 누적 확인 응답 방식을 사용할 수도 있다.
이 방식의 핵심은 수신 측이 프레임의 순서를 재배열할 수 있는 버퍼를 갖는다는 점이다. 예를 들어, 송신 윈도우 크기가 5이고 1, 2, 3, 4, 5번 프레임을 전송했을 때 3번 프레임에 오류가 발생했다고 가정하자. 수신 측은 1, 2번 프레임은 정상 수신하여 ACK를 보내고, 4, 5번 프레임도 정상 수신하지만 순서 번호가 맞지 않으므로 버퍼에 저장한다. 송신 측은 3번 프레임에 대한 NAK 또는 타임아웃을 통해 3번만 재전송한다. 3번 프레임이 정상 수신되면, 수신 측은 버퍼에 있던 4, 5번 프레임과 함께 상위 계층에 순서대로 전달한다.
선택적 재전송의 장단점은 다음과 같이 정리할 수 있다.
장점 | 단점 |
|---|---|
오류가 발생한 프레임만 재전송하므로 대역폭 활용도가 높다. | 수신 측이 순서 재배열을 위한 버퍼 관리가 필요하여 구현이 복잡하다. |
정상 수신된 후속 프레임을 버리지 않아 전송 효율이 우수하다. | 각 프레임에 대한 개별적인 확인 응답과 타임아웃 관리가 필요할 수 있다. |
특히 지연이 크거나 오류율이 높은 채널에서 Go-Back-N ARQ보다 성능이 뛰어나다. | 프레임 번호 공간이 윈도우 크기에 비해 충분히 커야 한다[1]. |
따라서 선택적 재전송 ARQ는 높은 신뢰성과 효율성이 모두 요구되는 환경에서 유용하게 적용된다. 현대의 TCP는 기본적으로 Go-Back-N ARQ와 유사한 누적 확인 응답 방식을 사용하지만, 선택적 확인 응답(SACK) 옵션을 통해 선택적 재전송의 개념을 부분적으로 도입하여 성능을 개선하기도 한다.

흐름 제어와 혼잡 제어는 모두 네트워크 성능을 최적화하고 데이터 손실을 방지하기 위한 기법이지만, 해결하려는 문제의 근본 원인과 작동 범위가 다르다. 흐름 제어는 점대점(point-to-point) 통신에서 수신자의 처리 능력과 송신자의 전송 속도를 조절하는 데 목적이 있다. 즉, 수신자의 버퍼 오버플로우를 방지하여 데이터가 버려지는 것을 막는 것이 주된 임무이다. 반면, 혼잡 제어는 네트워크 전체의 상태를 고려한다. 네트워크 경로 상의 라우터나 스위치 등 중간 노드에 과도한 트래픽이 몰려 패킷 손실이나 지연이 발생하는 현상, 즉 네트워크 혼잡을 감지하고 완화하는 것을 목표로 한다.
두 기법은 서로 독립적으로 동작하지만, 실제 현상에서는 밀접하게 연관되어 있다. 예를 들어, 네트워크가 혼잡해지면 중간 라우터의 큐가 가득 차 패킷이 손실된다. 이 패킷 손실은 최종 수신자에게 도달하지 못했기 때문에, 송신자 입장에서는 수신자의 버퍼 문제인 흐름 제어 실패로 오인할 수 있다. 그러나 실제 원인은 경로 상의 혼잡이다. 따라서 현대의 TCP 같은 프로토콜은 두 기법을 통합하여 구현한다. TCP의 슬라이딩 윈도우 메커니즘은 수신 윈도우 크기로 흐름 제어를 수행하면서, 동시에 혼잡 윈도우 크기를 별도로 유지하여 네트워크 상태를 추정하고 조절한다.
다음 표는 두 기법의 주요 차이점을 요약한다.
구분 | 흐름 제어 | 혼잡 제어 |
|---|---|---|
주요 목표 | 수신자의 버퍼 오버런 방지 | 네트워크 전체의 과부하 방지 |
제어 범위 | 송신자와 수신자 간의 점대점 연결 | 연결 경로 상의 모든 네트워크 자원 |
주요 원인 | 수신자 응용 프로그램의 처리 속도 | 네트워크 경로의 대역폭과 라우터 큐 용량 |
일반적인 신호 | 수신 윈도우 크기(RWND) | 패킷 손실, 지연 증가(예: RTT 증가) |
대표적 조치 | 수신 윈도우 크기 통지, 전송 일시 정지 | 혼잡 회피, 느린 시작, 패스트 리트랜스미션 알고리즘 실행 |
결론적으로, 흐름 제어는 수신자 중심의 로컬 최적화라면, 혼잡 제어는 네트워크 중심의 글로벌 최적화에 가깝다. 효과적인 데이터 전송을 위해서는 수신자가 데이터를 받을 준비가 되어 있는지(흐름 제어)와 동시에 네트워크가 그 데이터를 운반할 여유가 있는지(혼잡 제어)를 모두 고려해야 한다.

TCP는 전송 계층에서 신뢰성 있는 연결 지향 통신을 제공하는 핵심 프로토콜이다. TCP의 흐름 제어는 데이터 송신자와 수신자 간의 처리 속도 차이로 인한 오버플로를 방지하는 메커니즘이다. 이는 수신자의 버퍼 용량을 고려하여 송신자가 보낼 수 있는 데이터 양을 동적으로 조절함으로써 구현된다.
흐름 제어의 핵심은 수신 윈도우 필드이다. TCP 세그먼트 헤더에 포함된 이 값은 수신 측이 현재 수용할 수 있는 데이터의 바이트 수를 송신 측에 알린다. 수신 윈도우 크기는 수신 애플리케이션이 데이터를 읽어가는 속도와 수신 측 TCP 버퍼의 여유 공간에 따라 지속적으로 변한다. 송신 측은 자신이 보낼 수 있는 미확인 데이터의 누적 양을 송신 윈도우 크기로 관리하며, 이 값은 수신 윈도우와 혼잡 윈도우 중 더 작은 값에 의해 제한된다.
TCP의 슬라이딩 윈도우 구현은 누적 확인응답 방식을 기반으로 한다. 송신자는 수신 윈도우 범위 내에서 연속된 바이트 스트림을 세그먼트로 나누어 전송한다. 수신자는 성공적으로 수신한 가장 높은 시퀀스 번호 다음 번호를 확인응답 번호로 회신하며, 이 번호는 윈도우의 시작 지점을 앞으로 이동시킨다. 수신 윈도우가 0으로 보고되면 송신자는 전송을 중지하고, 수신 윈도우가 다시 열릴 때까지 주기적으로 제로 윈도우 탐색 패킷을 보내 상태를 확인한다.
이 메커니즘은 효율적인 전송을 보장한다. 빠른 송신자가 느린 수신자를 압도하는 것을 방지하면서도, 수신 처리 속도가 빨라지면 윈도우 크기를 키워 대역폭을 최대한 활용할 수 있게 한다. TCP의 흐름 제어는 혼잡 제어와 밀접하게 협력하여 네트워크의 효율성과 안정성을 동시에 추구한다.
수신 윈도우는 TCP에서 흐름 제어를 구현하는 핵심 메커니즘이다. 이는 수신 측이 자신의 버퍼 용량을 고려하여 송신 측에게 현재 수용 가능한 데이터의 양을 바이트 단위로 알려주는 역할을 한다. 송신 측은 이 수신 윈도우 크기만큼의 데이터를 확인응답을 기다리지 않고 연속적으로 전송할 수 있다. 수신 윈도우의 크기는 동적으로 변하며, TCP 세그먼트의 헤더에 있는 '윈도우 크기' 필드를 통해 전달된다.
수신 윈도우의 크기는 수신 측의 가용 버퍼 공간에 의해 결정된다. 애플리케이션이 버퍼에서 데이터를 읽어 처리하면 가용 공간이 늘어나고, 이에 따라 수신 윈도우 크기도 커진다. 반대로 데이터가 버퍼에 쌓이면 가용 공간과 수신 윈도우 크기는 줄어든다. 만약 버퍼가 가득 차 수신 윈도우 크기가 0이 되면, 송신 측은 새로운 데이터의 전송을 중지해야 한다. 이 상태를 제로 윈도우라고 한다. 제로 윈도우 상태를 해제하기 위해 수신 측은 별도의 윈도우 업데이트 세그먼트를 보낸다.
수신 윈도우는 슬라이딩 윈도우 프로토콜의 개념을 구체화한다. 송신 측은 자신의 송신 윈도우를 관리하는데, 이 윈도우의 크기는 수신 윈도우 크기와 네트워크의 혼잡 윈도우 크기 중 작은 값에 의해 제한받는다. 따라서 수신 윈도우는 수신자의 처리 능력을 반영하여 송신률을 조절함으로써, 수신 측 버퍼의 오버플로우를 방지하는 최종적인 안전장치 역할을 한다.
TCP에서 슬라이딩 윈도우 흐름 제어는 세 가지 핵심 변수, 즉 송신 윈도우, 수신 윈도우, 그리고 혼잡 윈도우를 통해 구현된다. 송신 측은 이 세 윈도우 중 가장 작은 크기만큼의 데이터를 네트워크로 보낼 수 있다. 이는 수신자의 처리 능력과 네트워크의 혼잡 상태를 동시에 고려하여 데이터 전송률을 결정하기 위함이다.
구체적인 동작은 다음과 같다. 송신자는 자신의 송신 버퍼를 세 부분으로 관리한다. 이미 확인응답(ACK)을 받아 전송이 완료된 데이터, 전송은 했으나 아직 ACK를 받지 못한 데이터, 그리고 아직 전송되지 않아 송신 가능한 데이터로 구분된다. 수신자로부터 정기적으로 전달되는 수신 윈도우 크기 정보는 송신 가능한 데이터의 최대 양을 제한한다. 수신자가 새로운 ACK를 보내면, 송신 윈도우는 해당 ACK 번호를 기준으로 앞으로 "슬라이드"하며, 새로운 데이터의 전송이 가능해진다.
이 과정에서 혼잡 제어 알고리즘은 별도로 계산된 혼잡 윈도우 크기를 제공한다. 최종적인 "효과적 윈도우" 크기는 min(수신 윈도우, 혼잡 윈도우) 공식으로 결정된다. TCP의 대표적인 혼잡 제어 알고리즘인 TCP Reno는 느린 시작, 혼잡 회피, 빠른 재전송, 빠른 회복 단계를 거치며 혼잡 윈도우 크기를 동적으로 조절한다.
수신 측의 구현은 상대적으로 단순하다. 수신자는 자신의 가용 수신 버퍼 공간을 바탕으로 수신 윈도우 크기를 계산하고, 이를 ACK 세그먼트의 윈도우 크기 필드에 담아 송신자에게 지속적으로 알린다. 버퍼에 데이터가 애플리케이션 계층으로 전달되어 공간이 생기면, 윈도우 크기 정보를 업데이트하여 새로운 ACK와 함께 보내 송신자가 더 많은 데이터를 보낼 수 있도록 한다.

TCP 외에도 다양한 네트워크 프로토콜은 각자의 환경과 요구사항에 맞춰 특화된 흐름 제어 메커니즘을 채택한다. UDP는 기본적으로 흐름 제어 기능을 제공하지 않는다. 이는 신뢰성보다 낮은 지연과 단순성이 중요한 실시간 애플리케이션에 적합한 설계 선택이다. 따라서 UDP를 사용하는 애플리케이션은 필요 시 애플리케이션 계층에서 자체적인 속도 제어 로직을 구현해야 한다.
데이터 링크 계층 프로토콜도 고유의 흐름 제어 방식을 사용한다. 예를 들어, 이더넷은 CSMA/CD 방식을 기반으로 충돌 감지 및 재전송을 통해 매체 접근을 제어하지만, 전통적인 의미의 수신자 기반 흐름 제어는 제공하지 않는다. 반면, HDLC나 PPP와 같은 점대점 프로토콜은 슬라이딩 윈도우 프로토콜의 변형을 사용하여 프레임 단위의 흐름 제어를 수행할 수 있다.
고속 네트워크나 특수 목적 네트워크에서는 다른 접근법이 사용된다. ATM 네트워크는 연결 설정 시 협상된 트래픽 계약을 기반으로 한 사용 파라미터 제어 및 네트워크 파라미터 제어를 통해 사전 예방적인 흐름 제어를 실현한다. 인피니밴드는 신용 기반 흐름 제어를 채택하여, 수신자가 송신자에게 사용 가능한 버퍼 공간을 나타내는 신용량을 보내고, 송신자는 이 신용 범위 내에서만 데이터를 전송한다. 이 방식은 지연을 최소화하면서 효율성을 높인다.

흐름 제어 기법은 네트워크 성능에 직접적이고 복합적인 영향을 미친다. 적절한 흐름 제어는 처리율을 최대화하고 지연 시간을 줄이며 자원 활용도를 높이는 데 목표를 둔다. 그러나 구현 방식과 네트워크 조건에 따라 성능 지표 간에는 트레이드오프 관계가 발생하기도 한다. 예를 들어, 정지-대기 프로토콜은 구현이 단순하지만, 매 패킷마다 확인응답을 기다려야 하므로 채널 이용률이 낮아져 전체 처리율이 저하된다. 이는 특히 전파 지연이 큰 위성 통신과 같은 환경에서 심각한 성능 저하를 유발한다.
보다 진보된 슬라이딩 윈도우 프로토콜은 여러 데이터그램을 연속적으로 전송함으로써 채널을 효율적으로 가득 채워 처리율을 향상시킨다. 그러나 윈도우 크기 설정은 핵심적인 성능 변수로 작용한다. 윈도우 크기가 너무 작으면 송신자가 네트워크의 가용 대역폭을 충분히 활용하지 못해 처리율이 제한된다. 반대로, 윈도우 크기가 수신자의 버퍼 용량이나 네트워크의 혼잡 수준을 초과하면 패킷 손실이 발생하고, 이로 인한 재전송으로 실제 처리율이 오히려 떨어지고 지연이 증가할 수 있다.
다양한 재전송 오류 제어 방식도 성능 차이를 만든다. Go-Back-N ARQ 방식은 오류 발생 시 윈도우 내의 모든 후속 패킷을 재전송하므로, 대역폭 효율성이 떨어질 수 있다. 반면, 선택적 재전송 ARQ는 오류난 패킷만 선택적으로 재전송하여 대역폭 낭비를 줄이지만, 수신 측에서 패킷을 순서대로 재조립하기 위한 더 복잡한 버퍼 관리와 처리가 필요하다. 따라서 추가적인 구현 복잡성과 처리 오버헤드가 발생한다.
최종적으로, TCP와 같은 현대 프로토콜의 흐름 제어는 혼잡 제어 알고리즘과 긴밀하게 상호작용하며 종합적인 성능을 결정한다. TCP 혼잡 제어는 네트워크의 포화 상태를 감지하고 윈도우 크기를 동적으로 조절함으로써, 흐름 제어가 단순히 수신자 처리 능력만 고려하는 것을 넘어 네트워크 전체의 안정성과 공정성을 유지하는 데 기여한다. 잘 조율된 흐름 제어는 네트워크 성능을 최적화하는 데 필수적이다.
