컴퓨터 네트워크 9-2일차 : 신뢰 높은 데이터 전송, rdt 버전

 

컴퓨터 네트워크 9-1일차 : transport layer, UDP, (de)multiplexing, TCP

CHAPTER 3 TRANSPORT LAYER

PART2 시작입니다~!

 

---

1. reliable한 데이터 전송의 원리

transport layer에서 신뢰성있는 데이터를 전송해주는 것은 네트워크 관점에서 굉장히 중요한 주제입니다. 

 

sending process가 데이터를 보내기 위해서 소켓을 통해서 데이터를 보냅니다. 만약 transport layer 부분이 reliable한 채널이다라고 가정한다면, 데이터가 손실이 나지 않는 채널을 형성해준다는 것을 말합니다. 즉, receiver 단에서 아무 문제 없이 오리지널 데이터를 잘 받을 수가 있는 것입니다.

 

transport layer에서 여러 알고리즘을 동원해 마치 transport layer가 application layer 관점에서 reliable한 채널처럼 보이게끔 하는 것이 우리의 목적입니다. 

 

실제 transport layer가 데이터를 전송하는 밑에 physical layer는 reliable한 채널이 아닙니다. 전파는 노이즈에 의해서 왜곡될 수도 있고, 중간에 라우터에서 큐잉이 너무 많이 된다면 큐잉 로스가 발생할 수도 있기 때문입니다. 이런 unreliable한 채널을 통해서 transport layer는 receiver process까지 데이터를 전송해야 합니다.

 

그러기 위해서 transport layer에서 reliable한 데이터 transport 프로토콜을 설계해야합니다. application layer에서 데이터를 transport layer로 내려주면, application 관점에서는 transport layer 프로토콜이 reliable한 전송을 해준다고 보기 때문에 (reliable data transfer)rdt_send()를 통해서 데이터를 transport layer에 내려주게 되는 것입니다. 즉, 내 밑에서 잘해줘서 신뢰성있게 전달해줄거야 라고 믿고, rdt_send()라는 메세지를 호출하는 것입니다. 우리가 설계를하기 위한 임의의 함수명으로 지원을 온 것입니다.

 

rdt라는 프로토콜을 설계한다고치면, rdt 프로토콜은 unreliable한 채널을 통해서 패킷을 흘려보내줍니다. (udt_send())

server에서는 rdt_rcv함수를 통해 데이터를 받고, application으로 올려보내줍니다. rdt 프로토콜을 설계해줘야 unreliable을 통해서 데이터를 신뢰성있게 전송할 수 있습니다.

결국에는 rdt 프로토콜에 의해서 신뢰성있는 전송이 일어나게 해야합니다. application layer에서는 rdt_send()를 통해 데이터를 rdt 프로토콜 계층으로 내려보내줍니다. 

 

udt_send()는 rdt 프로토콜에 의해서 호출이 됩니다. 이 패킷은 물리 계층인 unreliable채널에 의해서 데이터를 전달시킵니다.

 

rdt_rcv()로 패킷이 리서버 사이드에서 도착했습니다. 그럼 호출이되어서 rdt 프로토콜로 올려보내줍니다. 그럼 rdt transfer 계층에서는 최종적으로 deliver data()를 통해서 application으로 데이터를 올려줘서 application data를 만듭니다.

 

1-1. reliable data tranfer(rdt) 프로토콜을 만들기 위해 필요한 재료들

1) rdt 설계하는 과정이 복잡하기 때문에 점진적으로 설계해나갈 겁니다. 데이터가 손실되는 원인이 다양하기 때문에 한 번에 설계하면 복잡하기 때문입니다.

2) sender와 receiver의 동작을 규정하기 위한 finite state machines(FSM)을 활용하면서 알고리즘을 설계할 겁니다.

finite state machines

어떤 이벤트가 발생하면 state1 -> state2로 바뀐다라는 표현입니다. 또한 state 트랜지션이 발생할 때 취하는 action이 있을 수 있습니다. 이벤트 아래다 액션을 써주면 됩니다. 참고로 ^ 이 표시는 어떠한 액션도 취해지지 않는다는 것을 의미합니다.

 

 

1-2. unreliable한 채널을 통해 데이터 전송을 할 때 발생할 수 있는 데이터 손실이나 데이터 에러의 종류

1) bit error : 패킷 로스는 발생하지 않지만, 전달 받은 데이터에 오류가 있습니다. 1011->1110이 온 격 입니다. 리시버는 checksum을 활용해 에러를 알 수 있습니다.

 

2) loss(drop) packets : 패킷 손실은 좀 더 까다롭습니다. 리시버 입장에서는 패킷이 아예 오지를 않았으니 센더가 나에게 보냈는지 조차 모르게 되기 때문입니다. 센더는 데이터가 잘 갔는지 에러가 났는지를 모르게 됩니다. 알 수 있는 유일한 방법은 리시버로부터 데이터를 보내고 잘 갔으면, acknowledgement를 보내달라 약속하고, 일정 시간 내 오지 않으면, loss가 났다고 판정하는 것입니다.

 

3) reordering or duplication : 데이터가 중복해서 오거나 순서가 꼬여서 오는 경우 입니다.

 

TCP는 이 문제들을 다 해결할 수 있는 알고리즘을 채용하고 있습니다.

 

 

1-3. rdt의 변화

버전 1.0에서는 데이터를 신뢰성있게 보내기만 하면 됩니다.

버전 2.0에서는 신뢰성 있지 못한 채널인데, bit error만 발생합니다. 이 때 rdt 프로토콜이 어떻게 동작해야하는지를 배웁니다.

버전 3.0에서는 에러와 로스가 발생하는 채널에서 rdt 프로토콜이 어떻게 동작해야하는지를 배웁니다.

 

1) rdt 1.0

이미 보내는 채널이 신뢰성있습니다. 비트 에러나 로스가 발생하지 않는다고 가정한 것입니다. 이 때 FSM이 어떻게 동작하는지 살펴보도록 하겠습니다.

initial state에서 위에서 호출을 기다립니다. application layer에서 이 호출을 보내줘라는 것을 기다립니다. rdt_sender(data) 호출이 들어오면(=event), 다음과 같은 액션이 취해집니다. (아래 명시)

 

패킷을 만들기 위해 make_pkt(data)를 해주고, 패킷을 udt_send(packet)을 통해서 아래의 채널로 보내줍니다.

 

이 과정이 끝나면, 그럼 또 rdt_send를 기다리는 일의 반복이기 때문에 상태는 변하지 않습니다.

 

그럼 receive 단에선 데이터가 전달되면, rdt_rcv(packet)가 호출됩니다. (=event)

그럼 다음과 같은 액션이 발생합니다.

extract(packet, data)를 통해 패킷으로부터 데이터를 추출합니다.

그 후 deliver_data(data)를 통해 이 데이터를 application data를 통해 올려줍니다.

 

그 후 리시버 단에서도 rdt_rcv를 기다리는 state가 연속되는 것입니다.

 

 

2) rdt 2.0

신뢰성 있지 않은 채널에 bit error만 발생하는 케이스 입니다. bit error는 아래 채널이 flip bits를 발생시킬 수 있다는 것을 의미합니다. (0->1 , 1->0) 때문에 이것을 체크하기 위해서 checksum을 활용합니다. 그렇다면, 이 에러를 어떻게 복구할 수 있는 방법이 있을까요?

우리는 사람과 대화할 때도 알아듣지 못하는 경우 다시 알려달라고 요청합니다. 

 

1) acknowledgements

OK와 같이 긍정 피드백을 acknowledgements(ACKs)라고 합니다. sender에게 너가 보낸 패킷을 제대로 받았다라고 알려주자는 것입니다. 리시버는 안심할 수 있는 것이죠.

 

2) negative acknowledgements

SORRY?와 같이 부정 피드백을 negative acknowledgements(NACKs)라고 합니다. 패킷이 에러가 발생했다고 리시버가 확실하게 알려주자는 것입니다. 그럼 sender는 retransmits를 하게 됩니다. 

 

종합적으로 버전2.0에선 다음과같은 메카니즘이 필요합니다.

- error detection

- feedback (ACK,NAK)

- retransmission(재전송)

자세한 원리는 아래와 같습니다.

 

3) rdt 3.0

신뢰성 낮은 채널에서 error와 loss가 발생하는 케이스 입니다. 이를 해결하기 위해 data와 ACK을 활용할 겁니다. 

 

패킷 로스가 발생하게 된다면 문제점이 리시버는 데이터를 받지 못합니다. 즉, 피드백 메세지를 보낼 수 없습니다. sender 입장에선 무한정 기다려야 합니다. 이에 대한 아이디어로 타이머를 쓰기로 합니다.

 

리시버가 데이터를 잘 받았다면, ACK을 보내줄 겁니다. 데이터를 못받았다면 피드백을 보내지 않을 겁니다. 때문에 sender는 일정시간 내 피드백이 오지 않으면, data loss라고 판단합니다. 그 후 retransmission을 하게 됩니다.

 

 

---

9일차 마지막 내용까지 정리 완료!