[네트워킹] TCP 흐름제어/혼잡제어

✅ TCP 통신이란 ?!

• TCP/IP 프로토콜 중 하나로 OSI 계층 모델의 관점에서 트랜스포트 계층(4계층)에 해당
• 네트워크 통신에서 신뢰적인 연결방식을 말한다.
• 기본적으로 unreliable network에서 reliable network를 보장할 수 있도록 하는 프로토콜
  • IP의 비신뢰적인 서비스에 신뢰적인 연결지향성 서비스를 추가 제공하는 방식
• TCP는 network congestion avoidence algorithm을 사용한다.

 

 

✅ TCP의 특징들

• 신뢰성(Reliable)
• 연결지향적(Connect-Oriented)
• 상위 계층과 바이트 스트림(Byte Stream)으로 주고받음 (메세지 스트림과 대조)
• 세그먼트화 (데이터를 패키징 처리함)
• 흐름제어
• 혼잡제어
• 멀티캐스트 불가능

 

TCP의 특징 중 하나인 신뢰성을 보장한다는 것은 여러 문제점이 존재한다.

1) 손실 : Packet이 손실될 수 있는 문제
2) 순서 변경 : packet의 순서가 바뀌는 문제
3) Congestion(혼잡) : 네트워크가 혼잡한 문제
4) Overload : receiver가 overload 되는 문제

이를 해결하기 위해 ! 흐름제어/혼잡제어 를 채택한다.

 

 

✅ 흐름제어/혼잡제어란 ?

TCP의 흐름제어(flow control)와 혼잡제어(congestion control)는 모두 TCP가 데이터를 안정적으로 전송하기 위해 사용하는 메커니즘이다.

 

목적

• 흐름제어: 송신 측과 수신 측 간의 데이터 전송률을 조절하여 수신 측의 버퍼 오버플로우를 방지
• 혼잡제어: 네트워크의 혼잡을 감지하고 조절하여 네트워크 붕괴를 방지하고 안정적인 데이터 전송을 유지

 

제어 대상

• 흐름제어: 수신 측의 버퍼 크기와 전송율을 제어한다.
• 혼잡제어: 네트워크 내의 패킷 손실률과 대역폭을 제어한다.

 

동작 시기

• 흐름제어: TCP 연결 수립 후, 데이터 전송 중에도 동적으로 조절된다.
• 혼잡제어: TCP 연결 수립 후, 네트워크 혼잡 상황을 감지하여 동적으로 조절된다.

 

제어 방식

• 흐름제어: TCP 수신 측은 송신 측에게 윈도우 크기를 알려주어 송신 측이 수신 측의 버퍼 상태를 파악하고 전송율을 제어한다.
  • TCP 버퍼 : 송신 측은 버퍼에 TCP 세그먼트를 보관한 후 순차적으로 전송하고 수신측은 도착한 TCP 세그먼트를 애플리케이션이 읽을 때까지 버퍼에 보관한다.
• 혼잡제어: TCP 송신 측은 패킷 손실을 감지하고 패킷 손실이 발생한 경우 전송율을 조절하여 네트워크 혼잡을 막는다.

 

따라서, 흐름제어는 수신 측의 버퍼 오버플로우를 방지하기 위해 전송율을 제어하며, 혼잡제어는 네트워크 붕괴를 방지하고 안정적인 데이터 전송을 유지하기 위해 네트워크 혼잡을 감지하고 제어한다.

 

 

TCP 전송의 전체 흐름

1) Application layer : 송신측 응용 계층이 socket에 data를 쏜다.
2) Transport layer : data를 segment화 한다. 그 후 network layer에 넘겨준다.
3) 그러면 하위 계층으로 receiving node로 전송이 된다.
이 때, sender의 sender buffer에 data를 저장하고, reciver는 receive buffer에 data를 저장한다.
4) application에서 준비가 되면 이 buffer에 있는 것을 읽기 시작한다.

따라서 flow control의 핵심은 이 receiver buffer가 넘치지 않게 하는 것이다.
따라서 receiver는 RWND(Receive Window)을 홍보한다.

• RWND : receive buffer의 여유 공간

---

✅ 흐름제어(Flow Control)

• 송신측의 데이터 처리 속도가 빠를 때 발생
• 수신측에서 제한된 저장 용량을 초과한 후 도착하는 데이터는 손실될 수 있으며, 만약 손실된다면 불필요하게 응답과 데이터 전송이 송/수신 간 빈번히 발생한다.
  → 이를 위해 송신측의 데이터 전송량을 수신측에 맞춰 조절해야 한다.

 

흐름 제어 기법

1) Stop and Wait

• 매번 전송한 패킷에 대해 확인-응답을 받아야만 그 다음 패킷을 전송하는 방법
• 한계 : 패킷을 하나씩 보내기 때문에 비효율적이다.

 

2) Sliding Window(Go Back N ARQ)

• 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법 
• 목적 : 전송은 되었지만, ACK를 받지 못한 byte의 숫자를 파악하기 위해 사용하는 protocol
  • LastByteSent - LastByteAcked <= ReceiveWindowAdvertised
    마지막에 보내진 바이트 - 마지막에 확인된 바이트 <= 남아있는 공간 == 현재 공중에 떠 있는 패킷의 수 <= sliding window
• 윈도우 크기
  최초의 윈도우 크기는 3-way Handshake를 통해 수신측 윈도우 크기로 설정되며, 이후 수신측의 버퍼에 남아있는 공간에 따라 변한다(가변적).
  윈도우 크기는 수신측에서 송신측으로 ACK를 보낼 때 TCP 헤더(window size)에 담아서 보낸다.
  즉, 윈도우는 메모리 버퍼의 일정 영역이라고 생각하면 된다.
  
  
• 동작 방식
  먼저 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는대로 윈도우를 옆으로 옮김으로써
  그 다음 패킷들을 전송한다.
  

  

  Sliding Window Protocol

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

 

• 세부 구조
  • 송신 버퍼
    

    

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

    

  • 송신 윈도우
    

    

    • 수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정하게 되면 흐름제어가 가능하다.
  • 송신 윈도우 이동
    

    

    • Before : 203~204를 전송하면 수신측에서는 확인응답 203을 보내고, 송신측은 이를 받아
      After 상태와 같이 수신 윈도우를 203~209 범위로 이동시킨다.
    • After : 205~209가 전송 가능한 상태
  • 재전송
    송신측이 일정시간 동안 수신측으로부터 ACK를 받지 못하면 패킷을 재전송한다. 
    송신측에서 재전송을 했는데 수신측의 버퍼에 남는 공간이 없는 경우면 문제가 생긴다. 
    -> 이를 해결하기 위해 수신측은 ACK를 보내면서 남는 버퍼의 크기(윈도우 크기)도 함께 보내준다.

 

 

✅ 혼잡제어(Congestion Control)

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

흐름 제어 기법

• AIMD(Additive Increase / Multiplicative Decrease)
  • 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
  • 패킷 전송에 실패하거나 일정 시간을 넘으면 패킷의 보내는 속도를 절반으로 줄인다.
  • 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형상태로 수렴하게 되는 특징이 있다.
  • 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

 

• Slow Start (느린 시작)
  • AIMD 방식이 네트워크의 수용량 주변에서는 효율적으로 작동하지만, 처음에 전송 속도를 올리는데 시간이 오래 걸리는 단점이 존재했다.
  • Slow Start 방식은 AIMD와 마찬가지로 패킷을 하나씩 보내면서 시작하고, 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려준다. 즉, 한 주기가 지나면 window size가 2배로 된다.
  • 전송속도는 AIMD에 반해 지수 함수 꼴로 증가한다. 대신에 혼잡 현상이 발생하면 window size를 1로 떨어뜨리게 된다.
  • 처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만, 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있다.
  • 그러므로 혼잡 현상이 발생하였던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킨다.

 

• Fast Retransmit (빠른 재전송)
  • 빠른 재전송은 TCP의 혼잡 조절에 추가된 정책이다.
  • 패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 된다.
  • 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있다.
  • 중복된 순번의 패킷을 3개 받으면 재전송을 하게 된다. 약간 혼잡한 상황이 일어난 것이므로 혼잡을 감지하고 window size를 줄이게 된다.

 

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

 

 

참고

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