TCP | 혼잡제어 & 흐름제어 & 오류제어


created_at : 01 June 2022 - 6 mins read time
Tags: CS Network

Table of Contents
source : tech-interview-for-developer @jsj3282 benlee73

TCP란?

TCP 통신이란?

  • 네트워크 통신에서 신뢰적인 연결방식
  • TCP는 기본적으로 unreliable network에서, reliable network를 보장할 수 있도록 하는 프로토콜
  • TCP는 network congestion avoidance alogirthm을 사용

Reliable Network를 보장한다는 것 -> 4가지의 문제점 존재

  • 손실 : packet이 손실될 수 있는 문제
  • 순서 바뀜 : packet의 순서가 바뀌는 문제
  • Congestion : 네트워크가 혼잡한 문제
  • Overload : receiver 가 overload 되는 문제

전송의 전체 과정

  • Application layer : sender application layer가 socket에 data를 씀.
  • Transport layer : data를 segment에 감싼다. 그리고 network layer에 넘겨줌.
  • 그러면 아랫단에서 어쨋든 receiving node로 전송이 됨. 이 때, sender의 send buffer에 data를 저장하고, receiver는 receive buffer에 data를 저장함.
  • application에서 준비가 되면 이 buffer에 있는 것을 읽기 시작함.
  • 따라서 flow control의 핵심은 이 receiver buffer가 넘치지 않게 하는 것임.
  • 따라서 receiver는 RWND(Receive WiNDow) : receive buffer의 남은 공간을 홍보함

TCP의 제어 기능

흐름제어 : 전송되는 데이터의 양을 조절

송신측과 수신측의 데이터 처리 속도차이를 해결하기 위한 기법으로 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것

receiver가 sender에게 현재 자신의 상태를 feedback한다

  • 수신측이 송신측보다 데이터 처리 속도가 빠르면 문제가 없지만, 송신측의 속도가 빠를 경우 문제가 생긴다
  • 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 도리 수 잇으며, 만약 손실된다면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 빈번히 발생한다.
  • 이러한 위험을 줄이기 위해 송신측의 데이터 전송량을 수신측에 따라 조절해야 한다.

해결방법

Stop and Wait

매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법

stopandwait

Sliding window (Go Back N ARQ)

수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법

  • 목적 : 전송은 되었지만, acked 를 받지 못한 byte의 숫자를 파악하기 위해 사용

    LastByteSent - LastByteAcked <= ReceiveWindowAdvertised

    (마지막에 보내진 바이트 - 마지막에 확인된 바이트 <= 남아있는 공간) ==

    (현재 공중에 떠있는 패킷 수 <= sliding window)

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

      slidingwindow

오류제어 : 데이터가 유실되거나 잘못된 데이터가 수신되엇을 경우 대처하는 방법

오류 검출과 재전송을 포함한다.

  • ARQ(Automatic Repeat Request) 기법을 사용해 프레임이 손상되었거나 손실되었을 경우, 재전송을 통해 오류를 복구한다. ARQ 기법은 흐름 제어 기법과 연관되어 있다.

1. Stop and Wait ARQ

  • 송신 측에서 1개의 프레임을 송신하고, 수신측에서 수신된 프레임의 에러 유무에 따라 ACK 혹은 NAK(Negative Acknowledgement)를 보내는 방식이다.
  • 식별을 위해 데이터 프레임과 ACK 프레임은 각각 0, 1 번호를 번갈아가며 부여한다.
  • 수신측에 데이터를 받지 못했을 경우 NAK를 보내고, NAK를 받은 송신측은 데이터를 재전송한다.
  • 만약, 데이터나 ACK가 분실되었을 경우 일정 간격의 시간을 두고 타임아웃이 되면 송신측은 데이터를 재전송한다.

2. Go-Back-n ARQ

  • 전송된 프레임이 손상되거나 분실된 경우 그리고 ACK 패킷의 손실로 인한 TIME_OUT이 발생한 경우, 확인된 마지막 프레임 이후로 모든 프레임을 재전송한다.
  • 슬라이딩 윈도우는 연속적인 프레임 전송 기법으로 전송측은 전송된 프레임의 복사본을 가지고 있어야 하며, ACK와 NAK 모두 각각 구별해야 한다.
  • ACK : 다음 프레임을 전송
  • NAK : 손상된 프레임 자체 번호를 반환

재전송 되는 경우

(1) NAK 프레임을 받았을 경우

만약 수신측으로 0 ~ 5까지의 데이터를 보냈다고 가정했을 때, 수신측에서 데이터를 받았음을 확인하는 데이터 오류 프레임 2를 발견하고 NAK2를 전송측에 보낸다고 해보자.

NAK2를 받은 전송측은 데이터 프레임 2가 잘못되었다는 것을 알고 데이터를 재전송한다. GBn ARQ의 특징은 데이터를 재전송하는 부분이다. NAK(n)를 받아 데이터를 재전송한다.

(2) 전송 데이터 프레임의 분실

GBn ARQ의 특징은 확인된 데이터 이후의 모든 데이터 프레임 재전송과 수신측의 폐기이다. 수신측에서 데이터 1을 받고 다음 데이터로 3을 받게 된다면 데이터 2를 받지 못했으므로 수신측에서는 데이터 3을 폐기하고 데이터 2를 받지 못했다는 NAK2를 전송측에 보낸다. NAK를 받은 전송측은 (1)의 경우와 마찬가지로 NAK(n) 데이터로부터 모든 데이터를 재전송하며 수신측은 기존에 받았던 데이터 중 NAK(n)으로 보냈던 대상 데이터 이후의 모든 데이터를 폐기하고 재전송 받는다.

img

(3) 지정된 타임 아웃 내의 ACK 프레임 분실

전송측은 분실된 ACK를 다루기 위해 타이머를 가지고 있다. 또한 전송측에서는 이 타이머의 타임 아웃 동안 수신측으로부터 ACK 데이터를 받지 못했을 경우, 마지막 ACK된 데이터부터 재전송한다.

img

즉, 이를 정리하면 다음과 같다.

  • 전송측은 NAK 프레임을 받았을 경우, NAK 프레임 번호부터 데이터를 재전송한다.
  • 수신측은 원하는 프레임이 아닐 경우, 데이터를 모두 폐기 처분한다.
  • 타임아웃(ACK 분실)의 경우, 마지막 ACK된 데이터부터 재전송한다.

3. SR(Selective-Reject) ARQ

  • GBn ARQ의 확인된 마지막 프레임 이후의 모든 프레임을 재전송하는 단점을 보완하는 기법이다.
  • SR ARQ는 손상되거나 손실된 프레임만 재전송한다.
  • 그렇기 때문에 별도의 데이터 재정렬을 수행해야 하며, 별도의 버퍼를 필요로 한다.
  • 수신 측에 버퍼를 두어 받은 데이터의 정렬이 필요하다.
GBn(Go-Back-n) ARQ SR(Selective-Reject) ARQ
손상/분실된 프레임 이후의 프레임을 모두 재전송 손상/분실된 프레임만을 재전송
구조가 비교적 간단하고 구현이 단순 구조가 복잡(프레임 재배열 등의 추가 로직 필요)
데이터 폐기 방식을 사용하여 추가적 버퍼가 필요 없음 폐기 방식을 사용하지 않으므로 순차적이지 않은 프레임을 재배열하기 위한 버퍼가 필요
비용이 비교적 저렴(SR ARQ에 비해) 비용 및 유지관리 비용이 증가

혼잡제어 : 네트워크 혼잡에 대처

  • 송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달된다. 만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 된다. 이런 경우 호스트들은 또 다시 재전송을 하게되고 결국 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생시키게 된다. 따라서 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송속도를 강제로 줄이게 되는데, 이러한 작업을 혼잡제어라고 한다.
  • 또한 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어라고 한다.
  • 흐름제어가 송신측과 수신측 사이의 전송속도를 다루는데 반해, 혼잡제어는 호스트와 라우터를 포함한 보다 넓은 관점에서 전송 문제를 다루게 된다.

해결방법

img](http

AIMD (Additive Increase / Multiplicative Decrease)

  • 처음에 패킷을 하나씩 보내고 문제가 발생하지 않으면 윈도우 크기를 1씩 증가하는 방법
  • 패킷 전송에 실패하거나 일정 시간을 넘으면 패킷 전송 속도를 절반으로 줄인다.
  • 네트워크에 늦게 들어온 호스트가 처음에는 불리하지만, 시간이 흐르면서 평형상태로 수렴한다.
  • 단점
    • 처음에 전송 속도를 올리는 데 시간이 오래걸린다.
    • 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄인다.

Slow Start (느린 시작)

  • AIMD와 같이 패킷을 하나씩 보내고 문제가 발생하지 않으면 각 ACK 패킷마다 윈도우 크기를 1씩 늘려준다. 즉, 한 주기가 지나면 윈도우 크기는 2배가 된다.
  • AIMD와 달리 전송 속도를 지수 함수 꼴로 증가시켜서 윈도우 크기를 더 빠르게 증가시킨다.
  • 혼잡이 감지되면 윈도우 크기를 1로 줄인다.
  • 처음에는 네트워크 수용량을 예상할 수 있는 정보가 없지만, 한 번 혼잡 현상이 발생한 후에는 네트워크의 수용량을 어느 정도 예상할 수 있다.
  • 그래서 혼잡 현상이 발생하는 윈도우 크기의 절반가지는 지수 함수 꼴로 윈도우 크기를 증가시키고 그 이후에는 완만하게 1씩 증가시킨다.

Fast Retransmit (빠른 재전송)

  • TCP는 지금가지 받은 데이터 중 연속되는 패킷의 마지막 순번 이후를 ACK 패킷에 실어서 보낸다.
  • 그래서 송신 측이 아래처럼 3, 4번을 보내더라도 ACK 2 를 중복해서 받는다.
  • 그러면 timeout이 발생하기 전이라도 송신 측은 문제가 되는 2번 패킷을 재전송한다.
  • 그리고 혼잡한 상황이라고 판단해서 윈도우 크기를 줄인다.
  • 3 ACK Duplicated : 송신 측이 3번 이상 중복된 ACK 번호를 받은 상황

img

Fast Recovery (빠른 회복)

  • 혼잡한 상태가 되면 윈도우 크기를 1이 아니라 반으로 줄이고, 선형 증가시킨다.
  • 혼잡 상황을 한번 겪은 이후로는 AIMD 방식으로 동작한다.

💙You need to log in to GitHub to write comments.💙