에르노트
[RDT] Realiable Data Transfer (신뢰할 수 있는 데이터 전송) 본문
RDT에서는 송신자와 수진자를 명시하기 위해 FSM(Finite State Machine: 유한 상태 머신)을 사용한다.
RDT 1.0
하위 채널이 완전히 Realiable하다고 가정한다.
- 비트 에러 없음
- 패킷 손실 없음
송신측과 수신측이 분리된 FSM을 갖는다.
송신측은 하위 채널로 데이터를 전송하고 수신측은 하위 채널로부터 데이터를 수신한다.
RDT 2.0
하위 채널이 패킷에 비트 에러를 야기할 수 있다고 가정한다.
- Checksum(검사합)을 이용한 에러 검출
- 어떻게 에러를 복구할 것인가?
수신측의 피드백: Ack(Acknowledgement) 또는 NAK(Negative Acknowledgement)
ACK: "패킷이 잘 도착했음." 송신측은 수신측에서 ACK를 받으면 다음 패킷을 전송한다.
NAK: "패킷에 오류가 발생했음." 송신측은 Nck를 받는 즉시 해당 패킷을 재전송한다.
But, ACK 또는 NAK에 문제가 발생하면?
송신측은 수신측에 어떤 일이 일어났는지 알 수 없다. -> stop and wait
송신측에서 중복 전송 할 경우 수신측은 중복 수신하게됨 -> 효율성 저하
RDT 2.1
RDT 2.0의 문제점을 해결하기 위해서, 패킷에 seq(순서 번호)를 추가한다.
수신측에서 seq가 같은 패킷을 버리므로 중복 수신을 막을 수 있다!
RDT 2.2
ACK만 사용해서 RDT 2.1과 같은 기능을 구현한 것
NAK를 사용하는 대신, 마지막으로 올바르게 수신된 패킷의 ACK를 전달한다.
동일한 seq의 ACK을 받았을 경우 현재 패킷을 재전송한다.(NAK을 받았을 경우의 동작과 동일하게)
RDT 3.0
하위 채널에서 패킷들이 손실될 수 있다고 가정한다.
송신측은 ACK를 받을 때까지 충분한 시간을 기다려야한다. 만약 이 시간 안에 ACK를 받지 못했다면 해당 패킷을 재전송한다.(Timeout)
기능적으로 잘 동작하지만 성능이 다소 아쉽다.
'CS > Network' 카테고리의 다른 글
[네트워크 용어 정리]TCP? IP? 프로토콜? 인터넷? (0) | 2019.09.14 |
---|---|
[파일질라] FTP 접속 프로그램 FileZilla (0) | 2017.12.17 |
[OpenVPN] 호스팅 서버(우분투)에 VPN(가상사설망) 설치하기 (0) | 2017.12.09 |