애플리케이션 계층(2) _ RDT

 TCP_신뢰성있는 통신의 원리 

• reliable
  • application layer 에서 내려온 메시지가 하나도 유실되지 않고 receiver측 애플리케이션까지 도착하는 100% 도착하는 것

• transport 계층의 하위 계층들은 unreliable한 환경
  • 발생 할 수 있는 문제
    • Packet error
    • Packet loss

---

 RDT_신뢰성을 보장하는 법 

• Reliabl Data Transper
• unreliable한 상황에서 발생할 수 있는 문제들을 해결하기 위해 TCP는 RDT를 구현
• 이 프로토콜은 굉장힌 단순해서 한번에 패킷 하나만 보냄

---

• FSM
  • FSM
    • 유한개의 상태가 존재할 때, 어떤한 상태가 어떠한 사건에 의해 다른 상태로 변하는 전이가 발생하는 것을 도식화한 모델

---

 RDT 1.0 (reliable transfer over a reliable channel) 

packet error나 packet loss가 전혀 없이 완전히 안정적이라고 생각하는 상태 (즉, 상태가 하나뿐)

• sender
  • 상위 레이어에서 데이터를 보내오면 rdt_send(data) 호출
  • make_pkt(data)로 packet을 만듦
  • udt_send(packet) 호출해 packet을 전송
• receiver
  • 하위 레이어에서 데이터를 받아오면 rdt_rcv(packet) 호출
  • extract(paket, data) 호출해 패킷에서 데이터를 추출
  • deliver_data(data) 호출해 상위 레이어로 데이터 보냄

---

 RDT 2.0 (channel with packet errors) 

패킷 에러 발생 가능한 채널에서의 신뢰성 보장 방법

• 에러 감지(Error detection)
  • 에러 발생 여부 판단
  • checksum 으로 데이터 무결성 확인
• 피드백(Feedback)
  • receiver는 데이터를 잘 받았는지를 sender에게 피드백을 줌
  • ACK(Acknowledgements): 잘 받았어~!
  • NAKs(Negative ACKs): 못 받았어~!
• 재전송(Retransmission)
  • sender가 NAK을 받으면 재전송함
  • 반대로 ACK를 받으면 다음 패킷 전송

 

⚠️ 발생할 수 있는 문제점  → 피드백 패킷의 에러

< 해결방법 >

❗재전송

• 못 받았다는 가정하에 일단 재전송

❓복제된 패킷인지 어떻게 알 수 있을까? (보내고자 한 메시지가potato인지 potato potato인지..)

❗피드백 패킷의 Sequence numnber

• 메시지에 sequence number를 붙임
• 1번을 받았는데 1번이 또 온다면 복제된 패킷이므로 버리면 됨

⇒ 이게 RDT 2.1

---

 RDT 2.1 _ 2.0의 문제점을 해결한 버전 

• 에러 감지, 피드백, 재전송, 시퀀스 넘버
• sender
  • 패킷마다 시퀀스 넘버(Sequence#)을 붙임
  • 피드백(ACK/NAK) 오류 확인하고, 오류가 있으면 현재 패킷 재전송
• receiver
  • 복제된 패킷이면 버림
  • 잘 받았으면 ACK, 못 받았으면 NAK 

---

✔️ sequence number의 최소화

- 헤더는 부가적 정보들이 적히는 곳. 따라서 작을수록 좋음

- 최소한의 필드만을 사용해야할 뿐 아니라 각 필드는 최소화 되어야함.

- 이 프로토콜 상황에서 sequence number는 최소 2개 숫자만으로도 통신 가능

- 이전 패킷과 같은지 아닌지를 0과 1로 판단 할 수 있음

- 따라서 1비트(0,1)만으로 표현 가능

---

 RDT 2.2 _ NAK를 없앤 버전 

• receiver가 무조건 ACK를 보내는데 마지막으로 받은 정상적인 패킷의 시퀀스 넘버를 같이 전송
  • 3번 메시지를 전송했는데 ACK 2가 돌아오거나 ACK 메시지에 에러가 발생했다면, 3번 메시지를 재전송

---

 RDT 3.0 (channels with errors and loss) 

• sender가 패킷을 보냈는데 패킷이 유실된다면 피드백을 받지 못함
• ⏰ 타이머 ⏰ _ 해결 방법
  • 패킷을 보낼 때마다 타이머를 실행시켜 타임아웃이 되었는데도 피드백이 없으면 유실되었다고 판단하여 재전송
• RDT 3.0의 4가지 형식

A. 정상적 통신의 경우

B. packet loss가 발생한 경우

C. ACK loss가 발생한 경우

D. time out이 ACK보다 먼저 실행됬을 경우

• timeout이 너무 많이 발생하게 되면 receiver와 sender는 네트워크 상 duplicate된 packet을 여러번 전송하게 됨
• 현재의 메커니즘 상 sequence number로 복제된 패킷은 버리므로 문제는 없지만 많은 패킷을 보내면 네트워크에 오버헤드가 많아짐
• 타이머를 길게 설정하여 충분한 피드백을 기다리는 방법으로 오버헤드를 예방할 수 있지만 유실 상황에 대한 반응이 느려진다는 단점이 있음

---

 TCP RDT 정리 

• unreliable한 채널에서 발생 할 수 있는 두 가지
  • 패킷 에러(Packet error)
  • 패킷 로스(Packet loss)
• 패킷 에러(Packet error) 해결방법
  • 에러 감지(error detection)
  • 피드백(feedback)
  • 재전송(retransmission)
  • 시퀀스 넘버(sequence number)
• 패킷 유실(Packet loss) 해결방법
  • 타임 아웃(Timeout)

---

 RDT 의 문제점 

• Stop and Wait protocol
• 현재 방식으로는 하나의 패킷 전송 후 피드백 패킷을 받을 때까지 대
• 네트워크 상의 resource를 제대로 사용하지 못하고 제한 하는 것과 같음
• 따라서 현재의 TCP는 pipeline을 통해 한 번에 여러개의 packet을 전송하고 feedback도 한번에 받고 있음

이상 다음 포스팅에서~!

 

---

참고자료

컴퓨터네트워크 

컴퓨터네트워크

•