TCP/IP 흐름제어 & 혼잡제어(Flow control & Congestion control)

Ouroboros·2023년 11월 17일

tcp 전송제어 혼잡제어 흐름제어

네트워크

목록 보기

12/20

TCP의 3가지 제어 기능
흐름제어 : 전송되는 데이터의 양을 조절
오류제어 : 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처하는 방법
혼잡제어 : 네트워크 혼잡에 대처

흐름 제어

'송신측의 전송량' > '수신측의 수신량'이라면
전송된 패킷은 수신측의 큐를 넘어서 손실될 수 있다. 따라서 송신 측의 패킷 전송량을 제어해야 한다.

1. Stop and Wait(정지 - 대기)

매번 전송한 패킷에 대한 확인 응답을 받고 확인 응답을 받은 후 그 다음 패킷을 전송할 수 있는 것을 말한다.
하지만 이러한 구조는 시간이 많이 소요되고 비효율적이라는 단점이 있다.

2. Sliding Window(슬라이딩 윈도우)

수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 기법이다.

송신측에서 4, 5, 6, 7, 8, 9, 10, 11, 12을 보낼 수 있는 프레임을 가지고 있고 데이터 4, 5을 전송했다고 가정하면 슬라이딩 윈도우 구조는 6, 7, 8, 9, 10, 11, 12처럼 변하게 된다. 이때 만약 수신측으로부터 ACK라는 프레임을 받게 된다면 송신측은 이전에 보낸 데이터 4, 5을 수신측에서 정상적으로 받았음을 알게 된다.
송신측의 슬라이딩 윈도우는 ACK 프레임의 수만큼 오른쪽으로 경계가 확장된다.

수신 윈도우

송신 측이 수신측의 현재 윈도우[1] 크기를 모른다면 패킷을 너무 많이 전송해서 수신 윈도우 크기를 넘어서면 손실이 발생할 것이다.
문제를 방지하고 데이터 송신을 효율적으로 제어하기 위해 TCP 프로토콜 헤더에 자신이 현재 수신 윈도우 여유 크기를 담아 서로 상대방에게 알려준다.
수신 측이 한 번에 처리할 수 있는 데이터의 양(윈도우 크기)을 3 way handshake할 때 송신 측에 전달한다.

송신 윈도우

송신 윈도우(Sender window)는 고정 값이 동적으로 크기가 조절된다.
송신 윈도우 크기는 송신 측 혼잡 윈도우(Congestion window)와 수신 측 수신 윈도우 중 작은 값이 설정된다.
★ 송신 윈도우 = Min(혼잡 윈도우, 수신 윈도우 여유 크기)
패킷의 왕복 시간(RTT)이 크다면 네트워크가 혼잡하다고 생각하여 윈도우 크기를 실제 버퍼의 크기보다 작게 설정한다.
통신 과정 중에도 네트워크 혼잡 등의 조건을 통해 윈도우 크기는 유동적으로 설정한다.

오류 제어

통신 중에 오류가 발생하면 해당 데이터를 재전송하는 기법이다.
재전송 기반 오류 제어 ARQ(Automatic Repeat Request)를 사용한다.

오류를 아는 방법

송신 측이 ACK(긍정응답)을 받지 못하는 경우
중복된 ACK를 받는 경우
수신 측이 NACK(부정응답)을 보내는 경우

1. Stop and Wait ARQ

ACK를 받고 나서 다음 데이터를 보내는 방식이다.
일정 시간을 지나 timeout이 발생하면 이전 데이터를 재전송한다.
데이터 프레임과 ACK 프레임은 각각 0, 1 번호를 번갈아가며 부여한다.
데이터를 받지 못했을 경우 NAK를 보내고, NAK를 받은 송신측은 데이터를 재전송한다.

2. Go-Back-n ARQ

전송된 프레임이 손상되거나 분실되었을때, ACK 패킷의 손실로 인한 TIME_OUT이 발생했을 때
확인된 마지막 프레임 이후로 모든 프레임을 재전송한다.
성공적으로 전송된 데이터까지 재전송하기 때문에 비효율적일 수 있다.

ACK : 다음 프레임을 전송
NAK : 손상된 프레임 자체 번호를 반환

3. Selective Repeat

오류가 발생한 데이터만 재전송하는 방식이다.
그렇기에 버퍼[2]의 데이터가 순차적이지 않다.
따라서 정렬의 과정이 추가로 필요하고 별도의 버퍼가 필요하다.

혼잡 제어

혼잡은 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 말한다.
흐름 제어는 송신 측과 수신 측의 전송 속도를 다루고, 혼잡 제어는 라우터를 포함한 넓은 범위의 전송 문제를 다룬다.

1. AIMD (Additive Increase / Multiplicative Decrease)

처음에 패킷 하나를 보내는 것으로 시작한다.
전송한 패킷이 문제 없이 도착한다면 Window Size를 1씩 증가시키며 전송하는 방법이다.
만약, 패킷 전송을 실패하거나 TIME_OUT이 발생하면 Window Size를 절반으로 감소시킨다.
네트워크에 늦게 들어온 호스트가 처음에는 불리하지만, 시간이 흐르면서 평형상태로 수렴한다.
처음에 전송 속도를 올리는 데 시간이 오래걸린다.
또한 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

2. Slow Start (느린 시작)

AIMD와 마찬가지로 패킷을 하나씩 보내는 것부터 시작한다. 이 방식은 패킷이 문제 없이 동작하여 ACK 패킷마다 Window Size를 1씩 늘린다. 즉, 한 주기를 지나면 Window Size는 2배가 된다.
혼잡 현상이 발생하면 Window Size를 1로 떨어뜨린다.
처음에는 네트워크 수용량을 예상할 수 있는 정보가 없지만, 한 번 혼잡 현상이 발생한 후에는 네트워크의 수용량을 어느 정도 예상할 수 있다.
미리 정해진 임계값(threshold)에 도달할 때까지 윈도우의 크기를 2배씩 증가시킨다.
전송되는 데이터의 크기가 임계 값에 도달하면 혼잡 회피 단계로 넘어간다.

3. Fast Retransmit (빠른 재전송)

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

4. Fast Recovery (빠른 회복)

TCP는 지금가지 받은 데이터 중 연속되는 패킷의 마지막 순번 이후를 ACK 패킷에 실어서 보낸다.
송신 측이 아래처럼 3, 4번을 보내더라도 ACK 2 를 중복해서 받는다.
그러면 timeout이 발생하기 전이라도 송신 측은 문제가 되는 2번 패킷을 재전송한다.
이때 혼잡한 상황이라고 판단해서 윈도우 크기를 줄인다.
** 3 ACK Duplicated : 송신 측이 3번 이상 중복된 ACK 번호를 받은 상황