[2. Transport Layer] TCP Flow Control & Congestion Control

TCP가 제공하는 중요한 기능 중 하나가 Flow Control(흐름제어)와 Congestion Control(혼잡제어)다.

 

1. Flow Control (흐름제어)

송신자와 수신자가 서로 데이터를 보낼 때, 상대방의 버퍼의 크기를 고려하지 않고 보내면 송신자의 입장에서는 편할 수

있다. 하지만 수신자의 입장에서는 자신의 버퍼크기보다 많은 데이터가 들어오게 되면 모두 처리하지 못하고 버퍼를 초과한 데이터들은 버리게 되어버린다. 이러한 Overflow를 방지하기 위해서 TCP는 흐름제어를 한다.

 

우선 TCP가 수신하는 데이터는 버퍼에 저장되지만, 저장되는 즉시 Application Layer으로 올라가는 것은 아니다. 

Application은 다른 작업을 하고 있을 수 있고 해당 데이터가 아직 필요로 하지 않을 수 있기 때문이다. 그렇게 때문에

흐름제어를 통해서 애플리케이션이 읽는 속도와 송신자의 송신 속도를 일치시키는 역할을 한다.

 

TCP에는 '수신 윈도' 라는 필드가 존재한다. 해당 필드는 자신의 버퍼의 가용사이즈가 얼마인지 알려주는 역할을 한다. A가 B로 패킷을 보내면 B는 A에게 보내는 패킷에 자신의 버퍼 크기가 담긴 세그먼트를 보낸다. 

하지만 만약 B에 가용버퍼가 0이고, B는 A에게 보낼 패킷이 없다면 어떻게 될까?

 

A는 현재 B의 가용버퍼가 0이라고 알고 있지만 B는 시간이 지날수록 애플리케이션이 데이터를 읽어가며 버퍼를 비웠다. 

그러면 현재 추가적인 패킷을 받을 수 있는 상황이지만 A는 현재 B의 버퍼크기가 0으로 알고 있고 B는 보낼 패킷이 없기 때문에 A는 계속 0인것으로 안다.

이런 문제를 해결하기 위해서 A는 B에게 아주 작은 1바이트 데이터 세그먼트를 보내게 된다. 만약 버퍼에 여유 공간이 있다면 A는 B의 가용버퍼 사이즈를 응답받게 될 것이다.

 

TCP는 이렇게 흐름제어를 통해서 패킷에 대한 신뢰적인 전송을 가능하게 한다.

 

2. Congestion Control(혼잡제어)

흐름제어가 TCP 버퍼에 들어가는 패킷에 대한 control 이라면 Congestion Control 은 네트워크에서의 패킷 control 이라고

할 수 있다.

혼잡제어는 흐름제어와 다르게 누가 현재 상황에 대해 알려줄 방법이 없다. 그렇다고 마구잡이로 데이터를 보내게 된다면 

네트워크상에 혼잡이 일어나게 될 것이고, 네트워크는 개인의 것이 아닌 모두가 사용하는 것이기 때문에 나뿐만 아니라 모두에게 지연이 발생하게 될 것이다.

 

그렇기 때문에 네트워크가 혼잡할때를 대비해서 어떻게 전송해야할지에 대한 메커니즘이 필요하다.

그럼 TCP는 혼잡 제어를 어떻게 하는 것일까?

 

Slow Start

TCP가 시작되면 '혼잡 윈도' 라는 버퍼는 1MSS로 초기화가 된다. 

1MSS 크기의 데이터를 보내게 되고 확인 응답을 기다린다. 확인응답이 온다면 지수적 증가로

2개를 보내고 이후 4개, 16개 ... 로 빠르게 윈도의 크기를 증가시킨다.

하지만 무작정 올릴 수 있는 것은 아니다.

혼잡이 발생한다면 Slow Start에서는 혼잡 윈도를 다시 1로 설정하고 다시 시작한다.

다른 경우에는 Slow Start Threshold(ssthresh)를 넘긴 경우이다. 이 임계점을 넘는 경우 현재 혼잡 윈도의 절반 크기를 잡고 다시 슬로우 스타트를 시작한다

 

AIMD (Additive Increase Multiple Decrease)

AIMD는 보내는 세그먼트를 1개씩 증가시키고, 혼잡이 발생한 경우 윈도우의 크기를 절반으로 줄이는 방법이다.

슬로우 스타트와 다르게 세그먼트를 1개씩 전송하기 때문에 속도가 느리다는 단점이 있다. 

 

TCP Taho

TCP Taho 에서는 ssthresh 임계점을 넘어가기 전까지는 지수적 증가로 빠르게 속도를 올린다. 임계점을 넘긴 순간부터는 Additive Increase로 천천히 올리게 되는데 만약 패킷이 유실되는 시점(혼잡 발생) 이 있다면 윈도를 1 MSS로 줄이고 다시 Slow Start를 시작한다. 이때 임계점은 (윈도우 사이즈 / 2) 만큼 줄여서 시작하게 된다.

 

TCP Reno

TCP Reno는 Taho와 다르게 패킷을 유실한 경우 윈도 사이즈를 1로 줄이는 것이 아니라 3 Duplicate ACK와 Timeout으로 구분을 먼저 한다.

네트워크 입장에서는 Time out 보다는 3 Duplicate ACKs가 부담이 적다. 그 이유는 ACK가 도착했다는 것은 네트워크가 그렇게 혼잡하지는 않고 수신이 된다는 뜻이기 때문이다. Timeout의 경우 어떠한 응답을 받지 못해서 타임아웃이 발생한 것이기 때문에 네트워크가 혼잡하다고 생각하는 것이다.

 

Taho에서는 Timeout과 3-Dup. ACKs를 구분하지 않고 혼잡이 발생하면 윈도크기를 1로 설정하고 SlowStart를 진행했다면 Reno 에서는 3-Duplicate ACKs 가 발생하면 윈도사이즈를 1로 줄이는 것이 아니라 절반으로만 줄인다는 것이다. 그렇기 때문에 이를 '빠른 회복 Fast Recovery' 라고 부른다.

 

Timeout이 발생한 경우에는 Reno역시 윈도 사이즈를 1로 줄이고 Slow Start과 Linear Increase의 기법을 사용하게 된다.