TCP/IP 흐름제어와 혼잡제어: 데이터 전송 관리

☀️ TCP 통신의 문제점

1. Packet Loss (손실)

   : 데이터 패킷이 송신자에서 수신자로 전송되는 도중에 네트워크 상에서 손실되는 현상

   • 원인: 네트워크 혼잡, 잘못된 라우팅, 패킷 충돌, 하드웨어 결함 등 다양한 이유로 발생할 수 있습니다.
   • 영향: 데이터의 전송 속도 감소, 연결의 비안정성, 데이터의 무결성 문제 등이 발생할 수 있습니다.
   • 해결 방법: 재전송 요청(ARQ)와 같은 메커니즘을 사용하여 손실된 패킷을 다시 보내거나, 전송 제어 프로토콜(TCP)와 같은 프로토콜이 패킷 손실을 감지하고 재전송을 수행합니다.

2. Out-of-Order Packets (순서 바뀜)

   : 데이터 패킷들이 송신자에서 보낸 순서와 다른 순서로 수신자에게 도착하는 현상

   • 원인: 패킷들이 서로 다른 경로로 전송되거나, 네트워크 상의 지연 등으로 인해 발생합니다.
   • 영향: 데이터의 무결성 문제, 애플리케이션 오류, 성능 저하 등이 발생할 수 있습니다.
   • 해결 방법: TCP와 같은 프로토콜은 수신 순서를 확인하는 시퀀스 번호를 사용하여 패킷을 올바른 순서로 재정렬합니다.

3. Congestion (혼잡)

   : 네트워크에 데이터 패킷이 과도하게 몰리는 현상으로, 특정 섹션 또는 노드에서 처리 능력을 초과하는 트래픽의 양이 발생하는 상황

   • 원인: 네트워크 자원의 한계, 라우터 또는 스위치의 버퍼 오버플로우, 대량의 데이터 전송 등에 의해 발생합니다.
   • 영향: 패킷 손실, 지연 증가, 연결의 비안정성 등이 발생할 수 있습니다.
   • 해결 방법: 혼잡 제어 알고리즘(예: TCP의 혼잡 제어)을 사용하여 네트워크의 혼잡 상태를 관리하고 조절합니다.

4. Overload

   : 수신자가 처리 능력을 초과하는 양의 데이터를 받게 되는 상황

   • 원인: 송신자가 너무 빠른 속도로 데이터를 전송하거나, 수신자의 처리 능력이 제한적인 경우 발생합니다.
   • 영향: 패킷 손실, 지연, 데이터의 무결성 문제 등이 발생할 수 있습니다.
   • 해결 방법: 흐름 제어(flow control)를 사용하여 송신자와 수신자 간의 데이터 전송 속도를 조절하거나, 수신자의 처리 능력을 높이는 방법으로 문제를 해결할 수 있습니다.

☀️ 데이터 전송의 전체 과정

1. 응용 계층 (Application layer)
   • sender application이 데이터를 소켓에 입력한다.
2. 전송 계층 (Transport layer)
   • 데이터는 세그먼트라는 작은 단위로 나누어지며, 필요한 헤더 정보가 추가된다. 이후 네트워크 계층으로 전달된다.
   • 발신자 측에서는 send buffer를 사용하여 이 세그먼트를 임시로 저장합니다.
3. 전송
   • 세그먼트는 네트워크를 통해 수신자에게 전송된다.
4. 수신자 버퍼
   • 데이터가 수신자에 도착하면 receive buffer에 저장됩니다.
5. 응용 계층에서의 데이터 처리
   • 수신된 데이터는 응용 프로그램이 준비될 때까지 receive buffer에 보관되며, 준비가 되면 응용 프로그램이 이 데이터를 읽습니다.

⇒ 이 과정에서 흐름 제어의 핵심은 receive buffer 가 넘치지 않도록 하는 것이다. 이를 위해 receiver는 RWND (Reccive WiNDow) 라는 값을 통해 현재 남은 버퍼 공간을 발신자에게 알린다. RWND 값은 발신자에게 얼마나 많은 데이터를 안전하게 보낼 수 있는지 알려주는 지표로 사용된다.

☀️ 흐름 제어

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

• 데이터 전송 속도를 조절하여 수신자의 버퍼 오버플로우나 패킷 손실을 방지한다.

  : 수신자가 패킷을 지나치게 많이 받지 않도록 조절하는 것

• 수신자가 송신자에게 현재 자신의 상태를 피드백한다는 것이 기본 개념이다.

송신측이 수신측보다 데이터 처리 속도가 빠를 때 문제가 발생한다. 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있으며, 만약 손실 된다면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 빈번이 발생한다.

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

☀️ 흐름 제어 주요 방법

Stop-and-Wait (정지-대기방식)

송신측이 데이터 프레임을 하나 전송한 뒤, 해당 프레임에 대한 확인 응답(ACK)을 수신할 때까지 대기하는 흐름 제어 방법

특징

• 검출후 재전송 방식(ARQ)의 일종
• 크기가 1인 미닫이 창을 사용

동작 방식

1. 송신

   송신측은 데이터 프레임 하나를 수신측으로 전송한다.

2. 대기

   송신측은 수신측으로부터 ACK(확인 응답)을 받을 때까지 다른 데이터를 전송하지 않고 대기한다.

3. 확인 응답

   수신측은 데이터 프레임을 올바르게 수신하면 ACK를 송신측에게 반환한다. 만약 프레임에 오류가 발생하면, 수신측은 ACK를 전송하지 않고 무시하거나 오류 응답(NAK)을 전송한다.

4. 재전송

   송신측은 ACK나 NAK를 정해진 시간 내에 받지 못하면 해당 프레임을 다시 전송한다. 이것을 '타임아웃'이라고 한다.

장점

• 단순함: 알고리즘이 매우 간단하여 구현이 쉽다.
• 신뢰성: 각 프레임마다 확인 응답을 받기 때문에 데이터 전송의 신뢰성이 높아진다.

단점

• 효율성: 네트워크의 대역폭을 최대한 활용하지 못하며, 대기 시간 때문에 전체적인 전송 효율이 낮다.
• 지연: 각 프레임 전송 후 확인 응답을 기다려야 하므로 전송 속도에 지연이 발생한다.

결론

Stop-and-Wait은 데이터 프레임의 안전한 전송을 위한 기본적인 흐름 제어 방식이지만, 네트워크의 효율성과 전송 속도 면에서는 한계가 있다.

Sliding Window

동시에 여러 프레임을 전송하면서 효율적인 흐름 제어와 오류 제어를 제공하는 통신 프로토콜

슬라이딩 윈도우 프로토콜은 데이터 통신에서 흐름 제어 및 오류 제어를 위한 중요한 메커니즘이다.

슬라이딩 윈도우는 송신측과 수신측 간에 윈도우라는 프레임의 크기를 정하여, 해당 윈도우 크기만큼의 프레임들을 동시에 전송하거나 수신할 수 있게 한다. 윈도우는 송신측과 수신측에서 모두 '슬라이드'하며, 새로운 프레임을 전송하거나 수신하게 된다.

Go Back N (GBN) 프로토콜

GBN은 슬라이딩 윈도우의 한 방식으로 손실된 프레임부터 윈도우 내의 모든 후속 프레임들을 재전송하는 프로토콜

특징

• N 크기의 윈도우: 송신측은 N 개의 프레임을 연속적으로 전송할 수 있지만, 수신측은 오직 시퀀스 순서대로 프레임을 받아들인다.
• ACK: 수신측은 올바르게 수신된 마지막 프레임에 대한 확인 응답(ACK)을 송신측에게 전송한다. ACK 번호는 다음에 기대하는 프레임의 시퀀스 번호를 의미한다.
• 오류 발생: 만약 프레임에 오류가 발생하면, 해당 프레임과 그 이후의 모든 프레임들은 무시한다. 수신측은 마지막으로 성공적으로 수신된 프레임 다음 번호의 ACK를 계속해서 전송한다.
• 타임아웃: 송신측은 각 프레임에 대한 ACK를 기다린다. 특정 시간 내에 ACK를 받지 못하면, 해당 프레임 및 그 이후의 모든 프레임들을 재전송한다.

슬라이딩 윈도우 크기

• 송신 윈도우
  • GBN에서 송신측의 윈도우 크기는 N이라고 할 때, 한 번에 최대 N개의 프레임을 연속적으로 전송할 수 있다. 이중 프레임 하나라도 손실되면 해당 프레임부터 윈도우 내의 모든 후속 프레임들을 재전송한다.
• 수신 윈도우
  • GBN에서 수신측의 윈도우 크기는 항상 1이다. 수신측은 항상 다음 예상 프레임만을 기다리는데, 다른 프레임이 도착하면 그 프레임은 무시된다.

동작 과정

1. 윈도우 크기 설정:
   • 송신측은 윈도우 크기 N에 따라 최대 N개의 프레임을 연속적으로 전송할 수 있다.
   • 수신측은 오직 시퀀스 순서에 따라 프레임을 수신한다.
2. 데이터 전송:
   • 송신측은 각 프레임에 시퀀스 번호를 부여하며, 이 번호는 모듈로 연산을 통해 범위 내에서 순환한다.
   • 송신측은 아직 ACK를 받지 않은 가장 오래된 프레임부터 시작하여 최대 N개의 프레임을 연속적으로 전송한다.
3. ACK 응답:
   • 수신측은 정확하게 수신된 프레임에 대해 ACK(확인 응답)을 송신측에게 반환한다. ACK의 번호는 수신측이 다음에 기대하는 프레임의 시퀀스 번호를 나타낸다.
4. 오류 처리:
   • 만약 수신측에서 어떤 프레임에 오류가 감지되면 (잘못된 시퀀스 번호 또는 손상된 프레임으로 인해), 수신측은 해당 프레임에 대한 ACK를 전송하지 않는다. 또한, 해당 프레임 이후로 오는 프레임들 역시 무시된다.
5. 타임아웃 및 재전송:
   • 송신측은 각 프레임에 대한 ACK를 일정 시간 동안 기다린다. 이를 '타임아웃'이라고 한다. ACK를 타임아웃 내에 받지 못하면, 해당 프레임부터 윈도우 내의 모든 후속 프레임들을 재전송한다.
6. 윈도우 슬라이드:
   • 송신측은 ACK를 받을 때마다 윈도우를 "슬라이드"시켜서 다음 프레임들을 전송할 준비를 한다.

장점

• 단순성: GBN은 구현이 비교적 단순하며, 수신측의 버퍼링 요구 사항이 작다.
• 신뢰성: 모든 프레임에 대한 확인 응답을 사용하므로 전송의 신뢰성이 높다.

단점

• 효율성: 손실된 프레임의 후속 프레임들도 모두 재전송되므로 네트워크 자원의 사용이 비효율적일 수 있다.
• 지연: 재전송 때문에 전송 속도에 지연이 발생할 수 있다.

결론

슬라이딩 윈도우 프로토콜은 네트워크 통신에서 효율적인 흐름 제어와 오류 제어를 가능하게 한다. Go-Back-N은 이 프로토콜의 한 형태로, 특정 상황에서 장점을 가지지만 효율성 측면에서의 한계도 있다.

전송 오류율이 높은 환경에서는 더 발전된 프로토콜, 예를 들면 Selective Repeat를 사용하는 것이 더 효율적일 수 있다.

Selective Repeat (SR) 프로토콜

슬라이딩 윈도우 프로토콜의 변형 중 하나로, 손실된 프레임만 재전송하는 방법을 제공한다. 이 방법은 네트워크의 프레임 손실률이 높을 때 특히 유용하다.

특징

• 수신측은 순서대로 프레임을 기다리지 않고 수신한 프레임을 버퍼에 저장한다.
• 송신측은 각 프레임에 대한 개별 타임아웃을 가지고 있다.
• 선택적 반복 프로토콜에서 ACK Number는 수신된 오류 없는 패킷의 시퀀스 번호를 의미한다.

슬라이딩 윈도우 크기

• 송신 윈도우
  • SR에서 송신측의 윈도우 크기는 N이다.
  • SR에서는 각 프레임에 대한 개별적인 ACK를 기다리며, 특정 프레임만 재전송하게 된다. 그래서 윈도우 내에서 여러 프레임들이 독립적으로 전송 및 재전송될 수 있다.
• 수신 윈도우
  • SR에서 수신측의 윈도우 크기도 N이다.
  • 수신측은 순서에 상관없이 윈도우 내의 모든 프레임을 수신할 준비가 되어 있다. 수신된 프레임은 버퍼에 저장되며, 순서대로 상위 계층에 전달된다.

동작 방식

1. 윈도우 설정:
   • 송신측과 수신측 모두 슬라이딩 윈도우의 크기 N을 갖는다. 이 크기는 동시에 전송되거나 수신 대기 중인 프레임의 최대 개수를 나타낸다.
2. 데이터 전송:
   • 송신측은 프레임에 시퀀스 번호를 부여하고 전송한다.
3. ACK 및 NACK 응답:
   • 수신측은 올바르게 수신된 프레임에 대해 ACK를 반환한다.
   • 손상된 프레임 또는 순서에 어긋나는 프레임이 도착하면 NACK(부정 응답) 또는 아무런 응답도 전송되지 않을 수 있다.
4. 선택적 재전송:
   • 송신측은 타임아웃 또는 NACK을 기반으로 특정 프레임만 재전송한다.
   • 이 방법은 Go-Back-N 프로토콜과 달리 모든 프레임을 재전송하는 대신, 실제로 손실 또는 손상된 프레임만 재전송한다.

장점

• 효율성: 손실된 프레임만 재전송하기 때문에 네트워크 자원의 사용이 효율적이다.
• 빠른 응답: 오류가 발생한 프레임만 재전송하므로 전체 응답 시간이 줄어든다.

단점

• 복잡성: SR 프로토콜은 Go-Back-N에 비해 구현이 복잡하다. 각 프레임에 대한 개별적인 상태 추적이 필요하며, 수신측에서의 버퍼 관리도 필요하다.
• 버퍼링 요구사항: 수신측에서 모든 수신 프레임을 임시로 저장할 수 있어야 한다.

결론

Selective Repeat 프로토콜은 효율성과 성능을 중시하는 환경에서 매우 유용하며, 특히 프레임 손실률이 높은 네트워크에서 효과적이다.

그러나 이러한 이점은 구현의 복잡성과 버퍼링 요구 사항으로 인한 비용으로 상쇄될 수 있다. 따라서 사용 환경과 요구 사항에 따라 적절한 프로토콜을 선택해야 한다.

☀️ 혼잡 제어

송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법

• 많은 데이터 패킷이 동시에 특정 네트워크 세그먼트나 장치를 통과하려 할 때 발생하는 네트워크 혼잡 상황을 관리하고 방지하는 메커니즘

데이터는 지역망이나 인터넷을 통해 큰 네트워크로 전송된다. 만약 데이터가 한 라우터에서 몰리게 되면, 그 라우터는 들어오는 데이터를 모두 처리할 수 없다. 이때, 호스트가 데이터를 재전송하게 되면 네트워크 혼잡이 더 심해질 수 있다. 이로 인해 발생하는 오버플로우나 데이터 손실을 막기 위해 송신측은 전송 속도를 제한하게 되는데, 이것을 혼잡제어라고 한다.

네트워크 내에서 패킷 수가 과도하게 많아지는 현상을 '혼잡'이라 부르며, 이 혼잡을 방지하거나 해소하는 것 역시 혼잡제어의 일부이다.

흐름제어는 송신측과 수신측 간의 데이터 전송 속도 조절에 중점을 둔다. 반면, 혼잡제어는 호스트부터 라우터에 이르는 더 큰 범위의 네트워크 전송 문제에 대해 접근한다.

☀️ 혼잡 제어 주요 방법

AIMD (Additive Increase / Multiplicative Decrease)

• AIMD는 패킷 전송을 시작할 때 단위 시간당 하나의 패킷을 전송하며 시작한다. 패킷이 성공적으로 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법이다.
• 패킷 전송에 실패하거나 일정 시간이 초과되면, 현재의 window 크기(패킷 전송 속도)를 절반으로 줄입니다.
• 이 방법의 주요 특징은 여러 호스트가 동일한 네트워크를 공유할 때, 처음에는 나중에 진입하는 쪽이 불리하지만, 시간이 지나면 모든 호스트가 공평하게 네트워크 자원을 사용하게 된다는 특징이 있다. (= 평형상태로 수렴하게 된다.)
• AIMD의 문제점은 초기에 네트워크의 높은 대역폭을 최대한 활용하지 못하여 시간이 오래 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못하여 혼잡 상태가 발생한 후에야 대역폭을 줄이게 된다는 점이다.

Slow Start (느린 시작)

• Slow Start는 AIMD의 초기 전송 속도 증가 단계에서 느리게 반응하는 단점을 개선하기 위해 도입된 방법이다.
• AIMD와 마찬가지로 단위 시간당 하나의 패킷을 전송하며 시작하고, 각 패킷의 ACK를 받을 때마다 window size를 1씩 증가시킨다. 즉, 한 주기가 지나면 window size는 기존의 2배가 된다.
• AIMD에 반해 전송 속도가 지수 함수 꼴로 증가한다. 만약 혼잡이 감지되면 window size는 1로 초기화된다.
• 한 번 혼잡이 발생한 후에는, 네트워크의 수용 능력을 어느 정도 예상할 수 있기 때문에, 이전에 감지된 혼잡 상태의 window size 절반까지는 이전처럼 지수적으로 증가시키고, 그 이후부터는 선형적으로(1씩) 증가시키게 됩니다.

Fast Retransmit (빠른 재전송)

• Fast Retransmit은 TCP 혼잡 제어의 확장된 부분으로, 패킷의 순차적인 도착을 보장하기 위한 메커니즘이다.
• 패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 된다.
• 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있다.
• 예를 들어,
  1. 수신측이 패킷 1을 받으면, "다음에는 패킷 2를 기대한다"는 의미로 ACK 2를 송신측에 보냅니다.
  2. 만약 패킷 2가 중간에 손실되었고, 패킷 3이 도착하면 수신측은 여전히 패킷 2를 기대하고 있습니다. 그래서 "다음에는 패킷 2를 기대한다"는 의미로 다시 ACK 2를 송신측에 보냅니다.
  3. 패킷 4가 도착하더라도 패킷 2가 아직 도착하지 않았기 때문에 수신측은 계속해서 ACK 2를 송신측에 보냅니다.
• 즉 중복 ACK를 3번 연속으로 받는 경우, 해당 패킷은 손실된 것으로 판단하고 즉시 재전송합니다. 동시에 이러한 중복 ACK는 네트워크의 혼잡을 암시하기 때문에 window size를 조절한다.

Fast Recovery (빠른 회복)

• Fast Recovery는 혼잡이 발생했을 때 회복 속도를 빠르게 하기위한 방법이다.
• 중복 ACK를 받아 혼잡이 감지되면 window size를 반으로 줄인다. 이는 네트워크 혼잡을 완화하고, 손실된 패킷에 대한 재전송을 처리하기 위해서이다.
• 이후 Fast Recovery 기간 동안, 중복 ACK 패킷을 받을 때마다 cwnd(congestion window) 창 크기를 선형적으로 증가시킨다. 따라서 재전송 대기 중인 패킷 외에도 추가적인 패킷을 전송할 수 있는 여유가 생긴다. 이렇게 하면, 재전송이 완료되는 시기에 TCP는 혼잡 상태 전의 창 크기 근처에서 다시 시작하게 된다. 따라서 혼잡 상태 후의 회복 시간을 단축시키며 네트워크의 사용률을 극대화한다.
• 새로운 ACK (중복되지 않은 ACK)를 수신하면, TCP는 Fast Recovery 모드를 종료하고 AIMD (Additive Increase / Multiplicative Decrease) 방식으로 돌아간다. 이때, 창 크기는 혼잡 시점에서의 창 크기의 절반으로 설정됩니다.
• 이후, 선형적인 증가 (Additive Increase)와 혼잡 감지 시의 곱셈적인 감소 (Multiplicative Decrease)로 네트워크 상태를 조절한다.

---

☀️ 참고

TCP/IP (흐름제어/혼잡제어) | 👨🏻‍💻 Tech Interview

재전송 기반 에러제어

Chapter 11. Data-Link Layer