흐름 제어 (Flow Control)
1. 개요
흐름 제어(Flow Control)란 네트워크 통신에서 송신측(Sender)과 수신측(Receiver) 사이의 데이터 처리 속도 차이를 조절하여, 수신측이 처리할 수 있는 양보다 더 많은 데이터가 전송되어 데이터가 손실되는 것을 방지하는 메커니즘이다.
네트워크 통신에서는 하드웨어 성능, OS의 버퍼 크기, 애플리케이션의 처리 속도 등에 따라 송신측은 빠르게 데이터를 보낼 수 있지만, 수신측은 이를 즉각적으로 처리하지 못하는 상황이 빈번하게 발생한다. 흐름 제어는 이러한 속도 불균형을 해결하여 신뢰성 있는 데이터 전송을 보장하는 것을 목적으로 한다.
2. 흐름 제어의 필요성
데이터 전송 시 수신측은 네트워크 카드를 통해 들어온 데이터를 즉시 처리하기 전, 임시 저장 공간인 버퍼(Buffer)에 저장한다.
2.1 버퍼 오버플로우 (Buffer Overflow)
송신측이 수신측의 처리 속도를 고려하지 않고 데이터를 지속적으로 전송할 경우, 수신측의 버퍼가 가득 차는 버퍼 오버플로우 현상이 발생한다. 버퍼에 더 이상 공간이 없을 때 도착하는 패킷은 저장될 곳이 없어 강제로 폐기되는데, 이를 패킷 드롭(Packet Drop)이라고 한다.
2.2 재전송 비용 문제
패킷 드롭이 발생하면 TCP의 신뢰성 보장 메커니즘에 의해 송신측은 유실된 패킷을 다시 전송해야 한다. 이는 다음과 같은 부작용을 초래한다.
- 대역폭 낭비: 이미 전송했던 데이터를 다시 보내므로 네트워크 자원이 낭비된다.
- 지연 시간(Latency) 증가: 재전송 대기 시간 및 처리 시간으로 인해 전체적인 통신 속도가 저하된다.
- 처리 부하 증가: 송신측과 수신측 모두 패킷 추적 및 재조립을 위한 CPU 자원을 추가로 소모하게 된다.
3. 주요 메커니즘
흐름 제어를 구현하는 방식은 크게 단순한 '정지-대기' 방식과 효율적인 '슬라이딩 윈도우' 방식으로 나뉜다.
3.1 정지-대기 (Stop-and-Wait)
송신측이 패킷 하나를 보내고, 수신측으로부터 해당 패킷을 잘 받았다는 확인 응답(ACK, Acknowledgement)이 올 때까지 다음 패킷을 보내지 않고 기다리는 가장 단순한 방식이다. 구현이 쉽지만, 응답을 기다리는 시간 동안 네트워크 회선이 유휴 상태가 되어 효율성이 매우 낮다.
3.2 슬라이딩 윈도우 (Sliding Window)
수신측이 한 번에 받을 수 있는 데이터 양(윈도우 크기)을 미리 지정하고, 그 범위 내에서는 ACK 없이도 연속적으로 패킷을 보낼 수 있게 하는 방식이다. ACK를 받을 때마다 윈도우의 범위가 오른쪽으로 밀려나며(Sliding) 다음 데이터를 전송할 수 있게 된다.
[표 1] 정지-대기 vs 슬라이딩 윈도우 비교
| 구분 |
정지-대기 (Stop-and-Wait) |
슬라이딩 윈도우 (Sliding Window) |
| 작동 방식 |
1개 패킷 전송 $\rightarrow$ ACK 대기 $\rightarrow$ 다음 전송 |
윈도우 크기만큼 연속 전송 $\rightarrow$ ACK 수신 시 윈도우 이동 |
| 효율성 |
매우 낮음 (RTT에 종속적) |
높음 (파이프라이닝 가능) |
| 장점 |
구조가 단순하고 구현이 쉬움 |
네트워크 대역폭을 최대한 활용 가능 |
| 단점 |
전송 속도가 매우 느림 |
버퍼 관리 및 윈도우 크기 조절 로직이 복잡함 |
4. TCP 슬라이딩 윈도우의 동작 원리
TCP에서는 수신측의 버퍼 상태를 송신측에 알려주는 윈도우 크기(Window Size) 필드를 사용하여 동적으로 흐름을 제어한다.
4.1 수신 윈도우(RWND)와 동적 변경
수신측은 TCP 헤더의 Window Size 필드에 현재 자신의 버퍼에서 사용 가능한 여유 공간인 RWND(Receiver Window) 값을 담아 ACK 패킷과 함께 송신측에 보낸다.
[윈도우 크기 계산 수식]
- $\text{RWND} = \text{MaxBufferSize} - (\text{BufferedData} - \text{ReadData})$
- (텍스트 표기: RWND = 최대 버퍼 크기 - (현재 버퍼에 저장된 데이터 - 애플리케이션이 읽어간 데이터))
윈도우 스케일 옵션 (Window Scaling, RFC 1323)
TCP 헤더의 Window Size 필드는 16비트로 제한되어 있어 최대 65,535 바이트까지만 표현 가능하다. 하지만 현대의 고속 네트워크(LFN, Long Fat Networks)에서는 이 크기가 너무 작아 대역폭을 충분히 활용하지 못하는 병목 현상이 발생한다. 이를 해결하기 위해 TCP 연결 설정 단계(3-way handshake)에서 Window Scale 옵션을 협상하여, 윈도우 크기 값에 배수를 곱해 실제 윈도우 크기를 최대 약 1GB까지 확장하여 사용할 수 있다.
4.2 윈도우 이동 과정 (시각화)
송신 윈도우 크기가 4라고 가정했을 때의 동작 과정은 다음과 같다.
[동작 다이어그램]
1. 초기 전송 (Win=4)
송신측: [1, 2, 3, 4] -------------------> 수신측
윈도우 범위: [1~4]
2. ACK 수신 및 슬라이딩 (ACK 3, Win=4 수신)
수신측: <--- [ACK 3, Win=4] (1, 2번 수신 완료 알림)
송신측: [3, 4, 5, 6] (윈도우가 3번부터 시작하도록 이동)
윈도우 범위: [1~4] -> [3~6]
3. 추가 전송
송신측: [5, 6] -------------------> 수신측
- 단계 1: 송신측은 윈도우 크기(4)만큼 패킷 1, 2, 3, 4를 연속 전송한다.
- 단계 2: 수신측이 1, 2번을 처리하고
ACK 3을 보내면, 송신측은 1, 2번이 성공적으로 전달되었음을 확인하고 윈도우를 오른쪽으로 2칸 이동시킨다.
- 단계 3: 이동된 윈도우 범위([3~6])에 따라 아직 보내지 않은 패킷 5, 6을 추가로 전송할 수 있게 된다.
5. 혼잡 제어(Congestion Control)와의 차이점
흐름 제어와 혼잡 제어는 모두 데이터 전송량을 조절한다는 점에서 유사하지만, 제어의 대상과 목적이 완전히 다르다.
- 흐름 제어: 송신측과 수신측 사이의 1:1 관계에서 수신측의 처리 능력에 맞추는 것.
- 혼잡 제어: 송신측과 네트워크 경로 사이의 관계에서 네트워크의 혼잡도(Congestion)에 맞추는 것.
[표 2] 흐름 제어 vs 혼잡 제어 비교
| 구분 |
흐름 제어 (Flow Control) |
혼잡 제어 (Congestion Control) |
| 제어 대상 |
수신측 (Receiver) |
네트워크 경로 (Network Path/Router) |
| 발생 원인 |
수신측 버퍼 부족 및 처리 속도 저하 |
네트워크 내 패킷 과다로 인한 라우터 큐 포화 및 패킷 손실 |
| 해결 방법 |
RWND (수신 윈도우) 조절 |
CWND (혼잡 윈도우) 조절 (Slow Start 등) |
| 핵심 지표 |
수신측의 가용 버퍼 크기 |
패킷 손실률, RTT(Round Trip Time) 변화 |
6. 실무적 관점의 분석
6.1 실제 패킷 캡처 사례 (Wireshark 분석)
Wireshark와 같은 패킷 분석 도구로 TCP 세션을 캡처하면 다음과 같은 흐름을 확인할 수 있다.
- TCP Window Update: 수신측이 버퍼 공간을 확보했을 때, 데이터 전송 없이 윈도우 크기만 업데이트하여 송신측에 알리는 패킷이 관찰된다.
- Zero Window: 수신측 버퍼가 완전히 가득 차면 Win=0 패킷을 보낸다.
Zero Window 발생 시 처리 방식
수신측이 Win=0을 보내면 송신측은 데이터 전송을 즉시 중단한다. 이후 다음과 같은 메커니즘으로 통신을 재개한다.
1. Window Update 대기: 수신측이 버퍼 공간을 확보한 후 Win > 0인 업데이트 패킷을 보내면 송신측이 다시 전송을 시작한다.
2. Zero Window Probe (ZWP): 만약 수신측의 업데이트 패킷이 유실되면 송신측은 영원히 대기하는 교착 상태(Deadlock)에 빠질 수 있다. 이를 방지하기 위해 송신측은 일정 시간마다 아주 작은 크기의 Probe 패킷을 보내 수신측의 버퍼 상태를 강제로 확인한다.
6.2 흐름 제어 실패 시나리오
흐름 제어 메커니즘이 정상적으로 작동하지 않거나, 설정값이 부적절할 때 다음과 같은 시나리오가 발생한다.
1. 송신측의 무시: 송신측이 수신측의 Win=0 신호를 무시하고 데이터를 계속 보낼 경우, 수신측은 모든 패킷을 드롭하며 네트워크에는 불필요한 재전송 패킷만 가득 차게 된다.
2. 윈도우 크기 설정 오류: 윈도우 크기를 너무 작게 설정하면, 네트워크 대역폭이 충분함에도 불구하고 ACK를 기다리는 시간이 길어져 처리량(Throughput)이 급격히 저하된다.
3. Application-level Bottleneck: 수신측 OS 버퍼는 충분하지만, 상위 애플리케이션이 데이터를 읽어가는 속도가 극도로 느릴 경우, 결국 RWND가 0으로 수렴하는 TCP Zero Window 상태가 지속된다. 이 상태가 길어지면 송신측의 재전송 타이머가 만료되어 연결이 끊어지거나, 전체적인 통신 세션의 타임아웃 문제가 발생할 수 있다.
# 흐름 제어 (Flow Control)
## 1. 개요
**흐름 제어(Flow Control)**란 네트워크 통신에서 송신측(Sender)과 수신측(Receiver) 사이의 데이터 처리 속도 차이를 조절하여, 수신측이 처리할 수 있는 양보다 더 많은 데이터가 전송되어 데이터가 손실되는 것을 방지하는 메커니즘이다.
네트워크 통신에서는 하드웨어 성능, OS의 버퍼 크기, 애플리케이션의 처리 속도 등에 따라 송신측은 빠르게 데이터를 보낼 수 있지만, 수신측은 이를 즉각적으로 처리하지 못하는 상황이 빈번하게 발생한다. 흐름 제어는 이러한 속도 불균형을 해결하여 신뢰성 있는 데이터 전송을 보장하는 것을 목적으로 한다.
## 2. 흐름 제어의 필요성
데이터 전송 시 수신측은 네트워크 카드를 통해 들어온 데이터를 즉시 처리하기 전, 임시 저장 공간인 **버퍼(Buffer)**에 저장한다.
### 2.1 버퍼 오버플로우 (Buffer Overflow)
송신측이 수신측의 처리 속도를 고려하지 않고 데이터를 지속적으로 전송할 경우, 수신측의 버퍼가 가득 차는 **버퍼 오버플로우** 현상이 발생한다. 버퍼에 더 이상 공간이 없을 때 도착하는 패킷은 저장될 곳이 없어 강제로 폐기되는데, 이를 **패킷 드롭(Packet Drop)**이라고 한다.
### 2.2 재전송 비용 문제
패킷 드롭이 발생하면 TCP의 신뢰성 보장 메커니즘에 의해 송신측은 유실된 패킷을 다시 전송해야 한다. 이는 다음과 같은 부작용을 초래한다.
- **대역폭 낭비:** 이미 전송했던 데이터를 다시 보내므로 네트워크 자원이 낭비된다.
- **지연 시간(Latency) 증가:** 재전송 대기 시간 및 처리 시간으로 인해 전체적인 통신 속도가 저하된다.
- **처리 부하 증가:** 송신측과 수신측 모두 패킷 추적 및 재조립을 위한 CPU 자원을 추가로 소모하게 된다.
## 3. 주요 메커니즘
흐름 제어를 구현하는 방식은 크게 단순한 '정지-대기' 방식과 효율적인 '슬라이딩 윈도우' 방식으로 나뉜다.
### 3.1 정지-대기 (Stop-and-Wait)
송신측이 패킷 하나를 보내고, 수신측으로부터 해당 패킷을 잘 받았다는 확인 응답(**ACK**, Acknowledgement)이 올 때까지 다음 패킷을 보내지 않고 기다리는 가장 단순한 방식이다. 구현이 쉽지만, 응답을 기다리는 시간 동안 네트워크 회선이 유휴 상태가 되어 효율성이 매우 낮다.
### 3.2 슬라이딩 윈도우 (Sliding Window)
수신측이 한 번에 받을 수 있는 데이터 양(윈도우 크기)을 미리 지정하고, 그 범위 내에서는 ACK 없이도 연속적으로 패킷을 보낼 수 있게 하는 방식이다. ACK를 받을 때마다 윈도우의 범위가 오른쪽으로 밀려나며(Sliding) 다음 데이터를 전송할 수 있게 된다.
### [표 1] 정지-대기 vs 슬라이딩 윈도우 비교
| 구분 | 정지-대기 (Stop-and-Wait) | 슬라이딩 윈도우 (Sliding Window) |
| :--- | :--- | :--- |
| **작동 방식** | 1개 패킷 전송 $\rightarrow$ ACK 대기 $\rightarrow$ 다음 전송 | 윈도우 크기만큼 연속 전송 $\rightarrow$ ACK 수신 시 윈도우 이동 |
| **효율성** | 매우 낮음 (RTT에 종속적) | 높음 (파이프라이닝 가능) |
| **장점** | 구조가 단순하고 구현이 쉬움 | 네트워크 대역폭을 최대한 활용 가능 |
| **단점** | 전송 속도가 매우 느림 | 버퍼 관리 및 윈도우 크기 조절 로직이 복잡함 |
## 4. TCP 슬라이딩 윈도우의 동작 원리
TCP에서는 수신측의 버퍼 상태를 송신측에 알려주는 **윈도우 크기(Window Size)** 필드를 사용하여 동적으로 흐름을 제어한다.
### 4.1 수신 윈도우(RWND)와 동적 변경
수신측은 TCP 헤더의 `Window Size` 필드에 현재 자신의 버퍼에서 사용 가능한 여유 공간인 **RWND(Receiver Window)** 값을 담아 ACK 패킷과 함께 송신측에 보낸다.
**[윈도우 크기 계산 수식]**
- $\text{RWND} = \text{MaxBufferSize} - (\text{BufferedData} - \text{ReadData})$
- (텍스트 표기: RWND = 최대 버퍼 크기 - (현재 버퍼에 저장된 데이터 - 애플리케이션이 읽어간 데이터))
#### 윈도우 스케일 옵션 (Window Scaling, RFC 1323)
TCP 헤더의 Window Size 필드는 16비트로 제한되어 있어 최대 65,535 바이트까지만 표현 가능하다. 하지만 현대의 고속 네트워크(LFN, Long Fat Networks)에서는 이 크기가 너무 작아 대역폭을 충분히 활용하지 못하는 병목 현상이 발생한다. 이를 해결하기 위해 TCP 연결 설정 단계(3-way handshake)에서 **Window Scale** 옵션을 협상하여, 윈도우 크기 값에 배수를 곱해 실제 윈도우 크기를 최대 약 1GB까지 확장하여 사용할 수 있다.
### 4.2 윈도우 이동 과정 (시각화)
송신 윈도우 크기가 4라고 가정했을 때의 동작 과정은 다음과 같다.
**[동작 다이어그램]**
```text
1. 초기 전송 (Win=4)
송신측: [1, 2, 3, 4] -------------------> 수신측
윈도우 범위: [1~4]
2. ACK 수신 및 슬라이딩 (ACK 3, Win=4 수신)
수신측: <--- [ACK 3, Win=4] (1, 2번 수신 완료 알림)
송신측: [3, 4, 5, 6] (윈도우가 3번부터 시작하도록 이동)
윈도우 범위: [1~4] -> [3~6]
3. 추가 전송
송신측: [5, 6] -------------------> 수신측
```
- **단계 1:** 송신측은 윈도우 크기(4)만큼 패킷 1, 2, 3, 4를 연속 전송한다.
- **단계 2:** 수신측이 1, 2번을 처리하고 `ACK 3`을 보내면, 송신측은 1, 2번이 성공적으로 전달되었음을 확인하고 윈도우를 오른쪽으로 2칸 이동시킨다.
- **단계 3:** 이동된 윈도우 범위([3~6])에 따라 아직 보내지 않은 패킷 5, 6을 추가로 전송할 수 있게 된다.
## 5. 혼잡 제어(Congestion Control)와의 차이점
흐름 제어와 혼잡 제어는 모두 데이터 전송량을 조절한다는 점에서 유사하지만, **제어의 대상과 목적**이 완전히 다르다.
- **흐름 제어:** 송신측과 수신측 사이의 1:1 관계에서 **수신측의 처리 능력**에 맞추는 것.
- **혼잡 제어:** 송신측과 네트워크 경로 사이의 관계에서 **네트워크의 혼잡도(Congestion)**에 맞추는 것.
### [표 2] 흐름 제어 vs 혼잡 제어 비교
| 구분 | 흐름 제어 (Flow Control) | 혼잡 제어 (Congestion Control) |
| :--- | :--- | :--- |
| **제어 대상** | 수신측 (Receiver) | 네트워크 경로 (Network Path/Router) |
| **발생 원인** | 수신측 버퍼 부족 및 처리 속도 저하 | 네트워크 내 패킷 과다로 인한 라우터 큐 포화 및 패킷 손실 |
| **해결 방법** | RWND (수신 윈도우) 조절 | CWND (혼잡 윈도우) 조절 (Slow Start 등) |
| **핵심 지표** | 수신측의 가용 버퍼 크기 | 패킷 손실률, RTT(Round Trip Time) 변화 |
## 6. 실무적 관점의 분석
### 6.1 실제 패킷 캡처 사례 (Wireshark 분석)
Wireshark와 같은 패킷 분석 도구로 TCP 세션을 캡처하면 다음과 같은 흐름을 확인할 수 있다.
- **TCP Window Update:** 수신측이 버퍼 공간을 확보했을 때, 데이터 전송 없이 윈도우 크기만 업데이트하여 송신측에 알리는 패킷이 관찰된다.
- **Zero Window:** 수신측 버퍼가 완전히 가득 차면 `Win=0` 패킷을 보낸다.
#### Zero Window 발생 시 처리 방식
수신측이 `Win=0`을 보내면 송신측은 데이터 전송을 즉시 중단한다. 이후 다음과 같은 메커니즘으로 통신을 재개한다.
1. **Window Update 대기:** 수신측이 버퍼 공간을 확보한 후 `Win > 0`인 업데이트 패킷을 보내면 송신측이 다시 전송을 시작한다.
2. **Zero Window Probe (ZWP):** 만약 수신측의 업데이트 패킷이 유실되면 송신측은 영원히 대기하는 교착 상태(Deadlock)에 빠질 수 있다. 이를 방지하기 위해 송신측은 일정 시간마다 아주 작은 크기의 **Probe 패킷**을 보내 수신측의 버퍼 상태를 강제로 확인한다.
### 6.2 흐름 제어 실패 시나리오
흐름 제어 메커니즘이 정상적으로 작동하지 않거나, 설정값이 부적절할 때 다음과 같은 시나리오가 발생한다.
1. **송신측의 무시:** 송신측이 수신측의 `Win=0` 신호를 무시하고 데이터를 계속 보낼 경우, 수신측은 모든 패킷을 드롭하며 네트워크에는 불필요한 재전송 패킷만 가득 차게 된다.
2. **윈도우 크기 설정 오류:** 윈도우 크기를 너무 작게 설정하면, 네트워크 대역폭이 충분함에도 불구하고 ACK를 기다리는 시간이 길어져 처리량(Throughput)이 급격히 저하된다.
3. **Application-level Bottleneck:** 수신측 OS 버퍼는 충분하지만, 상위 애플리케이션이 데이터를 읽어가는 속도가 극도로 느릴 경우, 결국 RWND가 0으로 수렴하는 **TCP Zero Window 상태가 지속**된다. 이 상태가 길어지면 송신측의 재전송 타이머가 만료되어 연결이 끊어지거나, 전체적인 통신 세션의 타임아웃 문제가 발생할 수 있다.