TCP/IP - 흐름 제어 / 혼잡 제어

이유석·2022년 4월 12일
0

CS - Network

목록 보기
2/8
post-thumbnail

TCP

정의

  • 응용 프로그램이 데이터를 교환할 수 있는 네트워크 대화를 설정하고 유지하는 방법을 정의하는 표준이다.

특징

  • IP 네트워크를 통해서 통신하는 호스트에서 실행되는 애플리케이션 간에 신뢰할 수 있다.
  • 통신의 순서가 정해져있으며, 오류를 체크하고 전송할 수 있다.
  • 네트워크 혼잡 방지 알고리즘을 사용한다. (Network Congestion Avoidance Algorithm)
    • 네트워크에서 부하로 인해 패킷 손실이 발생하는 것을 줄인다.

Reliable(신뢰성) Network 보장으로 인한 문제점

  • 손실 : Packet이 손실될 수 있는 문제
  • 순서 바뀜 : Packet의 순서가 바뀔 수 있는 문제
  • Congestion (혼잡) : Network내의 Packet의 수가 과도하게 증가하는 현상
  • Overload : 수신측이 Overload 되는 문제

TCP 연결 및 연결 해제 방법

  • 연결 : 3 way hadshake 방법 사용
  • 연결 해제 : 4 way handshake 방법 사용
  • 세부 내용은 다음 포스트에서 다룰 예정 입니다.

흐름 제어

정의

  • 수신측이 송신측보다 데이터 처리 속도가 빠르면 문제없지만, 송신측의 전송 속도가 빠를 경우 문제가 생긴다.

  • 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있다.

    • 만약 손실된다면, 송/수신 측에서 불필요한 응답과 데이터 전송이 발생 할 수 있다.
  • 이러한 위험을 줄이기 위해 송신 측의 데이터 전송량을 수신측에 따라 조절해야한다.

해결 방법

  • Stop and Wait
    매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
    그러나 패킷을 하나씩 보내야 하기 때문에, 비효율적인 방법이다.

  • Sliding Window
    수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답(ACK) 없이 패킷을 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법이다.

Sliding Window

윈도우 크기

  • 최초의 윈도우 크기는 호스트들의 연결 방법인 '3 way handshaking'을 통해 수신 측 윈도우 크기로 설정됩니다.
    이후 수신 측의 버퍼에 남아있는 공간에 따라 변할 수 있다.
  • 윈도우 크기는 수신 측에서 송신 측으로 확인 응답(ACK)을 보낼 때 TCP 헤더(window size)에 담아서 보낸다.

동작 방식

  • 먼저 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는대로 이 윈도우를 옆으로 옮김으로써 그 다음 패킷들을 전송

  • 최초로 수신자는 윈도우 사이즈를 7로 정한다.
  • 송신자는 수신자의 확인 응답(ACK)을 받기 전까지 데이터를 보낸다.
  • 수신자는 확인 응답(ACK)을 송신자에게 보내면, 슬라이딩 윈도우 사이즈을 충족할 수 있게끔 윈도우를 옆으로 옮긴다
  • 이후 데이터를 다 받을 때까지 위 과정을 반복한다.

재전송

  • 송신 측은 일정 시간 동안 수신 측으로부터 확인 응답(ACK)을 받지 못하면, 패킷을 재전송한다.
  • 만약, 송신 측에서 재전송을 했는데 패킷이 소실된 경우가 아니라 수신 측의 버퍼에 남는 공간 없는 경우면 문제가 생긴다.
  • 이를 해결하기 위해 송신 측은 해결 응답(ACK)을 보내면서 남은 버퍼의 크기 (윈도우 크기)도 함께 보내 준다.

혼잡 제어

정의

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

  • 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어라고 한다.

  • 흐름제어가 송신측과 수신측 사이의 전송속도를 다루는데 반해, 혼잡제어는 호스트와 라우터를포함한 보다 넓은 관점에서 전송 문제를 다루게 된다.

해결 방법

  • AIMD (Additive Increse/Multicative Decrease)

    • 합 증가/곱 감소 방식이다.
    • AIMD 방식은 처음에 패킷을 하나씩 보내고 문제 없이 도착하면 윈도우의 크기를 1씩 증가시켜가며 전송한다.
    • 만약, 전송에 실패하면 윈도우 크기를 반으로 줄인다.
    • 단점 : 윈도우 크기를 너무 조금씩 늘리기 때문에 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기까지 시간이 오래 걸린다는 단점이 있다.
  • Slow Start (느린 시작)

    • 위에서 이야기했듯이 AIMD 방식은 윈도우 크기를 선형적으로 증가시키기 때문에, 제대로된 속도가 나오기까지 시간이 오래 걸린다.
    • 반면, Slow Start는 윈도우의 크기를 1, 2, 4, 8, ...과 같이 지수적으로 증가시키다가 혼잡이 감지되면 윈도우 크기를 1로 줄이는 방식이다.
    • 이 방식은 보낸 데이터의 ACK가 도착할 때마다 윈도우 크기를 증가시키기 때문에 처음에는 윈도우 크기가 조금 느리게 증가할지라도, 시간이 가면 갈수록 윈도우 크기가 점점 빠르게 증가한다는 장점이 있다.
  • Fast Retransmit (빠른 재전송)

    • 패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고, 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 된다.
    • 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게된다.
      이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있다.
    • 중복된 순번의 패킷을 3개 받으면 재전송을 하게 된다.
  • Fast Recovery (빠른 회복)

    • 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다.
    • 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.
profile
소통을 중요하게 여기며, 정보의 공유를 통해 완전한 학습을 이루어 냅니다.

0개의 댓글