TCP가 윗단의 어플리케이션에게 제공하는 서비스는 신뢰적인 데이터 전송의 채널을 만들어 주는 것이다. 신뢰적인 채널에서는 전송된 데이터가 손상되거나, 손실되지 않는다(0에서 1로, 혹은 1에서 0으로 바뀌지 않음). 그리고 모든 데이터는 전송된 순서대로 전달된다.
이러한 서비스 추상화를 구현하는 것은 신뢰적인 데이터 전송 프로토콜(reliable data transfer protocol)의 의무이다. 하지만 TCP 아래의 계층들의 신뢰성이 떨어져 이 작업이 어려워진다.
신뢰적인 데이터 전송 프로토콜의 송신자 측면과 수신자 측면을 점진적으로 개발해 나가자. 하부 채널에서는 패킷의 순서를 바꾸지 않는다고 가정한다.
위의 그림은 데이터 전송 프로토콜에 대한 인터페이스를 나타낸다. 송신측은 rdt_send()호출에 의해서 위쪽으로부터 호출될 것이다. 수신측에서는 상위 계층으로 전달될 데이터를 넘긴다. (rdt는 reliable data transfer 프로토콜을 의미하고, _send 는 송신 측이 호출된다는 것을 의미한다.) 수신 측에서 rdt_rcv()는 패킷이 태널의 수신측으로 도착했을 때 호출된다. rdt 프로토콜이 상위 계층에 데이터를 전달하려고 할 때 deliver_data()를 호출한다. udt_send()를 호출함으로써 다른 쪽에 패킷을 전송한다. (udt; unreliable data transfer)
완전한 신뢰적 데이터 전송 프로토콜에 도달하기 위해 조금씩 더 복잡해지는 일련의 프로토콜들을 알아보자.
완벽하게 신뢰적인 채널 상에서의 신뢰적인 데이터 전송 : rdt1.0
*점선으로 된 화살표가 FSM의 초기 상태이다.
*이벤트 발생 시 어떠한 행동도 취해지지 않거나 어떠한 이벤트 발생 없이 행동이 취해질 때, 동작이나 이벤트가 없음을 명확히 표시하기 위해 각각 평행성 아래나 또는 위에 뒤집어진 V모양 표시를 한다.
송신자: 위에서부터 데이터를 기다리다가 도착하면 패킷을 생성한다. 패킷을 밑의 채널로 전송한다.
수신자: 밑에서부터 패킷을 받고, 받은 패킷을 상위 계층으로 전달한다.
이처럼 완전히 신뢰적인 채널에서는 오류가 생길 수 없으므로 수신측이 송신측에게 어떠한 피드백도 제공할 필요가 없다.
비트 오류가 있는 채널상에서의 신뢰적 데이터 전송: rdt2.0
비트 오류는 패킷이 전송 또는 전파되거나 버퍼링될때 네트워크의 물리적 구성요소에서 일반적으로 발생한다. 전송된 모든 패킷들이 송신된 순서대로(비록 패킷이 손상되었다 하더라도) 수신된다고 가정한다.
사람들이 서로 전화를 할때 잘 듣지 못한 말에 대해서 "뭐라고?"라며 다시 물어보는 것에서 아이디어를 착안한다.
수신자 측에서 잘 들었을 경우는 positive acknowledgement (ACK)를, 잘 듣지 못했을 경우 negative acknoledgement(NAK) 를 보낸다. 만약 잘 듣지 못했다는 NAK가 도착하면 패킷을 재전송한다.
이렇듯 재전송을 기반으로 하는 신뢰적인 데이터 전송 프로토콜은 자동 재전송 요구(Automatic Repeat reQuest, ARQ)프로토콜로 알려져 있다.
비트 오류를 처리하기 위해서 기본적으로 다음과 같은 세 가지 부가 프로토콜 기능들이 ARQ프로토콜에 요구된다.
1. 오류 검출 : 데이터 패킷의 체크섬 필드
2. 수신자 피드백 : ACK, NAK
3. 재전송
송신자는 패킷 체크섬과 함께 전송될 데이터를 포함하는 패킷 (sndpkt) 을 생성하고, 그 패킷을 send 동작을 통해 보낸다. 보낸 후 송신자는 수신자로부터 응답을 기다리는 상태가 된다. 응답을 받기 전까지는 이전의 상태(위에서부터 데이터를 기다리는 상태)로 돌아가지 않는다 (전송 후 대기 stop and wait 프로토콜로 알려져 있다). 만약 수신자로부터 NAK를 받으면 패킷을 재전송한다.
수신자는 송신자로부터 패킷을 기다리다가, 오류검출을 한 후에 ACK혹은 NAK로 응답을 보내준다.
rdt2.0의 치명적인 오류는 ACK혹은 NAK가 손상될 수 있다는 가능성을 고려하지 않았다는 것이다. 손상된 응답을 회복하는 방법으로는 송신된 데이터 패킷을 재전송 하는 방법이 있으나, 단순히 재전송을 하면 수신자 채널로 중복 패킷을 전송할 우려가 있다. 뿐만 아니라 마지막으로 전송된 ACK혹은 NAK가 송신자에게 정확히 수신되었는지 수신자는 전혀 알 방법이 없으므로 현재 들어오는 패킷이 재전송인지 사전에 알 방법이 없다.
이 문제는 데이터 패킷에 새로운 필드를 추가해 이 필드에 순서번호(sequence number)를 삽입함으로써 해결할 수 있다. 수신자는 수신된 패킷이 재전송인지 결정할 때는 이 순서번호만 확인하면 된다.
rdt2.1 은 위의 사항들을 고려해 수정된 버전이다.
위의 ACK와 NAK의 번거로움을 줄이기 위해 수정한 버전이 rdt2.2 이다. 이 버전에서는 NAK대신 ACK와 함께 가장 최근에 들어온 패킷의 순서번호를 부착한다. 만약 ACK0 가 송신자에게 전달되면, 송신자는 그 다음 패킷 (순서번호 1)을 전달할 준비를 한다.
비트 오류와 손실있는 채널 상에서의 신뢰적 데이터 전송 : rdt3.0
비트가 손상되는 것 외에도 하위 채널이 패킷을 손실(Loss) 하는 경우를 생각해보자.
* 어떻게 패킷 손실을 검출할 것인가?
* 패킷 손실이 발생했을 때 어떤 행동을 할 것인가? 를 고려해야 한다.
패킷 손실을 다루는 방법에는 다양한 접근이 가능하나, 여기서는 송신자에게 손실의 책임을 부여한다. 송신자가 패킷을 전송했으나 송신한 패킷, 또는 수신된 패킷에 대한 ACK응답을 손실했다고 가정하자. 어느 경우에나 송신자에게는 어떠한 응답도 없다. 만약 송신자가 패킷을 잃어버렸다는 것을 확신할 정도로 충분한 시간을 기다릴 수만 있다면, 데이터 패킷은 간단하게 재전송될 수 있다.
만일 패킷이 유별나게 큰 지연을 가진다면 송신자는 비록 데이터 패킷이나 그 패킷에 대한 ACK가 손실되지 않았더라도 패킷을 재전송할 수 있다. 송신자의 관점에서 재전송은 만병통치약과 같다.
시간 기반의 재전송 매커니즘을 구현하기 위해 주어진 시간이 경과된 후에 송신자를 인터럽트할 수 있는 카운트다운 타이머가 필요하다. 그러므로 송신자는 다음처럼 동작해야 한다.
1. 매 패킷이 송신된 시간에 타이머를 시작함.
2. 타이머 인터럽트에 반응함.
3. 타이머를 멈춤
패킷의 순서번호가 0과 1이 번갈아 일어나므로, 프로토콜 rdt3.0은 때때로 얼터네이팅 비트 프로토콜(alternating bit protocol)이라고 부른다.
'Computer Network' 카테고리의 다른 글
| [Lecture 7, 8] TCP Service (0) | 2020.07.15 |
|---|---|
| [Lecture 6] RDT : Pipelined Protocols (0) | 2020.07.03 |
| CS144 : Lab 프로젝트 (Github Repository) (0) | 2020.07.01 |
| [Lecture 4-2] Transport Layer (1) : Overview & UDP (0) | 2020.06.29 |
| [Lecture 4-1] Application Layer 마무리 : Mail Server (0) | 2020.06.27 |