컴퓨터 네트워크 Week 10-1-2 : reliable data transfer

Principles of reliable data transfer

#  두 host는 packet이 손실되었거나 손상된 경우 신경쓰지 않는다. --> transport layer이 처리한다.

# application layer은 신뢰할 수 있는 채널이다. 사실 신뢰할 수 있는 채널이 아니다

# transport layer에서 수행되는 모든 모든 일을 숨긴다.(데이터 복구, 데이터 재전송)

 

# 데이터가 확인되지 않는 한 데이터를 다시 보내야하고

# 이 두 host사이에 channel이 noisy가 많지 않으면 transport layer는 덜 작동하므로 복잡성은 줄어든다.

--> transport layer의 복잡성은 unreliable channel의 특성에 의존한다.

# 두 host는 여러 physical link로 구성되어 있다. 

# 발신자와 수신자를 같이 보는게 좋다

# 둘 다 다른 쪽에서 무슨 일이 일어나고 있는지 모릅니다. --> message를 통해서만 알 수 있다.

                                                                                (잘 전달 됐는지 , 손상되어 전달 됐는지)

Reliable data transfer protocol (rdt): interfaces

# 파이썬뿐만 아니라 자바에서도 의미는 동일합니다.

 

# rdt : reliable data transfer / udt : unreliable data transfer

 

# trasport layer에서 application layer로 데이터 전달.

# 정상 작동하고 신뢰할 수없는 데이터가 있습니다. --> 단일 시스템 내에서 전송이 발생 --> 손상 없음

 

# 신뢰할 수없는 채널로 데이터를 전송하고

 

# 다른 쪽에서는 신뢰할 수있는 데이터 전송 수신을 받으면 자동으로 호출된다

 

# checksum하고 오류가 발생하지 않으면 호출됩니다.

 

# 양방향이다.

Reliable data transfer: getting started

우리는 : 
▪ 신뢰할 수있는 데이터 전송 프로토콜 (rdt)의 발신자, 수신자 측 점진적 개발 
▪ 단방향 데이터 전송만 고려 
   • 그러나 제어 정보는 양방향으로 흐릅니다! 
▪ FSM (Finite State Machine)을 사용하여 발신자, 수신자 지정

# 단계적으로 더 복잡하지만 더 효율적인 솔루션으로 안정적으로 데이터 전달을 위해 FSM을 사용한다.

FSM

- 한번의 하나의 상태를 가지며, 현재 상태란 임의의 주어진 시간의 상태를 칭한다

- 어떠한 사건에 의  한 상태에서 다른 상태로 변화할 수 있으며 이를 전이(transition)라 한다.

 

- 시스템이 신뢰할 수 있는 데이터 전송인경우 FSM이 시스템을 대표한다는 것을 의미합니다.

- 프로토콜을 정의하거나 설명할 수 있다.

- 자신의 프로토콜을 자세히 텍스트로 설명한다.  그런데 이것을 다른 host가 다르게 해석할 수 있다.

- 그것보다 많지 않은 2 개의 3 개의 4 개의 상태를 가질 수 있습니다

송신자, 수신자의 동작을 정의한다.

rdt1.0: reliable transfer over a reliable channel

rdt1.0 하위 채널이 완전히 신뢰적인 가장 간단한 경우

▪ 완벽하게 신뢰할 수있는 기본 채널 
   • 비트 오류 없음 
   • 패킷 손실 없음

▪ 발신자, 수신자를 위한 별도의 FSM : 
   • 보낸 사람이 데이터를 기본 채널로 보냅니다. 
   • 수신기는 기본 채널에서 데이터를 읽습니다.

   # 서로 의사소통할 필요가 없기 때문에

   # 송신자는 데이터를 아래 채널로 보내고 수신자는 데이터를 읽습니다

# rdt_send 이벤트가 발생하면 우리는 이 데이터를 기반으로 패킷을 만들고 make_pkt 보낸다. udt_send

# 발신자와 수신자 간의 채널이 안정적이므로 패킷손실이 없다

# 수신자 측에서 이 rdt_rcv 이벤트는 패킷을 수신(추출)한다. extract 그리고 패킷을 application layer에 전달 deliver_data

rdt2.0: channel with bit errors

▪ 아래 채널은 패킷의 bit를 뒤집을 수 있습니다. 
   • 비트 오류 감지를위한 checksum (예 : 인터넷 checksum )

 

#0101010... 의 스트림으로 전달 되고 중간에 하나정도 0에서 1로 변할 수 있다. checksum으로 확인한다

▪ 질문 : 오류로부터 복구하는 방법?

                  인간은 대화 중에 "오류"에서 어떻게 회복합니까?

     • acknowledgements승인 (ACK) : 수신자가 송신자에게 pkt가 OK를 수신했음을 명시적으로 알립니다. 
     • negative acknowledgements 부정 승인 (NAK) : 수신자가 송신자에게 pkt에 오류가 있음을 명시적으로 알립니다. 
     • 보낸 사람이 NAK를 받으면 pkt를 재전송합니다.

수신자와 송신자는 서로의 상태를 모른다.

 

stop and wait

보낸 사람이 하나의 패킷을 보낸 다음 수신자 응답을 기다립니다.

rdt2.0: FSM specifications

# A의 상태가 되면 정상적으로 전송이 되었으므로 다음 패킷을 보낸다.

# NAK이면 재전송

 

# corrupt 발생하면 sender에게 nak신호 보낸다

# 정상이면 데이터 추출하고 전송해서 ack을 보낸다

rdt2.0: operation with no errors

rdt2.0: corrupted packet scenario

rdt2.0 has a fatal flaw!

ACK / NAK가 손상되면 어떻게됩니까? 
▪ 발신자는 수신자에게 무슨 일이 일어 났는지 모릅니다! 
▪ 재전송 만 할 수 없음 : 중복 가능성

 

중복 처리 : 
▪ 발신자는 ACK / NAK가 손상된 경우 현재 패킷을 재전송합니다. 
▪ 발신자는 각 패키지에 순서 번호를 추가합니다. 
▪ 수신자가 중복 패키지 삭제 (전달하지 않음)

 

stop and wait

보낸 사람이 하나의 패킷을 보낸 다음 수신자 응답을 기다립니다.

rdt2.1: sender, handling garbled ACK/NAKs

# 보낼 때 패킷에 번호를 매길 것임을 의미합니다.

#  첫 번째 패킷에 다음 sequence 번호를 0으로 설정하고 패킷을 보냅니다.

-->  패킷이 올바르게 도착하면 sequence 번호 1

--> 다음 패킷에 0을 넣어서   01010101 ...

 

# application layer에서 0 or 1을 가진 packet을 기다린다 --> 0 or 1을 넣어서 보낸다.

# 받았다 망가지 않았다. ack을 받았다 --> 다음 1 or 0을 application layer에서 오길 기다린다

# 받았다 망가졌다. nak을 받았다 --> 재전송

rdt2.1: receiver, handling garbled ACK/NAKs

# 받았다 망가졌다

# 받았다 망가지지 않았지만 내가 원하는 0 or 1이 아니다

# 받았다 망가지지 않았다 내가 원한는 0 or 1이다.

rdt2.1: discussion

sender: 

▪ seq # pkt에 추가됨 

▪ two seq. #s (0,1)이면 충분합니다. 왜? 0이냐 1이냐로 충분하다

▪ 수신 된 ACK / NAK가 손상되었는지 확인해야합니다.

 ▪ 두 배 많은 상태 

    • 상태는 "예상 된"pkt가 시퀀스 번호 0 또는 1을 가져야하는지 여부를 "기억"해야합니다.

receiver:

▪ 수신 된 패킷이 중복되었는지 확인해야합니다.

    • 상태는 예상되는 0 또는 1인지 여부를 나타냅니다. pkt seq #

▪ 참고 : 수신자는 마지막 ACK / NAK가 발신자에서 OK를 수신했는지 알 수 없습니다.

rdt2.2: a NAK-free protocol

▪ ACK 만 사용하는 rdt2.1과 동일한 기능
▪ NAK 대신 수신자는 OK를 수신한 마지막 pkt에 대해 ACK를 보냅니다.
       • 수신자는 ACK되는 pkt의 시퀀스 번호를 명시적으로 포함해야합니다.
▪ 발신자에서 중복 ACK 결과 NAK와 동일한 동작이 발생합니다.
       현재 pkt 재전송

앞으로 보게 될 TCP는이 접근 방식을 사용하여 NAK가 없습니다.

# 내가 받은 마지막 ack이 무엇인지 전달해서 정상을 표시한다.

# sender가 1을 보냈다 --> 손상됨 --> receiver는 손상된걸 보고 마지막으로 받은 0을 보낸다 --> sender는 0을 받고 1이 망가진 것을 확인하고 --> 1을 다시 보낸다.

# 이전의 receiver는 0,1을 포함하지 않았지만 nak을 포함했다.

rdt2.2: sender, receiver fragments

rdt3.0: channels with errors and loss

 

새로운 채널 가정 : 기본 채널도 패킷 (데이터, ACK)을 잃을 수 있습니다. 

      • checksum, sequence번호, ACK, 재전송이 도움이 될 수 있지만 충분하지는 않습니다. 

# 효율적이지 않다. 데이터를 안정적으로 전송하는 것에 대해서는 잘 작동한다.

Q : 대화에서 손실된 발신자-수신자 단어를 어떻게 처리합니까?

 

Approach : 발신자는 ACK를 위해“합리적인”시간을 기다립니다. 

  ▪이 시간에 수신 된 ACK가 없으면 재전송합니다. 

  ▪ pkt (또는 ACK)가 방금 지연된 경우 (손실되지 않음) : 

     • 재전송은 중복되지만 seq #s는 이미 이것을 처리합니다! 

     • 수신자는 ACK 된 패킷의 시퀀스 번호를 지정해야합니다. 타임 아웃 

# 기간 내에 프레임이 도착하지 않았으므로 발신자 또는 수신자 둘 다 패킷이 손실 된 것으로 간주합니다.

# 실제로는 손실이 아니고 지연이다.

# 지연은 다른 패킷이 가질 수 있다.

# 지연이 발생하는 여러 가지 이유는 전송 지연, 전파 지연, 버퍼 지연, 각 패키지 마다 다른 유형의 지연이 있을 수 있다.

# 5초라고 정하고 5.5초에 도착했을 때 이미 5초에 재전송 요청을 했지만 sequence 숫자로 중복 패킷을 처리할 수 있다.

# 시간은 RTT(왕복 시간)을 기준으로 한다.

 

  ▪“합리적인”시간이 지난 후 중단하려면 카운트 다운 타이머를 사용합니다.

# handshake 당시 계산했을 수있는 초기 RTT를 기준으로 하고 채널 상태 또는 연결 상태로 시간 결정

# 두 호스트 간의 논리적 링크 조건은 동일하게 유지됩니다. 일부 흐름 제어를 기반으로 계산 시간은 변한다.

rdt3.0 sender

# 2.1과 2.2와 동일한 수의 상태가 있다.

# 타이머를 포함한다.

 

# timer의 응답에 따라 데이터 전송 및 수신 속도를 조정할 수 있습니다. (일종의 알고리즘 사용)

-> 네트워크 혼잡 제어(회복하는데 도움이 된다.)

# 잘못된 sequence 번호나 ack이 잘못된 경우 더 기다리지 않고 재전송한다.

# 이전의 전송이 성공해서 다음 상위에서 다음 패킷을 기다릴 때 응답이 오면 무시한다.

rdt3.0 in action

 

 

성능관점에서 rdt 3.0은 좋은 선택이 아니다.

성능을 개선해야한다. 발신자와 수신자 간의 자원 활용도를 우선적으로 정의합니다.