[네트워크] RDT (Reliable Data Transfer) 프로토콜

1. rdt 2.1: 시퀀스 번호의 도입 (비트 오류 및 응답 오류 해결)

image_cdfe45.png(송신자)와 image_ce549e.png(수신자)를 통해 확인할 수 있는 단계입니다.

핵심 문제 해결

• 문제: rdt 2.0에서는 ACK/NAK 자체가 깨질 경우 송신자가 재전송을 해야 하는데, 수신자는 이게 '새 데이터'인지 '중복 데이터'인지 구분할 수 없었습니다.
• 해결: 데이터 패킷에 시퀀스 번호(0, 1)를 붙입니다.

FSM 주요 로직

1. 송신자 (Sender):
   
   • 패킷을 보낼 때 0 또는 1 번호를 부여합니다.
   • ACK/NAK에 숫자가 없는 이유: 송신자 스스로가 현재 '0번 응답 대기' 또는 '1번 응답 대기' 상태에 있기 때문에, 들어오는 응답이 어떤 패킷에 대한 것인지 상태(State)로 이미 알고 있기 때문입니다.
2. 수신자 (Receiver):
   • has_seq0 또는 has_seq1 조건을 사용하여 내가 지금 기다리는 번호가 맞는지 확인합니다.
   • 만약 이미 받았던 번호가 다시 오면(중복), 데이터를 위로 올리지는 않되 ACK를 다시 보내서 송신자를 안심시킵니다.

2. rdt 2.2: NAK-Free 프로토콜 (구조의 단순화)

핵심 문제 해결

• 문제: ACK와 NAK라는 두 종류의 제어 메시지를 관리하는 것이 번거롭습니다.
• 해결: ACK에 시퀀스 번호를 포함시켜서 NAK의 기능을 대신하게 합니다. (NAK 제거)

FSM 주요 로직

• 수신자: 패킷이 깨졌거나 잘못된 번호가 오면, "내가 마지막으로 성공한 패킷의 번호"를 담아 ACK를 보냅니다. (예: 0번 기다리는데 1번이 오면 ACK 1 전송)
• 송신자: 내가 0번을 보냈는데 ACK 1이 오면(이미지 속 isACK(rcvpkt, 1)), 이를 암시적인 NAK으로 받아들이고 0번을 다시 보냅니다.

3. rdt 3.0: 타이머의 도입 (패킷 유실 해결)

image_ce76c6.png부터 image_d86f6a.png까지 설명하는 완성형 단계입니다.

핵심 문제 해결

• 문제: 패킷이 중간에 아예 사라지는(Loss) 경우, 송신자와 수신자 모두 응답을 무한정 기다리는 교착 상태(Deadlock)에 빠집니다.
• 해결: Countdown Timer (타이머)를 도입합니다.

FSM 주요 로직

1. start_timer / stop_timer: 데이터를 보낼 때 타이머를 켜고, 정확한 ACK가 오면 타이머를 끕니다.
2. timeout: 정해진 시간 동안 아무 소식이 없으면 패킷을 다시 전송(udt_send)하고 타이머를 다시 시작합니다.
3. Λ (아무것도 안 함): 응답이 깨졌거나 잘못된 번호가 오면, rdt 2.1처럼 즉시 대응하지 않고 가만히 기다립니다. 어차피 조금 뒤에 타이머가 울려서(timeout) 재전송이 일어날 것이기 때문입니다.

실제 작동 시나리오 

• ACK Loss: 수신자가 보낸 ACK가 사라져도, 송신자의 타이머가 터지면 다시 데이터를 보내 해결합니다.
• Premature Timeout: 네트워크 지연으로 ACK가 늦게 와서 중복 전송이 발생해도, 시퀀스 번호(0, 1) 덕분에 수신자가 중복을 걸러낼 수 있습니다.

요약표: 프로토콜 진화 과정

단계	환경 가상	주요 메커니즘	해결된 문제
rdt 2.1	비트 오류	시퀀스 번호 (0, 1)	응답 오류 시 발생하는 중복 패킷 구분
rdt 2.2	비트 오류	ACK + 시퀀스 번호	NAK 없이 ACK만으로 제어 가능 (단순화)
rdt 3.0	비트 오류 + 유실	Countdown Timer	패킷/응답 분실 시 발생하는 무한 대기 해결

최종 결론: rdt 3.0은 현대 통신의 신뢰성을 보장하는 가장 기본적인 원리(에러 검출, 피드백, 순서 번호, 타임아웃)를 모두 갖춘 모델입니다.