RDT
ㆍ 신뢰적 데이터 전송을 보장하기 위해 사용하는 프로토콜
ㆍ Transport Layer 의 프로토콜
rdt 1.0
ㆍ 손실, 손상되어 있지 않은 채널에서의 데이터 전송
ㆍ 수신 -> 송신 측으로 어떤 피드백도 보낼 필요가 없음
rdt 2.0
ㆍ 손실은 없으나 손상이 있는 채널에서의 데이터 전송
ㆍ 손상(비트 오류)을 확인하기 위해 1) 오류 검출, 2) 수신자 피드백, 3) 재전송을 거침
ㆍ 손상에 대한 피드백을 주기 전까지 새로운 데이터를 전송하지 않음 = 전송 후 대기 프로토콜
rdt 3.0
ㆍ 손실, 손상되어 있는 채널에서의 데이터 전송
ㆍ 패킷이 손실, 손상 되어 응답이 없을 경우 재전송으로 해결 가능
ㆍ 하지만, 필요한 대기 시간을 알 수 없으므로 성능이 좋지 않음
전송 후 대기 프로토콜
ㆍ 흐름 제어 프로토콜
ㆍ 송신자가 한 개의 패킷을 전송하면 수신자로부터 응답을 받을 때까지 기다리는 방식
ㆍ 패킷 에러 유무를 확인한 뒤 ACK(인정), NAK(부정) 신호를 사용함
작동 방식
1. A(송신자)가 B(수신자)에게 패킷을 보냄
2. B는 패킷의 에러 유무를 확인함
2.1. 에러 없음) ACK 신호 보냄
2.2. 에러 있음) NAK 신호 보냄
3. A는 받은 신호를 확인함
3.1. ACK) 다음 패킷 전송
3.2. NAK) 패킷 재전송
장/단점
장점
ㆍ 구현이 간단함
ㆍ 오류 검출, 복구가 쉬움
: 패킷이 순서대로 전송됨
: 데이터를 확인하는 작업 동반
단점
ㆍ 효율성 낮음, 속도 느림
: 송신자가 항상 한 개의 프레임만 보낼 수 있기 때문
개선 방법
ㆍ 슬라이딩 윈도우 프로토콜
ㆍ 파이프라인 프로토콜
파이프라인 프로토콜
ㆍ 요청에 대한 응답을 기다리지 않고 다른 패킷 전송을 가능하게 하는 프로토콜
ㆍ 패킷을 작게 분리하고 각 부분을 순서대로 처리함
ㆍ ACK 신호를 회신 받지 않아도 됨
주요 방법론
1) Go-Back-N(GBN)
2) Selective Repeat ARQ
장/단점
장점
ㆍ 전송 속도 빠름, 네트워크 정체 개선
ㆍ 장거리 데이터 전송에 사용할 수 있음
단점
ㆍ 앞 요청이 처리될 때까지 뒤의 요청의 대기 시간이 길어짐
ㆍ 구현이 복잡하여 오류 발생 시 해결하기 어려울 수 있음
개선 방법
ㆍ Multiflexed Streams
: HTTP 프로토콜 참고
참고
ㆍ https://frog-in-well.tistory.com/48
ㆍ https://code-lab1.tistory.com/26
ㆍ https://velog.io/@yoonuk/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%A0%84%EC%86%A1-%ED%9B%84-%EB%8C%80%EA%B8%B0-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C
ㆍ https://velog.io/@yoonuk/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C
