신뢰적인 데이터 전송의 원리

3.4 신뢰적인 데이터 전송의 원리

상위 계층 객체에게 제공되는 서비스 추상화는 데이터가 전송될 수 있는 신뢰적인 채널의 서비스 추상화다.

 

이러한 서비스 추상화를 구현하는 것이 신뢰적인 데이터 전송 프로토콜(reliable data transfer protocol)의 의무다. 이 작업은 신뢰적인 전송 프로토콜의 '아래에 있는' 계층이 신뢰적이지 않을 수 있어서 어려워진다.

 

TCP는 비신뢰적인 종단 간의 네트워크 계층(IP)의 바로 상위에 구현된 신뢰적인 데이터 전송 프로토콜이다.

 

여기서 신뢰적이지 않은 계층 위에 어떻게 신뢰성이 있는 데이터 전송 프로토콜을 개발할 것인지에 대해 알아본다.

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

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

• 비트 에러가 없음.
• 패킷의 손실이 없다.
• 오류가 발생하지 않으므로 수신측이 송신측에 어떤 피드백(feedback)도 제공할 필요가 없다.

비트 오류가 있는 채널상에서 신뢰적 데이터 전송 : rdt 2.0

• 패킷의 손실은 없지만, 비트에러가 발생하는 경우
• 수신자는 제대로된 패킷을 받았다면 긍정 확인응답(positive acknowlegement)를 보내고, 에러가 판별되면 부정 확인응답(negative acknowlegement)를 보낸다.
  • 이러한 제어 메시지는 정확하게 수신되었는지 또는 잘못 수신되어 반복이 필요한지를 수신자가 송신자에게 알려줄 수 있게 한다.

컴퓨터네트워크에서 이러한 재전송을 기반으로하는 신뢰적인 데이터 전송 프로토콜은 자동 재전송 요구(Automatic Repeat reQuest, ARQ) 프로토콜로 알려져 있다.

 

비트 오류를 처리하기 위해 ARQ에 요구되는 기능

• 오류 검출 : 비트 오류가 발생했을 때 수신자가 검출할 수 있는 기능이 필요하다.
• 수신자 피드백 : 송신자가 수신자의 상태(패킷이 정확하게 수신되었는지 아닌지)를 알기 위한 유일한 방법은 수신자가 송신자에게 피드백을 제공하는 것이다.
• 재전송 : 수신자에서 오류를 가지고 수신된 패킷은 송신자에 의해 재전송된다.

위의 FSM 그림에서, 송신자는 수신자가 현재의 패킷을 정확하게 수신했음을 확신하기 전까지(ACK 응답을 받기 전까지) 새로운 데이터를 전송하지 않을 것이다. 이러한 행동 때문에 rdt 2.0과 같은 프로토콜은 전송 후 대기(stop-and-wait) 프로토콜로 알려져 있다.

 

rdt 2.0은 잘 동작하는 것 같지만, 치명적인 결함이 있다. ACK 또는 NAK가 손상될 가능성을 고려하지 않았다. 손상된 ACK 또는 NAK를 처리하기 위한 대안은 다음과 같다.

• 송신자가 검출뿐만 아니라 비트 오류로부터 회복할 수 있도록 충분한 체크섬 비트를 추가하는 것이다.
  • 이 방식은 패킷이 손상될 순 있으나 손실되지는 않는 채널의 경우에 즉각적으로 문제를 해결할 수 있다.
• 송신자가 왜곡된 ACK, 또는 NAK 패킷을 수신할 떄 현재 데이터 패킷을 다시 송신하는 것이다.
  • 중복 패킷(duplicate packet)을 전송하는 문제가 발생한다.
    • 마지막으로 전송된 ACK 또는 NAK가 송신자에게 정확히 수신됐는지 알 수 없다.
    • 따라서 도착하는 패킷이 새로운 데이터를 포함하고 있는 것인지, 아니면 재전송인지 사전에 알 수 없다.

이러한 새로운 문제의 해결책은 데이터 패킷에 새로운 필드를 추가하고 이 필드 안에 순서 번호(sequence number)를 삽입하는 방식으로 데이터 패킷에 송신자가 번호를 붙이는 것이다.

• 수신자는 수신된 패킷이 재전송인지를 결정할 떄는 이 순서 번호만 확인하면 된다.

rdt 2.1

송신자

수신자

 

rdt 2.1은 수신자로부터 송신자까지의 긍정 확인응답과 부정 확인응답을 모두 포함한다.

• 순서가 바뀐 패킷이 수신되면, 수신자는 이미 전에 수신한 패킷에 대한 긍정 확인응답을 전송한다.
• 손상된 패킷이 수신되면, 수신자는 부정 확인응답을 전송한다.

수신자는 가장 최근에 정확하게 수신된 패킷에데 대해 ACK를 송신함으로써 NAK를 송신한 것과 같은 효과를 얻을 수 있다. 같은 패킷에 대해 2개의 ACK를 수신한 송신자는 수신자가 두번 ACK 한 패킷의 다음 패킷을 정확하게 수신하지 못했다는 것을 안다.

 

rdt 2.2에서는 수신자가 ACK 메시지의 의해 확인 응답되는 패킷의 순서 번호를 포함해야 한다. 송신자는 수신된 ACK 메시지에 의해 확인응답된 패킷의 순서 번호를 반드시 검사해야 한다.

 

rdt 2.2

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

이제 패킷의 손실도 발생한다고 가정하자. 그러면 다음과 같은 두 가지 부가 내용을 프로토콜이 다루어야 한다.

• 어떻게 패킷 손실을 검출한 것인가.
• 패킷 손실이 발생했을 때 어떤 행동을 할 것인가.
  • 체크섬, 순서 번호, ACK 패킷, 재전송을 이용하면된다.

패킷 손실을 검출하려면 새로운 프로토콜 메커니즘을 추가해야 한다.

• 송신자는 ACK 응답을 받기 위해 기다린다.
• 만약 특정 시간동안 ACK 응답을 받지 못하면 패킷을 재전송한다.
  • 송신자는 데이터 패킷이 손실되었는지, ACK가 손실 되었는지, 패킷 또는 ACK가 단순히 지연된 것인지를 알지 못한다.
  • 재전송은 중복된 패킷을 전송할 수 있지만, sequence number로 처리한다.
• 시간 기반의 재전송 메커니즘을 구현하기 위해, 주어진 시간이 지난 후에 송신자를 인터럽트(중단)할 수 있는 카운트다운 타이머(countedown timer)가 필요하다.

타이머가 추가됨

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

프로토콜 rdt 3.0은 기능적으로 정확하지만 성능적으로는 만족하지 못한다.

rdt 3.0은 전송 후 대기(stop-and-wait)하는 프로토콜이다.

• 확인 응답을 받은 후 데이터를 전송한다.
• 전송 후 대기는 이용률이 좋지 않다.(밑의 그림 참고)

확인 응답을 받지 않고 여러 패킷을 전송하면 낮은 이용률을 개선할 수 있다.

이와 같은 기술을 파이프라이닝(pipelining)이라고 부른다.

 

파이프라이닝을 사용할 때 고려해야 할 사항

• 순서 번호의 범위가 커져야 한다. 각각의 전송 중인 패킷은 유일한 순서 번호를 가져야 하고 전송 중인 확인응답(ACK)이 안된 패킷이 여럿 있을 수 있다.
• 프로토콜의 송신 측과 수신 측은 패킷 하나 이상을 버퍼링해야 한다. 최소한 송신자는 전송되었으나 확인응답되지 않은 패킷을 버퍼링해야 한다.
• 필요한 순서 번호의 범위와 버퍼링 조건은 데이터 전송 프로토콜이 손실 패킷과 손상 패킷 그리고 상당히 지연된 패킷들에 대해 응답하는 방식에 달려 있다.
  • GBN(Go-Back-N) : N 부터 반복
  • SR(Selective Repeat) : 선택적 반복

3.4.3 GBN

GBN(Go-Back-N) 프로토콜에서 송신자는 확인응답을 기다리지 않고 여러 패킷을 전송(가능할 때)할 수 있다. 그러나 파이프라인에서 확인응답이 안된 패킷의 최대 허용 수 N보다 크지 말아야 한다.

• already ack'ed
  • 이미 확인 응답이 됨
• usable, not yet send
  • 사용가능하지만 전송이 안됨
• sent, not yet ack'ed
  • 전송은 되었지만, 응답이 없음
• not usable
  • 사용할 수 없음

프로토콜이 동작할때, N인 윈도는 오른쪽으로 이동한다. N을 윈도 크기(window size)라고 부르며, GBN 프로토콜을 슬라이딩 윈도 프로토콜(sliding-window protocol)이라고 부른다.

• ACK(n)을 받으면 윈도우는 n+1으로 이동한다.

타임아웃이 발생하면 송신자는 이전에 전송되었지만 아직 확인응답되지 않은 모든 패킷을 다시 송신한다.

 

GBN 프로토콜에서는 수신자는 순서가 잘못된 패킷들을 버린다.

• n번째 패킷전에 n+1번째 패킷이 도착하면 n+1번째 패킷을 버린다.
• n번째 패킷이 손실된다면 송신자는 n, n+1 번째 패킷을 다시 전송한다.
• 수신자의 버퍼는 단순해진다.(다음 순서의 패킷 순서만 알면 된다.)

3.4.4 SR

GBN은 패킷 하나의 오류가 발생하면, 많은 패킷을 재전송하므로 불필요한 전송이 일어나게 된다. SR(Selective Repeat) 프로토콜은 수신자에게 오류가 발생한 패킷을 수신했다고 의심되는 패킷만을 송신자가 다시 전송한다.

SR에서는 수신자가 현재의 윈도 base보다 작은 특정 순서 번호를 가진 이미 수신된 패킷을 무시하지 않고 재확인 응답을 하는 것이 중요하다.

• 재확인 응답을 하지 않는다면 송신자의 send_base는 오른쪽으로 이동하지 않을 것이다.

SR의 동작

수신버퍼는 0번,1번 패킷을 받으면 수신 윈도우 시작점을 2로 옮긴다. 패킷 2번이 손실되었지만 3번, 4번, 5번 패킷을 받았으므로 수신 윈도우는 2 3 4 5에 위치할 것이다. 만약 2번 패킷을 받았다면 수신 윈도우는 6 7 8 9로 옮겨질 것이다.

 

SR의 딜레마

수신자는 송신자의 행동을 볼 수 없다. 수신자는 송신자가 보낸 0번 패킷이 새로운 패킷인지, 아니면 재전송되는 패킷인지 구분할 수 없다.

• 순서 번호보다 윈도 크기가 절반보다 작거나 같으면 해결이 가능하다.

윈도 크기가 절반보다 작으면 잘못된 패킷은 버린다.