흐름 제어(Flow Control) / 혼잡 제어(Congestion Control)

흐름 제어(Flow Control)

송신 측과 수신 측의 TCP 버퍼 크기 차이로 인해 생기는 데이터 처리 속도 차이를 해결하기 위한 기법

• 송신자가 데이터를 전송하는 속도가 수신자가 데이터를 처리하는 속도보다 빠른 상황에 필요
• 수신자가 패킷을 지나치게 많이 받지 않도록 조절
• 수신자(receiver)가 송신자(sender)에게 현재 자신의 상태를 feedback한다.
• 수신 측에서 제한된 저장 용량(버퍼)을 초과한 이후에 도착하는 패킷은 손실되며 만약 손실된다면 불필요한 추가 패킷을 전송한다.
• 송신자의 데이터 전송 속도를 조절

흐름제어 기본 과정

1. 송신자가 수신자에게 데이터를 전송
2. 수신자는 송신자에게 데이터를 받을 때마다 자신의 남은 버퍼 공간을 알려준다.
3. 송신자는 수신자가 보낸 정보를 보고 자신의 데이터 전송 속도를 조절

Stop and Wait

• 송신자는 수신자에게 패킷을 하나씩 전송하고 ACK을 받아야 다음 패킷을 전송한다.

Sliding Window

• 송신자는 한 번에 여러 개의 데이터를 보내고 수신자의 응답을 기다린다.
• 수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하여 제어
• 송신 버퍼의 범위는 수신 측의 여유 버퍼 공간을 반영하여 동적으로 바뀜

재전송

• 송신측은 일정 시간 동안 수신 측으로부터 ACK 응답을 받지 않으면 패킷을 재전송
• 만약 송신 측에서 패킷을 재전송하였을 때, 패킷이 손실된 경우가 아니고 수신 측의 버퍼 여유공간이 없어서 생긴 상황이면 문제가 된다.
• 해결 : 수신 측은 ACK을 전송할 때 남은 버퍼 크기(윈도우 크기)도 같이 전송

혼잡 제어(Congestion Control)

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

• 데이터 양이 라우터가 처리할 수 있는 양을 초과하면 라우터가 처리하지 못한다.
  • 라우터 : 네트워크에서 송신자가 보낸 데이터를 알맞은 수신자에게 보내주는 장치
• 송신 측은 라우터가 처리하지 못한 데이터를 손실 데이터로 간주하여 계속해서 재전송한다 ~> 네트워크 혼잡
• 해결방식의 공통점 : 혼잡이 발생하면 윈도우 크기를 줄이거나 증가시키지 않으며 혼잡을 회피한다

AMID(Additive Increse/Multicative Decrease)

• 합 증가, 곱 감소
• 처음에 패킷을 하나씩 전송하다가 패킷이 문제없이 도착하면 윈도우 크기를 1씩 증가시키며 전송
• 만약 패킷 전송에 실패하게 되면 네트워크가 혼잡하다고 판단하고 패킷 전송 속도를 절반으로 줄인다
• 단점 : 윈도우 크기를 너무 조금씩 늘리기 때문에 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기까지 너무 오랜시간이 걸린다

Slow Start

• 윈도우 크기를 2배로 늘린다.(AMID에서 윈도우 크기를 너무 조금씩 늘린다는 단점 보안)
• 그러다 혼잡현상이 발생하면 창 크기를 1로 떨어드린다.
• 그 후 혼잡현상이 발생했던 창 크기의 절반까지는 이전처럼 지수 함수 꼴로(2배로) 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가

Fast Recovery

• 혼잡한 상태가 되면 창 크기를 1로 줄이지 않고 반으로 줄이고 선형 증가시키는 방식
• 혼잡제어를 한 번 겪은 이후에는 AMID 방식으로 동작

참고
https://steady-coding.tistory.com/507
https://www.geeksforgeeks.org/flow-control-in-data-link-layer/
https://80000coding.oopy.io/f5fe190f-bbad-4956-8789-36546f42be83