4. Reliable Data Transfer in TCP - TCP에서의 신뢰성 있는 데이터 전송

 

 

▶ Reliable Data Transfer(신뢰성 있는 데이터 전송, 이하 RDT)

 

- 현재까지 송수신간의 신뢰성 있는 데이터 전송 프로토콜을 개발해왔고, 단계적으로 그 과정을 살펴볼 것이다.

 

- 단방향 데이터 전송만을 고려해왔으나 제어 정보는 양방향으로 전송한다.

 

- RDT에서는 송신자와 수신자를 명시하기 위해 유한 상태 머신(Finite State Machines, FSM)을 사용한다.

 

[FSM]

 

 

 

▶ RDT 1.0

 

- 신뢰성 있는(오류 없는) 채널에서 신뢰적인 데이터 전송

 

- 하위 채널에 비트 오류가 없고 패킷(3계층 데이터 단위)의 손실이 없다.

 

- 송신자와 수신자가 분리된 유한 상태 머신을 가지고 있다.

 

- 송신자가 데이터에 헤더를 씌워 패킷으로 만들어 하위 채널로 데이터(패킷)를 전송하면, 수신자는 하위채널로부터 데이터를 받는다.

 

[ 각 2개의 상태를 가지고 있음 ] 

 

 

▶ RDT 2.0

 

- 하위 채널이 패킷에 비트 오류를 일으킬 가능성이 있다.

 

- 해결책으로 헤더에 설정한 체크섬(Checksum)을 통해 오류를 검출한다.

 

- RDT 1.0의 오류복구 기능 : 수신자의 피드백 ACK, NAK

• Acknowledgements (ACK) : 수신자가 송신자에게 “패킷이 잘 도착했음.“을 알리는 방식으로 송신자는 수신자로부터 ACK를 받으면 다음 패킷을 전송한다.
• Negative Acknowledgements (NAK) : 수신자가 송신자에게 “패킷에 오류가 발생했음.“을 알리는 방식으로 송신자는 NAK를 받는 즉시 오류 패킷을 재전송한다.

- 문제점 : ACK/NAK에서도 오류가 발생할 수 있다.

• 수신측이 보낸 ACK/NAK에 오류가 발생하여 송신측이 계속 기다리게 된다.
• 송신측에서 오류가 났는지 모르고 있으며, 패킷을 재전송할 수 없다.
• 송신측에서 중복패킷을 전송할 경우 수신측은 중복수신을 하게 된다.
• 즉, 비효율적인 링크 사용이 증가한다.

 

 

 

▶ RDT 2.1

 

- RDT 2.0의 해결책 : 각각의 패킷에 순서번호(Seq#)를 추가한다. 그러면 수신측에서 순서번호가 같은 패킷(중복패킷)을 버리게 되므로 중복수신이 방지된다.

 

- 송신자의 입장

• 패킷에 순서번호(0, 1) 추가 : 패킷은 0번->1번->0번->1번의 순서를 가진다. 즉, 0과 1의 상태로 기억된다.
• 수신된 ACK/NAK의 오류 여부에 대한 상태가 추가되어 RDT 2.0보다 상태 수가 2배 증가하므로 총 4개의 상태를 가진다.

- 수신자의 입장

• 순서번호로 중복 패킷의 유무를 조사한다.
• 마지막으로 보낸 ACK/NAK가 송신측에서 제대로 받았는지 알지 못한다.

 

 

 

▶ RDT 2.2

 

- NAK가 없는 채널에서의 신뢰적인 데이터 전송

 

- NAK가 없다는 점을 제외하고 RDT 2.1의 기능과 같다.

 

- 수신자는 마지막에 올바르게 수신된 패킷의 ACK를 송신자에게 전송한다.

 

- ACK에는 패킷의 순서번호가 포함된다.

 

- 송신자가 중복된(동일한 순서번호의) ACK를 받을 경우 현재 패킷을 재전송한다.(NAK를 받았을 때와 같은 동작)

ex) 송신측에서 ACK 0번을 기다리는데 ACK 1이 올 경우 순서번호 0번의 데이터를 재전송한다. 그 이유는 1번 데이터는 받았으나 0번 데이터를 못받았기 때문이다.

RDT 2.0	RDT 2.1
성공수신 -> ACK 중복수신 or 수신실패 -> NAK	성공수신 or 중복수신 -> ACK

▶ RDT 3.0

 

- 하위 채널에서의 패킷들(데이터, ACK)의 손실을 고려하였으며, 체크섬 ,순서번호, 재전송 모두 도움은 되나 근본적인 해결이 충분치 않다고 판단

 

- 카운트다운 타이머

• ACK를 계속 기다리는 것이 비효율적이므로 송신자가 ACK에 대해 충분한 시간을 갖고 기다린다. 
• 그러나 해당 타이머 안에 못 받으면(타임아웃되면) 해당 순서번호의 패킷을 재전송한다.
• 단, 패킷이 손실되지 않고 지연되어 송신측이 똑같은 패킷을 재전송하면 중복패킷이 되나 순서번호로 이 문제를 해결할 수 있다. 순서번호가 같으면 수신측에서 드랍하기 때문이다.
• 즉, 수신자는 ACK 패킷의 순서 번호를 송신자에게 알려야 한다.

- 네트워크 프로토콜이 물리적 자원의 사용을 제한한다. 따라서 재전송을 원하는 만큼 할 수 없다.

 

- 기능적으로 잘 동작하지만 성능은 만족스럽지 못하다.

 

▶ 파이프라인 프로토콜(Pipelined Protocols)

- 배경 : RDT 3.0의 Stop-and-Wait 방식으로 인해 데이터가 많을 경우 대기 시간때문에 링크가 비효율적이게 사용되는 것의 해결책으로 나옴

- 송신자가 ACK의 응답을 받지 않고 다수의 패킷을 전송 (링크의 효율성 증가)

(즉, 송신자는 파이프라인에 최대 N개까지 ACK받지 못한 패킷들을 전송 가능)

- 순서번호 증가, 송신자와 수신자 사이에 패킷을 버퍼링해야함.

- GBN(Go-Back-N)

• 수신자는 누적된(cumulative) ACK만 전송 (수신된 패킷들의 순서번호 사이에 갭이 있으면 ACK는 응답하지 않음)
• 수신자는 비순차(out of order) 패킷으로 버퍼링하지 않는다.
• 송신자는 ACK받지 못한(문제가 생긴) 가장 오래된 패킷부터 모두 재전송 (타이머가 1개)

- Selective Repeat(선택적 반복)

• 수신된 패킷들 사이에 갭이 있더라도 갭 이후의 패킷들을 수신측에 있는 버퍼에 저장
• 즉, 수신자는 모든 패킷들에 대해 개별적으로 ACK 응답
• 상위 게층에 순차적으로 전달하기 위해 비순차 패킷들을 버퍼에 저장
• 비순차 패킷 -> 순차적으로 정렬 -> 상위 게층으로 전달
• 송신자는 개별 패킷마다 타이머를 가지고 있다.
• 문제가 생긴 패킷만 개별적으로 재전송

- TCP는 위 두개의 경우가 하이브리드된 형태로 사용한다.