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

TCP/IP라고 언급한 이유?

흐름제어와 혼잡제어가 TCP의 주요 기능이긴하지만 IP프로토콜의 위에서 동작하기 때문

즉, IP프로토콜은 데이터그램을 목적지까지 전송하는 역할을 담당하기 때문에 TCP는 그 위에 흐름제어와 혼잡제어, 신뢰성 등의 기능을 제공하기 때문에 TCP/IP라고 언급한 것입니다.

흐름 제어(Flow Control)란?

• EndSystem 대 EndSystem
• 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
  • 수신측이 송신측보다 데이터 처리 속도가 빠르면 문제 없지만, 송신측의 속도가 빠를 경우 문제가 생깁니다.
• Flow Control은 receiver가 packet을 지나치게 많이 받지않도록 조절하는 것
  • 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있으며, 만약 손실된다면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 빈번이 발생한다.
• 기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback 합니다.

이렇게 문제가 생기는 점을 줄이기 위해 송신측의 데이터 전송량을 수신측에 따라 조절해야 합니다.

해결 방법

• Stop and Wait : 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법

• Sliding Window (Go Back N ARQ)
  • 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어기법
  • 목적은 전송은 되었지만, acked를 받지 못한 byte의 숫자를 파악하기 위해 사용되는 프로토콜
  • LastByteSent - LastByteAcked ≤ ReceivercWindowAdvertised
    (마지막에 보내진 바이트 - 마지막에 확인된 바이트 ≤ 남아있는 공간)
  • 동작 방식 : 먼저 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는대로 이 윈도우를 옆으로 옮김으로써 그 다음 패킷들을 전송
    
    
  • 
  • Window : TCP/IP를 사용하는 모든 호스트들은 송신하기 위한 것과 수신하기 위한 2개의 window를 가지고 있습니다. 호스트들은 실제 데이터를 보내기 전에 3 Way Handshaking을 통해 수신 호스트의 receive window size에 자신의 send window size를 맞추게 됩니다.
    
    
    

세부 구조

 

1. 송신 버퍼

• 200이전 (200 오른쪽)의 바이트는 이미 전송되었고, 확인응답을 받은 상태
• 200~202바이트는 전송되었으나, ACK(확인응답)을 받지 못한 상태
• 203~211 바이트는 아직 전송이 안된 상태

 

 

 

  2. 수신 윈도우

• 수신 프로세스가 처리할 바이트는 194바이트 부터입니다.
• 수신 윈도우는 200의 수신을 기다립니다.

 

 

3. 송신 윈도우

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

4. 송신 윈도우 이동

 

• Before 상태에서 203~204를 전송하면 수신측에서 확인응답으로 203을 보내준다.
• 송신측은 이를 확인 응답을 받아 After 상태와 같이 수신 윈도우를 203~209범위도 이동한다.
• 205~209가 전송한 상태가 된다.

 

---

 

 

 

혼잡제어란?

 

 

혼잡제어는 네트워크가 과부화되지 않도록 데이터를 전송하는 속도를 조절하는 방법입니다. 네트워크의 과부화는 라우터와 스위치 등 여러 곳에서 발생할 수 있습니다.

• 데이터 전송속도를 동적으로 조절하여 네트워크 혼잡을 예방하고 해결하는데 사용하는 AIMD
  • Addtive Increase, Multiplicative Decrease
    (선형 증가, 기하급수적 감소)의 약자
• TCP는 이를 해결하기 위해 천천히 데이터를 전송하다가 속도를 올리는 Slow Start
• 혼잡해지기 전에 속도를 천천히 증가시키는 Congestion Avoidance
• 데이터 손실을 빠르게 감지하고 재전송하는 Fast Retransmit
• 손실 후 전송 속도를 줄였다가 회복하는 Fast Recovery
  
  
  

1. AIMD

• 패킷을 하나씩 보내고 문제없이 도착하면 윈도우 크기(단위시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
• 만약 패킷전송을 실패하거나 일정시간이 넘으면 패킷을 보내는 속도를 절반으로 줄이게된다.
• 매우 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 불리하지만, 시간이 지날 수록 평형상태로 수렴하는 특징이 있습니다.
• 문제점으로는 초기 네트워크의 높은 대역폭을 사용 못하여 오랜 시간이 걸리고, 혼잡해지는 상황을 미리 감지하지 못해 네트워크 혼잡을 경험한 후 대역폭을 조정하는 방식입니다.
  
  
  

2. Slow Start

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

3. Fast Retransmit

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

4. Fast Recovery

• 혼잡한 상태가 되면 Window Size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법입니다. 이 정책까지 적용하면 혼잡 상황을 한 번 겪고 나서부터는 순수한 AIMD방식으로 동작하게 됩니다.

 

 

출처 : gyoogle.dev