나만의 코딩기록

3.4 rdt 원리

TCP 프로토콜은 신뢰적인 데이터 전송 rdt(reliable data transfer) 를 지원한다.

rdt 를 보장하기 위해 필요한건 다음과 같으며 순서대로 설명해보겠다.

1. error detection
2. feedback
3. sequence number
4. timer

TCP 의 세그먼트는 사실 트랜스포트 계층 이외도 전송계층, 링크계층, 물리계층을 모두 타고 이동하여 상대방에게 전송된다.

즉 트랜스포트 계층 이외 계층을 통해 데이터가 전송될때도 TCP 의 rdt 가 지켜지기 위해 TCP는 여러 헤더를 사용한다.

데이터는 여러 라우터를 거쳐 상대의 종단 시스템에 도착할 것이다. 이때 발생할수 있는 문제(rdt 를 위배할수있는 문제)는 2가지 정도 된다.

1. 데이터 이동중 에러 발생 (데이터는 결국 010101 이런식으로 보내질텐데, 데이터가 손상될수 있다.)
2. 데이터 Loss (앞서배운 큐잉지연 등에 의해 데이터가 손실될수 있다.)

rdt를 위배할수 있는 위 2가지 사항을 극복하면 TCP 프로토콜은 rdt를 보장할수 있을 것이다.

1. error detection

우리가 수신시스템으로 보내는 데이터가 여러 라우터를 거치는 와중에 데이터에 에러가 발생할 가능성이 있다.

TCP 는 기본적으로 error detection 을 보장한다. 헤더에 checksum 필드를 추가하여 해당 데이터에 이상 유무를 수신단에서 확인할수 있게 한다.

2. feedback

수신 시스템에서 체크섬 필드를 통해 데이터의 이상유무를 확인했을때 해당 데이터에 이상이 있다면 송신 시스템으로 부터 데이터를 다시 전송받아야한다.

위와 같은 매커니즘을 사용하려면, 송신 시스템은 수신시스템으로부터 이상없는 데이터를 받았는지에 대한 feedback 이 필요할 것이다.

이때 사용하는 것이 ACK(positive acknowledgment) 와 NAK(negative acknowledgment) 이다.

ACK, 와 NAK 는 일종의 피드백이다. 수신자 축에서 받은 데이터에 대해 오류가 있으면 송신자 측으로 NAK 응답을 보내고, 오류가 없다면 ACK 응답을 송신자 측으로 보낸다.

❗️ACK 손상 가능성

위 설명대로 일종의 피드백 형태인 ACK 와 NAK 를 사용하면 데이터가 이동중 에러가 발생했을 상황을 극복할수 있을것 같다.

하지만 우린 ACK 또는 NAK 패킷이 손상가능하다라는 가능성을 고려해야한다.

즉 수신 시스템이 이상이 있는 데이터를 받아 송신 시스템에게 NAK 응답을 했는데, 만약 NAK 응답자체가 송신시스템으로 가는 도중에 손상이 발생한다면?

위와같은 상황을 해결하기 위해 tcp 프로토콜은 sequence number를 사용한다.

3. sequence number

수신자측은 데이터를 받을때 송신자 측에게 ACK 또는 NAK 응답을 반드시 보낸다.

위와같은 ACK응답이 손상되었을때 재전송 을 해결방안으로 생각한 사람이 있을수도 있다.

ACK응답이 오지 않으면 그외의 경우는 모두 재전송을 한다고 가정했을때, 문제가 발생할수 있는 경우는 아래와 같다.

수신자 측에서 오류가 없는 데이터 A 를 받았다고 가정한다.

그후 수신자는 송신자에게 데이터 A에 대한 ACK 응답을 할것이다.

하지만 이 ACK 응답이 가는도중 데이터에 에러가 발생하여 송신자 측에 응답이 도착했을땐 ACK 인지 NAK인지 판단할수 없다.

따라서 송신시스템은 데이터 A를 수신시스템에게 재전송 할 것이다.

데이터 A 가 수신시스템에게 왔다, 수신시스템은 데이터 A가 재전송이 된 데이터인지, 새로운 데이터인지 판단할수 없다.

위 가정에서 보면 결국 수신시스템은 수신한 데이터가 재전송을 위한 데이터인지, 새로운 데이터인지 판단해야한다.

이런 상황을 타개하기위해 sequence number 를 사용하는 것이다.

sequence number 는 송신자 측에서 보내는 세그먼트에 고유한 순차 번호를 부여하는 것이다.

수신자 측에서는 순차 번호를 통해, 받은 데이터가 중복된 데이터인지 새로운 데이터 인지 확인할수 있다.

수신자 측에서 오류가 없는 데이터 A (헤더에 순차번호가 0번인) 를 받았다고 가정한다.

그후 수신자는 송신자에게 데이터 A에 대한 ACK 응답을 할것이다.

하지만 이 ACK 응답이 가는도중 데이터에 에러가 발생하여 송신자 측에 응답이 도착했을땐 ACK 인지 NAK인지 판단할수 없다.

따라서 송신시스템은 데이터 A를 수신시스템에게 재전송 할 것이다.

데이터 A 가(헤더에 순차번호가 0번인) 수신시스템에게 왔다, 수신시스템은 순차번호를 통해 해당 데이터가 재전송된 데이터 인지 확인할수 있으며 해당 데이터를 버린다.

sequence number 를 도입하는 순간 NAK 의 필요성이 사라진다. 만약 수신자 측에서 ACK, 또는 NAK 응답을 보낼때 수신자가 지금까지 받은 데이터의 sequence number 를 같이 보내준다면 NAK 응답이 필요없어 진다. 이를 acknowledgement number 라고 한다.

acknowledgement number 는 수신자가 다음에 기대하는 바이트의 순서번호를 나타낸다.

즉 마지막으로 성공적으로 받은 데이터 바이트의 순서번호에 1을 더한다.

<정상적인 데이터를 받았을 경우>

수신자 측에서 오류가 없는 데이터 A (헤더에 순차번호가 0번인) 를 받았다고 가정한다.

그후 수신자는 송신자에게 데이터 A에 대한 ACK#1 (순차번호가 0번인 것까지는 완벽하게 받았으니) 응답을 할것이다.

송신자 측에선 ACK#1 을 통해 그다음 데이터인 1번 데이터를 전송해야 하는것을 알수있다.

<비정상 적인 데이터를 받았을 경우>

수신자 측에서 오류가 있는 데이터 B (헤더에 순차번호가 1번인) 를 받았다고 가정한다.

그후 수신자는 송신자에게 데이터 B에 대한 재전송을 위해 ACK#1 (순차번호가 0번인 것까지는 완벽하게 받았으니) 응답을 할것이다.

송신자 측에선 ACK#1 을 통해 순차번호가 1번인 데이터 B를 재전송 해야한다는 것을 인지할수 있다.

 

4. timer

지금까지 본 error detection, feed back, sequence number 3가지를 사용하면 rdt를 지키기위해 트랜스포트 계층 외 계층에서 발생할수 있는 error 에 대한 해결방안은 모두 제시했다.

이제는 Loss 에 대한 해결책만을 확인하면 된다.

Loss 는 잘못된 응답이 오고 안오고를 떠나서 응답자체가 안오는 경우에 대해서는 어떻게 해결을 할것이냐? 에 대한 물음이다.

즉 송신자 측에서 데이터를 보냈는데 데이터가 가는도중에 패킷이 유실되든, 수신자측에서 받은 데이터에 대한 응답이 송신자측으로 가는 도중에 유실이 되든 사실 송신자 입장에선 응답이 안오는 같은 상황이다.

단순히 생각해봐도 해당 응답이 올때까지 무한정 대기할수는 없다. 따라서 우린 timer 를 사용한다.

timer를 사용하여 일정 시간이 지나도록 응답이 오지 않으면 재전송을 하게한다.

대기하는 시간은 일반적으로 rtt(round-trip-time) + margin 으로 잡는다.

참고로 segment 를 보낼때마다 rtt를 측정하여, 재전송 타이머를 동적으로 조절한다 (매번 네트워크 지연시간이 다르기 때문에 첫번째 rtt 를 계속해서 타이머로 설정하는데에는 무리가 있다).

또한 이 평균을 측정하는데 있어서 재전송 에 대해서는 포함하지 않는다.