[Computer Science][Network] 💡 완벽한 TCP 흐름제어와 혼잡제어 이해하기: 네트워크 안정성의 핵심 기술

💡 TCP (흐름제어/혼잡제어)

---

🚀 들어가기 전

• TCP(Transmission Control Protocol) 통신이란?
  • 네트워크 통신에서 연결 지향적 프로토콜이며, 이는 데이터 전송 전에 송신자와 수신자 간에 연결을 설정하고 데이터가 정확하게 도착했는지를 확인하는 신뢰적인 연결 방식을 지니고 있다.
  • TCP는 기본적으로 데이터 전송 중에 패킷이 손실되거나 중복되거나, 순서가 뒤바뀔 수 있는 unreliable network 환경에서, reliable network를 보장할 수 있도록 하는 프로토콜입니다. 즉 데이터가 손실되면 재전송하고, 도착한 데이터의 순서를 맞추며, 중복된 데이터를 제거하여 최종적으로 데이터를 완전하고 정확하게 수신자에게 전달합니다.
  • TCP는 네트워크 혼잡(데이터 트래픽이 많아져 네트워크가 과부하 상태에 이르는 것)을 방지하기 위해 network congestion avoidance algorithm(네트워크 혼잡 회피 알고리즘)을 사용합니다.
• reliable network를 보장하기 위해 해결해야하는 4가지 문제점
  • 손실 : packet이 손실될 수 있는 문제
  • 순서 바뀜 : packet의 순서가 바뀌는 문제
  • Congestion : 데이터 트래픽이 많아져 네트워크가 과부하 상태에 이르는 문제.
  • Overload : 수신자가 처리할 수 있는 용량을 초과하는 양의 데이터가 빠르게 도착하여, 수신자가 데이터를 처리하지 못하는 문제.
• 흐름제어/혼잡제어란?
  • 흐름제어(Flow Control)
    • 송신측과 수신측의 데이터 속도 차이를 해결하기 위한 기법
    • Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 하여 수신 측의 과부하를 방지
    • 송신 측(sender)은 데이터를 빠르게 전송하고 싶어도, 수신 측(receiver)이 데이터를 처리하는 속도가 느리면 문제가 발생할 수 있습니다. 수신 측이 데이터를 처리하기 전에 너무 많은 데이터를 수신하면 버퍼 오버플로우가 발생하여 데이터가 손실될 수 있습니다.
    • 수신 측이 송신 측에게 현재 처리 가능한 데이터의 양을 피드백하여, 송신 측이 그에 맞춰 데이터를 전송하도록 조절하는 과정입니다.
    • 수신 윈도(Receive Window)라는 개념이 사용됩니다. 수신 측은 자신의 수신 버퍼 상태에 따라 윈도우 크기를 설정하고, 이 정보를 송신 측에 전달합니다. 송신 측은 이 윈도우 크기 내에서만 데이터를 전송하게 됩니다.
  • 혼잡제어(Congestion Control) : 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
    • 송신 측이 너무 많은 데이터를 네트워크에 빠르게 전송하면, 네트워크 장치(라우터, 스위치 등)가 과부하 상태에 빠져 패킷 손실이나 지연이 발생할 수 있는데 이를 네크워크 혼잡이라고 합니다.
    • Congestion Control은 네트워크의 상태를 모니터링하고, 혼잡이 발생할 가능성이 있을 때 송신 속도를 조절하여 네트워크가 안정적으로 작동하도록 하는 과정입니다.
    • Congestion Window라는 개념이 사용되며, 이 윈도우 크기는 네트워크 상태에 따라 동적으로 변합니다. 혼잡이 감지되면 윈도우 크기를 줄이고, 네트워크가 안정적일 때는 윈도우 크기를 증가시킵니다.
• 전송의 전체 과정
  • 응용 계층(Application Layer)에서 데이터를 전송할 때, 보내는 쪽(sender)의 애플리케이션(Application)은 직접 네트워크로 데이터를 보내는 것이 아닌 소켓(Socket)이라는 인터페이스를 통해 데이터를 쓰게 됩니다.
  • 이 데이터는 전송 계층(Transport Layer)으로 전달되어 세그먼트(Segment)라는 작은 단위로 나누어집니다.
  • 전송 계층은 이 세그먼트를 네트워크 계층(Network Layer)에 넘겨줍니다.
  • 전송된 데이터는 수신자(receiver)쪽으로 전달되어, 수신자 쪽에서는 수신 버퍼(Receive Buffer)에 저장됩니다.
  • 이때, 수신자 쪽에서는 수신 버퍼의 용량을 넘치지 하지 않도록 조절해야 합니다.
  • 수신자 쪽에서는 자신의 수신 버퍼의 남은 용량을 상대방(sender)에게 알려주는데, 이를 수신 윈도우(Receive Window)라고 합니다.
  • 송신자(sender)는 수신자의 수신 윈도우를 확인하여 수신자의 수신 버퍼 용량을 초과하지 않도록 데이터를 전송합니다.
  • 이를 통해 데이터 전송 중에 수신 버퍼가 넘치는 현상을 방지하면서, 안정적인 데이터 전송을 보장합니다. 이를 플로우 컨트롤(Flow Control)이라고 합니다.

따라서 플로우 컨트롤은 전송 중에 발생하는 수신 버퍼의 오버플로우를 방지하면서, 안정적인 데이터 전송을 위해 중요한 기술입니다.

💡 1. 흐름제어(Flow Control)

• 수신측이 송신측보다 데이터 처리 속도가 빠르면 문제 없지만, 송신측의 속도가 빠를 경우 문제가 생긴다.
• 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있으며, 만약 손실 된다면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 빈번이 발생한다.
  • 데이터가 손실되면, 송신 측은 해당 데이터가 수신 측에 제대로 도달하지 않았음을 인지하고, 재전송을 시도합니다.
  • 또한, 수신 측은 손실된 데이터에 대한 응답(ACK)을 보내지 않거나, 오류 메시지를 송신 측에 보낼 수 있습니다.
• 이러한 위험을 줄이기 위해 송신 측의 데이터 전송량을 수신측에 따라 조절해야한다.
• 해결방법
  • Stop and Wait : 각 데이터 프레임에 대해 하나씩 전송하고, 각 프레임이 성공적으로 수신되었음을 확인(ACK)한 후에 다음 프레임을 전송하는 방식.
  • Sliding Window (Go Back N ARQ)
    • 수신 측에서 설정한 윈도우 크기만큼 송신 측이 확인 응답(ACK) 없이 세그먼트를 연속적으로 전솔할 수 있도록 하여, 데이터 전송의 효율성을 높이는 방법.

      핵심개념

      1. LastByteSent - LastByteAcked <= ReceivecWindowAdvertised:

         • LastByteSent: 송신 측에서 마지막으로 전송된 바이트의 위치
         • LastByteAcked: 송신 측에서 마지막으로 확인 응답(ACK)을 받은 바이트의 위치
         • ReceiveWindowAdvertised: 수신 측이 광고한 수신 윈도우의 크기. 즉, 수신 측이 더 받을 수 있는 데이터의 크기

         이 식은 현재 공중에 떠있는 패킷 수가 수신 측이 처리할 수 있는 크기를 초과하지 않도록 하는 것을 의미합니다. 쉽게 말해, 송신 측은 수신 측이 처리할 수 있는 만큼만 데이터를 전송합니다. 공중에 떠있다는 네트워크에서 송신 측이 이미 전송했지만, 수신 측으로부터 아직 확인 응답(ACK)을 받지 못한 데이터를 의미한다.

      2. 윈도우의 동작 방식

         • 송신 측은 윈도우 내에 포함되는 모든 패킷을 한 번에 전송할 수 있습니다.
         • 송신 측은 각 패킷에 대해 수신 측으로부터 ACK를 받으면, 윈도우를 오른쪽으로 슬라이딩(이동)시키면서 다음 데이터를 전송합니다.
    • Window : TCP/IP를 사용하는 모든 호스트들은 송신하기 위한 것과 수신하기 위한 2개의 Window를 가지고 있다.
      • 송신 윈도우(Send Window): 송신 측에서 데이터를 보낼 때 사용하는 윈도우. 이 윈도우 크기만큼 송신 측은 데이터를 전송할 수 있으며, 확인 응답(ACK)를 받기 전에 데이터를 보내기 위해서는 이 크기를 넘지 않아야 한다.
      • 수신 윈동(Receive Window): 수신 측에서 데이터를 받을 때 사용하는 윈도우. 이 윈도우 크기만큼 수신 측은 데이터를 받을 수 있으며, 이 크기만큼의 데이터를 처리할 수 있는 버퍼 공간이 있다는 것을 의미.
    • 호스트들은 실제 데이터를 보내기 전에 '3way hand-shake' 과정 중 수신 측은 자신의 수신 윈도우 크기(Receive Window Size)를 송신 측에 알려줍니다. 또한 송신 측은 수신 측의 수신 윈도우 크기에 맞추어 자신의 송신 윈도우 크기(Send Window Size)를 조정합니다.

      예시

      • 송신버퍼
        • 202 이전의 바이트 : 이미 전송되었고, 확인 응답(ACK)을 받은 상태
        • 200 ~ 202 바이트 : 이미 전송되었지만, 아직 확인 응답(ACK)을 받지 못한 상태
        • 203 ~ 211 바이트 아직 전송되지 않은 상태
      • 송신 윈도우의 이동
        • 예를 들어, 송신 측이 203과 204 바이트를 전송하고, 수신 측에서 203 바이트에 대한 ACK를 받았다면, 송신 윈도우는 오른쪽으로 슬라이딩하여 205~209 바이트가 전송 가능한 상태가 됩니다.

💡 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를 줄이게 된다.
    • 예를들어 1번 패킷을 받고 ACK 2를 보낸다. 하지만 2번 패킷이 손실되어서 그 다음으로 다착한 3번 패킷을 받았지만 2번 패킷을 받을 차례이므로 ACK 2를 다시 보낸다.
  • Fast Recovery (빠른 회복)
    • 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다. 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.

---

Connection Timeout과 Read Timeout

Connection Timeout

• Connection Timeout은 클라이언트가 서버에 연결을 시도할 때, 그 연결이 성공적으로 이루어지지 않으면 일정 시간 후에 시도를 중단하는 것을 의미합니다.

• 사용 시나리오 : 클라이언트가 서버에 요청을 보낼 때, 서버가 응답하지 않거나 네트워크가 불안정한 경우 연결을 시도할 수 있습니다. 이 시도가 너무 오래 지속되면, 클라이언트는 무한히 대기하지 않고 정해진 시간 이후에 연결 시도를 포기하게 됩니다.

Read Timeout

• Read Timeout은 서버와의 연결이 성공적으로 이루어진 후, 서버로부터 데이터를 수신하는 동안 일정 시간 내에 응답이 없으면 그 수신을 중단하는 것을 의미합니다.

• 사용 시나리오 : 서버에 연결이 된 이후에, 클라이언트는 서버로부터 데이터를 받아야 합니다. 그러나 서버가 데이터를 전송하지 않거나 전송이 지연되는 경우, 클라이언트는 설정된 시간이 지나면 더 이상 기다리지 않고 데이터를 읽는 작업을 포기합니다.

---

공인 IP와 사설 IP

1. 공인 IP (Public IP)

• 정의
  • 공인 IP는 전 세계적으로 고유한 IP 주소로, 인터넷 상의 모든 장치들이 서로를 식별하고 통신할 수 있도록 합니다.
  • 이런한 IP 주소는 전 세계의 네트워크에서 고유한 설정되어 있어, 인터넷에 직접 연결된 장치(예: 웹 서버, 이메일 서버)가 주로 사용합니다.
• 할당 방식
  • 공인 IP는 IANA(Internet Assigned Numbers Authority) 또는 지역 인터넷 등록 기관(RIR)과 같은 조직에 의해 관리되고 할당됩니다.
  • ISP(인터넷 서비스 제공자)나 기업들은 공인 IP 주소를 할당받아 사용합니다.
• 사용 범위
  • 공인 IP는 인터넷에 직접 노출되어 있으므로, 인터넷상의 다른 모든 장치들과 직접 통신할 수 있습니다.
  • 예를 들어, 웹사이트에 접속할 때 사용되는 서버의 IP 주소는 공인 IP입니다.
• 특징
  • 고유성 : 공인 IP는 전 세계에서 유일한 IP 주소입니다.
  • 접근성 : 인터넷에서 누구나 접근할 수 있으며, 인터넷상의 통신에서 필수적입니다.

2. 사설 IP (Private IP)

정의 :

• 사설 IP는 내부 네트워크에서만 사용되는 IP 주소로, 인터넷과 같은 외부 네트워크에서는 사용되지 않으며, 내부 통신을 관리하는 데 사용됩니다.
• 동일한 사설 IP 주소는 여러 내부 네트워크에서 중복될 수 있습니다.
  할당 방식
• 사설 IP 주소는 NAT(Network Address Translantion)을 통해 공인 IP로 변환되어 외부 네트워큭와의 통신을 가능하게 합니다.
• 사설 IP 주소 범위는 RFC 1918에 따라 정해진 범위 내에서 사용됩니다.
• 사용 범위
  • 사설 IP는 주로 가정, 기업 등의 내부 네트워크에서 사용되며, 라우터나 DHCP 서버가 자동으로 할당합니다.
  • 내부 네트워크 간의 통신이나, 장치 간 파일 공유, 프린터 연결 등에 사용됩니다.
• 특징
  • 비고유성 : 동일한 사설 IP 주소가 여러 내부 네트워크에서 사용될 수 있습니다.
  • 보안 : 외부 네트워크에서 직접 접근할 수 없으므로 보안이 강화됩니다.
  • NAT 필요성 : 외부와의 통신을 위해 NAT를 통해 공인 IP로 변환되어야 합니다.

---

통신 방식 비교 : 유니캐스트, 멀티캐스트, 브로드캐스트

1. 유니캐스트 (Unicast)

• 정의
  • 유티캐스트는 한 대의 송신자가 한 대의 수신자에게 데이터를 전송하는 방식입니다. 네트워크에서 가장 일반적인 통신 방식으로, 클라이언트-서버 모델에서 주로 사용됩니다.
• 특징
  • 1:1 통신 방식
  • 각 유니캐스트 통신은 고유한 경로를 통해 이루어지며, 네트워크 트래픽(즉, 데이터)은 각 수신자(전송 받는 대상자에게만)에게 개별적으로 전달됩니다.
  • 예시 : 웹 브라우저에서 특정 웹 서버에 HTTP 요청을 보내는 경우, 이메일 전송, 파일 다운로드 등이 유니캐스트 통신에 해당됩니다.

2. 멀티캐스트 (Multicast)

• 정의
  • 멀티캐스트는 한 대의 송신자가 특정 그룹의 여러 수신자에게 데이터를 전송하는 방식입니다. 데이터를 수신하고자 하는 그룹에 속한 수신자들만 데이터 패킷을 수신하게 됩니다.
• 특징
  • 한 번의 전송으로 해당 그룹 내 모든 수신자가데이터를 수신할 수 있게 합니다. 이로 인해 네트워크 자원을 절약할 수 있습니다.
  • 예시 : 실시간 비디오 스트리밍, IPTV 서비스, 온라인 강의 등이 멀티캐스트 방식으로 전송될 수 있습니다.

3. 브로드캐스트 (Broadcast)

• 정의 : 브로드캐스트는 한 대의 송신자가 네트워크의 모든 장치에게 데이터를 전송하는 방식입니다. 주로 로컬 네트워크(LAN)에서 사용되며, 네트워크 내 모든 장치가 데이터 패킷을 수신하게 됩니다.
• 특징 : 1: 전체 통신 방식
  • 네트워크의 모든 장치가 데이터를 수신하므로, 네트워크 부하가 발생할 수 있습니다.
  • ARP(Address Resolution Protocol) 요청, DHCP(Dynamic Host Configuration Protocol) 서버에서 IP 주소를 할당할 때의 통신 등이 브로드캐스트 방식으로 이루어집니다.