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

오늘의 네트워크 포스팅 주제는 TCP/IP 흐름제어, 혼잡제어이다.

면접에서 많이 나오는 주제인 것 같으니 피드백 많이 해주시면 좋슴니다 🙃

 

☑️ 흐름제어/혼잡제어란?

 

✅ 흐름제어 (endsystem 대 endsystem, flowcontrol) :

송신측과 수신측 사이의 데이터 처리 속도 차이(흐름)을 해결하기 위한 기법

만약, 송신측의 전송 속도가 수신측의 처리 속도보다 빨라서 송신측의 전송량 > 수신측의 수신량 일 경우 전송된 패킷은 수신측의 큐를 넘어서 손실될 수 있음 ➡ 송신측의 패킷 전송량을 수신측에 따라 제어해야 함

 

잠깐! 패킷이란?: 

인터넷 내에서 데이터를 보내기 위한 경로 배정(라우팅)을 효율적으로 하기 위해서 데이터를 여러 개의 조각으로 나누어 전송을 하는데, 이때 조각을 패킷이라고 한다. 

 

• 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
• Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
• 기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback 한다는 점

[전송의 전체 과정]

1. Application Layer : 송신측 Application Layer 가 소켓에 데이터를 입력

2. Transport Layer : 데이터를 세그먼트로 감싸고 Network Layer 에 전달

3. 수신측 노드로 세그먼트가 전송됨. 동시에 송신측의 Send Buffer 와 수신측의 Receive Buffer 각각에 데이터가 저장됨.

4. 수신측 Application Layer 에서 준비가 되면, Receive Buffer 에 있는 데이터를 읽기 시작함

5. 따라서, Receive Buffer 가 넘쳐나지 않도록 하는 것이 흐름 제어의 핵심!

→ 이를 위해 RWND(Receive Window, Receive Buffer 의 남은 공간) 을 송신측에 계속하여 피드백함

 

✅ 흐름제어 방식

• Stop and Wait(정지 대기) : 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
• 단점: 패킷을 하나씩 보내기 때문에 비효율적

• Sliding Window (Go Back N ARQ)
  • 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어기법
  • 수신 측에서 설정한 윈도우 크기만큼은 송신 측에서 확인 응답ACK를 받기 전에 전송 가능.
  • 송신 버퍼의 범위는 수신 측의 여유 버퍼 공간을 반영하여 동적으로 바뀜.
• 동작방식 : 먼저 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인(ACK)되는대로 이 윈도우를 옆으로 옮김으로써 그 다음 패킷들을 전송
  •  

  

• Window : TCP/IP를 사용하는 모든 호스트들은 송신하기 위한 것과 수신하기 위한 2개의 Window를 가지고 있다. 호스트들은 실제 데이터를 보내기 전에 '3 way handshaking'을 통해 수신 호스트의 receive window size에 자신의 send window size를 맞추게 된다.

 

🔍세부구조

1. 송신 버퍼 

   

    200 이전의 바이트는 이미 전송되었고, 확인응답을 받은 상태 - 200 ~ 202 바이트는 전송되었으나 확인응답을 받지 못한 상태,  203 ~ 211 바이트는 아직 전송이 되지 않은 상태
2. 수신 윈도우

 

1. 송신 윈도우

   

    - 수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정하게되면 흐름제어가 가능하다.
   
   • 저 그림에서 수신 윈도우 크기: 7
2. 송신 윈도우 이동

   

    - Before : 203 ~ 204를 전송하면 수신측에서는 확인 응답 203을 보내고, 송신측은 이를 받아 after 상태와 같이 수신 윈도우를 203 ~ 209 범위로 이동 - after : 205 ~ 209가 전송 가능한 상태
   
   
3. Selected Repeat

 

✅ 혼잡제어(Congestion Control):

송신측의 데이터 전달과 네트워크 상의 데이터 처리 속도 차이를 해결하기 위한 기법
: 송신측에서 보내는 데이터의 전송 속도를 제어

• 송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달된다. 만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 된다. 이런 경우 호스트들은 또 다시 재전송을 하게되고 결국 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생시키게 된다. 따라서 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송속도를 강제로 줄이게 되는데, 이러한 작업을 혼잡제어라고 한다.
• 또한 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어라고 한다.
• 흐름제어가 송신측과 수신측 사이의 전송속도를 다루는데 반해, 혼잡제어는 호스트와 라우터를 포함한 보다 넓은 관점에서 전송 문제를 다루게 된다.

✅ 해결 방법

• AIMD(Additive Increase / Multiplicative Decrease) : 합 증가/ 곱 감소 알고리즘

• • 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
  • 패킷 전송에 실패하거나 일정 시간을 넘으면 패킷의 보내는 속도를 절반으로 줄인다.
  • 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형상태로 수렴하게 되는 특징이 있다.
  • 문제점:
    • 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 된다. 
    • 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.
• Slow Start (느린 시작)
  • AIMD 방식이 네트워크의 수용량 주변에서는 효율적으로 작동하지만, 처음에 전송 속도를 올리는데 시간이 오래 걸리는 단점이 존재했다.
  • Slow Start 방식은 AIMD와 마찬가지로 패킷을 하나씩 보내면서 시작하고, 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려준다. 즉, 한 주기가 지나면 window size가 2배로 된다.
  • 즉 윈도우의 크기를 1, 2, 4, 8, ...과 같이 지수적으로 증가시키다가 혼잡이 감지되면 윈도우 크기를 1로 줄이는 방식이다.
  • 전송속도는 AIMD에 반해 지수 함수 꼴로 증가한다. 대신에 혼잡 현상이 발생하면 window size를 1로 떨어뜨리게 된다.
  • 처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만, 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있다.
  • 그러므로 혼잡 현상이 발생하였던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킨다.

슬로우 스따또

 

• Fast Retransmit (빠른 재전송)
  • TCP는 지금까지 받은 데이터 중 연속되는 패킷의 마지막 순번 이후를 ACK 패킷에 실어서 보낸다.
  • 그래서 송신 측이 아래처럼 3, 4번을 보내더라도 ACK 2 를 중복해서 받는다.
  • 그러면 timeout이 발생하기 전이라도 송신 측은 문제가 되는 2번 패킷을 재전송한다.
  • 그리고 혼잡한 상황이라고 판단해서 윈도우 크기를 줄인다.
  • 3 ACK Duplicated : 송신 측이 3번 이상 중복된 ACK 번호를 받은 상황

    

    빠른 재전송

• Fast Recovery (빠른 회복)
  • 혼잡한 상태가 되면 window size를 1 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다. 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.

 

☑️ 혼잡 제어 정책

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

 

이러한 혼잡 제어 정책들은 공통적으로 혼잡이 발생하면 윈도우 크기를 줄이거나, 혹은 증가시키지 않으며 혼잡을 회피한다 라는 전제를 깔고 있다.

 

모든 정책을 다룰 수는 없으니, 대표적인 정책인 Tahoe와 Reno를 다루려고 한다.

 

Tahoe와 Reno는 기본적으로 처음에는 Slow Start 방식을 사용하다가 네트워크가 혼잡하다고 느껴졌을 때는 AIMD 방식으로 전환하는 방법을 사용하는 정책이다.

 

1. TCP Tahoe

• 처음에는 Slow Start 방식을 사용하다가 임계점에 도달하면 AIMD 방식 사용
• 그러다 3 ACK 순번 중복(중간패킷유실, 위에 빠른 재전송 설명 참고)이나 타임아웃이 발생하면 혼잡이라고 판단하여 임계점(ssthresh)은 혼잡이 발생한 윈도우 크기의 절반으로, 윈도우 크기는 1로 줄임
• 잠깐! 타임아웃이 뭔데? 임계점은 뭔데?
  • 타임아웃: 송신 측이 보낸 데이터 자체가 유실되었거나, 수신 측이 응답으로 보낸 ACK가 유실되는 경우
  • 임계점: Slow Start Threshold(ssthresh) 를 뜻하는 것으로, 여기까지만 Slow Start를 사용하겠다는 의미를 가짐

 

tahoe, 까만선이 ssthresh

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

 

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

 

이 상황에서 3 ACK Duplicated나 Timeout과 같은 혼잡 상황을 만나면 어떻게 될까?

 

그래프를 보면 처음 혼잡 상황이 발생한 상태의 혼잡 윈도우 크기는 6이며, 그에 따라 ssthresh를 3으로 변경하고, 자신의 혼잡 윈도우 크기를 1로 줄였다. 이후 다시 Slow Start로 시작하여 임계점에 도달하면 AIMD를 시작한다.

 

이 정책은 한 번 혼잡 상황이 발생한 지점을 기억하고 그 지점이 가까워지지 않도록 합리적으로 조절하고 있다.

 

하지만, 초반의 Slow Start 구간에 윈도우 크기를 늘릴 때 오래 걸린다는 단점이 있고, 혼잡 상황이 발생했을 때 다시 윈도우 크기를 1에서부터 시작해야 한다는 단점이 있다. 그래서 TCP RENO 가 등장했다. 

 

2. TCP Reno

TCP Reno는 TCP Tahoe 이후에 나온 정책으로, Tahoe와 마찬가지로 Slow Start로 시작하여 임계점을 넘어서면 AIMD을 사용한다. 다만, Tahoe와는 다르게 3 ACK Duplicated와 Timeout 혼잡 상황을 구분한다.

 

reno, (까만선이 ssthresh)

 

Reno는 3개의 중복 ACK가 발생했을 때, 윈도우 크기를 1로 줄이는 것이 아니라 AIMD처럼 반으로만 줄이고 sshthresh를 줄어든 윈도우 값으로 정하게 된다. 이 방식을 빠른 회복이라고 부른다.

 

그러나 Timeout에 의해서 데이터가 손실되면 Tahoe와 마찬가지로 윈도우 크기를 바로 1로 줄여버리고 Slow Start를 진행한다. 이때 ssthresh를 변경하지는 않는다.

 

즉, Reno는 ACK 중복은 Timeout에 비해 그리 큰 혼잡이 아니라고 가정하고 혼잡 윈도우 크기를 1로 줄이지도 않는다는 점에서 혼잡 상황의 우선 순위를 둔 정책이라 볼 수 있다.