목차
1. Reliable Data Transfer
2. rdt 1.0 : 모든 게 이상적인 환경
3. rdt 2.0 : Bit errors (no loss)
4. rdt 2.1 : Introducing Sequence Number
5. rdt 2.2 : NAK-free Version
6. rdt 3.0 : Lossy Channel With Bit Error
7. Summary
1. Reliable Data Transfer
rdt는 reliable data tranfer protocol을 의미하는 가상의 프로토콜이다. (실제로 없는 개념)
📌 As-is
- Reliable channer : 신뢰적인 데이터 채널 (Transport Layer)
- Unreliable channer : 비신뢰적인 데이터 채널 (Network Layer 이하)
📌 To-be
💡 하위 계층이 비신뢰적인 채널인 경우, 상위 채널에서 신뢰적인 통신을 제공해야 한다.
- rdt_send() : 신뢰적인 Layer로 데이터를 보낼 때. (소켓 생성 필요. app이 호출)
- udt_send() : 비신뢰적인 Layer로 데이터를 보낼 때.
- rdt_rcv() : 상위 rdt에 data를 전달할 때 (패킷이 채널의 수신측에 도착했을 때 호출)
- deliver_data() : TCP가 Application Layer에 데이터를 전달할 때. (소켓이 열려야 하는데 리스너가 열어준다.)
2. rdt 1.0 : 모든 게 이상적인 환경
📌 하위 채널이 완전히 신뢰적인 경우
- no bit error
- no loss of packets
즉, 하는 일이 없다.
📌 FSM
Sender는 Multiplexing만, Receiver는 Demultiplexing만 해도 문제가 없다.
Sender
- 상위 계층에서 call이 올 때까지 대기한다.
- 상위 계층에서 데이터를 rdt_send로 보내는 이벤트가 발생한다.
- 받은 데이터를 packet으로 make_pkt 한다.
- packet을 하위 계층으로 udt_send한다.
- packet을 보내고 다시 대기 모드로 전환한다.
Receiver
- 하위 계층에서 call이 올 때까지 대기한다.
- 하위 계층에서 packet을 rdt_rcv로 보내는 이벤트가 발생한다.
- 받은 packet 안의 데이터를 추출한다.
- 추출한 데이터를 상위 계층으로 deliver한다.
- data를 보내고 난 후에 다시 packet 대기 상태로 돌아간다.
3. rdt 2.0 : Bit Errors (no loss)
1️⃣ Checksum Field
비트 오류가 발생할 수 있는 환경에선 수신자가 에러를 감지할 수 있어야 한다.
sender가 checksum을 데이터에 추가하면, receiver가 검증한다.
이 때, packet의 손실이나 순서는 보장한다.
2️⃣ Feedback
수신측은 받은 데이터에 대한 긍정적인, 혹은 부정적인 피드백을 해줄 필요가 있다.
- Acknowledgement (ACKs) : receiver가 sender에게 packet을 잘 받았다는 긍정적 응답
- Negative Acknowledgement (NAKs) : receiver가 sender에게 packet에 error가 있음을 알리는 부정적 응답
3️⃣ Retransmission
- Sender가 ACKs를 받으면 buffer에 임시 저장된 패킷을 버린다
- Sender가 NAKs를 받으면 buffer에 임시 저장된 패킷을 다시 전송한다.
이때 ACKs, NAKs는 절대 깨지지 않는다는 가정이 필요하다.
✒️ Buffer
rdt 2.0부터는 packet을 보낸 후에 error나 loss이 발생해 재전송할 가능성이 있다.
따라서 sender는 receiver로 부터 feedback이 올 때 까지는 송신한 packet을 buffer에 저장해두고 있어야 한다.
📌 Stop-and-wait protocol
정리하자면 rdt 2.0에선 다음 3가지 기능이 필요하다.
- Error detection : checksum field
- Receiver Feedback : ACKs, NAKs
- Retransmission : buffer
Sender는 paket을 하나 보내고, Receiver의 응답을 기다리는 Protocol을 Stop-and-wait (non pipe lining)이라 정하자.
(비효율적이라 TCP에서 사용하진 않는다.)
4. rdt 2.1 : Introducing Sequence Number
📌 As-is
재전송 시 가정했던 ACKs, NAKs는 bit error가 발생하지 않는다는 가정을 없애면 어떻게 될까?
- Sender
- ACKs 혹은 NACKs가 도중에 bit error가 발생하면, sender는 receiver 측에 어떤 일이 발생했는지 알 수 없다.
- 깨진 ACK이 도착하면 computer program은 최악의 상황이라 가정하기 때문에 NAKs로 간주하여 pkt를 재전송한다.
- Receiver
- 처리가 끝난 중복된 data를 Application에 올리면 신뢰적인 data 전송을 보장할 수 없게 된다.
📌 To-be. sequence #
Receiver가 중복 패킷을 감지할 수 있게, 패킷마다 번호(Unique Value)를 붙이면 된다.
- Sender
- NAKs를 받으면 같은 sequence #를 붙여서 재전송하면 된다.
- Stop-and-wait protocol에서는 1bit로도 구분 가능하다.
- Receiver
- 마지막으로 받은 pkt와 수신한 pkt의 seq #를 비교한다.
- 중복이라면 pkt를 버리고, 해당 패킷에 대한 ACK을 재전송한다.
📌 Summary
정리하면 rdt2.1에선 다음과 같은 기능들이 필요하다.
- Error detection
- Feedback
- Retransmission
- Sequence number
5. rdt 2.2 : NAK-free Version
동일한 기능을 구현할 수 있다면, 보다 간단한 방법을 택하는 것이 좋다.
NAKs를 보내는 대신에 정확히 수신한 packet에 대한 ACK을 전달해보자.
즉, receiver가 ACK에 잘 받은 데이터까지의 seq#를 보낸다.
Sender는 중복된 ACK을 받게 되면 ACK pkt 이후의 pkt가 정상적으로 수신되지 못했음을 인지하고 재전송한다.
따라서 ACK만으로도 sender는 마지막 수신한 ACK seq# 이전의 pkt는 모두 정상적으로 전달되었음을 알 수 있다.
6. rdt 3.0 : Lossy Channel With Bit Error
bit error 뿐만 아니라 도중에 패킷이 손실되는 가정을 추가해보자.
checksum, seq #, ACK만으로는 충분하지 않다.
📌 Time-out
- Sender는 "합리적인" 시간만큼 ACK을 기다린다. → #9에서 다룸
- 합리적인 시간만큼 기다려도 ACK이 오지 않으면 재전송한다.
- 만약 ACK이 지연되어 중복 pkt 재전송한 것이어도 seq #로 해결할 수 있다.
1️⃣ no loss
2️⃣ packet loss
packet이 손실되면 ACK이 돌아오지 않으므로 time-out이 발생하여 재전송이 발생한다.
3️⃣ ACK loss
ACK이 손실되어도 time-out이 발생하여 재전송이 일어난다.
4️⃣ premature timeout/delayed ACK
timer가 너무 짧아서 중복 패킷을 전달하게 되어도 receiver는 seq #로 충분히 중복 여부를 판단할 수 있다.
7. Summary
지금까지 신뢰할 수 있는 데이터 전송을 위한 간이 프로토콜을 만들어봤다.
물론 실제 TCP는 훨씬 복잡하지만, 같은 원칙을 가지고 있다.
- rdt1.0 : no bit error, no loss
- rdt2.0 : with bit error
- checksum
- ACKs, NAKs
- retransff
- rdt2.1 : with ACKs loss
- seq #
- rdt2.2 : free NAKs
- ACK up to the receive seq #
- rdt3.0 : with packet loss
- timer