TCP (흐름제어/혼잡제어)
들어가기 전
- TCP 통신이란?
- 네트워크 통신에서 신뢰적인 연결방식
- TCP는 기본적으로 unreliable network에서, reliable network를 보장할 수 있도록 하는 프로토콜
- TCP는 network congestion avoidance algorithm을 사용
네트워크 혼잡 회피란?
네트워크 혼잡 회피(Congestion Avoidance) 알고리즘은 TCP(Transmission Control Protocol) 프로토콜에서 네트워크 혼잡을 회피하기 위해 사용되는 알고리즘입니다. 이 알고리즘은 네트워크 상황을 모니터링하고, 네트워크 혼잡을 발견하면 데이터 전송 속도를 감소시키는 방식으로 동작합니다. 이를 통해 네트워크 혼잡을 회피하고, 안정적인 데이터 전송을 보장합니다.TCP 프로토콜에서 사용되는 대표적인 네트워크 혼잡 회피 알고리즘으로는 다음과 같은 것들이 있습니다.
- Slow Start: 처음 데이터를 보낼 때 데이터 전송 속도를 빠르게 늘려가는 알고리즘입니다. 데이터 전송이 원활하게 이루어지고, 혼잡 현상이 발생하지 않으면 데이터 전송 속도를 지수적으로 증가시킵니다.
- Congestion Avoidance: Slow Start 이후, 데이터 전송 속도를 선형적으로 증가시키는 알고리즘입니다. 이때, 패킷 손실이 발생하거나 일정 기준을 초과할 경우, 데이터 전송 속도를 감소시킵니다.
- Fast Retransmit: 일정 시간동안 ACK(Acknowledgement) 패킷을 받지 못할 경우, 재전송하는 알고리즘입니다. Slow Start나 Congestion Avoidance보다 효율적으로 패킷 손실을 처리할 수 있습니다.
- Fast Recovery: Fast Retransmit 이후에 사용되는 알고리즘으로, 패킷 손실을 처리하는 동안 데이터 전송 속도를 절반으로 감소시키는 것이 아니라, 속도를 조금 늦추는 방식으로 데이터 전송 속도를 감소시킵니다.
이러한 네트워크 혼잡 회피 알고리즘들은 TCP 프로토콜에서 사용되며, 안정적인 데이터 전송을 보장하기 위해 매우 중요합니다.
Fast Retansmit 이란?
Fast Retransmit은 TCP(Transmission Control Protocol) 프로토콜에서 사용되는 네트워크 혼잡 제어(Congestion Control) 알고리즘 중 하나입니다. Fast Retransmit 알고리즘은 패킷 손실을 감지하고, 해당 패킷을 재전송하는 것을 목적으로 합니다.Fast Retransmit 알고리즘은 일반적으로 Timeout 기반의 재전송보다 더 빠르게 패킷을 재전송할 수 있는 장점이 있습니다. Timeout 기반의 재전송은 일반적으로 매우 느리며, 속도가 느리기 때문에 재전송이 많이 발생할 수 있습니다. 반면 Fast Retransmit 알고리즘은 패킷 손실이 발생하면 ACK(Acknowledgement) 패킷이 오기를 기다리지 않고 바로 재전송을 시도합니다. 이러한 방식으로 빠르게 재전송을 처리할 수 있습니다.
Fast Retransmit 알고리즘은 패킷이 손실되었다는 것을 판단하는 기준이 되는 임계값을 설정합니다. 일반적으로 패킷을 재전송하는데 필요한 ACK 패킷의 수는 3개입니다. 따라서, 패킷 손실이 발생하면 ACK 패킷이 3개 이상 연속으로 오지 않으면, 해당 패킷을 재전송합니다. 이를 3 Duplicate ACKs라고 합니다.
Fast Retransmit 알고리즘은 Timeout 기반의 재전송보다 더 빠르게 패킷을 재전송할 수 있는 장점이 있지만, 잘못된 Duplicate ACKs로 인해 패킷이 재전송되는 경우도 있습니다. 이러한 경우를 방지하기 위해서는 TCP 프로토콜에서는 Fast Recovery 알고리즘을 함께 사용합니다. Fast Recovery 알고리즘은 Fast Retransmit이 발생한 후에 데이터 전송 속도를 조금 늦추는 방식으로 동작합니다.
- reliable network를 보장한다는 것은 4가지 문제점 존재
- 손실 : packet이 손실될 수 있는 문제
- 순서 바뀜 : packet의 순서가 바뀌는 문제
- Congestion : 네트워크가 혼잡한 문제
- Overload : receiver가 overload 되는 문제
Reliable Network에서 Overload는 네트워크 상황에서 발생하는 혼잡 현상을 말합니다. 네트워크는 유한한 대역폭(Bandwidth)을 가지고 있기 때문에, 동시에 많은 양의 데이터가 전송될 경우 네트워크 혼잡이 발생할 수 있습니다. 이러한 혼잡 현상은 데이터 전송 속도를 저하시키고, 패킷 손실을 야기할 수 있습니다.
Overload는 일반적으로 다음과 같은 상황에서 발생할 수 있습니다.
- 대역폭 초과
네트워크의 대역폭을 초과하는 양의 데이터가 전송되는 경우 발생합니다. 대역폭은 유한하기 때문에, 대역폭을 초과하는 양의 데이터가 전송되면 다른 데이터 전송 속도가 느려지고, 패킷 손실이 발생합니다. - 라우터 혼잡
네트워크의 라우터에서 처리할 수 있는 데이터 양을 초과하는 양의 데이터가 전송되는 경우 발생합니다. 이 경우, 라우터에서 처리되지 못한 데이터는 버려지거나, 큐(Queue)에 쌓이기 때문에 패킷 손실이 발생하고, 전송 속도가 느려집니다. - 데이터 전송 속도 불균형
대량의 데이터가 특정 노드로 전송될 경우, 해당 노드에서는 다른 노드보다 데이터 처리 속도가 느려지기 때문에 혼잡 현상이 발생할 수 있습니다.
Overload를 방지하기 위해서는 네트워크 혼잡 회피(Congestion Avoidance) 알고리즘이 사용됩니다. 이 알고리즘은 TCP(Transmission Control Protocol) 프로토콜에서 사용되며, 네트워크 혼잡을 감지하면 데이터 전송 속도를 감소시켜 혼잡 현상을 회피합니다.
- 대역폭 초과
- 흐름제어/혼잡제어란?
- 흐름제어 (endsystem 대 endsystem)
- 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
- Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
- 기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback 한다는 점
- 혼잡제어 : 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
- 흐름제어 (endsystem 대 endsystem)
- 전송의 전체 과정
- 응용 계층(Application Layer)에서 데이터를 전송할 때, 보내는 쪽(sender)의 애플리케이션(Application)은 소켓(Socket)에 데이터를 쓰게 됩니다.
- 이 데이터는 전송 계층(Transport Layer)으로 전달되어 세그먼트(Segment)라는 작은 단위로 나누어집니다.
- 전송 계층은 이 세그먼트를 네트워크 계층(Network Layer)에 넘겨줍니다.
- 전송된 데이터는 수신자(receiver) 쪽으로 전달되어, 수신자 쪽에서는 수신 버퍼(Receive Buffer)에 저장됩니다.
- 이때, 수신자 쪽에서는 수신 버퍼의 용량을 넘치게 하지 않도록 조절해야 합니다.
- 수신자 쪽에서는 자신의 수신 버퍼의 남은 용량을 상대방(sender)에게 알려주는데, 이를 "수신 윈도우(Receive Window)"라고 합니다.
- 송신자(sender)는 수신자의 수신 윈도우를 확인하여 수신자의 수신 버퍼 용량을 초과하지 않도록 데이터를 전송합니다.
- 이를 통해 데이터 전송 중에 수신 버퍼가 넘치는 현상을 방지하면서, 안정적인 데이터 전송을 보장합니다. 이를 "플로우 컨트롤(Flow Control)"이라고 합니다.
따라서, 플로우 컨트롤은 전송 중에 발생하는 수신 버퍼의 오버플로우를 방지하면서, 안정적인 데이터 전송을 위해 중요한 기술입니다.
1. 흐름제어 (Flow Control)
-
수신측이 송신측보다 데이터 처리 속도가 빠르면 문제없지만, 송신측의 속도가 빠를 경우 문제가 생긴다.
-
수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있으며, 만약 손실 된다면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 빈번히 발생한다.
-
이러한 위험을 줄이기 위해 송신 측의 데이터 전송량을 수신측에 따라 조절해야한다.
-
해결방법
-
Stop and Wait : 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
-
Sliding Window (Go Back N ARQ)
-
수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어기법
-
목적 : 전송은 되었지만, acked를 받지 못한 byte의 숫자를 파악하기 위해 사용하는 protocol
LastByteSent - LastByteAcked <= ReceivecWindowAdvertised
(마지막에 보내진 바이트 - 마지막에 확인된 바이트 <= 남아있는 공간) ==
(현재 공중에 떠있는 패킷 수 <= sliding window)
-
-
동작방식 : 먼저 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는대로 이 윈도우를 옆으로 옮김으로써 그 다음 패킷들을 전송
-
Window : TCP/IP를 사용하는 모든 호스트들은 송신하기 위한 것과 수신하기 위한 2개의 Window를 가지고 있다. 호스트들은 실제 데이터를 보내기 전에 '3 way handshaking'을 통해 수신 호스트의 receive window size에 자신의 send window size를 맞추게 된다.
-
세부구조
- 송신 버퍼
-
- 200 이전의 바이트는 이미 전송되었고, 확인응답을 받은 상태
- 200 ~ 202 바이트는 전송되었으나 확인응답을 받지 못한 상태
- 203 ~ 211 바이트는 아직 전송이 되지 않은 상태
- 수신 윈도우
- 송신 윈도우
- 수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정하게되면 흐름제어가 가능하다.
- 송신 윈도우 이동
- Before : 203 ~ 204를 전송하면 수신측에서는 확인 응답 203을 보내고, 송신측은 이를 받아 after 상태와 같이 수신 윈도우를 203 ~ 209 범위로 이동
- after : 205 ~ 209가 전송 가능한 상태
- Selected Repeat
- 송신 버퍼
-
Sliding Window(슬라이딩 윈도우)는 네트워크 프로토콜에서 데이터를 전송하는데 사용되는 방식 중 하나입니다. Sliding Window는 전송하는 데이터의 일부분만 보내고, 수신 측에서 ACK(Acknowledgement)를 받은 후에 나머지 데이터를 전송하는 방식입니다. 이를 통해 전송 속도를 향상시키고, 데이터 손실을 최소화할 수 있습니다.
Sliding Window는 일반적으로 다음과 같은 요소로 구성됩니다.
- Window Size(윈도우 크기)
- Window Size는 전송할 수 있는 데이터의 크기를 나타내며, 일반적으로 바이트(Byte) 단위로 표현됩니다. Window Size는 송신 측과 수신 측에서 모두 동일해야 하며, 데이터 전송 시에 윈도우 크기를 초과하지 않도록 제한됩니다.
- Sequence Number(시퀀스 번호)
- Sequence Number는 전송되는 데이터의 순서를 나타내는 번호입니다. Sequence Number는 송신 측에서 할당되며, 수신 측에서는 Sequence Number를 이용하여 전송된 데이터의 순서를 파악할 수 있습니다.
- Acknowledgement Number(ACK 번호)
- Acknowledgement Number는 수신 측에서 전송한 데이터를 송신 측에서 잘 받았는지를 알려주는 번호입니다. ACK 번호는 송신 측에서 전송한 데이터의 시퀀스 번호와 동일하거나, 그보다 큰 번호를 가지며, 수신 측에서는 ACK 번호를 이용하여 전송한 데이터의 일부분만 수신한 경우에도 송신 측에게 알려줄 수 있습니다.
- Timeout(타임아웃)
- Timeout은 데이터 전송에 소요되는 시간을 나타내며, 일반적으로 밀리초(millisecond) 단위로 표현됩니다. Timeout은 ACK를 수신하는데 걸리는 시간을 고려하여 설정됩니다. 만약, ACK를 수신하지 못한 경우 Timeout이 발생하면 해당 데이터를 다시 전송하게 됩니다.
Sliding Window는 일반적으로 TCP(Transmission Control Protocol) 프로토콜에서 사용됩니다. TCP 프로토콜에서는 Sliding Window를 이용하여 데이터 전송 속도를 향상시키고, 데이터 손실을 최소화할 수 있습니다.
2. 혼잡제어 (Congestion Control)
- 송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달된다. 만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 된다. 이런 경우 호스트들은 또 다시 재전송을 하게되고 결국 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생시키게 된다. 따라서 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송속도를 강제로 줄이게 되는데, 이러한 작업을 혼잡제어라고 한다.
- 또한 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어라고 한다.
- 흐름제어가 송신측과 수신측 사이의 전송속도를 다루는데 반해, 혼잡제어는 호스트와 라우터를 포함한 보다 넓은 관점에서 전송 문제를 다루게 된다.
- 해결 방법
- AIMD(Additive Increase / Multiplicative Decrease)
- 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
- 패킷 전송에 실패하거나 일정 시간을 넘으면 패킷의 보내는 속도를 절반으로 줄인다.
- 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형상태로 수렴하게 되는 특징이 있다.
- 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.
- Slow Start (느린 시작)
- AIMD 방식이 네트워크의 수용량 주변에서는 효율적으로 작동하지만, 처음에 전송 속도를 올리는데 시간이 오래 걸리는 단점이 존재했다.
- Slow Start 방식은 AIMD와 마찬가지로 패킷을 하나씩 보내면서 시작하고, 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려준다. 즉, 한 주기가 지나면 window size가 2배로 된다.
- 전송속도는 AIMD에 반해 지수 함수 꼴로 증가한다. 대신에 혼잡 현상이 발생하면 window size를 1로 떨어뜨리게 된다.
- 처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만, 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있다.
- 그러므로 혼잡 현상이 발생하였던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킨다.
- Fast Retransmit (빠른 재전송)
- 빠른 재전송은 TCP의 혼잡 조절에 추가된 정책이다.
- 패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 된다.
- 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있다.
- 중복된 순번의 패킷을 3개 받으면 재전송을 하게 된다. 약간 혼잡한 상황이 일어난 것이므로 혼잡을 감지하고 window size를 줄이게 된다.
- Fast Recovery (빠른 회복)
- 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다. 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.
[ref]
