3-2. 전송(Transport) 계층: 신뢰성 있는 데이터 전송(RDT)

해당 글은 한양대학교 이석복 교수님의 과목 "컴퓨터 네트워크"를 공부하고 작성한 글입니다. 해당 강의를 직접 수강하시려면 다음 링크를 참고해주세요.

컴퓨터 네트워크 - 한양대학교 | KOCW 공개 강의

컴퓨터네트워크

 

---

 

1. TCP에서의 신뢰성

전송 계층에서 사용되는 대표적인 프로토콜 중 하나인 TCP는 신뢰성이 높다.

 

여기서 신뢰성이 높다는 것은 애플리케이션(Application) 프로세스 사이에 전달되는 데이터가 "하나도 유실되지 않고" 전달되도록 하는 것을 말한다.

 

역으로 말하면 TCP가 위치한 전송(Transport) 계층의 하위 레벨에서는 신뢰성이 보장되지 않는 환경(Unreliable channel)이라는 말이기도 하다.

Reliable Channel(좌측)에서는 데이터가 제대로 전송되므로 문제가 생기지 않는다. 그러나 Unreliable Channel(우측)에서는 데이터에 문제가 발생할 수 있으므로 RDT 프로토콜과 같은 방법을 사용해야 한다.

(1) 신뢰성 없는 채널(Unreliable channel)

신뢰성이 보장되지 않는 곳에서는 두 가지 현상이 발생한다.

• 패킷(메시지) 에러
  • 패킷 또는 메시지에 문제가 생겨 기존과 달리 변경됨
• 패킷(메시지) 유실
  • 패킷이 중간에 제대로 전달되지 않고 유실됨

이 두 현상을 해결하면 네트워크 상에서는 신뢰할 수 있다(reliable)고 말한다.

(2) 신뢰성을 보장하는 법

신뢰성을 보장하는 방법은 간단하다.

정상적으로 패킷이 전송되었는지 확인하고, 제대로 전송되면 다음 패킷을 전송하는 것이다.

이를 구현하기 위해 다양한 생각을 해볼 수 있다.

 

 

2. 신뢰성 있는 데이터 전송(RDT; Reliable data transfer)

RDT(Reliable data transfer) 프로토콜은 TCP에서의 신뢰성을 보장해준다.

 

이상적인 상황부터 시작해서 RDT를 어떻게 만들지 생각해보자.

 

(1) RDT 1.0: 완벽하게 데이터가 전송되었을 때

첫 번째로 가정할 상황은 바로, 하위 계층이 신뢰성 높고(reliable) 완벽하게 데이터를 전송할 때이다.

 

그렇게 되면 전송(transport) 계층에서 데이터의 신뢰성을 준수할 필요가 없다. 데이터는 하위 계층을 거쳐 전송되므로, 이미 데이터의 신뢰성이 보장되는 셈이다.

만약 택배를 배달할 때 100% 상품에 충격을 안 주고 전달할 수 있다면, 굳이 택배를 부칠 때 포장재를 두를 필요가 없을 것이다.

받고 나서 문제가 생겨도 그건 물건 자체에 결함이 있는 것이다. 

 

이런 이상적인 상황에서는 바로 택배(여기서는 패킷)를 전송하기만 하면 될 것이다.

 

그러나 현실은 이런 이상적인 상황과 거리가 멀다.

 

(2) RDT 2.0: 패킷 에러만 발생할 때

두 번째 상황은 보다 현실적인 상황으로, 패킷 유실 없이 패킷 에러만 있는 채널을 타고 데이터가 전송될 때이다.

 

택배로 비유를 들면, 택배가 이상한 곳으로 배달되는 일이 없는 상황이다. 대신 두 번째 상황에서는 충격을 받아 상품에 흠집이 생길 수도 있다.

 

이런 상황에서 에러를 어떻게 처리할까?

 

1. 에러 감지(Error detection)
   • 먼저 에러가 발생했는지를 알아봐야 한다.
   • 여기서는 체크섬(checksum) 방법으로 데이터의 무결성을 확인한다.
2. 피드백(Feedback)
   • receiver는 데이터를 잘 받았는지 확인하기 위해, 패킷을 받을 때마다 피드백을 주어야 한다.
   • 잘 받았다면 ACKs(Acknowledgements), 에러가 발생하면 NAKs(Negative ACKs)을 전송
   • 예를 들면, 친구랑 대화할 때 "어, 응"이라고 말하다가, 잘못 들을 경우 "어? 뭐라고?" 등으로 답한다. 이것과 똑같은 원리.
3. 재전송(Retransmission)
   • 패킷에 오류가 있으면 다시 전송해준다.
   • sender가 NAK을 받게 되면 재전송한다.
   • 반대로 ACK를 받게 되면 sender는 제대로 전달되었다고 확인하고, 다음 패킷을 전송한다.

 

1) 문제점과 이를 보안한 RDT 2.1

하지만 위와 같은 과정을 거치면 문제가 몇 가지 있다.

우선 피드백 신호에 에러가 발생할 수 있다.

제대로 패킷을 받고 receiver가 ACK를 보냈는데 ACK에 에러가 발생해서, 패킷이 제대로 전송되었는지 아닌지 알 수 없는 것이다.

피드백 메시지(ACK, NAK)에 에러가 발생했을 때

• 이럴 땐 깔끔하게 패킷을 재전송해서 해결할 수 있다.

만약 상대측이 패킷을 잘 받았는데 ACK에 에러가 발생했던 것이라면, 재전송받은 패킷은 깔끔하게 버리는 것이다.

 

여기서 재전송하는 패킷을 기존 패킷을 복제했다고 해서 복제된 패킷(Duplicate packets)이라 한다.

 

그러면 새로 온 메시지가 복제된 패킷인지는 어떻게 알까?

• 메시지에 시퀀스 넘버(Sequence number)를 붙여 해결할 수 있다.

0번 메시지, 1번 메시지, 2번 메시지 이런 식으로 번호를 붙여 전송하게 되면, 이 패킷이 방금 받은 패킷인지 아닌지 쉽게 구분할 수 있다.

만약 2번 메시지까지 보냈는데, 다음으로 온 것이 2번이면 복제된 패킷인 것이다.

여기서 사용하는 번호를 시퀀스 넘버(Sequence number)라 부른다.

RDT 2.1 예시

 

이전의 문제를 개선한 RDT 2.1 프로토콜을 정리하면 다음과 같다.

RDT 2.1 요약

• Sender가 패킷마다 시퀀스 번호(Sequence number)를 붙인다.
• 피드백(ACK/NAK) 메시지에 오류가 있는지 확인하고, 오류가 있으면 Sender는 현재 패킷을 재전송한다.
• Receiver는 복제된 패킷(Duplicate packet)을 버린다.
• 이외에는 RDT 2.0과 동일

 

여기서 시퀀스 넘버는 몇 개까지 셀 수 있어야 할까?

• 무한히 많은 수를 셀 수 있다면 좋겠지만 패킷의 헤더는 한계가 있다.
• 보내는 메시지의 길이가 커질수록 비용도 커지게 된다.
• 이전에 보낸 것과 같은지 아닌지만 구분할 수 있으면 된다. (복제 패킷을 확인하는 용도)
• 따라서 1비트(0, 1)만으로 표현할 수 있다.

 

2) NAK를 없앤 RDT 2.2

여기서 NAK를 없앨 수도 있다.

RDT 2.1에서 무조건 Receiver가 ACK를 보내도록 하는 것이다.

그 대신 마지막으로 받은 정상적인 메시지가 무엇인지를 전송하는 것이다.

 

예를 들어 마지막으로 시퀀스 넘버가 2인 메시지를 받았다면, ACK 2를 전송한다.

마지막으로 받은 메시지는 시퀀스 넘버(Seq #)를 통해 알려준다.

 

3번 메시지를 전송했는데 ACK 2가 돌아오거나 ACK 메시지에 에러가 발생했다면, 3번 메시지를 재전송하는 것이다.

 

 

(3) RDT 3.0: 패킷 유실, 패킷 에러가 발생할 때

이제 RDT는 패킷 에러를 처리할 수 있다.

그렇다면 패킷이 아예 도착을 안 한다면 어떻게 처리할까?

JTBC 뉴스 중. 카카오톡에서 네트워크가 안 좋으면 이렇게 전송 실패가 뜬다.

대표적인 예시는 카카오톡에서 전송 실패가 뜨는 것이 있겠다.

카카오톡 서버가 불안정할 때나 아예 인터넷에 접속이 안 될 때면 위 사진처럼 발송에 실패하곤 한다.

이 상황이 바로 패킷 유실(Packet loss)이다.

 

이때, 카톡에서는 메시지를 보내고 바로 전달 실패가 되는 것이 아니라 한참이 지나고 나서야 전송이 실패되었다고 알려준다.

어느 정도 시간이 지날 때까지 기다리고 나서도 피드백이 오지 않으면 전송에 실패했다고 판단하는 것이다.

 

1) 해결 방법: 타이머

패킷 유실을 해결하는 방법도 바로 카카오톡에서 사용한 방법과 똑같다.

 

상대방에게 피드백이 안 오는 것을 통해 패킷 유실을 판단한다.

그 이유는 다음과 같다.

• 패킷을 보내면 반드시 ACK든 NAK든 반응이 와야 한다.
• 즉, 피드백이 안 오면 패킷이 유실된 거다.

패킷을 보낼 때 타이머를 작동시켰다가, 일정 시간 동안 응답이 안 오면 타임아웃(Timeout)으로 간주하는 것이다.

그 순간 데이터를 재전송하게 되면 패킷 유실을 해결할 수 있다.

 

2) 대체 얼마나 기다려야 하나?

그런데 문제가 있다면 언제까지 기다려야 하는지이다.

 

교재에서는 타이머를 적당히(reasonable) 조절해야 한다고 말한다.

따로 정해진 바가 없다는 뜻이다.

 

너무 짧거나 길면 아래에 적힌 문제가 생기게 된다.

1. 타이머가 너무 짧으면?
   • 빠르게 유실 상황을 복구할 수 있다
     유실이 일어났을 때 빠르게 알 수 있기 때문이다.
   • 그러나 네트워크에 중복된 패킷이 전송될 수 있다.
     • 패킷 전송이 느려서 아직 전달되지 않았을 수도 있다.
     • 그 경우, 정상적으로 전달되었는데도 같은 데이터가 여러 번 보내질 수 있게 된다.
       물론 복제된 패킷이 버려지므로 정상적으로 전달은 이뤄진다.
       그러나 필요 없는 데이터를 보내면서 네트워크에 대한 오버헤드가 많아진다.
       (오버헤드 overhead: 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리)
2. 타이머가 너무 길면?
   • 네트워크에 대한 오버헤드를 예방할 수 있다.
     데이터가 전송될 때까지 충분한 시간이 주어지기 때문에, 중복된 패킷이 전송되는 일도 적어진다.
   • 반면 유실 상황에 대한 반응이 느린 단점이 있다.
     유실을 판단하는 데에 너무 시간이 많이 걸리기 때문에 조치도 느려지는 것이다.

길이를 설정하는 것에는 양측 모두 장단점이 있다.

따라서 타이머를 어느 정도 길이로 설정할 것인지는 짧음과 긺 사이에서 적당히 타협을 보아 해결하는 수밖에 없다.

 

타이머를 정하는 방법은 이후 포스팅에서 설명할 예정이다.

 

3. TCP RDT(Reliable data transfer) 정리

RDT 3.0에 대한 내용을 정리하면 이러하다.

• 신뢰성 낮은 채널(Unreliable channel)에서는 두 가지 현상이 발생함
  • 패킷 에러(Packet error)
  • 패킷 유실(Packet loss)
• 패킷 에러(Packet error)에 대한 대응책
  
  • 에러 감지(error detection), 피드백(feedback), 재전송(retransmission), 시퀀스 넘버(sequence number)
• 패킷 유실(Packet loss)을 위한 대응책
  • 타임 아웃(Timeout)

 

TCP에서는 패킷 에러과 유실을 해결하기 위한 정보가 패킷 헤더(Header)에 저장된다.

이외에도 흐름 제어(Flow control) 등의 기능을 보장하기 위해 다양한 내용이 들어간다.

 

4. 전송 속도 문제

그러나 RDT 3.0를 한 패킷씩 전송하게 되면 정말 많은 패킷 낭비가 발생한다.

 

현재 방식으로는 패킷 하나를 전송하고 나서 ACK 메시지가 올 때까지 그 소켓은 어떤 통신도 할 수 없다.

100개가 넘는 패킷을 보낼 시간 동안 상대 패킷을 기다린다고 아무것도 할 수 없는 것이다.

지금 방식은 좌측(a)과 같이 패킷 낭비가 심각하다.

따라서 한 번에 데이터를 동시에 전송하고, 피드백도 한 번에 받는 방식이 필요하다.

그래야 패킷 낭비가 덜해지기 때문이다.

 

그러나 이렇게 전송하면 ACK 피드백을 처리하기가 더 복잡해진다.

 

그러니까 다음에는 ACK를 기다리느라 낭비되는 시간을 활용하기 위한 방법을 알아보자.

 

 

 

 

출처

Multiplexing & Demultiplexing (velog.io)

Multiplexing & Demultiplexing

카톡 사진 '전송 실패'…카카오 "긴급점검, 현재 정상화" | 모바일 JTBC뉴스 (joins.com)

카톡 사진 '전송 실패'…카카오 "긴급점검, 현재 정상화"