주제 : Reliable Data Transmission Protocol 디자인
Transport Layer : Reliable
네트워크 레이어를 보면, Transport layer를 통해 Reliable한 데이터 전송이 가능하다.
즉 그 아래 레이어들은 Unreliable하다는 뜻인데,
데이터 전송이 Unreliable하다는 뜻은
- Error 가능
- Loss 가능
이란 뜻이다.
그렇다면 Transport layer에서 어떤 작업들을 해주길래 위 2가지를 방지할 수 있다는 것일까?
직접 상상을 하면서, 간단한 Reliable Data Transmission을 디자인을 해보자.
RDT v1.0 : Error, Loss가 없는 상황
- Sender : 걍 보내
- Receiver : 걍 받아
비현실적인 상황이다.
RDT v2.0 : Error만 발생할 수 있는 상황 (no loss)
패킷을 보냈는데 에러가 발생할 수도 있다. 그렇다면 어떻게 이를 방지할까?
- Error detection
- Checksum bits (ex. 모든 데이터의 합을 체크섬으로 사용하면 위변조 판단 가능)
- Feedback
- ACKs : 잘 받았어 ~ 전달
- NAKs : 에러 있어 ~ 전달
- Retransmission
- NAKs을 받으면 다시 전송하면 된다.
즉 Error 발생은 checksum, feedback,retransmission으로 커버할 수 있다.
이는 일반인들도 상상할 수 있는 부분이다.
전화통화를 할 때, 상대방이 말할 때 나는 아무 응답을 안하고 있는가?
ACKs : 어,어,어
NAKs : 뭐라고 ? 잘 안들려
이런식으로 표현을 나도 모르게 하고 있다. 컴퓨터의 소통도 인간의 소통과 별반 다르지 않다.
Seq# 필요성
저 3가지로 모든 Error를 커버할 수 있을까? 다음 예시를 보자.
오른쪽 그림을 보자. Sender가 Potato라는 메시지를 보냈다. 그리고 ACKs를 보냈는데, 이게 가는 도중 에러가 났다.
그래서 Sender는 다시 Potato를 보냈고 나는 받았다. 그럼 이게
- Duplicate packets : 동일한 메시지를 두번 보낸건지
- No error : 그냥 메시지가 PotatoPotato를 의도한 건지
어떻게 판단할까?
=> 패킷에 번호를 붙이면 된다. 그것이 Sequence Number다. 패킷의 헤더에 포함된다.
IF 패킷을 하나씩 보내며 통신할 경우, Seq # 몇 개 필요할까?
=> 0,1 1비트만 있으면 된다. 0보내고 잘 받았으면 1보내고, 다시 0 보내고, 몽말인지 알지?
RDT v2.2 : NAKs 없애기
ACK에 내가 받은 Seq #를 함께 보내면, Sender 입장에서 다음 보낼 패킷을 알 수 있다.
정리 : 패킷 에러 대처 방안 : Seq#, Error detection, Feedback, Retransmission 4가지 !
RDTv3.0 : Loss + Error
이제 Loss에 포커싱을 맞춰보자.
Sender 입장에서, 메시지를 보냈는데, 이게 중간에 유실됬는지, 어떻게 알까?
- Timer : 적절한 타이머를 설정해, 피드백이 안오면 재전송
Sender 입장에선, 지가 보낸 패킷이 유실되거나, Feedback이 유실되거나 똑같다. 무식하게 "재전송" 하면 된다.
정리 :
Unreliable : Loss or Error
Error : Error detection, Feedback, Retransmission, seq#
Loss : Timer
한계 :
그러나, 이 모든 과정은 패킷을 딱 1개씩 주고 받고 할 때고, 실제로는 패킷을 뭉탱이로 쏟아보내고, 각각 패킷에 대해 피드백을 한다. 다음 시간에 계속....
