[네트워크] 3.4 신뢰적인 데이터 전송의 원리

3.4.1 신뢰적인 데이터 전송 프로토콜의 구축

제공된 서비스 --> 서비스 구현

▶ 신뢰적인 데이터 전송 프로토콜(reliable data transfer protocol): 서비스 추상화를 구현하는 것

• 단방향 데이터 전송(unidirectional data transfer)
• 양방향(전이중) 데이터 전송(bidirectional data transfer)

 

 

3.4.2 파이프라이닝된 신뢰적인 데이터 전송 프로토콜

완벽하게 신뢰적인 채널상에서의 신뢰적인 데이터 전송: rdt1.0

• 송신 측: 상위로부터의 호출을 기다림
• 수신 측: 하위로부터의 호출을 기다림

이러한 간단한 프로토콜에서는 데이터 단위와 패킷의 차이점이 없다. 모든 패킷의 흐름은 송신자로부터 수신자까지다. 즉, 완전히 신뢰적인 채널에서는 오류가 생길 수 없으므로 수신 측이 송신 측에게 어떤 피드백도 제공할 필요가 없다. 또한 수신자는 송신자가 데이터를 송신하자마자 데이터를 수신할 수 있다고 가정했음을 유념해야 한다. 따라서 수신자가 송신자에게 천천히 보내라는 것을 요청할 필요가 없다.

 

비트 오류가 있는 채널상에서의 신뢰적 데이터 전송: rdt2.0

▶ 자동 재전송 요구(Automatic Repeat reQuest, ARQ) 프로토콜

• 송신 측: 상위로부터의 호출을 기다림 --> ACK, NAK 응답을 기다림
  - ACK: 긍정 확인 응답 "OK"
  - NAK: 부정 확인 응답 "그것을 반복해주세요"
• 수신 측: 하위로부터의 호출을 기다림

- 오류 검출: 체크섬 필드 --> 수신자가 패킷 비트 오류를 검출하고 복구할 수 있게 해준다.

- 수신자 피드백: ACK, NAK

- 재전송: 수신자에서 오류를 가지고 수신된 패킷은 송신자에의해 재전송된다.

 

▶ 전송 후 대기(stop-and-wait) 프로토콜

: 송신자 프로토콜은 수신자로부터 ACK, NAK 패킷을 기다린다. 송신자가 ACK 또는 NAK를 기다리는 상태에 있을 때, 상위 계층으로부터 더 이상의 데이터를 전달받을 수 없다.

 

▷ Problem: ACK, NAK 패킷이 손상될 수 있다.

▷ Solution: 데이터 패킷에 순서 번호(sequence number) 필드를 추가하여 데이터 패킷에 송신자 번호를 붙인다.

 

비트 오류와 손실 있는 채널상에서의 신뢰적인 데이터 전송: rdt3.0

: 비트가 손상되는 것 외에도, 하위 채널이 패킷을 손실하는 경우

 

송신자가 데이터 패킷을 전송하고, 패킷 또는 수신자가 패킷에 대한 ACK를 손실했다고 가정하자. 어느 경우에서나 송신자에게 수산자로부터 어떠한 응답도 없다. 만약 송신자가 패킷을 잃어버렸다고 확신할 정도로 충분한 시간을 기다릴 수만 있다면, 데이터 패킷은 간단하게 전송될 수 있다.

• 송신자가 어떤 패킷을 손실했다는 것을 확신하기 위해 얼마나 오랫동안 기다려야 할까?
  : 송신자와 수신자 사이의 왕복 시간 지연(중간 라우터에서의 버퍼링 포함) + 수신 측에서 패킷을 처리하는 데 필요한 시간

실제 상황에서 채택한 접근 방식은 송신자가 패킷 손실이 일어났다는 보장은 없지만 손실이 일어났을 만한 그런 시간을 현명하게 선택하는 것이다. 만약 ACK가 이 시간 안에 수신되지 않는다면 패킷은 재전송된다.

만일 패킷이 유별나게 큰 지연을 갖는다면, 송신자는 비록 데이터 패킷이나 그 패킷에 대한 ACK가 손실되지는 않았다고 하더라도 패킷을 재전송할 수 있다. 이것은 송신자 대 수신자 채널에서 중복 데이터 패킷(duplicate data packet)의 가능성을 포함한다.

1. 매 캐싯이 송신된 시간에 타이머를 시작한다.
2. 타이머 인터럽트에 반응한다.
3. 타이머를 멈춘다.

 

 

3.4.2 파이프라이닝된 신뢰적인 데이터 전송 프로토콜

▷ Problem: rdt3.0의 핵심적인 성능 문제는 rdt3.0이 전송 후 대기(stop-and-wait) 프로토콜이라는 점이다. (성능 문제)

▷ Solution: 파이프라이닝 -- 전송 후 대기 방식으로 동작하는 대신에 송신자에게, 확인응답을 기다리지 않고 여러 패킷을 전송하도록 허용한다.

• sequence number의 범위가 커져야 한다.
  왜냐하면 각각의 전송 중인 패킷(재전송은 고려하지 않음)은 유일한 순서 번호를 가져야 하고, 전송 중인 확인 응답(ACK)이 안 된 패킷이 여럿 있을지도 모르기 때문이다.
• 프로토콜의 송신 측과 수신 측은 패킷 하나 이상을 버퍼링해야 한다. 최소한 송신자는 전송되었으나, 확인응답되지 않은 패킷을 버퍼링해야 한다. 정확하게 수신된 패킷의 버퍼링은 수신자에게서도 필요하다.
• 필요한 sequence number의 범위와 버퍼링 조건은 데이터 전송 프로토콜이 손실 패킷과 손실 상 패킷, 그리고 상당히 지연된 패킷들에 대해 응답하는 방식에 달려 있다. 
  파이프라이닝 오류 회복의 두 가지 기본적인 방법으로는 GBN(Go-Back-N,N부터 반복)과 SR(Selective Repeat, 선택적 반복) 등이 있다.

 

 

3.4.3 GBN (Go-Back-N, N부터 반복)

: 송신자는 확인응답을 기다리지 않고 여러 패킷을 전송할 수 있다. 그러나 파이프라인에서 확인응답이 안 된 패킷의 최대 허용 수 N보다 크지 말아야 한다.

▶ 슬라이딩 윈도 프로토콜(sliding-window protocol)

• acknowledgement number: sent, not yet ACKed
• sequence number: usable, but not yet sent

 

 

3.4.4 SR (Selective Repeat, 선택적 반복)

수신자에서 오류가 발생한 패킷을 수신했다고 의심되는 패킷만을 송신자가 다시 전송하므로, 불필요한 전송을 피한다. 

필요에 따라 각각의 개별적인 재전송은 수신자가 올바르게 수신된 패킷에 대한 개별적인 확인응답을 요구할 것이다.