TCP 흐름제어 혼잡제어

flow control(흐름 제어)

송신 측과 수신 측의 데이터 처리 속도 차이를 해결하기 위한 기법이다.

수신 측이 송신 측보다 속도가 빠른 것은 아무 문제가 없다. 하지만 송신 측이 수신 측보다 속도가 빠르면 문제가 발생한다.

수신 측에서 수신된 데이터를 처리해서 상위 계층으로 서비스 하는 속도보다 송신 측에서 보내는 데이터의 속도가 더 빠르다면 수신 측에서는 제한된 저장용량을 초과하여 이후에 도착하는 데이터는 손실될 수 있다. 만약 데이터가 손실 된다면 불필요하게 응답과 데이터의 재전송이 송신 측과 수신 측간에 빈번히 이동해야 한다.

따라서 이러한 위험을 줄이기 위해 송신 측의 데이터 전송 량을 수신 측의 에 따라 조절한다.

이러한 작업을 흐름 제어라고 한다.

(a) Stop and Wait 방식

(b) Windowing 방식

 

tcp흐름제어

TCP는 먼저 연결을 설정한 후에 전송을 시작하지만 수신 측의 처리 능력이나 네트워크 대역폭 문제로 세그먼트를 원활하게 전송하지 못할 수도 있다.

이를 위해 TCP는 송신 측 전송 속도를 제어하는 메커니즘인 슬라이딩 윈도우 기법을 사용한다.

(1) Sliding Window 정의

- TCP 슬라이딩 윈도우 기법은 수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법이다. 이처럼 슬라이딩 윈도우 기법을 통하여 송신 버퍼의 범위는 수신 측의 여유 버퍼 공간을 반영하여 동적으로 바뀜으로써 흐름제어를 수행하게 된다.

 

- 슬라이딩 윈도우는 일단 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인 되는대로 이 윈도우를 옆으로 옮김(Slide)으로서 그 다음 패킷들을 전송하는 방식이다.

 

- 또한 윈도우의 크기만큼은 수신 쪽의 확인(응답)을 받지 않고도 보내는 것이 가능하므로 매번 전송한 패킷에 대해 확인을 받아야만 그 다음 패킷을 전송하는 방법(stop-and-wait)를 사용하는 것보다 훨씬 네트워크를 효율적으로 사용할 수 있다.

(2) window크기

- tcp/ip를 사용하는 모든 호스트들은 각각 2개의 window를 가지고 있다. 하나는 보내기 위한 window이며 또 다른 하나는 받기 위한 window이다.

- 호스트들은 실제 데이터를 보내기 전에 먼저 “TCP-3-way handshaking”을 통하여 수신컴퓨터의 receive window size에 자신의 send window size를 맞추게 된다. 즉 상대방이 받을 수 있는 크기에 맞추어 전송을 하겠다는 것이다.

- 즉 TCP 송신 윈도우 크기는 수신 측으로부터 확인응답 없이 전송할 수 있는 데이터의 개수를 의미한다. 윈도우 크기는 전송했으나 아직 확인 응답 받지 못한 데이터와 지연 없이 전송할 수 있는 데이터 크기를 합한 값이 된다.

congestion control(혼잡 제어)

- 송신 측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법이다. 송신 측의 데이터는 지역 망이나 인터넷으로 연결된 대형 네트워크를 통해 전달된다. 만약 한 라우터에 데이터가 몰릴 경우, 다시 말해 혼잡할 경우 라우터는 자신에게 온 데이터를 모두 처리 할 수 없다. 그렇게 되면 호스트들은 또 다시 재전송을 하게 되고 결국 더욱 더 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생 시킨다. 따라서 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송 속도를 강제로 줄이게 된다. 이러한 작업을 혼잡 제어라고 한다.

 

- 또한 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡(Congestion)이라고 하며 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어(Congestion Control)라고 한다. 흐름제어가 송신 측과 수신 측 사이의 전송 속도를 다루는데 반하여 혼잡제어는 호스트와 라우터를 포함한 보다 넓은 관점에서의 전송 문제를 다룬다.

 

- 앞에서 본 흐름 제어는 두 장비 간의 데이터 송신을 통제하는 중요한 부분이지만 연결에 참여하는 두 장비의 상황만 고려할 뿐 두 장비 사이에 있는 라우터 같은 다른 장비는 고려하지 않는다. 이것은 사실 계층 구조상 당연한 일이지만, 실제로는 TCP가 3계층에서 어떤 일이 벌어지고 있는지 아는 것은 매우 중요하다. 왜냐하면 네트워크가 혼잡해지게 되면 라우터 버퍼들의 오버플로우가 발생하며 세그먼트를 송신하는 속도가 느려지거나 어떤 때에는 버려지기도 한다.

 

- 혼잡제어 알고리즘

(a) AIMD(Additive Increase / Multicative Decrease)

- 이 방식은 AIMD라고 불리는 방식이다. 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 창 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가면서 전송하는 방법이다. 만일 패킷 전송을 실패하거나 일정한 시간을 넘으면 패킷을 보내는 속도를 절반으로 줄이게 된다.

 

- 이 방식은 공평한 방식이다. 이 방식을 사용하는 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만 시간이 흐르면 평형 상태로 수렴하게 되는 특징이 있다.

 

- 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지는 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

 

(b) slow start

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

 

(c) Fast Retransmit(빠른 재전송)

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

 

(d) Fast Recovery(빠른 회복)

빠른 회복 정책은 혼잡한 상태가 되면 창 크기를 1로 줄이지 않고 반으로 줄이고 선형 증가시키는 방법이다. 빠른 회복 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 합 증가/곱 감소 방식으로 동작한다.

 

이러한  TCP의 성질 때문에 Reliable한 특징을 가지는 것!