Flow Control, Error control and Congestion Control in TCP Protocol
TCP 프로토콜에서의 흐름제어, 오류제어, 혼잡제어
Contents
1️⃣ 흐름제어 (Flow Control)
2️⃣ 오류제어 (Error Control)
3️⃣ 혼잡제어 (Congestion Control)
TCP 흐름제어, 오류제어, 혼잡제어 Summary
✅흐름제어 (Flow Control)
슬라이딩 윈도우 (Sliding Window) 메커니즘을 사용하여 송신측에서 수신측으로 데이터가 넘치지 않도록 제어한다.
수신측의 수신 윈도우 크기 (rwnd)를 기반으로 송신 윈도우 크기를 조정하여 데이터가 효율적으로 전송되도록 한다.
✅오류제어 (Error Control): TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 오류 제어를 수행한다.
재전송 타이머(RTO)가 만료되거나, 3개의 중복 ACK를 수신하면 데이터 패킷을 재전송한다.
데이터 손실이나 중복 상황에서 확인응답(ACK)을 활용하여 손실된 데이터를 복구하고 송신을 조정하게 된다.
✅혼잡제어 (Congestion Control) : 네트워크 혼잡을 방지하거나 해결하기 위해 혼잡 제어를 수행한다. 혼잡윈도우(cwnd)와 수신윈도우(rwnd) 중 작은 값을 송신 윈도우 크기로 사용합한다.
혼잡 제어는 3단계로 이루어진다.
느린 시작 (Slow Start): 혼잡윈도우를 지수적으로 증가시켜 초기 전송 속도를 조정
혼잡 회피 (Congestion Avoidance): 혼잡윈도우를 선형적으로 증가시켜 혼잡 발생을 방지
혼잡 감지 (Congestion Detection): 혼잡 발생 시, 혼잡윈도우 크기를 감소(지수 감소)시키고 다시 느린 시작으로 전환한다.
TCP는 흐름 제어, 오류 제어, 혼잡 제어를 통해:
흐름 제어: 수신측의 용량을 고려해 데이터 초과를 방지.
오류 제어: 손실된 데이터를 재전송하여 신뢰성을 보장.
혼잡 제어: 네트워크 혼잡을 예방 및 해결하여 전송 효율을 최적화.
이 세 가지 메커니즘은 네트워크의 안정성과 효율성을 유지하는 핵심 요소이다.
1️⃣ 흐름제어 (Flow Control)
💡요약: TCP 흐름제어 (TCP Flow Control)의 과정을 그림으로 확인한다. 송신자가 데이터를 보내면, 수신자는 이를 받고 피드백을 돌려보내어 송신자가 너무 빨리 데이터를 보내지 않도록 한다. 이 과정을 통해 데이터 전송이 안전하고 효율적으로 이루어지게 된다.
Application Layer(응용 계층)에서 데이터가 Transport Layer(전송 계층)로 전달된다.
데이터는
Segments형태로 전송되고, 송신자와 수신자 간의 데이터 흐름에 피드백을 주고받음으로써 과부하를 방지한다.Flow Control Feedback(흐름제어 피드백)은 송신자가 수신자의 상태에 맞게 데이터 전송 속도를 조절할 수 있도록 돕는 역할을 한다.
왼쪽에는 송신자 (Sender), 오른쪽에는 수신자 (Receiver)가 있다. 송신자는 데이터를 보내고, 수신자는 받은 데이터에 대한 피드백을 송신자에게 보낸다. 이 피드백은 송신자가 데이터를 보낼 때 과도하게 보내지 않도록 도와준다.
흐름제어는 송신자가 너무 빠르게 데이터를 보내서 수신자가 감당하지 못하는 상황을 방지하는 중요한 역할을 한다. 또한, 이 이미지는 장치와 장치 사이뿐 아니라, 서로 다른 계층 간에도 데이터 흐름제어가 일어날 수 있다는 점을 보여준다.
오늘은 이 과정 중에서도 특히 전송 계층 (Transport Layer)에 집중해서 살펴볼 예정이다.
TCP 흐름제어 #1: 윈도우 크기(TCP Window Size and Flow Control)
💡요약: TCP 윈도우 크기 (TCP Window Size)와 관련된 흐름제어를 살펴보자. 송신 윈도우 (Sending Window)와 수신 윈도우 (Receiving Window)는 데이터가 안전하고 효율적으로 전송되도록 도와주는 중요한 개념이다. 오늘은 특히 전송 계층 (Transport Layer)에서 데이터 흐름과 윈도우 크기를 어떻게 조정하는지 집중적으로 살펴볼 예정이다.
✅송신 윈도우 (Sending Window)
송신 윈도우 크기는
수신자의 상태와 네트워크 상황 (Receiver's Status and Network Conditions)에 따라 조정된다.데이터를 세그먼트 단위 (Segment Units)로 전송하지만, 실제로 윈도우 크기를 바이트 단위 (Byte Units)로 관리한다.
✅수신 윈도우 (Receiving Window):
수신 윈도우는 송신 측에서 넘치지 않고 수신자가 처리할 수 있는 데이터 바이트 크기를 결정할 수 있다.
- 윈도우 크기 계산 공식:
rwnd (Receive Window)=버퍼 크기 (Buffer Size)-읽히기를 기다리는 바이트 수 (Bytes Waiting to be Read)
수신자의 상태와 네트워크 상황 (Receiver's Status and Network Conditions)
✅수신자의 상태 변화, 흐름제어
만약 수신자의 버퍼가 거의 가득 찬 경우, 수신자는 송신자에게 작은 윈도우 크기(rwnd)를 전달한다. 송신자는 데이터를 천천히 보내게 된다.
반대로, 수신자가 데이터를 처리하고 버퍼 공간이 여유로워지면, 더 큰 rwnd 값을 송신자에게 보내게 된다.
✅ 네트워크 혼잡 상황, 혼잡제어
- 송신자가 데이터를 너무 빠르게 보낸다면 네트워크는 혼잡해지고 패킷 손실이 발생할 수 있다. 이를 감지하면 송신자는 윈도우 크기를 줄이고 전송 속도를 늦추게 된다.
TCP 흐름제어 #2: 송신 윈도우 동작 (How the TCP Send Window Operates)
💡요약: TCP 송신 윈도우가 슬라이딩 윈도우 방식 (Sliding Window Mechanism)으로 동작하며, 수신 상태와 네트워크 상황에 따라 동적으로 윈도우 크기가 조정되는 과정을 시각화하였다.
✅ 송신 윈도우의 주요 개념
윈도우 크기 (Window Size):
송신 윈도우는 송신자가 데이터의 어느 부분까지 전송할 수 있는지를 정의한다.
예시로, 윈도우 크기가 201~300 바이트라면, 송신자는 201번부터 300번 바이트까지 데이터를 자유롭게 보낼 수 있다.
주황색 부분 (Orange Area):
- 이미 송신된 데이터로, 수신자가 아직 확인 응답(ACK)을 보내지 않았다.
하얀색 부분 (White Area):
아직 전송되지 않은 데이터로, 송신 가능한 데이터 영역 (Usable Window)을 나타낸다.
예: 261~300 바이트는 아직 전송되지 않은 영역이다.
✅송신 윈도우의 동작
왼쪽 벽 (Left Wall):
데이터가 정상적으로 수신되었다는 확인(ACK)을 받으면 왼쪽 벽이 앞으로 이동 (Closes)하여 윈도우 크기를 조정한다.
이는 송신자가 전송된 데이터를 안전하게 버퍼에서 제거할 수 있음을 의미한다.
오른쪽 벽 (Right Wall):
윈도우 크기가 늘어나면 오른쪽 벽이 오른쪽으로 이동 (Opens)하게 된다.
수신자가 여유로운 상태임을 나타내며, 송신자가 더 많은 데이터를 전송할 수 있도록 허용한다.
Shrink (윈도우 축소):
수신자가 데이터를 받을 수 없는 긴급 상황 (Receiver Cannot Handle Data)이 발생하면, 오른쪽 벽이 줄어들어 윈도우 크기가 축소된다.
이는 드물게 발생하며, 송신자에게 데이터를 일시적으로 전송하지 말라는 신호를 보낸다.
TCP 흐름제어 #3: 수신 윈도우 동작 (How the TCP Receive Window Operates)
💡요약: TCP 수신 윈도우는 버퍼 크기 (Buffer Size)와 수신 데이터의 처리 상태 (Processing Status)에 따라 동적으로 조정된다. 이는 데이터를 효율적으로 받아들이고 송신자와 수신자 간 데이터 흐름을 조화롭게 유지하는 데 중요한 역할을 한다.
✅ 수신 윈도우의 주요 개념
주황색 영역 (Orange Area):
이미 수신된 데이터 (Bytes Already Received)로, 수신 장치가 정상적으로 데이터를 받아 처리 대기 상태에 있다는 뜻
수신된 데이터가 아직 응용 계층 (Application Layer)으로 전달되지 않은 경우에도 이 영역에 포함된다.
검은색 굵은 박스 (Black Bold Box):
수신 윈도우 크기 (Receive Window Size, rwnd)를 나타낸다.
rwnd = 버퍼 크기 (Buffer Size) - 읽히기를 기다리는 바이트 수 (Bytes Waiting to be Pulled by the Process).
버퍼 크기 제한 (Buffer Size Limit):
- 운영체제(OS)에서 설정된 메모리 크기이다. 수신 윈도우는 이 크기를 초과하지 않도록 동작한다.
✅수신 윈도우의 동작
왼쪽 벽 슬라이딩 (Left Wall Sliding - Closes):
- 수신된 데이터가 정상적으로 처리되었다면(예: 261번 데이터), 왼쪽 벽이 닫히며 (Closes) 이전에 사용되었던 영역이 해제된다.
- 이는 송신자에게 해당 데이터가 성공적으로 수신 및 처리되었음을 알리는 역할을 한다.
오른쪽 벽 슬라이딩 (Right Wall Sliding - Opens):
수신된 데이터가 처리되면서 버퍼 공간이 비워지면 오른쪽 벽이 열리며 (Opens) 새로운 데이터를 받을 준비가 된다.
이 과정은 수신 윈도우 크기를 늘려 송신자가 더 많은 데이터를 전송할 수 있도록 허용한다.
TCP 흐름제어 #4: 송신 윈도우와 수신 윈도우의 열기와 닫기 동작 (Opening and Closing Behavior of TCP Send and Receive Windows)
💡요약:
송신 윈도우 (Send Window):
닫기 (Closes): 확인 응답(ACK) 수신 시.
열기 (Opens): 수신 윈도우 크기(rwnd)에 따라.
수신 윈도우 (Receive Window):
닫기 (Closes): 데이터를 수신했을 때.
열기 (Opens): 응용 계층에서 데이터를 처리했을 때.
✅송신 윈도우 열기와 닫기
닫기 (Closing):
새로운 확인 응답 (ACK) 수신 시 송신 윈도우는 닫힘 (Closing when ACK is received).
송신자는 수신자로부터 데이터가 잘 수신되었다는 피드백(ACK)을 받으면 이전 데이터를 버퍼에서 제거하고 윈도우 크기를 조정한다.
열기 (Opening):
수신 윈도우 크기 (rwnd)에 따라 열림 (Opening based on Receive Window Size - rwnd).
송신자는 수신자로부터 받은 rwnd 값을 기반으로 더 많은 데이터를 전송할 수 있게 된다.
긴급 상황 (Emergency Situations):
- 수신자가 rwnd 값을 0으로 설정하면 송신 윈도우는 완전히 닫히며 데이터 전송이 중단된다.
혼잡 제어 (Congestion Control):
- 네트워크 상황에 따라 송신 윈도우 크기가 축소(Shrink)될 수도 있다.
✅수신 윈도우 열기와 닫기
닫기 (Closing):
데이터를 수신하면 수신 윈도우는 닫힘 (Closing when data is received).
수신자가 데이터를 수신하면 수신 버퍼에서 공간이 채워지면서 윈도우 크기가 줄어든다.
열기 (Opening):
응용프로세스가 데이터를 읽으면 수신 윈도우가 열림 (Opening when the application reads data).
응용 계층이 데이터를 처리하고 버퍼를 비우면, 수신 윈도우가 다시 열리면서 송신자가 더 많은 데이터를 보낼 수 있게 된다.
TCP 흐름제어 #5:
예 – Part 1 (Example of TCP Flow Control – Part 1)
💡요약: TCP 연결은 3-Way Handshake (3단계 핸드셰이크) 과정을 통해 설정되며, SYN → SYN + ACK → ACK를 통해 연결이 설정된다. 송신자가 데이터를 전송하면 수신자가 이를 확인(ACK)하며 윈도우 크기를 조정하게 된다. 수신자는 데이터 처리 후 수신 윈도우 (rwnd)를 업데이트하여 송신자가 전송할 수 있는 데이터를 조정한다.
💡중요개념
Sequence Number (seqNo): 데이터 전송의 순서 번호.
Acknowledgment Number (ackNo): 수신된 데이터에 대한 확인 번호.
Send Window Size: 송신자가 데이터를 보낼 수 있는 공간.
Receive Window Size (rwnd): 수신자가 데이터를 받을 수 있는 공간.
✅핸드셰이크 과정 (Handshake Process):
SYN (Synchronize): 클라이언트가 서버에 연결 요청을 보낸다.
- Sequence Number (seqNo): 100 (데이터 전송의 순서를 정하는 번호이다).
SYN + ACK (Synchronize + Acknowledgment):
서버가 연결 요청을 수락하고, 동시에 클라이언트에게 응답한다.
Sequence Number (seqNo): 1000 (서버의 초기 순서 번호).
Acknowledgment Number (ackNo): 101 (클라이언트의 SYN을 수락했다는 확인 번호).
ACK (Acknowledgment):
클라이언트가 서버의 응답을 확인한다.
이로써 연결이 완료된다.
✅데이터 전송 및 흐름제어 (Data Transmission and Flow Control):
송신 윈도우 설정 (Send Window Set):
클라이언트는 800바이트의 송신 윈도우 크기 (Size = 800)를 설정한다.
Sequence Number (seqNo): 101에서 시작.
데이터 전송 (Data Sent):
클라이언트는 200바이트를 서버로 전송한다.
송신 윈도우 크기 (Send Window Size)는 600으로 줄어든다 (800 - 200).
수신 윈도우 설정 (Receive Window Set):
- 서버는 800바이트의 수신 윈도우 크기 (rwnd = 800)를 설정한다.
데이터 수신 확인 (Data Acknowledgment):
서버가 데이터를 정상적으로 수신하면 Acknowledgment Number (ackNo): 301를 클라이언트에게 보낸다.
서버는 수신 윈도우 크기를 600 (rwnd = 600)으로 줄인다.
TCP 흐름제어 #6:
예 – Part 2 (Example of TCP Flow Control – Part 1)
✅초기 상태: 이 과정은 Part 1에서 이어진다.
클라이언트는 데이터를 계속 송신하고, 서버는 이를 수신하여 응답(ACK)을 보내며 윈도우 크기를 조정한다.
이전 단계에서 클라이언트는 seqNo: 301부터 시작되는 데이터를 보낼 준비가 되어 있다.
✅ 클라이언트가 데이터 전송 (Sender Sends Data)
클라이언트 → 서버: 클라이언트는 300바이트의 데이터를 전송한다.
- Sequence Number (seqNo): 301 (전송된 데이터의 시작 번호).
송신 윈도우 크기가 줄어든다. 기존 크기 (Size): 600, 새 크기: 600 - 300 = 400
- 송신 윈도우는 데이터를 전송한 만큼 크기가 감소한다.
✅ 서버가 데이터 수신 및 ACK 전송
서버 → 클라이언트: 서버는 300바이트의 데이터를 수신한다.
Acknowledgment Number (ackNo): 601 (301번부터 300바이트까지 데이터가 잘 수신되었음을 나타냄).
Receive Window Size (rwnd): 기존 크기: 400, 새 크기: 400 (300바이트를 수신했으나 100바이트만 응용 계층에서 소비됨).
✅ 서버의 데이터 처리 및 윈도우 크기 조정
서버: 서버가 수신한 데이터를 응용 계층으로 전달하면서 버퍼를 비운다. 추가로 200바이트가 소비되었다.
- Receive Window Size (rwnd): 기존 크기: 400, 새 크기: 600 (더 많은 공간이 확보됨).
✅ 서버가 업데이트된 ACK 전송
서버 → 클라이언트: 서버는 업데이트된 윈도우 크기와 함께 새로운 ACK를 전송
Acknowledgment Number (ackNo): 601 (이전 데이터가 모두 수신됨을 확인).
Receive Window Size (rwnd): 600 (서버가 수신 가능한 공간을 클라이언트에 알림).
✅ 송신 윈도우 크기 업데이트
- 클라이언트: 서버의 ACK를 수신하여 송신 윈도우 크기를 갱신한다. 송신 윈도우 크기가 다시 600으로 설정된다. 클라이언트는 새로운 데이터를 전송할 준비가 되었다.
TCP 흐름제어 #6: 어리석은 윈도우 신드롬 (Silly Window Syndrome)
💡요약: TCP의 흐름제어에서 발생할 수 있는 비효율적인 상황을 설명한다. 이 문제는 송신 측이나 수신 측의 응용 프로그램이 데이터를 비정상적으로 느리게 처리할 때 발생하게 된다.
✅문제 발생 상황
송신 측의 문제 (Slow Data Generation by the Sender):
- 송신 측의 응용 프로그램이 데이터를 천천히 발생 (Slowly Generate Data)시키는 경우) 예: 데이터를 10초에 한 번씩만 생성하는 상황.
수신 측의 문제 (Slow Data Consumption by the Receiver):
- 수신 측의 응용 프로그램이 데이터를 천천히 소비 (Slowly Consume Data)하는 경우. 예) 수신 프로그램이 데이터를 조금씩(1초 간격으로) 읽는 상황.
✅어리석은 윈도우 신드롬의 문제점
낭비되는 네트워크 자원 (Wasted Network Resources):
데이터를 아주 작은 단위로 나누어 전송하면, 각 데이터마다 20바이트의 TCP 헤더와 20바이트의 IP 헤더가 추가되게 된다. 예)1바이트의 데이터를 전송하기 위해 41바이트의 데이터그램이 필요하게 된다.
이는 불필요한 네트워크 대역폭을 차지하게 되어 자원이 낭비되는 결과를 낳는다.
전송 효율 감소 (Reduced Transmission Efficiency):
- 자주 발생하는 작은 데이터 전송은 네트워크를 혼잡하게 만들고, 다른 데이터 전송에도 영향을 미치게 된다.
TCP 흐름제어 #7: Nagle 알고리즘 (Nagle Algorithm)
💡요약: TCP에서 어리석은 윈도우 신드롬 (Silly Window Syndrome)을 방지하기 위해 설계된 송신 측 방안을 Nagle 알고리즘이라고 한다. 이 알고리즘은 데이터를 한 번에 조금씩 보내는 비효율을 줄이고, 네트워크 자원의 낭비를 최소화하는 데 초점을 둔다.
✅Nagle 알고리즘의 동작 원리
버퍼에서 대기 (Wait in the Buffer):
송신 TCP는 수신자로부터 ACK 패킷을 수신하거나,
또는 최대 크기의 세그먼트 (Maximum Segment Size, MSS)를 구성할 수 있을 정도로 충분한 데이터가 버퍼에 저장될 때까지 데이터를 전송하지 않고 대기한다.
RTT (Round Trip Time) 의존적 대기시간:
대기 시간은 네트워크의 왕복 전송 시간 (RTT)에 따라 결정된다.
즉, 송신 TCP는 네트워크 상태를 실시간으로 모니터링하면서 효율적인 시점에 데이터를 전송하게 된다.
데이터 전송 결정:
송신 TCP가 현재 데이터가 작더라도 ACK 패킷을 수신한 경우, 데이터를 전송한다.
또는 버퍼에 충분한 데이터가 쌓인 경우, 데이터를 한 번에 전송한다.
✅Nagle 알고리즘의 장점
네트워크 자원 절약 (Conserve Network Resources):
- 작은 데이터 조각들이 자주 전송되는 것을 방지하여 네트워크 대역폭을 절약한다.
전송 효율성 증가 (Increased Transmission Efficiency):
- 데이터를 묶어서 전송하므로 전송 횟수가 줄어들고, 전송 효율성이 높아진다.
RTT에 따른 최적화 (Optimization Based on RTT):
- 네트워크의 왕복 전송 시간(RTT)을 고려하여 데이터 전송을 최적화한다.
TCP 흐름제어 #8: 지연된 확인응답 알고리즘 (Delayed Acknowledgment Algorithm)
💡요약: TCP에서 수신 측 (Receiver)이 ACK 패킷(확인 응답)을 즉시 전송하지 않고, 일정 시간 대기한 후 전송하는 방안이다. 수신 윈도우가 충분히 커지거나 대기 시간이 최대 0.5초에 도달하면 ACK를 전송한다. 이를 통해 송신 측이 불필요한 재전송을 하지 않으면서 네트워크 효율을 높일 수 있게 된다.
✅ 지연된 확인응답 알고리즘의 동작 원리
대기 조건 (Waiting Condition):
수신 TCP는 데이터를 수신한 직후 즉시 ACK를 보내지 않는다.
대신, 수신 윈도우가 충분히 커질 때까지 (Wait until Receive Window is Large Enough) 대기한다.
이렇게 함으로써 네트워크에서 작은 크기의 ACK 패킷이 자주 전송되는 것을 방지한다.
대기 시간 (Waiting Time):
대기 시간이 최대 0.5초를 넘지 않도록 설계되었다.
송신 측에서 재전송 타이머가 만료되지 않도록 하기 위해 설정된 값이다.
대부분의 경우 ACK는 0.5초 이전에 처리되게 된다.
최적화 목표:
- 데이터를 더 묶어서 처리할 수 있도록 시간을 벌어 ACK 패킷 전송 횟수를 줄이고, 네트워크 자원 낭비를 방지한다.
✅ 지연된 확인응답 알고리즘의 장점
네트워크 자원 절약 (Saving Network Resources):
- 자주 발생하는 작은 크기의 ACK 패킷 전송을 방지하여 네트워크 대역폭을 절약한다.
효율적인 ACK 관리 (Efficient ACK Management):
- 수신 윈도우가 충분히 커질 때까지 대기하여 송신 측에서 데이터를 한 번에 더 많이 보낼 수 있도록 허용한다.
송신 측 재전송 방지 (Prevent Retransmissions by Sender):
- ACK 지연 시간이 0.5초를 초과하지 않도록 보장 (No Delay Beyond 0.5 Seconds)하여 송신 측이 불필요한 재전송을 하지 않도록 설계되었다.
2️⃣ 오류제어 (Error Control)
💡요약: 오류제어는 데이터가 네트워크에서 손실되거나 손상된 경우 복원하기 위한 메커니즘을 제공합니다. 누적 확인응답(ACK, Cumulative ACK)과 선택 확인응답(SACK, Selective ACK) 두 가지 유형이 존재한다. 어떻게 오류를 감지하고 데이터 손실을 복구하는 데 도움을 주는지 알아본다.
✅ 누적 확인응답 (Cumulative ACK)
정의: TCP 기본 헤더의 32비트 ACK 필드를 사용하여, 해당 ACK 번호보다 작은 순서번호의 데이터는 모두 정상적으로 수신되었음을 의미한다.
- 예) ACK 번호가 101이라면, 100번까지의 데이터는 모두 성공적으로 수신되었음을 나타낸다.
특징: 긍정적 확인응답 (Positive Acknowledgment) 방식.
데이터가 정상적으로 수신되지 않았을 경우(예: 데이터 손실, 중복 수신 등), 해당 데이터에 대한 피드백을 별도로 제공하지 않는다.
단순하고 효율적이지만, 손실된 데이터에 대한 정보가 부족하여 데이터 복구 과정이 느릴 수 있다.
✅ 선택 확인응답 (Selective ACK, SACK)
정의: TCP의 옵션 헤더를 사용한 부가적인 ACK 방식으로, 정상적으로 수신된 특정 데이터 바이트의 순서번호를 알려준다.
- 예) 데이터 손실로 인해 101
200번 데이터가 유실되었지만, 201300번 데이터는 정상적으로 수신되었다면, SACK을 통해 201~300번 데이터가 수신되었음을 송신자에게 알린다.
- 예) 데이터 손실로 인해 101
특징: 부분적인 확인응답 (Partial Acknowledgment) 방식.
손실된 데이터 구간을 빠르게 복구할 수 있어, 네트워크 효율성이 높아진다.
TCP 옵션 헤더를 사용하므로 추가적인 프로세싱이 필요하다.
오류제어 #1: 확인응답 전송의 일반적인 규칙들 (General Rules for Sending Acknowledgments in TCP)
💡요약: 확인응답(ACK)은 데이터 전송이 정상적으로 이루어졌는지 송신자에게 알리는 중요한 역할을 한다. 그렇기 때문에 ACK를 언제, 어떻게 전송할 것인가?는 네트워크 효율성을 위해 세밀하게 정의되어 있다.
✅ 확인응답 전송의 일반적인 규칙들 6가지
Rule-1: 데이터와 함께 ACK를 포함 (Piggybacking with Data)
설명: 송신 측에서 데이터 세그먼트를 전송할 때, 수신하고자 하는 다음 순서 번호 (Next Sequence Number)를 TCP 헤더에 포함시켜 전송한다.
- 이를 피기배킹 (Piggybacking)이라 부르며, 데이터와 ACK를 함께 전송하여 네트워크 자원을 절약할 수 있다.
장점: 별도의 ACK 패킷을 보내지 않아도 되므로 네트워크 트래픽이 줄어든다.
Rule-2: 데이터가 없을 때 ACK 전송 지연 (Delayed Acknowledgment)
설명: 수신 측에 전송할 데이터가 없고, 수신된 데이터 세그먼트에 대해 ACK만 전송해야 하는 경우, ACK 전송을 잠시 보류, 500ms 동안 지연한다.
- 이는 트래픽 증가를 방지하고 네트워크 효율성을 유지하기 위한 조치이다.
조건: ACK 지연 동안 추가 데이터가 도착하면, ACK는 새로운 데이터와 함께 전송된다. 최대 지연 시간(500ms)이 지나면, 별도의 ACK 패킷이 전송되게 된다.
💡 지연된 확인응답(Delayed Acknowledgment)방식이다. 이는 TCP에서 어리석은 윈도우 신드롬(Silly Window Syndrome)을 해결하기 위한 중요한 메커니즘 중 하나이다.
✅ Rule-3: 기대한 순서번호가 도착했을 때
설명: 수신자가 기대한 순서번호를 가진 데이터 세그먼트를 수신하였고 이전에 수신된 데이터 중 아직 확인응답(ACK)이 전송되지 않은 세그먼트가 있는 경우) 즉시 ACK 패킷을 전송하여 송신자에게 수신 상태를 알린다.
예: 수신자가 100번 데이터까지 수신했고, 기대 순서번호는 101번일 때, 101번 데이터가 도착하면 바로 ACK를 전송한다.
의의: 데이터 손실 방지 (Prevent Data Loss): 이전에 수신된 데이터에 대한 피드백을 빠르게 제공하여 송신자가 데이터 전송을 이어갈 수 있도록 돕는다.
✅ Rule-4: 기대보다 큰 순서번호가 도착했을 때
설명: 수신자가 기대한 순서번호보다 더 큰 순서번호를 가진 세그먼트를 수신한 경우) 즉시 ACK 패킷을 전송하여 송신자에게 현재 기대하고 있는 순서번호 (Expected Sequence Number)를 알린다.
예: 수신자가 101번을 기대하고 있었는데, 201번 세그먼트를 수신하면, ACK 패킷을 통해 송신자에게 101번 데이터를 다시 전송하도록 요청한다.
의의: 데이터 손실 및 중복 방지 (Prevent Data Loss and Duplication): 어긋난 데이터 순서를 처리하고, 송신자에게 빠르게 정보를 제공하여 네트워크 효율성을 유지한다.
✅ Rule-5: 누락된 세그먼트 복구
설명: 기대한 순서번호를 가진 누락된 세그먼트가 도착하면) 수신 측은 송신자에게 다음에 기대하는 순서번호 (Expected Sequence Number)를 알리기 위해 즉시 ACK를 전송한다.
예: 수신자가 100번 데이터까지 수신했고 101번이 누락 된 뒤 101번이 도착하면) ACK를 통해 송신자에게 "101번까지 잘 받았으며, 이제 102번을 기대합니다."라고 알리게 된다.
의의: 데이터 복구 및 흐름 조정 (Recovery and Flow Adjustment): 데이터 손실을 빠르게 복구하고, 송신자와의 데이터 흐름을 동기화한다.
✅ Rule-6: 중복된 세그먼트 처리
설명: 수신 측이 중복된 세그먼트를 수신한 경우, 중복된 데이터는 폐기하고, 즉시 ACK를 전송한다. 중복 ACK는 송신자에게 문제가 있음을 알리는 신호로 작동한다.
예: 송신자가 101번 데이터를 두 번 전송하면, 수신자는 첫 번째 101번 데이터를 수신한 후 ACK를 전송하고, 두 번째 101번 데이터를 무시한 뒤 다시 ACK를 전송하게 된다.
의의: 오류 탐지 및 복구 (Error Detection and Recovery): 송신 측은 중복 ACK를 확인하고 데이터 손실이 발생했는지 점검할 수 있다. ACK 중요성: ACK 자체의 손실 문제일 가능성이 높다.
오류제어 #2: 데이터 세그먼트의 재전송 (Retransmission of Data Segments in TCP)
💡요약: TCP 프로토콜은 데이터를 송신한 후, 확인응답(ACK)을 기반으로 데이터가 정상적으로 전달되었는지 판단한다. 만약 확인응답이 오지 않으면 데이터 세그먼트를 재전송하는 메커니즘을 사용하게 된다. 이 과정에서 중요한 역할을 하는 것이 RTO (Retransmission Time-Out) 타이머이다.
RTO (Retransmission Time-Out):
타이머 기반으로 데이터가 재전송.
타이머 값은 RTT의 4~5배로 설정.
TCP Tahoe:
타이머 만료 시 가장 작은 순서번호의 데이터를 재전송.
단순하고 신뢰할 수 있는 방식으로 작동.
✅ TCP Tahoe와 RTO 재전송 방식 - RTO (Retransmission Time-Out)란?
타이머 기반 재전송 (Retransmission Based on Timer): 데이터를 송신할 때, 동시에 타이머가 시작된다. 송신한 데이터에 대한 ACK를 타이머 만료 전까지 받지 못하면, 송신자는 해당 데이터를 재전송 (Retransmit)한다.
타이머 값 (Timer Value): 타이머 값은 네트워크의 RTT (Round Trip Time) 값을 기반으로 설정된다. 일반적으로 RTO 값은 RTT의 4~5배로 설정하여 타이머를 갱신한다.
✅ TCP Tahoe의 재전송 동작
타이머 만료 시 재전송: 확인응답(ACK)을 받지 못하면, 송신자는 송신 버퍼에서 가장 작은 순서번호의 데이터를 재전송한다. 이후, 다시 새로운 타이머를 설정한다.
타이머와 RTT: RTT는 데이터를 송신한 후 ACK를 받을 때까지 걸리는 시간을 측정한다. RTO 값은 RTT를 기반으로 조정되므로 네트워크 상태에 따라 동적으로 변경된다.
오류제어 #3: 데이터 세그먼트의 재전송 - TCP Reno (Retransmission of Data Segments - TCP Reno)
💡요약: TCP Tahoe에서 RTO(Retransmission Time-Out)를 기반으로 한 재전송은 신뢰성은 높지만 데이터 복구 속도가 느릴 수 있다. 이를 개선하기 위해 TCP Reno는 빠른 재전송(Fast Retransmit)이라는 새로운 매커니즘이 도입되었다.
✅ TCP Reno의 주요 특징
중복 ACK를 이용한 빠른 재전송 (Fast Retransmit Using Duplicate ACKs):
송신 측은 3번의 중복된 ACK(Duplicate ACK)를 수신하면 해당 패킷이 손실되었다고 간주하고 재전송을 즉시 시작하게 된다.
이는 재전송 타이머(RTO)가 만료되기 전에 데이터 복구를 시작할 수 있도록 도와준다.
왜 3번의 중복 ACK를 기준으로 하는가?
중복 ACK는 수신자가 기대한 순서번호의 패킷이 도착하지 않았음을 의미한다.
단순 네트워크 지연으로 인한 중복 ACK가 발생할 가능성을 줄이고, 신뢰할 수 있는 손실 판단을 위해 3번의 중복 ACK를 기준으로 설정하였다.
장점:
빠른 복구 (Faster Recovery):
- 패킷 손실이 발생하더라도, RTO 타이머 만료를 기다릴 필요 없이 데이터를 빠르게 재전송한다.
효율적인 오류제어 (Efficient Error Control):
- 데이터 복구 속도가 빨라 네트워크의 혼잡 상태를 완화한다.
오류제어 #4: TCP 송신 측의 단순화된 FSM (Simplified FSM for TCP Sender)
💡요약: TCP 송신 측의 FSM(Finite State Machine)이 다양한 상황에서 어떻게 상태를 전환하고, 데이터 전송과 복구를 관리하는지 설명한다. 여기에는 흐름제어, 확인응답 규칙, 타이머 기반 재전송, 그리고 중복 ACK를 활용한 빠른 재전송 등이 모두 포함되어 있다.
💡중요포인트:
Ready 상태: 데이터 준비 및 전송, 첫 세그먼트 전송 시 타이머 시작.
Blocking 상태: 송신 윈도우가 가득 찼을 때 대기, 윈도우가 열리면 Ready 상태로 복귀.
주요 이벤트 처리:
타임아웃: 첫 세그먼트 재전송.
중복 ACK: 3번 수신 시 빠른 재전송.
정상 ACK: 윈도우 크기 조정 및 큐 정리.
손상된 ACK: 폐기.
✅ FSM의 주요 상태
Ready 상태: 송신자는 데이터를 전송할 준비 상태이다.
Chunk of Bytes Accepted: 프로세스로부터 데이터가 수신되면 세그먼트를 생성하고, seqNo (Sequence Number)를 할당하여 큐에 저장한 뒤 전송한다.
첫 번째 세그먼트를 전송하면 타이머 시작 (Start the Timer).
Blocking 상태: 송신 윈도우가 가득 찼을 경우(Flow Control에 따라), 새로운 데이터를 전송하지 않고 Blocking 상태로 전환된다.
- 윈도우가 열리면 Ready 상태로 돌아간다.
✅ 주요 이벤트와 처리
타임아웃 발생 (Time-Out Occurred): 타이머가 만료되면, 송신자는 큐의 첫 번째 세그먼트를 다시 전송하고 타이머를 재설정한다.
- 의의: 데이터 손실을 복구하고 재전송 과정을 시작.
손상된 ACK 수신 (Corrupted ACK Arrived): ACK가 손상된 경우, 송신자는 이를 폐기한다.
- 의의: 잘못된 정보를 기반으로 동작하지 않도록 보장.
중복 ACK 수신 (Duplicate ACK Arrived): 동일한 ACK를 3번 수신하면, 송신자는 해당 세그먼트를 빠르게 재전송한다.
- 의의: 빠른 재전송(Fast Retransmit)을 통해 손실된 데이터 복구를 가속화.
오류 없는 ACK 수신 (Error-Free ACK Arrived): ACK가 정상적으로 수신되면, 송신자는 윈도우 크기를 조정(Slide the Window)하고 큐에서 해당 세그먼트를 제거 한다.
- 의의: 송신 윈도우를 조정하여 새로운 데이터를 전송할 준비.
오류제어 #5: TCP 수신 측의 단순화된 FSM (Simplified FSM for TCP Receiver)
💡요약: TCP 수신 측의 FSM(Finite State Machine)에서 다양한 상황을 처리하는 메커니즘을 알아보자. Transport Layer (전송 계층)의 동작에 초점을 맞추어, 데이터 세그먼트의 수신, 확인응답(ACK) 생성, 오류 처리 등을 어떻게 처리하는지 설명한다.
💡중요포인트
정상적인 세그먼트 처리: 데이터를 버퍼에 저장, ACK 생성 또는 지연.
오류 처리: 손상된 세그먼트는 폐기, 순서가 어긋난 세그먼트는 중복 ACK 생성.
ACK-지연 타이머: 타이머 만료 시 ACK 전송.
프로세스 요청: 데이터 전달 및 윈도우 크기 조정
✅ FSM의 주요 상태와 동작
- Ready 상태: 수신자는 데이터 수신을 준비하는 기본 상태이다. 데이터가 정상적으로 수신되거나 오류가 발생했을 때 상태 전이가 이루어진다.
✅ 주요 이벤트와 처리
정상적인 세그먼트 도착 (An Expected Error-Free Segment Arrived):
데이터를 버퍼(Buffer)에 저장한다.
다음 순서 번호를 업데이트한다 (Rn = Rn + data length).
ACK-지연 타이머 (ACK-Delaying Timer)가 작동 중이면 중단하고, 누적 ACK를 즉시 전송한다.
타이머가 작동 중이 아니면 새로 시작한다.
의의: 정상 데이터를 처리하고, 필요 시 ACK를 지연 또는 즉시 전송.
손상된 세그먼트 도착 (A Corrupted Segment Arrived):
- 손상된 세그먼트를 폐기한다.
- 의의: 데이터 손실을 방지하고 오류를 명확히 처리.
정상적이지만 순서가 어긋난 세그먼트 도착 (An Error-Free, But Out-of-Order Segment Arrived):
중복이 아닌 경우 세그먼트를 저장한다.
중복 ACK (Duplicate ACK)를 생성하여 송신자에게 누락된 세그먼트가 있음을 알린다.
의의: 송신자에게 누락된 데이터 요청을 전달.
중복 세그먼트 도착 (An Error-Free Duplicate Segment or Segment Outside Window Arrived):
세그먼트를 폐기한다. 기대 순서 번호와 동일한 중복 ACK를 전송한다.
의의: 불필요한 데이터 재처리를 방지하고, 송신자에게 현재 상태를 알림.
ACK-지연 타이머 만료 (ACK-Delaying Timer Expired):
지연된 ACK를 전송한다.
의의: 네트워크 트래픽을 줄이고 효율성을 유지.
프로세스로부터 데이터 요청 (Request from Process for Delivery of Data):
- 데이터를 전송하고, 윈도우를 슬라이드(Slide the Window)하여 윈도우 크기를 조정한다.
- 의의: 데이터 소비를 관리하고 송신자에게 새로운 데이터 전송을 허용한다.
오류제어 #6: TCP 프로토콜에서 정상적인 동작 상황 (Normal Operation in TCP Protocol)
💡요약: TCP 프로토콜의 오류제어(Error Control)가 정상적으로 작동하는 과정이다. Transport Layer (전송 계층)에서 송신자와 수신자가 데이터를 주고받으며 확인응답(ACK)을 교환하는 방식과 규칙(Rule 1 피기배킹, Rule 2 지연된 확인응답, Rule 3 중복 데이터 처리)을 중심으로 설명한다.
✅초기 데이터 전송 - Rule 1 적용(피기배킹)
클라이언트(Client) → 서버(Server):
클라이언트가 1201~1400 (200바이트)의 데이터를 서버로 전송한다.
서버는 데이터를 오류 없이 수신하고, 클라이언트로 데이터를 보내야 하는 상황이다.
서버 → 클라이언트:
서버는 4001~5000 (1000바이트)의 데이터를 전송하면서, 확인응답(ACK 1401)을 포함하여 피기배킹(Piggybacking)으로 전송한다.
의의: 데이터와 ACK를 함께 전송하여 네트워크 효율성을 높임.
✅ 타이머 기반 확인응답 - Rule 2 적용 (지연 확인 응답)
클라이언트(Client):
서버로부터 데이터를 정상적으로 수신한 클라이언트는 즉시 ACK를 보내지 않고 약 500ms 지연한다.
500ms 타이머가 만료된 후, 클라이언트는 ACK 5001을 서버로 전송한다.
의의: ACK 지연을 통해 네트워크 트래픽을 줄이고 효율성을 유지.
✅ 중복 데이터 처리 - Rule 3 적용 (중복 데이터 처리)
서버(Server) → 클라이언트(Client):
서버는 5001~6000 (1000바이트) 데이터를 전송한 후, 6001~7000 (1000바이트) 데이터를 두 번 전송한다.
클라이언트는 중복 데이터를 감지하고: 타이머를 중단 (Stop the Timer)하고, 즉시 ACK 7001을 서버로 전송한다.
의의: 중복 데이터로 인한 전송 혼란을 방지하고, 데이터 손실 없이 전송을 조정.
오류제어 #7: 손실된 세그먼트의 처리 과정 (Handling Lost Segments in TCP)
💡요약: TCP 프로토콜에서 손실된 세그먼트가 발생했을 때, 타임아웃 기반 재전송(Time-Out Retransmission)과 중복 ACK(Duplicate ACK)를 활용한 복구 과정이 어떻게 진행되는지를 보여준다.
✅초기 데이터 전송 및 정상 확인응답 (ACK)
클라이언트(Client) → 서버(Server):
클라이언트가 501~600 데이터를 전송한다.
서버는 데이터를 정상적으로 수신하여 버퍼에 저장하지만, 지연응답(Delayed ACK)을 사용해 바로 ACK를 보내지 않는다.
601~700 데이터 전송:
클라이언트가 데이터를 전송하고, 서버는 데이터를 수신한 뒤 ACK 701을 전송한다.
클라이언트 타이머: 정상적으로 수신되었음을 나타내는 ACK를 받았기 때문에 타이머를 스탑(Stop)한다.
✅ 데이터 손실 발생 (701~800 데이터)
701~800 데이터 전송:
클라이언트가 701~800 데이터를 전송했지만, 이 데이터는 네트워크에서 손실(Lost)된다.
클라이언트는 데이터가 손실되었음을 아직 알지 못하고, 801~900 데이터를 계속 전송한다.
✅ 중복 ACK 전송 (Duplicate ACK)
801~900 데이터 전송:
서버는 801~900 데이터를 정상적으로 수신하고, 701~800 데이터가 손실되었음을 인지한다.
서버는 송신자에게 701 ACK를 다시 전송(중복 ACK)하여 누락된 데이터를 요청한다.
✅ 타임아웃에 의한 재전송
클라이언트 타이머 만료(Time-Out):
- 클라이언트는 701~800 데이터에 대한 확인응답(ACK)을 받지 못했기 때문에, 타이머가 만료되고 해당 데이터를 재전송한다.
✅ 데이터 복구 및 최종 확인응답
701~800 데이터 재전송:
서버는 데이터를 정상적으로 수신하고, 누락된 세그먼트를 복구한다.
수신 버퍼가 완전해져서, 서버는 최종적으로 ACK 901을 클라이언트에게 전송한다.
전송 완료: 클라이언트와 서버는 모든 데이터를 성공적으로 주고받아 전송이 종료된다.
오류제어 #8: 빠른 재전송 (Fast Retransmit in TCP)
💡요약: 빠른 재전송은 3개의 중복된 ACK(Duplicate ACK)를 수신했을 때 손실된 세그먼트를 빠르게 재전송하여 타이머 만료 전에 데이터를 복구하는 방식이다. Transport Layer (전송 계층)의 오류제어에서 중요한 역할을 한다.
💡중요포인트:
✅ 중복 ACK를 통한 손실 감지 (Duplicate ACKs for Loss Detection):
중복 ACK는 수신자가 특정 데이터가 누락되었음을 송신자에게 알리는 신호.
3개의 중복 ACK는 손실이 발생했음을 신뢰성 있게 판단할 수 있는 기준.
✅타이머 만료 이전의 재전송 (Retransmission Before Timer Expiry):
- RTO 타이머를 기다리지 않고 손실된 데이터를 빠르게 재전송하여 데이터 복구 속도를 높임.
✅초기 데이터 전송
클라이언트(Client) → 서버(Server):
클라이언트는 101~200과 201~300 데이터를 전송하고, 서버는 정상적으로 수신 후 ACK 301을 전송한다.
클라이언트는 ACK를 받고 RTO 타이머를 중지한다.
✅ 데이터 손실 발생
301~400 데이터 손실:
클라이언트는 301~400 데이터를 전송하지만, 네트워크에서 데이터가 유실되었다.
이후 401~500 데이터는 정상적으로 전송된다.
서버는 ACK 301을 계속 전송하여 손실된 데이터를 알린다.
✅ 중복 ACK 수신
클라이언트(Client):
첫 번째 ACK 301은 정상적인 응답으로 간주.
이후 중복 ACK(Duplicate ACK)가 두 번째와 세 번째로 수신되며, 클라이언트는 3개의 중복된 ACK를 통해 손실된 데이터를 감지한다.
✅ 빠른 재전송 (Fast Retransmit)
클라이언트(Client):
3개의 중복 ACK를 수신한 후, 클라이언트는 RTO 타이머가 만료되기 전에 301~400 데이터를 재전송한다.
서버는 재전송된 데이터를 정상적으로 수신하고 ACK 701을 전송한다.
데이터가 복구되고 전송이 완료된다.
혼잡제어(Congestion Control)는 네트워크의 혼잡을 예방하고 데이터 전송 속도를 최적화하기 위해 설계된 메커니즘이다. 혼잡제어는 혼잡 윈도우(Congestion Window, cwnd)라는 개념을 중심으로 작동하며, 흐름제어와 오류제어와 유사한 방식으로 네트워크의 상태를 실시간으로 감지하고 대응한다.
3️⃣ 혼잡제어 (Congestion Control)
💡요약: 혼잡제어(Congestion Control)는 데이터를 신뢰성 있게 전송하고 네트워크 효율성을 높이기 위한 핵심 메커니즘이다. (흐름제어도 포함) 이 두 제어 방식은 각각 수신 측의 상태와 네트워크 전체의 상태를 기반으로 동작한다.
✅흐름제어 (Flow Control): 송신 측이 수신 측의 버퍼 상태를 고려하여 데이터 전송 속도를 조절하는 기법이다.
작동 원리: 수신 버퍼의 비어있는 공간을 계산하여 송신 윈도우 크기를 조정한다.
- 예: 수신 버퍼가 가득 차면 송신 측은 데이터를 더 이상 보내지 않음.
목표: 수신 버퍼가 넘치지 않도록(Overflow 방지) 데이터를 전송하는 것
장점: 수신 장치의 용량을 기반으로 데이터 전송을 조절하여 안정적 통신을 보장.
🤔 송신측에서 아무리 데이터 전송을 잘 조절하더라도 수신장치까지 데이터가 잘 전송되지 않는 상황이 발생할 수 있다. 그렇다보니 적절하게 네트워크의 상황을 반영하는 알고리즘/매커니즘이 필요하다. 네트워크는 하나의 장치가아닌 여러 네트워크 장치들이 얽히고 섥힌 복잡한 구조를 가지고있다. 시시때때로 새로운 장치가 생기고, 사라지기도 하는 유동적인 상태이다. 그렇기 때문에 이를 간략화해서 제어할수있는 매커니즘으로 끌어오기 위한 기법들이 필요하기 마련이다. TCP 프로토콜에서 혼잡제어는 네트워크의 상황을 어느정도 반영하여 결론적으로 "혼잡윈도우"로 혼잡정도를 표현하고 송신윈도우에 반영된다.
✅ 혼잡제어 (Congestion Control): 송신 측이 네트워크의 혼잡 상태를 고려하여 전송 속도를 조절하는 기법이다.
작동 원리: 네트워크 상태를 나타내는 혼잡윈도우(cwnd, Congestion Window)를 사용하여 송신 윈도우 크기를 조정한다.
송신 윈도우 크기는 다음과 같이 계산된다:송신 윈도우 크기 = Minimum (rwnd, cwnd)
rwnd (Receive Window): 수신 측 버퍼 크기.
cwnd (Congestion Window): 네트워크 상태에 따라 동적으로 변화.
목표: 네트워크 혼잡을 줄이고 데이터 손실을 예방.
장점: 네트워크 전체의 상태를 고려하여 효율적인 데이터 전송 가능.
✅ 흐름제어와 혼잡제어의 차이
흐름제어(Flow Control): 수신 측의 상태를 기반으로 동작하고 수신 버퍼가 가득 차는 것을 방지한다.
혼잡제어(Congestion Control): 네트워크 전체의 상태를 기반으로 동작하고 네트워크 혼잡을 줄이고 데이터 손실 예방을 목적으로 한다.
혼잡제어 #1: 3단계 원칙 (Three Principles of Congestion Control)
💡요약: TCP 혼잡제어는 네트워크의 혼잡을 방지하고 데이터를 안정적으로 전송하기 위해 3단계 원칙에 따라 송신윈도우의 크기를 동적으로 조정한다. Transport Layer (전송 계층)에서 이 단계들은 느린 시작(Slow Start), 혼잡 회피(Congestion Avoidance), 혼잡 감지(Congestion Detection)로 구성되어 있으며, 데이터 전송 속도와 네트워크 상태를 조화롭게 관리한다.
✅느린 시작 (Slow Start) 데이터 전송 초기 단계로, 네트워크 용량을 파악하기 위해 송신윈도우 크기를 점진적으로 증가시키는 과정.
송신윈도우 크기를 지수적으로 증가시킴: 예: 1 → 2 → 4 → 8 ...
초반에는 작은 크기로 시작하여 네트워크 상태를 천천히 탐색.
목표: 네트워크의 최대 전송 용량(Capacity)을 파악.
✅혼잡 회피 (Congestion Avoidance):느린 시작 이후, 네트워크 혼잡 가능성을 예방하기 위해 송신윈도우 크기를 선형적으로 증가시키는 단계.
송신윈도우 크기를 더 천천히 증가: 예: cwnd = cwnd + 1 (RTT마다 1씩 증가)
과도한 데이터 전송을 방지하기 위해 점진적 증가.
목표: 혼잡 없이 데이터 전송 속도를 유지.
✅ 혼잡 감지 (Congestion Detection): 네트워크 혼잡이 발생했음을 감지하고, 송신윈도우 크기를 줄이는 단계.
혼잡 발생 시 송신윈도우를 크게 줄인다. 예: cwnd = cwnd / 2 (일반적으로 절반으로 감소).
타이머 만료 또는 중복 ACK를 통해 혼잡을 감지.
목표: 네트워크를 안정화시키고 데이터 손실 복구.
💡 송신윈도우 크기 조정의 중요성
증가 (느린 시작, 혼잡 회피): 네트워크 상태를 확인하며 전송 속도를 늘림.
감소 (혼잡 감지): 네트워크 혼잡을 방지하고, 데이터 손실을 최소화.
혼잡제어의 1단계 - 느린 시작 (Slow Start in Congestion Control)
💡요약: 혼잡제어의 첫 번째 단계인 느린 시작(Slow Start)은 네트워크의 용량을 파악하기 위해 혼잡윈도우(cwnd) 크기를 지수적으로 증가(Exponential Increase)시키는 과정이다. 이름과는 달리, 데이터 전송 속도는 빠르게 증가한다.
✅혼잡윈도우 초기값 (Initial Congestion Window): 혼잡윈도우(cwnd)는 처음에 1 MSS(Maximum Segment Size)로 시작한다.
MSS: 한 번에 전송할 수 있는 최대 데이터 크기.
즉, 초기 설정은: cwnd = 1 MSS
✅지수적 증가 (Exponential Increase): 송신 측이 확인응답(ACK)을 받을 때마다 혼잡윈도우 크기를 MSS 단위로 두 배로 증가시킨다. 예: cwnd = 1 → 2 → 4 → 8 ...
- 결과: 데이터 전송 속도가 급격히 빨라진다.
✅수신윈도우와의 관계:
- 데이터 전송 초기에는 수신윈도우(rwnd)가 크기 때문에 송신윈도우 크기는 혼잡윈도우(cwnd)에 의해 제한된다. 즉, 송신윈도우 크기 = 혼잡윈도우(cwnd)
초기 단계 (1 cwnd):
송신장치(Sender)는 혼잡윈도우를 1 MSS(1500 bytes)로 설정.
데이터 전송: 1 MSS를 전송.
ACK 수신: 수신장치(Receiver)에서 ACK를 받음.
윈도우 크기 증가: cwnd = 2 MSS.
두 번째 단계 (2 cwnd):
송신장치는 2 MSS만큼 데이터를 전송.
수신장치: 2개의 데이터를 수신하고, 2개의 ACK를 전송.
송신장치: 2개의 ACK를 받고 cwnd를 4 MSS로 증가.
세 번째 단계 (4 cwnd):
송신장치는 4 MSS만큼 데이터를 전송.
수신장치: 4개의 데이터를 수신하고, 4개의 ACK를 전송.
송신장치: 4개의 ACK를 받고 cwnd를 8 MSS로 증가.
그 이후:
RTT(Round Trip Time)마다 송신 데이터의 양이 2배로 증가.
증가 패턴: 1, 2, 4, 8, ... (2^n 형태).
✅느린 시작의 특징
- 혼잡윈도우의 변화: 혼잡윈도우(cwnd)는 데이터 전송 초기에는 매우 작은 값으로 시작(예: cwnd = 1 MSS).
지수적 증가: 확인응답(ACK)을 받을 때마다 혼잡윈도우는 두 배로 증가한다.
1 RTT 이후: cwnd = 1 × 2 = 2 MSS
2 RTT 이후: cwnd = 2 × 2 = 4 MSS
3 RTT 이후: cwnd = 4 × 2 = 8 MSS
2. 느린 시작은 "느리지 않다"
- 이름은 느린 시작(Slow Start)이지만, 실제 데이터 전송 속도는 매우 빠르게 증가한다. RTT가 지날수록 혼잡윈도우는 2^n의 패턴으로 증가.
- 임계치(ssthresh)의 역할
혼잡윈도우는 임계치(ssthresh)에 도달하기 전까지 지수적으로 증가.
임계치 도달 후에는 혼잡 회피(Congestion Avoidance) 단계로 전환되어 선형적으로 증가.
- 지연된 확인응답의 영향: 네트워크에서 확인응답(ACK)이 지연될 경우, 혼잡윈도우 증가 속도가 느려질 수 있음.
혼잡제어의 2단계 - 혼잡 회피 (Congestion Avoidance in Congestion Control)
💡요약: TCP 혼잡제어의 두 번째 단계로, 느린 시작(Slow Start)에서 혼잡윈도우(cwnd)가 너무 빠르게 증가하는 것을 막고, 네트워크 혼잡을 방지하기 위해 송신 윈도우 크기의 증가 속도를 조절하는 메커니즘이다. 가산 증가(Additive Increase) 방식을 사용하며, 그래프에서는 직선으로 증가하는 패턴을 보인다.
✅혼잡 발생 방지
문제: 느린 시작 단계에서 혼잡윈도우가 지수적으로 증가하여 네트워크 혼잡이 발생할 수 있다다.
해결: 혼잡이 발생하기 전에 혼잡윈도우 증가 속도를 줄이기 위해 혼잡 회피 단계로 전환한다.
✅혼잡윈도우 증가 방식
임계치(ssthresh) 도달: 혼잡윈도우(cwnd)가 느린 시작 임계치(ssthresh)에 도달하면 느린 시작을 종료한다. 그 이후 혼잡 회피 단계가 시작되어 선형 증가하게 된다.
RTT 기반 증가: RTT(Round Trip Time)마다 혼잡윈도우는 1 MSS씩 증가시킨다. 즉, 확인응답(ACK) 하나당 혼잡윈도우는 전체 윈도우 크기에 비례하여 서서히 증가하게 된다.
✅가산 증가 (Additive Increase)
혼잡윈도우가 선형적으로 증가한다. (그래프에서 직선 형태).
예) 혼잡윈도우(cwnd) = 이전 값 + 1 MSS (RTT마다).
목표: 네트워크를 안정적으로 사용하면서 혼잡을 예방하는 것을 목표로 한다.
느린 시작(Slow Start)에서 혼잡윈도우가 지수적으로 증가했다면, 혼잡 회피에서는 매 RTT(Round Trip Time)마다 혼잡윈도우가 1씩 증가한다. 이는 네트워크 혼잡을 예방하면서 안정적으로 데이터 전송을 이어가기 위한 과정이다.
✅ 혼잡윈도우의 증가 패턴: 혼잡윈도우의 초기값을 4 MSS로 가정한다.
4개의 세그먼트(데이터 조각)를 전송하고, 이에 대한 4개의 ACK를 수신하면 cwnd는 +1 MSS 증가한다. 이후 혼잡윈도우는 다음과 같이 증가하게 된다.
RTT 1: cwnd = 4 → 5 MSS
RTT 2: cwnd = 5 → 6 MSS
RTT 3: cwnd = 6 → 7 MSS
이 패턴은 4, 5, 6, 7...처럼 일정하게 증가한다.
✅ 느린 시작과의 차이점
느린 시작: RTT마다 혼잡윈도우가 2배로 증가 (지수적 증가).
혼잡 회피: RTT마다 혼잡윈도우가 1 MSS씩 증가 (선형적 증가).
✅ 안정적 네트워크 사용
- 혼잡윈도우가 더 이상 지수적으로 증가하지 않기 때문에, 네트워크가 과부하 상태에 빠지지 않도록 안정적으로 데이터 전송할 수 있게 된다.
혼잡제어의 3단계 - 혼잡 감지 (Congestion Detection in Congestion Control)
💡요약: 혼잡 감지(Congestion Detection)는 TCP 혼잡제어의 마지막 단계로, 네트워크에 혼잡이 발생했다고 판단되었을 때, 혼잡윈도우(cwnd)를 지수적으로 감소(Multiplicative Decrease)시켜 네트워크를 안정화하는 과정이다. 혼잡 상황인지, 단순한 데이터 오류인지 구체적으로 구분하기는 어렵지만, 몇 가지 기준을 바탕으로 혼잡 발생 여부를 판단한다.
✅ 혼잡 상황 판단 방법
명확한 혼잡 감지 방법은 없음: 현재(2024년 기준) TCP 프로토콜은 혼잡 상태를 네트워크가 명확히 알려주지 않고 기준만 존재한다.
혼잡 상태를 추정하는 기준: 패킷을 재전송해야 하는 상황이 발생하면 혼잡 상태로 간주한다. 하지만, 이는 혼잡이 아닌 단순 데이터 오류일 가능성도 있다. 혼잡과 데이터 오류를 완벽히 구분할 방법은 없다.
✅ TCP에서 혼잡 상태를 간주하는 두 가지 경우
재전송 타이머(RTO) 만료: 송신 측에서 설정한 타이머가 만료되면, 해당 패킷이 손실되었다고 판단하고 재전송한다.
3개의 중복 ACK 수신: 동일한 ACK가 3번 반복되면, 특정 패킷이 손실되었음을 간주하고 손실된 패킷을 재전송하게 된다..
✅ 혼잡 감지의 동작 과정 (RTO 타이머 만료 시)
네트워크 혼잡 판단: 재전송 타이머(RTO)가 만료되면 네트워크가 혼잡 상태으로 패킷이 유실되었을 가능성이 높다고 판단한다.
혼잡 제어 조치:
① 느린 시작 임계치(ssthresh): 현재 혼잡윈도우 크기의 절반으로 설정한다.- 예: cwnd = 16 MSS → ssthresh = 8 MSS.
② 혼잡윈도우(cwnd): 혼잡윈도우를 1 MSS로 감소한다. (하나의 세그먼트 크기 값)
③ 느린 시작 단계로 전환: 혼잡 상태를 완화하고 네트워크를 재탐색하기 위해 다시 느린 시작(Slow Start) 단계부터 시작한다.
혼잡 감지 Part 2: 3개의 중복 ACK 수신 시 혼잡 제어 동작 (Congestion Detection in Congestion Control)
💡요약: TCP 송신단이 3개의 중복 ACK를 수신했을 경우, 네트워크 혼잡보다 단순 패킷 유실 가능성이 높다고 간주하게 된다. 이는 일부 데이터가 손실되었지만, 다른 세그먼트는 정상적으로 도달했다는 것을 의미한다. 따라서, 네트워크 전체 혼잡 상황은 아니라고 판단하고, 혼잡윈도우 크기를 감소시키되 재전송 타이머(RTO) 만료와는 다른 방식으로 처리한다.
✅ 혼잡 상태 판단 기준
중복 ACK란? 동일한 확인응답(ACK)을 세 번 반복해서 수신하는 상황을 뜻한다. 이는 송신된 특정 세그먼트가 손실되었지만, 다른 세그먼트는 정상적으로 수신되었음을 의미한다.
TCP의 해석: 단순한 데이터 손실 가능성으로 판단한다. 네트워크 혼잡이 발생했을 가능성도 일부 고려하기 때문이다.
✅ 혼잡 제어 조치
느린 시작 임계치(ssthresh): 현재 혼잡윈도우(cwnd)의 절반으로 감소한다. 예) cwnd = 16 MSS → ssthresh = 8 MSS.
혼잡윈도우(cwnd): 임계치(ssthresh)와 동일하게 설정한다. 예) ssthresh = 8 MSS → cwnd = 8 MSS.
혼잡 회피 단계로 전환: 느린 시작 단계로 돌아가지 않고, 혼잡 회피(Congestion Avoidance) 단계부터 재개한다. 혼잡윈도우는 선형적으로 증가하게 된다.
✅ 재전송 실행
- 손실된 세그먼트만 즉시 재전송: 중복 ACK를 세 번 수신한 시점에서 빠른 재전송(Fast Retransmit)을 실행하게 된다.
혼잡제어: 정책 요약 (Summary of TCP Congestion Control Policy)
💡요약: 아래 다이어그램은 TCP 혼잡 제어의 전체 흐름을 요약하며, 혼잡 감지 후 각 상황(재전송 타이머 만료 또는 중복 ACK)에 따른 처리 과정을 명확히 보여준다. 네트워크 혼잡을 예방하고 안정성을 유지하기 위한 TCP의 체계적인 접근 방식을 설명한다.
💡중요포인트:
TCP 혼잡 제어는 느린 시작(Slow Start)에서 시작하여, 혼잡 상황에 따라 혼잡 회피(Congestion Avoidance)와 재전송을 조율.
혼잡 상황은 Time-out 또는 중복 ACK를 통해 판단.
혼잡 발생 시마다 cwnd와 ssthresh를 조정하여 네트워크 안정성을 유지.
혼잡 제어의 주요 단계
1. 연결 설정(Connection Establishment)
TCP 연결이 처음 설정되면 느린 시작(Slow Start) 단계로 진입한다.
초기값: cwnd = 1 MSS, ssthresh = 초기 설정 값.
2. 느린 시작(Slow Start)
혼잡윈도우(cwnd)가 지수적으로 증가하며 네트워크 용량을 탐색한다.
혼잡 감지 조건:
재전송 타이머(Time-out) 만료: 혼잡 상황 발생으로 판단.
3개의 중복 ACK(3 duplicate ACKs): 손실된 데이터가 있다고 판단.
3. 혼잡 회피(Congestion Avoidance)
혼잡윈도우(cwnd)가 느린 시작 임계치(ssthresh)에 도달하면 가산 증가(Additive Increase) 방식으로 선형적으로 증가.
혼잡 감지 조건:
재전송 타이머(Time-out) 만료 시: 혼잡으로 간주.
3개의 중복 ACK(3 duplicate ACKs) 수신 시: 손실된 데이터만 재전송.
4. 혼잡 감지 후 처리
Time-out 발생 시:
혼잡윈도우(cwnd)를 1 MSS로 감소.
느린 시작 임계치(ssthresh)를 현재 혼잡윈도우의 절반으로 설정.
느린 시작(Slow Start) 단계로 복귀.
3개의 중복 ACK 수신 시:
손실된 데이터만 재전송.
혼잡윈도우(cwnd)는 ssthresh로 감소.
혼잡 회피(Congestion Avoidance) 단계로 전환.
5. 연결 종료(Connection Termination)
- 혼잡 상태가 지속되거나 더 이상의 데이터 전송이 필요하지 않을 경우 연결 종료.
혼잡제어: 예 - 혼잡제어 메커니즘 적용 사례 (TCP Congestion Example - Applying Congestion Control Mechanisms)
💡요약: 아래 이미지는 TCP의 혼잡제어 메커니즘(느린 시작, 혼잡 회피, 혼잡 감지)이 실제 네트워크 상황에서 어떻게 작동하는지를 시각적으로 설명한다. 느린 시작과 혼잡 회피의 증가 패턴과 혼잡 감지 후 감소 및 회복 과정을 명확히 보여준다.
💡중요포인트:
왼쪽 그래프: 혼잡윈도우(cwnd)의 변화와 느린 시작(Slow Start) 및 혼잡 회피(Congestion Avoidance) 과정을 시각적으로 표현.
오른쪽 그래프: 혼잡 감지(Congestion Detection) 후 혼잡윈도우(cwnd)가 감소하고 다시 증가하는 과정을 보여줍니다.
✅ 혼잡제어 과정 - 왼쪽 그래프 설명
느린 시작 단계: 초기 혼잡윈도우 크기(cwnd) = 1 MSS.
지수적 증가: cwnd = 1 → 2 → 4 → 8 → 16 MSS.
혼잡윈도우가 느린 시작 임계치(ssthresh)인 16 MSS에 도달하면, 혼잡 회피 단계로 전환된다.
혼잡 회피 단계: 혼잡윈도우는 선형적으로 증가한다.
cwnd = 16 → 17 → 18 → 19... MSS.
그래프 상에서는 곡선(느린 시작)과 직선(혼잡 회피)이 명확히 구분된다.
✅ 혼잡제어 과정 - 오른쪽 그래프 설명
혼잡 감지(중복 ACK): 혼잡윈도우(cwnd)가 W1(MSS) 크기일 때 3개의 중복 ACK를 수신하였다. 이를 혼잡 감지 원칙에 따라 아래와 같이 변한다. ssthresh = W1 / 2 , cwnd = ssthresh.
혼잡 회피: 새로운 ssthresh 값(0.5 W1)을 기준으로 선형적 증가가 재개된다.
재전송 타이머 만료:
혼잡윈도우가 W2(MSS) 크기일 때 RTO 타이머 만료되었다.
혼잡윈도우는 다시 1 MSS로 감소하고 느린 시작 단계로 돌아가게 된다.
새로운 ssthresh = 0.5 W2.
혼합제어: 예 - 혼잡제어 동작 사례 (TCP Congestion Example - Congestion Control in Action)
💡요약: 이 그래프는 TCP 혼잡제어의 3단계 원칙(느린 시작, 혼잡 회피, 혼잡 감지)이 네트워크 상태에 맞게 혼잡윈도우 크기를 조정하여 혼잡을 완화하고 안정성을 유지하는 과정을 명확히 시각화한 예시이다.
혼잡제어 단계별 설명
X축 (RTTs): 시간의 경과를 나타냄 (1 RTT = 한 번의 왕복 시간).
Y축 (cwnd): 혼잡윈도우 크기 (MSS 단위).
색상 구분: 핑크색 (SS): 느린 시작, 노란색 (AI): 혼잡 회피, MD: 혼잡 감지 후 감소.
1. 느린 시작 (Slow Start, SS):
초기 혼잡윈도우(cwnd) = 1 MSS로 시작.
혼잡윈도우는 지수적으로 증가 (1, 2, 4, 8, 16...).
혼잡윈도우가 임계치(ssthresh = 16 MSS)에 도달하면 혼잡 회피 단계로 전환.
2. 혼잡 회피 (Additive Increase, AI):
임계치(ssthresh) 이후 혼잡윈도우는 선형적으로 증가.
매 RTT마다 cwnd가 1 MSS씩 증가 (16 → 17 → 18...).
3. 혼잡 감지 (Multiplicative Decrease, MD):
Time-out 발생 (RTT 8):
혼잡윈도우가 급격히 감소.
새로운 임계치(ssthresh) = 현재 cwnd의 절반 (16 → 8 MSS).
혼잡윈도우(cwnd)는 1 MSS로 감소하고 느린 시작으로 복귀.
4. 중복 ACK 수신 (RTT 13):
3개의 중복 ACK 수신:
혼잡윈도우를 절반으로 감소 (10 → 5 MSS).
새로운 임계치(ssthresh) = 5 MSS.
혼잡 회피 단계로 전환, 선형적 증가 재개.
혼합제어: 송신 윈도우와 전송 속도의 관계 (TCP Transmission Window and Speed)
💡요약: TCP 송신 윈도우의 크기와 RTT(Round-Trip Time)를 기반으로 최대 도달 가능한 전송 속도(bps)를 계산하는 방법이다. 이를 통해 TCP에서 송신 속도 제어가 어떻게 이루어지는지 알 수 있다.
✅ 주요 공식
- 최대 도달 가능한 전송 속도 (bps): (송신 윈도우의 비트 크기)/RTT(송신 윈도우의 비트 크기)
✅ 예제 계산:
송신 윈도우 크기: 65,535 bytes
- 비트 크기 변환(바이트를 비트로 변환해야 한다.) : 865,535 × 8 bits = 524,280 bits.
RTT (왕복 시간, ms를 s로 변환해야 한다.): 100 ms = 10^-3초.
최대 전송 속도 (bps를 Mbps로 변환하여 답한다)
💡밀리초(ms)에서 초(s)로 변환
밀리초 정의: 1초 = 1,000 밀리초이다.
- 따라서, 1 밀리초(ms) = 10^{-3}가 된다.
100ms를 초로 변환
100 ms = 100×10^−3
이를 계산하면 0.1 초이다.
