흐름 제어 / 혼잡 제어 / 오류 제어
TCP에는 전송 데이터 양을 조절하는 흐름 제어, 데이터 유실/잘못 수신 시 대처하는 오류 제어, 네트워크 혼잡에 대처하는 혼잡 제어가 존재한다.
흐름 제어
송수신 측의 데이터 처리 속도가 다를 때(특히 송신 측의 속도가 빠른 경우), 버퍼가 흘러넘치는 오버플로우 문제가 발생할 수 있다. 수신 측의 버퍼 용량을 초과한 이후에 도착하는 패킷은 손실될 수 있으며, 불필요한 추가 패킷 전송이 발생한다.
이렇게 송수신측의 TCP 버퍼 크기 차이로 인한 문제를 방지하기 위해 송수신 측의 데이터 전송량(속도)을 조절하는 것이 흐름 제어다.
Stop & Wait
데이터를 전송한 후, 받았다는 응답이 돌아올 때까지 기다렸다가 ACK를 받으면 다음 패킷을 전송하는 방식이다.
(보냄 -> ACK -> 보냄 -> ACK...)
상대방이 응답을 하면 다음 데이터를 보내는 형식이기 떄문에 간단하지만 비효율적이다.
Sliding Window
현재 TCP는 대부분 슬라이딩 윈도우 방식으로 동작한다.
수신 측이 한 번에 처리 가능한 데이터를 정해두고, 수신 측의 데이터 처리 상황을 송신 측에 알려서 데이터 흐름을 제어하는 방식이다.
통신 초기에 Window Size를 교섭하기 때문에 송신 측이 수신 측이 처리 가능한 데이터의 양을 알고 있다. 따라서 수신 측에서는 굳이 처리 가능이라는 답을 날리지 않아도 송신 측에서 처리 가능 여부를 어느 정도 예측할 수 있다.
윈도우 크기
: 3-way handshake를 통해 수신 측 윈도우 크기로 설정되며, 버퍼에 남아있는 공간에 따라 변한다. 수신 측이 송신 측으로 ACK을 보낼 때 TCP header의 WIndow Size에 포함시켜 보낸다.
동작 방식
- 예를들어 송신 측이 0~6까지의 데이터를 전송하고자 할때.
- 송신 측은 수신 측에게서 받은 윈도우 크기와 네트워크 상황을 고려하여 Window Size를 측정한다.
- 3으로 잡은 경우, 우선 윈도우 3 내에 있는 0, 1, 2의 데이터를 전송한다.
- 수신 측에서 데이터를 받아 자신의 처리 속도대로 처리한 후, 응답으로 남아있는 버퍼 크기를 송신한다. 예를들어 하나 처리하여 남아있는 공간이 하나 생겼을 경우, Windoe Size: 1을 전송.
- 해당 ACK를 받은 송신 측은 수신 측이 데이터 하나를 처리했으며 1 만큼 더 받을 수 있음을 알고, 윈도우를 옆으로 Sliding하듯 움직여, 윈도우 3 내의 값을 1, 2, 3으로 바꾼다.
- 송신 측은 자신의 윈도우 내에 새로 들어온 3번 데이터를 수신 측에 전송한다.
즉, 슬라이딩 윈도우란 Window Size 만큼 데이터를 전송하고, 응답 받고, 응답받은 Window 크기 만큼 윈도우를 밀고, 윈도우 내의 데이터를 전송하고의 반복이다.
송신 측에서 일정 시간 동안 ACK를 받지 못하면 패킷을 재전송 하게 되는데, 만약 재전송했는데 패킷이 소실된 경우가 아니라 수신 측의 버퍼에 남은 공간이 없는 경우라면 문제가 발생한다.
이를 해결하기 위해 송신 측은 ACK을 보내며 남은 Window Size도 함께 보낸다.
하나씩 전송하고 응답받는 Stop & Wait보다는 훨씬 빠르며, 윈도우 크기를 송수신 측 간에 유연하게 조절할 수 있으므로 TCP의 기본적인 흐름 제어 기법으로 사용되고 있다.
혼잡 제어
네트워크 내의 패킷 수가 증가하면 오버플로우가 발생하는 등 장애가 발생할 수 있다.
송신 측의 전송 속도를 조절하여 이를 방지하는 것을 혼잡 제어라고 한다.
AIMD
Additive Increse/Multicative Decrease 즉, 합 증가/곱 감소라는 뜻이다.
처음에는 패킷을 하나씩 보내며 문제 없이 도착한다면 윈도우 크기를 1씩 증가시켜가며, 즉 합 증가 방식으로 전송한다.
만약 전송 실패하는 시점이 온다면, 윈도우 크기를 절반으로 줄인다. 즉, 곱 감소시킨다.
처음에 윈도우 크기를 너무 조금씩 늘리기 때문에 제대로 네트워크의 대역폭을 활용하여 전송하기까지의 시간이 오래 걸린다는 단점이 있다.
Slow Start
느리게 증가하는 AIMD 방식을 보완하였다.
Slow Start는 Window Size를 1, 2, 4, 8... 과 같이 지수적으로 증가시키다가 혼잡이 감지되면 윈도우 크기를 1로 줄인다.
처음에는 Window Size가 천천히 증가하지만, 시간이 갈수록 빠르게 증가하게 된다.
Fast Retransmit
TCP는 일반적으로 받은 데이터 중 연속되는 패킷의 마지막 번호 이후를 ACK 패킷에 실어 보낸다.
따라서 0, 1, 2(소실), 3, 4를 보내더라도 수신 측은 ACK 2를 중복하여 보내게 된다.
이때 timeout 발생 전이라도 송신 측은 손실된 것으로 보이는 2번 패킷을 재전송한다.
송신 측이 3번 이상 중복된 ACK를 보내는 3-ACK Duplicated가 발생하면 혼잡한 상황이라고 판단하고 Window Size를 줄이는 것이 Fast Retransmit이다.
Fast Recovery
혼잡한 상태가 되면, Window Size를 1로 줄이는 것이 아니라 절반으로 줄이고 선형 증가시키는 방법이다.
즉, 혼잡을 겪은 후, AIMD 방식으로 교체되는 것이다.
혼잡 제어 정책
위 혼잡 제어 기법들을 조합하여 실제로 어떤 상황에 어떤 기법을 사용해 혼잡을 제어할지 정의한 것이다.
혼잡 제어 정책들은 혼잡이 발생하면 윈도우 크기를 줄이거나, 증가시키지 않으며 혼잡을 회피한다는 공통 전제가 있다.
Tahoe와 Reno 둘 다 처음에는 Slow Start 방식을 사용하다가 혼잡이 감지되었을때에는 AIMD 방식으로 전환하는 방법이다.
Taboe
: 처음에는 Slow Start로 Window Size를 지수적으로 증가시키다가 임계치에 도달하면 이후부터는 AIMD를 사용하여 선형적으로 Window Size를 증가시킨다.
3 ACK Duplicated나 Timeout 발생 시, 혼잡으로 판단하여 임계치와 Window Size를 1로 줄이도록 조정한다.
Reno
: 처음에는 Slow Start로 시작하여 임계점을 도달하면 이후부터는 AIMD를 사용한다.
3 ACK Duplicate 발생 시, Window Size를 1이 아니라 AIMD처럼 절반으로 줄이고, 임계치를 줄어든 Window 값으로 정한다. (Fast Recovery)
Timeout에 의해 데이터 손실 시, Window Size를 바로 1로 줄이고 Slow Start 한다.
오류 제어
TCP에서는 통신 중에 오류가 발생하면 해당 데이터를 재전송하는 재전송 기반 오류 제어 ARQ를 제공한다.
기본적으로 송신 측이 ACK를 받지 못하거나, 중복된 ACK를 받거나, NACK를 받았을 때 오류가 발생했음을 알게 된다.
Stop & Wait
흐름 제어의 맥락에서도 쓰이지만, 오류 제어의 맥락에서도 사용된다.
ACK를 받고 나서 다음 데이터를 보내는 방식이므로, 일정 시간이 지나 ACK이 돌아오지 않은 채 timeout이 발생하면 이전 데이터를 재전송한다.
Go Back N
연속적으로 데이터를 전송하다가, 오류가 발생하면 해당 지점부터 재전송한다.
예를들어 1, 2, 3, 4, 5를 전송했는데 3번에서 오류가 발생한다면 3번 이후의 모든 데이터를 삭제하고 3번부터 재전송을 요청한다.
따라서 이후의 성공적으로 전송한 데이터까지 모두 재전송하기 때문에 비효율적이다.
Selective Repeat
오류가 발생한 데이터만 재전송하는 방식이다.
단점은 버퍼의 데이터가 순차적이지 않기 때문에 정렬 과정이 추가로 필요하고, 별도의 버퍼가 필요하다는 것이다.
Q. TCP/IP에서 흐름 제어 기법이 왜 사용되는지?
A. 송수신 측의 TCP 버퍼 크기 차이로 인해 데이터 손실, 재전송 등의 데이터 처리 속도 차이 문제가 발생하는 것을 막기 위해서다.
Q. TCP/IP 흐름 제어 기법은 무엇이 있는지?
A. Stop & Wait와 Sliding Window 기법이 있다.
Stop & Wait는 전송한 패킷에 대한 ACK를 받아야만 다음 패킷을 전송하는 기법이다.
Sliding Window는 수신 측에서 설정한 윈도우 크기 만큼 송신 측에서 ACK 없이도 전송할 수 있게 하며, 데이터 전송 흐름을 동적으로 조절하는 기법이다.
Q. TCP/IP 혼잡 제어 기법이 왜 사용되는지?
A. 송신 측에서 보내는 데이터 양이 중간 기기에서 처리 가능한 양을 초과하면 데이터가 처리되지 못해 송신 측에서 손실로 인식하게 되므로, 송신 측은 계속 재전송하여 네트워크를 혼잡하게 만들 수 있다. 이를 방지하기 위해 네트워크의 혼잡도에 맞춰 송신 측의 전송 속도를 적절히 조절하는 것이다.
