티스토리 뷰

Automatic Repeat reQuest

  • 수신측과 송신측의 데이터 전송과정에서 패킷의 오류나 손실이 발생 시 reliable한 통신을 위해서 해당 패킷을 다시 보내게 된다. 이때 어떻게 해당 패킷을 인지해서 다시 보낼지에 대한 방법이다.
  • Stop-and-Wait, Go-Back-N, Selective-Repeat, 3-duplicate-ACK 방식 등이 존재한다.
  • ARQ가 존재하기 때문에 TCP는 Relialbe한 통신이 될 수 있다.

 

Stop and Wait

  • 하나의 프레임을 보내고 ACK가 올 때까지 기다리는 방식이다.
    -> 프레임이 손실되거나 손상을 입은 경우 ACK는 오지 않게되고 해당 프레임에 대한 Timer 만료로 인해 재전송이 가게 된다.
  • 제대로 온 프레임에 대해서만 ACK를 보내고 그외에는 수신측에서 아무것도 하지 않는 것.
  • 이때 수신측은 프레임에 적혀있는 식별자(identifier)로 재전송 패킷인지 아닌지를 구별한다.
stop and wait을 이용한 통신 예

  • 0과 1 두개의 식별자를 이용해서 프레임을 구분한다.
    1. 송신측에서 0번으로 해서 보내고 ACK가 0번을 받으면 1번으로 식별자를 변경하고 1번 ACK를 보낸다.
    2. 1번 ACK를 받은 송신측은 제대로 통신이 이뤄짐을 확인하고 1번으로 식별자를 올리고 프레임을 보낸다.
    3. 수신측은 자신이 가리키는 식별자와 전달받은 식별자를 비교해서 같다면 새로 받아서 버퍼에 담고, 다르다면 재전송 받은거이라 판단하고 기존에 받았든 못받았든 비우고 새로 받는다.
  • 보낸 데이터에서 문제가 생기거나 ACK에서 문제가 생기면 타이머 만료로 재전송하게 된다.
정리
  • 송신측은 주어진 시간 중 일부분만 활용하는 알고리즘으로 매우 비효율적이다. 프레임을 보내고 ACK가 올 때까지 wait하면서 노는 구조이므로 유휴시간이 너무 많다.
  • 데이터 처리량이 프레임이 송신측에서 출발해서 수신측을 찍고 ACK가 다시 돌아오는 Round Trip Time (RTT)에 매우 의존적이다.

 

Go Back N

  • 전송의 효율성을 개선한 파이프라이닝 기법을 적용한 방식이다.
  • 연속해서 보내다가 N번 프레임에서 타임아웃이 발생하면 N번 프레임부터 전부 다시 보낸다.
  • Window Size를 지정해서 일정 개수의 프레임은 연속해서 보낸다.
    • 크기는 sequence number를 표현할 수 있는 m bit의 2^m - 1까지 가질 수 있다.
  • Sequence number를 위한 bit크기가 m일 때 2^m 만큼 sequence number를 사용할 수 있다.
    • m이 4일 경우, 0~15번까지 seq num으로 사용한다. 하지만 window size는 2^m -1 인 0~14번인 15개 까지만 사용이 가능하다.
    • window size는 연속으로 보낼 수 있는 프레임의 개수를 지칭한다. 이때 window size가 seq num과 같아질 경우 재전송과 아닌 것을 구분할 수가 없어진다.
  • cumulative ACK를 적용한다.
    • 누적 ACK란 이전에 전송한 프레임의 ACK를 전달받지 못했더라도 받은 ACK가 이를 포괄한다면 정상적으로 통신이 됐다고 판단하는 방식이다.

  • 전송하는 프레임이 유실 된 경우 해당 프레임은 타임아웃이 발생하고 해당 SEQ부터 다시 다 보내게 된다.
  • 수신측에서 보내는 ACK가 유실 된 경우 다음 프레임의 응답 ACK를 통해 cumulative로 응답해주게 된다. (재전송 X)
정리
  • Window Size를 이용해서 파이프라이닝 기법으로 연속적으로 프레임을 보낸다.
  • ACK가 제대로 오지 않아도 다음 ACK가 제대로 오면 cumulative 방식으로 이전 프레임의 통신 여부를 판단한다.
  • 프레임이 유실되어 Timer 만료가 되면 그때 해당 SEQ부터 전부 재전송한다. 타이머 시간을 잘 설정하는게 중요하다.
  • 송/수신측 window size는 가변적이므로 통신상황에 따라 달라진다.

 

3 duplicate ACKs

  • Timer의 시간을 잘 잡아야 되는데 왕복 시간인 Round Trip Time (RTT) 보다는 길어야 한다. 또한 Timer의 시간이 너무 길면 기껏 열심히 보내놓은 프레임을 전부 재전송해야하는 일이 발생한다.
  • 따라서 cumulative한 ACK 방식을 사용하지 않고 매 프레임마다 전부 ACK를 보내도록 한다. 이때 송신측은 ACK와 상관없이 window size에 맞춰서 프레임을 보낸다.
    수신측은 전달받은 프레임의 SEQ를 통해 차곡차곡 데이터를 쌓다가 빈 부분이 생기면 해당 부분을 다시 달라고 ACK를 보낸다.
    만약 동일한 부분에 대해 3번 ACK를 받으면 정말로 유실되었다고 판단하고 재전송하게 된다.
  • 즉 타이머 만료보다 빠르게 재전송 프레임을 판단하기 위한 방식이다. 단점으로는 모든 프레임마다 ACK를 보내야 한다는 점이다.

 

Selective Repeat

  • N번째 PDU가 손실이 되면 N번째만 재전송받는다
  • RX Entity는 N번을 못받고 N+1, N+2는 받았다면 제대로 받은 PDU를 저장을 하고 있는다
    (N번을 제대로 받을 때 까지 가지고 있는다)TX, RX 둘다 버퍼에 대한 요구사항이 있다
    → TX는 재선송을 위해 당연히 버퍼를 갖고있고 & RX에서도 재전송되는 패킷을 받을 때까지 정상수신된 패킷을 버퍼에 갖고있어야한다
  • 송신측은 ACK로 제대로 받았다는 내용만 보내게 되고, n번 패킷에서 loss가 나면 송신측 n번 패킷의 timer에서 expiry가 발생하고 해당 n번 패킷만 재전송하게된다.
  • 수신측은 n번까지 제대로 와서 버퍼가 다차면 그때 한번에 모은 패킷을 상위계층으로 전달한다.
    → 제대로 전달받은 PDU를 보관해야하는 RX측 버퍼링의 요구사항 & TX측에서 보내는 패킷마다 timer를 설정해서 만료를 체크하고 다시 보내야하는 부담감이있다.
  • 모든 패킷에대한 timer의 부담으로 실제 실무에서는 go back n을 사용한다.
반응형
Comments
반응형
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday