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

1. Flow Control

수신측이 송신측보다 속도가 빠른 것은 아무런 문제가 되지 않지만, 송신측이 수신측보다 빠르다면 문제가 발생할 수 있습니다.

예를 들어, 수업을 듣는 A, B라는 학생이 있다고 해봅시다. A는 똑똑하여 교수의 설명을 듣는 즉시 이해하고 받아들입니다. 수업내용이라는 데이터가 쌓일 여유도 없이 흡수하고 있습니다. 반면 B 학생은 이해가 A에 비하여 느립니다. 이전 수업내용을 이해하기 전, 새로운 내용이 들어오게 됩니다.

A의 경우는 문제가 없지만, B의 경우는 이전 내용을 처리하다가 새로운 내용을 놓칠 수 있습니다.

이처럼 수신측이 더 느릴경우 발생하는 문제점을 대처하기 위하여, 강제로 송신측의 데이터 전송을 조절하는 방법입니다.

1) Stop and Wait

매번 전송한 패킷에 대하여 확인응답을 받아야만 다음 패킷을 전송하는 방법입니다.

2) Sliding windows

수신 측에서 윈도우 사이즈를 설정하여 이 크기만큼 세그먼트를 전송하는 기법입니다.

이 윈도우 사이즈는 수신측의 여유 버퍼 공간을 반영하여 동적으로 결정합니다.

2. Congestion Control

송신측의 데이터 전달과 네트워크의 처리속도 차이를 조절하기 위한 기법입니다.

송신측의 데이터는 기존에 연결된 대형 네트워크를 통해 전달됩니다. 이 네트워크의 라우터에 트래픽이 몰리게 되는 경우, 라우터는 자신에게 온 데이터를 모두 처리할 수 없게 됩니다. 이렇게 되면, 송신측은 재전송을 하고 더욱 라우터의 혼잡을 가중시킵니다. 결국 오버플로우가 일어나거나 데이터 손실이 발생하게 될 것입니다.

이러한 네트워크 상에서 혼잡 문제를 피하기 위하여 송신측의 전송 속도를 조절하는 방법입니다.

1) AIMD (Additive Increase/Multiplicative Decrease)

처음에 패킷 하나를 보내는 것으로부터 시작합니다. 이후, 패킷이 정상적으로 도착하면 윈도우 크기를 1씩 증가시켜가며 전송하는 방법입니다. 

만약 패킷 전송이 실패 혹은 일정 시간이 넘어가면 윈도우 사이즈를 절반으로 줄입니다.

전체적으로 여러 호스트들에게 공평한 방식이나, 연결 초기에 높은 대역폭을 사용하지 못하여 전송 시간이 오래 걸리게 됩니다. 또한, 네트워크의 혼잡을 예측하지는 못합니다. 즉, 미리 혼잡을 예방하지는 못하고 대처만 하는 방법입니다.

2) Slow start

AIMD처럼 1 패킷을 보내는 것부터 시작합니다. 그리고 패킷이 성공적으로 전송되면 윈도우 사이즈를 2배씩 증가시킵니다.

이후, 혼잡현상이 발생하면 사이즈를 1로 떨어트리고, 이전 혼잡현상이 발생하였던 창 크기의 절반까지는 지수 함수 꼴로 창 크기를 증가시킵니다. 그리고 이후부터는 1씩 증가합니다.

단, 처음에 전송 속도를 올리는데 너무 길다는 단점이 여전히 존재합니다.

3) Fast Recovery

혼잡 상태시 창 크기를 1로 줄이는 것이 아니라 반으로 줄이고 선형 증가시키는 방법입니다.

1부터 시작하는 것이 아니니까, 금방 회복할 수 있겠죠?

4) Fast Retransmit

수신측에서 중간에 유실된 패킷의 다음 패킷 순번을 ACK에 실어서 보냅니다. 그러면 송신 측은 한 순번에 중복된 ACK를 받게 되고 데이터의 유실을 알 수 있습니다.  그리고 유실된 패킷을 재전송 할 수 있게 됩니다. 송신측은 3개의 중복된 순번을 받으면 재전송을 하고, 유실이 일어났다는 것은 혼잡한 상황이라는 의미이므로 윈도우 사이즈를 감소시킵니다.