[네트워크] RDT(Reliable Data Transfer)

1. RDT(Reliable data transfer)

 RDT란, 데이터를 전송할 때 패킷 데이터의 유실과 손상이 발생하지 않도록 보장해주는 프로토콜입니다. TCP와 UDP를 구분하는 큰 특징이기도 합니다.

 

 RDT의 단계를 이상적인 상황부터 시작해 설계해보며, 문제점을 위해 어떤 메커니즘이 필요한지 간단히 알아보겠습니다.

 

(1) RDT 1.0 : No error & No loss

 데이터가 완벽하게 전송되었을 때를 말합니다. 그래서 어떤 매커니즘도 필요하지 않습니다.

 

 좀 더 풀어서 얘기를 하자면, 데이터는 하위 계층을 거쳐 전송이 됩니다. 그런데 이 하위 계층이 신뢰성이 높고 완벽하기 때문에, 전송 계층에서 데이터의 신뢰성을 준수할 필요가 없는 것입니다.

 

 예를 들어 택배를 배달할 때, 상품의 배달 과정에서 상품에 어떠한 충격도 가해지지 않는다면, 굳이 포장재로 감쌀 필요가 없는 것과 같습니다. 하지만 현실은 이런 이상적인 상황과 거리가 멉니다.

 

(2) RDT 2.0 : Error 존재

 패킷에 유실은 없지만, 패킷 에러가 생기는 채널을 통해 데이터가 전송될 때입니다. 

 

 택배를 예로 들면, 엉뚱한 곳으로 배송되지는 않지만, 충격을 받아 상품에 데미지가 생기는 상황입니다. 이런 문제 상황은 에러 감지와 피드백을 통해 해결합니다.

 

 우선 에러감지를 통해 먼저 에러가 발생했는지를 알아봅니다. checksum bits를 통해 받는 사람이 에러가 있는지 없는지를 체크합니다. 

 

 그리고 Receiver가 데이터를 잘 받았는지 확인하기 위해 피드백이 사용됩니다. Receiver는 패킷을 받을 때마다 피드백을 줍니다. 패킷을 올바르게 받았다면 ACKs(Acknowledgements)를, 에러가 발생하면 NAKs(Negative ACKs)을 전송합니다.

 

 Sender가 NAK을 받게 되면 데이터를 재전송(Retransmission)합니다. 반대로 ACK를 받게 되면 Sender는 제대로 전달된 것으로 확인하고, 다음 패킷을 전송합니다.

 

 

(3) RDT 2.1 (Sequence Number 도입)

 여기서 주의해야할 것은, 리시버가 보낸 피드백 자체가 에러일 수가 있다는 것입니다. 그런 상황에서 Sender는 이 피드백이 에러가 발생했다고 판단해 패킷을 재전송할 것입니다.(Duplicate Packets 발생) 

 

 그럼 Receiver 서버는 중복된 데이터를 다시 받게 되기 때문에 이를 처리하는 방법에 대한 솔루션이 필요합니다. 그래서 Sequence Number라는 것이 사용됩니다. 

 

 Sequence Number는 Sender가 헤더에 Sequence Number를 추가하여 중복 패킷을 리시버가 판단할 수 있도록 도와줍니다.

 

 예를 들어 0번 메시지, 1번 메시지, 2번 메시지 이런 식으로 번호를 붙여 전송하게 되면, 이 패킷이 방금 받은 패킷인지 아닌지 쉽게 구분할 수 있습니다. 만약 2번 메시지까지 보냈는데, 다음 패킷이 다시 2번이면 복제된 패킷으로 판단하는 것입니다.

 

 여기서 Sequence Number는 이전에 보낸 번호와 같은지 아닌지(복제 패킷인지 아닌지)만 구분하면 되는 것이기 때문에 1비트인 0과 1만으로 표현이 가능합니다. 

 

 

(4) RDT 2.2 (NAK 없애기)

 위 방법에서 NAK을 없앨 수 있습니다.

 

 피드백은 무조건 ACK로 하되, Sequence Number(Seq #)을 통해 ACK, NAK를 판단하는 것입니다. 예를 들어, Sender가 0으로 패킷을 보냈는데 Seq num가 1로 돌아오거나 ACK 메시지에 에러가 발생했다면, 잘못 받았다는 의미로 받아들여 0번 메시지를 재전송하는 것입니다. 

 

 

(5) RDT 3.0 :  Error 존재 & Loss 존재

 RDT 2.0에서 RDT는 패킷 에러를 처리할 수 있게 되었습니다. 그렇다면 패킷이 아예 도착을 하지 않는다면 어떻게 해결할지 살펴보겠습니다.

 

 우선 타이머를 사용합니다. 패캇을 보내면 ACK나 NAK든, 어떤 식으로라도 반응이 돌아와야합니다. 하지만 일정 시간 동안 상대방에게 피드백이 오지 않는다면 패킷이 유실된 것으로 판단할 수 있습니다. 패킷을 보낼 때, 타이머를 동작시키고, 일정시간 동안 응답이 없으면 타임 아웃으로 간주해 패킷 유실로 처리하고 재전송해 문제를 해결합니다.

 

 그럼 여기서 고려해야할 것은 타이머의 시간을 얼마로 두어야 할 것인가? 입니다. 타이머의 시간을 얼마로 정할 것인지는 구체적으로 정해진 것이 없습니다. 대신, 너무 짧은 경우와 긴 경우로 가정해 문제를 살펴보겠습니다.

 

 만약 타이머의 길이가 너무 짧으면, 빠르게 유실 상황을 복구할 수 있다는 장점이 있습니다. 하지만 중복된 패킷을 전송할 수 있다는 문제가 있습니다. 패킷이 느려서 전송이 되지 않은 상황일 수 있기 때문입니다. 물론 복제된 패킷은 버려짐으로 전달은 정상적으로 이루어지지만, 필요없는 데이터에 대한 오버헤드가 발생하게 됩니다. 

 

 반면 타이머의 길이가 너무 길다면 네트워크에 대한 오버헤드는 줄일 수 있습니다. 하지만, 유실 상황에 대한 반응이 느려 조치가 느려집니다.

 

 그래서 타이머를 어느 정도 길이로 설정할 것인지는 적당한 선으로 설정해야합니다. 타이머를 어느 정도로 설정할지에 대해서는 다음 포스팅에서 다룰 것입니다.

 

 

 

 

2. RDT 문제점

 지금까지 살펴본 RDT 방식은 신뢰성은 보장하지만 효율성 측면에서는 떨어지는 부분이 있습니다. RDT 3.0를 하나씩 전송하게 되면 많은 패킷 낭비가 발생하기 때문입니다. 전체 시간 중 송신자가 네트워크를 사용하는 비율이 크면 클수록 성능이 좋다고 판단하는데 이러한 프로토콜은 데이터를 하나씩 주고 받으며 확인하기 때문에 성능이 떨어질 수 밖에 없습니다.

출처 : Computer Networking _ A Top Down Approach, 7th

 

 현재 방식으로는 위 그림과 같습니다. 패킷 하나를 전송하고 나서 ACK 메시지가 올 때까지 그 소켓은 어떤 통신도 할 수 없는 것입니다.  따라서 여러 개의 데이터를 한 번에 전송하고, 피드백도 한 번에 받는 방식이 필요합니다. 이를 위해 등장한 것이 Pipeline Protocol 입니다.

 

 

 Pipeline Protocol에 대해서는 다음 포스팅에서 알아보겠습니다.

 

 

참고자료

[컴퓨터 네트워크 - 한양대학교 이석복 교수님]
http://www.kocw.net/home/cview.do?cid=6166c077e545b736

https://the-square-of-y.tistory.com/215

https://the-brain-of-sic2.tistory.com/52

https://dev-nicitis.tistory.com/26

Computer Networking _ A Top Down Approach, 7th