OSI 7 Layer - 4 Transport Layer - TCP/IP의 흐름 제어 & 오류 제어 & 혼잡 제어

OSI 7 계층 중 4계층인 전송 계층은 1~3계층에 의해 전송되는 데이터에 대해 중복, 오류를 감지하고 제어하는 역할을 하는 계층이다. 해당 계층에서는 TCP 또는 UDP 프로토콜을 사용한다. 이 중 TCP가 신뢰성있는 통신을 제공하며, TCP/IP 통신은 다음과 같은 흐름 제어, 오류 제어, 혼잡 제어 방식을 제공한다.

---

흐름 제어

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

 

TCP 통신을 할 때, 송신 측은 버퍼에 TCP 세그먼트를 보관한 후 순차적으로 전송하고, 수신 측은 도착한 TCP 세그먼트를 애플리케이션이 읽을 때까지 버퍼에 보관한다.

 

수신 측이 송신 측보다 데이터 처리 속도가 빠르면 아무 문제가 없지만, 송신 측의 속도가 더 빠를 경우 문제가 생길 수 있다. 수신 측의 버퍼 용량이 초과된 이후에 도착하는 패킷은 손실될 수 있으며, 손실된다면 추가적인 패킷 전송이 필요하다.

Stop and Wait

멈춰서 기다린다는 이름에 맞게, 매번 전송한 패킷에 대해 확인 응답(ACK)을 받으면 다음 패킷을 전송하는 방법이다.

하지만 패킷을 하나씩 보내기 때문에 비효율적이다.

Sliding Window

수신 측에서 설정한 window 크기만큼 송신 측에서 확인 응답(ACK) 없이 패킷을 전송할 수 있게 하여, 데이터 흐름을 동적으로 조절하는 제어 기법이다. window size로 수신자가 한 번에 받을 수 있는 메시지의 개수를 제한한다.

 

다시 말하자면, ACK 패킷이 필요하긴 하지만 매번 필요하지 않으며, ACK 패킷 없이 윈도우 크기만큼은 데이터 전송이 가능하다.

 

❓ window 크기

window는 다음 보낼 데이터를 담고 있는 메모리 버퍼의 일정 영역이다.

초기 윈도우 크기는 TCP 연결을 수립할 때 ‘3-way handshaking’을 통해 수신 측 윈도우 크기로 설정되며, 이후 수신 측의 버퍼에 남아있는 공간에 따라 변한다. 즉, 수신 측의 버퍼에 k 만큼의 여유 공간이 있다고 하면, 윈도우 크기를 k로 설정하면 수신 측의 버퍼가 넘치지 않을 것이다. 윈도우 크기는 수신 측에서 송신 측으로 확인 응답(ACK)을 보낼 때 TCP 헤더에 window size로 담아서 보낸다.

 

아래는 TCP 헤더이다. window size를 담아서 보내는 걸 볼 수 있다.

 

 

동작 방식

1. 송신자의 최초 윈도우 사이즈는 TCP 연결 수립 시 3-way-handshaking을 할 때 수신자의 윈도우 사이즈로 정한다. 윈도우 사이즈 내에 들어가는 데이터는, 다 전송해도 수신자의 버퍼가 넘치지 않는다.
2. 송신자에서 데이터를 하나씩 전송하며, 전송한 데이터는 윈도우 밖으로 꺼내도록 윈도우 사이즈를 줄인다.
3. 수신자로부터 ACK를 받으면 TCP header에 담긴 윈도우 크기만큼 윈도우 사이즈를 오른쪽으로 늘린다.
   1. ACK2의 의미는, 처음~1번까지 받았으니 이제 2번 데이터를 보내 달라는 의미이다.
4. 이후 데이터를 다 받을 때까지 위 과정을 반복한다.
   1. 중간에 송신자의 window size가 0이 되면 전송을 멈추고 대기한다.

---

오류 제어

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

오류가 발생한 경우

• 송신 측이 ACK(긍정 응답)를 받지 못함
  • 송신 측이 보낸 데이터의 유실
  • 수신 측이 보낸 ACK의 유실
• 중복된 ACK를 받음(재전송 요청)

 

위와 같이 오류가 발생했을 때 재전송을 요청하는 방식은 다음과 같다.

Stop and Wait

ACK를 받고 나서 다음 데이터를 보내는 방식으로, 일정 시간이 지나 timeout이 발생하면 이전 데이터를 재전송한다.

흐름 제어에서의 슬라이딩 윈도우를 사용할 수 없으므로 더 효율적인 ARQ가 필요하다.

Go Back N

연속적으로 데이터를 보내다가 오류가 발생한 지점부터 재전송하는 방식이다.

4번 데이터에서 에러가 발생했다면 4번 이후 데이터는 모두 삭제하고, 4번부터 다시 재전송을 받는다.

성공적으로 전송된 데이터까지 재전송하기 때문에 조금 비효율적이다.

Selective Repeat

오류가 발생한 데이터만 재전송하는 방식이다.

앞선 Go Back N과 비교했을 때 성공적으로 전송된 데이터는 재전송하지 않기 때문에 더 효율적이지만, 오류 데이터만 재전송하므로 수신 측 버퍼의 데이터가 순차적이지 않을 수 있다. 따라서 정렬 과정과 별도의 버퍼가 추가로 필요하다.

 

Go Back N과 비교하여 상황에 따라 유리한 방법을 선택하면 된다.

 

선택 시 고려 사항 - GPT

1. 패킷 손실률: "go back N"은 패킷 손실 시 전체 윈도우의 패킷을 재전송하기 때문에 높은 손실률에 적합합니다. "selective repeat"은 개별적인 패킷 재전송을 지원하므로 일부 손실에 대해서만 처리할 수 있습니다.

2. 네트워크 환경: 네트워크 환경과 특성에 따라 어떤 프로토콜이 더 적합한지를 고려해야 합니다. 무선 네트워크에서는 패킷 손실이 빈번하므로 "go back N"이 유리할 수 있습니다.

3. 시스템 리소스 및 복잡성: 각 프로토콜의 구현 및 사용에 필요한 시스템 리소스와 복잡성을 고려해야 합니다. "go back N"은 단순하고 효율적이지만, "selective repeat"은 추가적인 복잡성과 오버헤드를 가집니다.

4. 수신측의 요구사항: 수신측에서 패킷 재배열이 필요한지, 개별적인 패킷 재전송이 필요한지에 따라 적합한 프로토콜을 선택해야 합니다.

따라서 어떤 프로토콜이 더 유리한지는 사용 환경과 요구사항을 고려하여 결정해야 합니다. 일반적으로 높은 패킷 손실률이 예상되거나 단순한 오류 복구 메커니즘이 필요한 경우에는 "go back N" 프로토콜을 사용하는 것이 유리할 수 있습니다.

 

---

혼잡 제어

데이터의 양이 라우터가 처리할 수 있는 양을 초과하면 초과한 데이터는 라우터가 처리하지 못한다. 이때 송신 측에서는 라우터가 처리하지 못한 데이터를 손실 데이터로 간주하고 계속 재전송하여 네트워크를 혼잡하게 한다. 이런 상황은 송신 측의 전송 속도를 적절히 조절하여 예방할 수 있는데, 이를 혼잡 제어라고 한다.

 

🌟 흐름 제어는 송수신 측 사이의 패킷 수를 제어하는 기능이라 할 수 있고, 혼잡 제어는 네트워크 내의 패킷 수를 조절하여 네트워크의 오버플로우를 방지하는 기능을 말한다.

AIMD(Additive Increase / Multiplicative Decrease)

우리말로 하면 합 증가/ 곱 감소 방식이다.

말 그대로 처음에 패킷을 하나씩 보내고 문제 없이 도착하면 윈도우 크기를 1씩 증가 시키며 전송한다. 만약 전송에 실패하면 윈도우 크기를 절반으로 줄인다.

단점

1. 윈도우 크기를 너무 조금씩 늘리기 때문에 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기까지 시간이 오래 걸린다.
2. 네트워크의 혼잡을 미리 감지하지 못한다. 즉 네트워크가 혼잡해지고 나서야 대역폭을 줄인다.

 

Slow Start (느린 시작)

윈도우 크기를 1, 2, 4, 8과 같이 지수적으로 증가 시키다가, 혼잡이 감지되면 윈도우 크기를 1로 줄이는 방식이다.

장점

보낸 데이터의 ACK가 도착할 때마다 윈도우 크기를 증가시키기 때문에 처음에는 윈도우 크기가 조금 느리게 증가할 지라도, 시간이 가면 갈수록 윈도우 크기가 점점 빠르게 증가한다.

단점

여전히 네트워크의 혼잡을 미리 감지하지 못한다. 즉 네트워크가 혼잡해지고 나서야 대역폭을 줄인다.

윈도우 크기를 1로 줄여버리기 때문에 너무 다시 처음부터 재전송하게된다.

 

 

위와 같은 것들을 좀 해결하기 위해서 다음과 같은 빠른 재전송, 빠른 회복의 개념이 등장했다.

Fast Retransmit (빠른 재전송)

중복 ACK를 세 개 받으면 바로 오류로 판단하고 재전송을 수행하는 방식이다.

 

패킷을 받는 수신자 입장에서는 세그먼트로 분할된 내용들이 순서대로 도착하지 않는 경우가 생길 수 있다. 이런 상황이 발생했을 때 수신 측에서는 순서대로 잘 도착한 마지막 패킷의 다음 순번, 즉 이제 받아야 할 순번을 ACK 패킷에 실어서 보낸다. 이러한 중복 ACK를 3개 받으면 송신자의 타임아웃이 지나지 않았어도 재전송이 이루어지며, 보다 빠른 재전송률을 유지할 수 있게 된다.

Fast Recovery (빠른 회복)

빠른 회복은 혼잡 상태가 되면 윈도우 크기를 1로 줄이지 않고, 반으로 줄인 다음 선형 증가 시키는 방법이다. 이 방법을 적용하면 혼잡 상황을 한 번 겪은 후에는 AIMD 방식으로 동작한다.

다 합친 예시

 

위의 방식을 다 합친 예시이다. 처음에는 slow start 기법으로 지수적으로 윈도우 사이즈를 늘린다. 여기서 ssthresh에 도달하면 거기서부터는 AIMD 방식으로 동작한다. ssthresh가 무엇인가?

❓ ssthresh, 임계점

이는 바로 직전에 혼잡 상황이 발생했을 때의 window size의 절반 값을 가진다.
임계점은 여기까지만 Slow Start를 사용하겠다 라는 의미로 slow start threshold(ssthresh)라고도 한다. 

 

즉, 임계점에 도달하면 그때부터는 혼잡이 발생할 가능성이 높아지기 때문에 선형적으로 증가시키는 것으로 바꾸는 것이다. 재전송이 발생하면 window size를 절반으로 줄이고, timeout이 발생하면 1로 줄인다.

 

이와 관련하여 혼잡 제어 정책을 정리한 것을 아래에서 볼 수 있다.

 

 

---

혼잡 제어 정책

TCP Tahoe

TCP Tahoe는 처음에는 Slow Start를 사용하다가 임계점(Threshold)에 도달하면 AIMD 방식을 사용한다. 처음 window size는 1 MSS이다.

3 duplicate ACKs 혹은 timeout을 만나면 임계점을 window size의 절반으로 줄이고 window size를 1로 줄인다.

 

TCP Tahoe 방식은 3 duplicate ACKs를 만나고 window size가 다시 1부터 키워나가야 하므로 속도가 느리다. 이를 해결할 수 있는 방식이 TCP Reno이다.

 

TCP Reno

TCP Reno는 TCP Tahoe와 비슷하지만 3 dupicate ACKs와 timeout을 구분한다는 점이 다르다.

• 3 duplicate ACKs를 만나면 window size를 절반으로 줄이고 임계점을 그 값으로 설정한다.
• timeout을 만나면 window size를 1로 줄인다. 임계점은 변하지 않는다.

---

참고자료

[네트워크] TCP/IP 흐름 제어 & 혼잡 제어

 

전송 계층 - TCP 의 모든 것 #2. 흐름제어, ARQ, Sliding Window

 

TCP 의 흐름 제어 / 오류 제어 / 혼잡 제어

 

[네트워크] TCP 혼잡제어(congestion control)| AIMD, Slow Start | TCP Reno, Tahoe