혼잡제어
흐름제어를 통해 송신, 수신 사이의 패킷 수를 조절했다면 혼잡제어는 네트워크 내의 패킷 수를 조절하여 네트워크의 overflow를 방지하는 방법이다.
만약, 한 라우터에 데이터가 몰려서 모든 데이터를 처리할 수 없는 상황이 왔다고 가정해보자. 호스트들을 보낸 데이터에 대한 응답이 오지 않으니 동일 데이터를 재전송할 것이고, 이러한 재전송은 혼잡을 더욱 가중시켜서 오버플로우, 데이터 손실이 발생할 것이다.
혼잡제어는 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송 속도를 제어하는 기법이다.
이러한 TCP의 혼잡 제어 방식은 여러가지 방법이 존재 하지만 가장 기본적인 혼잡 제어 방법은 AIMD와 Slow Start라는 혼잡 회피 방법을 상황에 맞게 조합하는 방법이라고 한다. 그럼 AIMD 와 Slow Start 방법에 대해 각각 알아보자!
혼잡 윈도우
본격적으로 혼잡 제어에 대해 알아보기 전에 아래 내용에서 반복적으로 나오게 될 '윈도우'의 개념을 정리 해 보자.
지난 흐름제어 포스팅에서 송신 윈도우, 수신 윈도우라는 말을 쉽게 사용했지만, 사실 송신측의 윈도우 크기는 수신측이 보내준 윈도우 크기와 네트워크 상황을 함께 고려해서 정해지게 된다.
송신측은 자신의 최종 윈도우 크기를 정할 때, 수신측이 보내준 윈도우 크기인 수신자 윈도우(RWND) 와 자신이 네트워크 상황을 고려해 정한 혼잡 윈도우(CWND) 중에서 더 작은 값을 택한다.
결국 송신자가 조절하는 윈도우 크기란 정확하게는 송신측이 가지고 있는 혼잡 윈도우 크기 인 것이다.
아래 내용에서 이렇게 저렇게 조절되는 윈도우란 바로 혼잡 윈도우 라고 생각하면 되겠다.
혼잡 회피 방식
AIMD (Addictive Increase Multicative Decrease)
송신자의 데이터 전송 속도를 제어하는 첫번째 방법은 AIMD, 우리 말로 번역하면 합 증가 - 곱 감소 알고리즘이다.
방법은 이름처럼 간단하다.
더해나갈때는 증가시키고 반으로 줄여 감소시킨다.
송신자는 처음에 하나의 패킷을 전송한다. 전송된 패킷이 문제없이 도착하는 것을 확인하면 윈도우 사이즈를 하나 증가시켜 두개를 보낸다. 이러한 식으로 하나씩 윈도우 사이즈를 늘려나가다 패킷이 전송되지 않거나 TIME_OUT 이 발생하면 늘려놨던 윈도우 사이즈를 절반으로 줄인다.
그래프 역시 간단한 모습일 것이다.
이 단순한 AIMD 알고리즘은 결국 모든 호스트가 공평하게 네트워크를 사용하게 하는데, 왜그럴까?
네트워크가 혼잡해져있는 상태에서 새로운 호스트가 진입했다고 가정하자.
이미 네트워크에 존재하던 호스트들은 큰 혼잡 윈도우를 가지고 있을 것이고, 새로 진입한 호스트의 혼잡 윈도우는 작은 상태이다. 기존에 존재하던 호스트 들은 큰 혼잡 윈도우를 가지고 있으므로 이미 혼잡한 네트워크에 무리하게 많은 데이터를 재전송하여 데이터가 더욱 유실될 것이고 자연스레 혼잡 윈도우 사이즈를 줄이게 된다.
그러면 새로 들어온 호스트는 자신의 혼잡 윈도우 사이즈를 하나씩 늘려가며 남게 되는 대역폭을 사용하게 되고 이러한 과정이 반복되며 여러 호스트들이 대역폭을 공평하게 나눠쓰는 형태로 향한다.
하지만 단점으로는, 윈도우 사이즈를 하나씩 늘려가기 때문에 초기 네트워크의 큰 대역폭을 바로 사용하지 못한다 는 점 때문에 네트워크의 모든 대역폭을 활용해 제대로 된 속도로 통신하기 까지 시간이 좀 걸린다.
또한 네트워크가 혼잡해지는 상황을 미리 감지할 수 없고 혼잡상태가 발생한 이후에 대역폭을 감소 시킨다는 점이 있다!
Slow Start
두번째 대표적인 혼잡 회피 방법은 느린시작, slow start 방식이다!
요즘에는 네트워크의 대역폭이 워낙 넓고 통신 인프라도 좋다보니 예전에 비해서 네트워크의 혼잡 상황 발생하는 빈도가 많이 줄어들었다. 때문에 혼잡 상황이 발생하기 전에도 제대로 속도를 내지 못하는 AIMD 의 단점이 더욱 부각되었다고 한다.
반면, Slow Start 는 (이름과는 참 다르게) 시작부터 빠르게 윈도우를 증가 시키고 특정 시기가 오면 윈도우를 확 줄여버리는 방식이다.
Slow Start 방식도 동일하게 처음에 패킷을 하나씩 전송한다. 패킷이 문제없이 도착하면 각각의 ACK 패킷 마다 window size를 하나씩 증가 시킨다. 즉, 윈도우 사이즈를 두배씩 증가 시킨다.
윈도우 사이즈를 빠르게 두배씩 증가시키다가 혼잡 현상이 발생시 윈도우 사이즈를 1로 확 줄여버린다.
Slow Start 방식은 윈도우 사이즈를 1개씩 늘려나가던 AIMD 방식과 다르게 지수적으로 윈도우 사이즈를 증가시켜 빠르게 네트워크의 대역폭을 사용하게 된다.
혼잡 제어 정책
이러한 TCP 회피 방식들을 활용한 다양한 혼잡 제어 정책이 존재하고, 정책들은 AIMD, Slow Start를 적절히 섞어서 사용하되 네트워크 혼잡 상황이 발생했을 때 어떻게 대처하는지에 따라서 나뉘게 된다고 한다.
또한 정책들은 '혼잡이 발생하면 윈도우 크기를 줄이거나 혹은 증가시키지 않으며 혼잡을 회피' 한다는 공통점을 가지고 있다.
그 중 빠른 재전송, 빠른 회복 등을 활용한 대표적인 정책 TCP Tahoe, TCP Reno 에 대해 공부 해 보았다!
정책들에 대해 알아보기 전에 정책 내용을 설명하면서 나올 용어들, TimeOut, 3 ACK Duplicated, ssthresh 에 해대 짚고 넘어가보자!
TimeOut
송신측이 수식측에 데이터를 보낸 이후,
- 여러가지 요인으로 인해서 보낸 데이터가 유실되었다거나
- 수신측이 데이터를 받고 전송한 ACK 응답이 유실되어
- 송신측이 일정 시간동안 응답받지 못하는 경우
3 ACK Duplicated
- 송신측이 3번이상 중복된 승인번호를 받은 상황
- 정상적으로 데이터가 전송 되지 못했음을 의미
- 어떠한 이유로 인해 수신측이 특정 시퀀스 번호 이후의 데이터를 제대로 처리하지 못한 상황
3번의 중복 승인번호를 받고 송신측이 이에 해당하는 데이터를 재전송하고 나면, 수신측은 Go back N 이나 Selective Repeat 등과 같은 오류 제어 작업에 들어가 이제 어디서부터 다시 보내면 되는 건지 송신측에 알려주게 된다.
이 때 송신측은 자신의 TimeOut 시간이 만료되지 않았어도 바로 보내야 하는 패킷을 전송할 수 있는데 이러한 대처 방식이 빠른 재전송 이다.
이러한 빠른 재전송 기법을 이용해 TimeOut 시간을 모두 기다리지 않고 바로 대응하면서 시간이 낭비되는 것을 방지할 수 있다!
TCP 에서 한두개 정도의 중복 승인 패킷으로는 네트워크가 혼잡하다고 판단하지 않는다고 한다!
ssthresh
- slow start threshold
- 여기까지만 slow start 를 사용하겠다는 의미
- 특정한 임계점을 정해놓고 윈도우 사이즈가 임계점을 넘어가면 이후부터는 AIMD 방식을 사용하여 윈도우를 증가시킴
TCP Tahoe
Tahoe 정책은 혼잡 제어의 초기 정책이고 빠른 재전송이 처음으로 도입된 정책이라고 한다.
처음에는 동일하게 Slow Start 방식으로 윈도우를 증가시키다가 ssthresh 시점 이후부터는 AIMD 방식을 사용한다.
이후 TimeOut 이나 3 ACK Duplicated 상황이 발생 시 네트워크가 혼잡하다는 것을 인지하고 ssthresh 는 혼잡상황 발생시 윈도우 사이즈의 절반으로, 윈도우 사이즈는 1로 수정하는 방식이다.
그림에서 검정색 선으로 표시된 부분이 ssthresh 를 의미하고, TimeOut 이나 3 ACK Duplicated 이 발생할 때 마다 윈도우는 1로, ssthresh는 이전 혼잡 상황 발생시 윈도우 크기의 절반으로 줄어드는 것을 확인할 수 있다.
하지만 이 방법에선 혼잡 상황이 발생할 때 마다 윈도우를 1로 초기화해 다시 증가시켜 나가는 부분이 비효율적이라 할 수 있다. 이러한 점을 개선시키기 위해 빠른 회복 을 적용한 TCP Reno 정책이 있다!
TCP Reno
TCP Tahoe 정책과 동일하지만 차이점은 바로 3 ACK Duplicated 와 TimeOut 을 구분해 대응한다는 점이다!
3 ACK Duplicated 이 발생하면 윈도우 크기를 1로 초기화 하지 않고 AIMD 처럼 윈도우 크기를 절반으로 줄이며 ssthresh 값 역시 줄어든 윈도우 값으로 설정한다.
이러한 방식으로 빠르게 윈도우 사이즈를 회복시켜 네트워크 대역폭을 사용하도록 하고, 이를 빠른 회복 (Fast Recovery) 라 한다!
TimeOut이 발생한다면 TCP Tahoe 와 동일하게 윈도우 사이즈를 1로 줄이고 Slow Start 를 시작하지만 ssthresh 값은 변경하지 않는다.
그림에서도 timeout 이 발생한 경우에는 ssthresh 값이 유지되는 것을 볼 수 있다. 즉 timeout에 비해 3 ACK Duplicated 는 그리 심각한 혼잡상황이라고 판단하지 않는 듯 하다.
나름대로 세심하게 공부 해 보았는데..! 잘 한지 모르겠다..!
CS는 참 공부할수록 어려운 것 같다 ㅎ,,
다행히 잘 정리된 양질의 포스팅을 찾아서 의미 있게 공부할 수 있었다!
