TCP/IP 흐름제어, 혼잡제어

흐름 제어

수신 측이 송신 측보다 데이터 처리 속도가 빠르면 문제 없지만, 송신 측의 속도가 빠를 경우 문제가 생긴다.

 

수신 측에서 제한된 저장 용량을 초과한 이후에 도착하는 패킷은 손실될 수 있으며,

만약 손실된다면 불필요한 추가 패킷 전송이 발생한다.

따라서 송신측의 패킷 전송량을 수신측에 따라 제어해야 한다.

 

흐름 제어는 위와 같이 송신 측과 수신 측의 TCP 버퍼 크기 차이로 인해 데이터 처리 속도 차이를 해결하기 위한 기법이다.

 

전체 전송 과정

1. Application Layer : 송신측 Application Layer 가 소켓에 데이터를 입력.
2. Transport Layer : 데이터를 세그먼트로 감싸고 Network Layer 에 전달.
3. 수신측 노드로 세그먼트가 전송되며 동시에 송신측의 Send Buffer 와 수신측의 Receive Buffer 각각에 데이터가 저장.
4. 수신측 Application Layer 에서 준비가 되면, Receive Buffer 에 있는 데이터를 읽기 시작.

결국 Receive Buffer 가 넘치지 않는 것이 흐름제어의 핵심이다

👉 이를 위해 RWND(Receive Window, Receive Buffer)의 남은 공간을 송신측에 피드백한다.

 

 

---

 

흐름제어 방식

Stop and Wait(정지 대기)

매번 전송한 패킷에 대해 확인 응답을 받으면 다음 패킷을 전송하는 방식이다.

하지만 패킷을 하나씩 보내기 때문에 비효율적인 방법이다.

 

 

Sliding Window (Go Banck N ARQ)

수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답없이 패킷을 전송할 수 있게 하여

데이터 흐름을 동적으로 조절하는 제어 기법이다.

 

최초의 윈도우 크기는 호스트들의 3 way handshaking을 통해 수신 측 윈도우 크기로 설정되며,

이후 수신 측의 버퍼에 남아있는 공간에 따라 변한다.

 

윈도우 크기는 수신측에서 송신측으로 확인 응답을 보낼 때 TCP 헤더에 담아서 보낸다.

즉, 윈도우는 메모리 버퍼의 일정 영역이라고 생각하면 된다.

 

 

정리

1. 최초의 수신자는 윈도우 사이즈를 7로 설정한다.
2. 송신자는 수신자의 확인 응답을 받기 전까지 데이터를 보낸다.
3. 수신자는 확인 응답을 송신자에게 보내면, 슬라이딩 윈도우 사이즈를 충족할 수 있게 윈도우를 옆으로 옮긴다.
4. 이 후 데이터를 다 받을 때까지 위 과정을 반복한다.

 

 

---

 

혼잡 제어

송신측의 데이터 전달과 네트워크 상의 데이터 처리 속도 차이를 해결하기 위한 기법이다.

 

데이터의 양이 라우터가 처리할 수 있는 양을 초과하면 초과된 데이터는 라우터가 처리하지 못한다.

이 때 송신 측에서는 라우터가 처리하지 못한 데이터를 손실 데이터로 간주하고 계속 재전송하여 네트워크를 혼잡하게 한다.

그래서 송신 측의 전송 속도를 적절히 조절해 줘야 하는데, 이것을 혼잡 제어라고 한다.

 

 

---

 

 

혼잡 제어 기법

AIMD(Additive Increse / Mulcicativa Decrease) : 합 증가 / 곱 감소 방식

 

처음에 하나의 패킷을 보내고 문제 없이 도착하면 윈도우의 크기를 1씩 증가시키며 전송한다.

만약, 전송에 실패하면 윈도우 크기를 반으로 줄인다.

 

윈도우 크기를 너무 조금씩 늘려 네트워크의 모든 대역을 활용하기 때문에 제대로 된 속도로 통신하기에 오래 걸린다.

 

Slow Start : 느린 시작

 

윈도우 크기를 1, 2, 4, 8.... 과 같이 지수적으로 증가시키다가 혼잡이 감지되면 윈도우의 크기를 1로 줄이는 방식이다.

 

이 방식은 보낸 데이터의 ACK 가 도착할 때마다 윈도우 크기를 증가시키기 때문에,

처음에는 윈도우가 조금 느리게 증가해도, 시간이 지날수록 점점 빠르게 증가하는 장점이 있다.

 

 

Fast Retransmit : 빠른 재전송

 

패킷을 받는 수신자 입장에선 세그먼트로 분할된 내용들이 순서대로 도착하지 않을 수 있다.

이럴 때 수신 측에서 순서대로 잘 도착한 마지막 패킷의 다음 순번을 ACK 패킷에 같이 보낸다.

그리고 이런 중복 ACK 를 3개 받으면 재전송이 이루어진다.

 

송신측은 자신이 설정한 시간이 안 지나도 바로 해당 패킷을 재전송할 수 있기 때문에 빠른 재전송을 유지할 수 있다.

 

Fast Recovery : 빠른 회복

 

혼잡한 상태가 되면 윈도우 크기를 1로 줄이지 않고 반으로 줄이고 선형 증가시키는 방법이다.

이 방법을 적용하면 혼잡 상황을 한 번 겪고나서부터는 AIMD 방식으로 동작한다.

 

 

---

 

 

혼잡 제어 정책

TCP에는 Tahoe, Reno, New Reno, Cubic, Ealstic-TCP까지 다양한 혼잡 제어 정책이 존재한다.

 

이런 혼잡 제어 정책들은 공통적으로

혼잡이 발생하면 윈도우 크기를 줄이거나 증가시키지 않으면 혼잡을 회피한다는 전제를 깔고 있다.

최근에 나온 방법은 예전 방법들에 비해 더 똑똑하게 혼잡 상황을 감지하고

네트워크 대역을 최대한 빠르고 안전하게 활용할 수 있는 방향으로 개발된 것이다.

 

여기선 가장 대표적인 Tahoe와 Reno만 설명한다.

 

Tahoe 와 Reno 는 처음에는 Slow Start 방식을 사용하다가

네트워크가 혼잡하다고 느껴졌을 때 AMID 방식으로 전환하는 방법을 사용하는 정책들이다.

 

빨간색이 Tahoe, 초록색이 Reno의 윈도우 크기다.

 

위 그래프의 Y축은 혼잡 윈도우, X축은 시간으로 하여 Tahoe와 Reno의 작동 방식을 설명하고 있다.

본격적으로 Tahoe와 Reno를 알아보기 전 , 이 그래프를 이해하기 위해 

 3 ACK duplicate , Timeout 용어와 그래프 상승 폭이 변하고 있는 지점인 Threshold 용어를 알아 보자.

 

Timeout

송신 측이 보낸 데이터 자체가 유실되었거나, 수신 측이 응답으로 보낸 ACK가 유실되는 경우를 뜻한다.

 

3 ACK Duplicate

송신 측이 3번 이상 중복된 ACK 번호를 받은 상황.

 

ssthresh (임계점)

여기까지만 Slow Start를 사용하겠다는 의미를 가진다.

 

송신 측은 본격적인 통신이 시작하기 전에 ssthresh 값을 자신의 혼잡 윈도우의 절반 크기인 0.5 MSS으로 초기화하고,

이후 어떤 혼잡 제어 방법을 사용하냐에 따라 다르게 대처하게된다.

 

---

 

TCP Tahoe

Slow Start 를 사용한 혼잡 제어 정책의 초기 버전으로, 위에 설명한 빠른 재전송 기법이 처음으로 도입된 방법이다.

 

Tahoe 이후의 혼잡 제어 정책은 Tahoe 와 마찬가지로 빠른 재전송 기법을 기본으로 사용하고,

효율을 위해 몇 가지 더 덧붙였다.

 

Tahoe는 처음에는 Slow Start를 사용하여 자신의 윈도우 크기를 지수적으로 빠르게 증가시키다가

ssthresh를 만난 이후부터는 AIMD에서 사용하는 합 증가 방식을 사용하여 선형적으로 윈도우 크기를 증가시킨다.

 

그러다가 ACK Duplicated 나 Timeout 이 발생하면 네트워크 혼잡이 발생했다고 판단하고,

ssthresh 와 윈도우 크기를 수정하게 된다.

 

 

위 그래프의 청록색 선은 송신 측의 혼잡 윈도우 크기를, 굵은 검정 선은 ssthresh 값을 보여준다.
이 시나리오에서 송시 측의 혼잡 윈도우 크기는 8로 초기화되었고, 그에 따라 ssthresh 는 8 * 0.5인 4로 설정됐다.

송신 측은 임계점을 만나기 전까지 Slow Start 방식을 사용하여 자신의 윈도우 크기를 지수적으로 증가시키다가
ssthresh를 넘어선 이후론 선형적으로 증가시키고 있다.

이때 3 ACK Duplicated나 Timeout과 같은 혼잡 상황이 발생하면 어떻게 될까?
그래프를 보면 가장 처음 혼잡 상황이 발생한 상태의 혼잡 윈도우 크기는 6이다.

이때 송신 측은 ssthresh 를 6의 절반인 3으로 변경하고, 자신의 혼잡 윈도우 크기를 다시 1로 변경하는 것이 확인된다.
이후 다시 Slow Start 로 시작하여 임계점에 도달하면 합 증가로 변경하는 방법을 반복한다.

즉, 이 전 혼잡 지점을 기억하고 그 지점이 가까워지면 윈도우 크기를 조금씩 올리는 원리이다.

하지만 Tahoe의 단점은 초반의 Slow Start 구간에서 윈도우 크기를 키울 때 너무 오래 걸린다는 것이다.
전체적으로 보면 합 증가 방식보단 지수 증가 방식이 빠르지만,
혼잡 상황이 발생했을 때 다시 윈도우 크기를 1부터 키워나가야 하는 것은 낭비라고 볼 수 있다.

그래서 이를 개선한 것이 빠른 회복 방식을 활용한 TCP Reno이다.

 

TCP Reno

TCP Reno는 TCP Tahoe 이후에 나온 정책으로, 

Tahoe와 마찬가지로 Slow Start로 시작하여 임계점을 넘어서면 합 증가로 변경하는 방법이다.

 

그러나 Tahoe는 명확한 차이가 있는데, 바로 3 ACK Duplicated와 Timeout을 구분한다는 것이다.

Reno는 3개의 중복 ACK가 발생했을 때, 윈도우 크기를 1로 줄이는 것이 아니라 AIMD처럼 반으로만 줄이고

sshthresh를 줄어든 윈도우 값으로 정하게 된다.

 

 

Reno는 Tohoe와 다르게 3개의 중복 ACK가 발생했을 때 반으로 줄인 후 합증가를 하는데,

이 방식은 Taho에 비해 빠르게 원래 윈도우 크기에 도달할 수 있기 때문에 빠른 회복이라 불린다.

 

이 때 ssthresh는 줄어든 윈도우의 크기와 동일하게 설정하게 된다.

그래프에서도 혼잡 상황이 발생하자 혼잡 윈도우 크기를 6에서 3으로 줄이고 ssthresh 또한 3으로 설정한다.

 

만약 타임아웃에 의해 데이터가 손실되면 Tahoe와 마찬가지로 윈도우 크기를 1로 줄여버리고

Slow Start를 진행하고 이때는 ssthresh를 변경하지 않는다.

 

즉, ACK가 중복된 상황과 타임아웃이 발생한 상황을 구분하면서 대처를 다르게 하는 것이다.

ACK 중복은 타임아웃에 비해 그리 큰 혼잡이 아니라 생각하고 크기를 1로 줄이지도 않기 때문에

어느정도 혼잡 상황에 중요성을 따지는 것을 알 수 있다.

 

https://steady-coding.tistory.com/507

[네트워크] TCP/IP 흐름 제어 & 혼잡 제어

 

https://yeoneeds.tistory.com/25

[Network] TCP/IP 흐름제어, 혼잡제어

 

https://evan-moon.github.io/2019/11/26/tcp-congestion-control/

사이 좋게 네트워크를 나눠 쓰는 방법, TCP의 혼잡 제어