(컴퓨터와 네트워크) 전송 계층 (기능, UDP, RDT의 원리)

 

 

 

본 게시물은 이석복 교수님의 네트워크 강의를 수강하며 작성한 강의노트와 추가 공부한 내용을 바탕으로 작성하였습니다.

• 참고 강의 및 사이트

KOCW

KOCW

[네트워크] TCP/IP 흐름 제어 & 혼잡 제어

[네트워크] TCP/IP 흐름 제어 & 혼잡 제어

---

Transport-Layer(전송계층)

전송계층에는 현재 TCP와 UDP 두가지 방식이 있다. 이 둘은 전송계층의 Protocol로서 상위 계층인 애플리케이션 계층에서 필요한 역할을 서비스한다.

 

전송계층의 기능

Multiplexing & Demultiplexing

프로세스에서 메시지를 보낼 때 알맞은 목적지 프로세스를 찾아 그 프로세스에 보내는 방식이다.

• Multiplexing

발신자는 수많은 인터페이스들(프로세스들) 중 하나의 프로세스로 내보내야 하기에, 여러 소켓의 패킷을 수집하여 하나의 세그먼트로 캡슐화하여 Network Layer로 내려주는 것을 말한다.

• Demultiplexing

수신자가 수행하는 과정으로 세그먼트가 Application Layer로 전달될 때, 올바른 소켓으로 전달하는 과정을 말한다. 그렇다면 어떤 소켓이 올바른 소켓인지 판단할 수 있을까? 이를 위해 세그먼트의 Header에 정보를 담아 전달한다.

TCP와 UDP 모두 Multiplexing과 Demultiplexing을 하지만 아래와 같은 차이를 가진다.

• UDP : Connectionless transport
  • PORT 번호만 보고 주고 받으며, 따로 Connection을 생성하지 않는다.
• TCP : Connection-oriented transport
  • 수신자와 발신자 소켓이 1:1 고유관계를 가진다.
  • 이 방식은 source IP, source Port, dest IP, dest Port 네 가지로 고유한 소켓이 결정된다.

UDP (: Connectionsless Transport) Demultiplexing

헤더에는 Source port와 Dest port, length, checksum(에러판단 목적)이 존재한다. UDP는 이 중 dest IP와 dest Port만을 이용해 소켓을 결정한다.

 

 

---

Principles of reliable data transfer(RDT)

신뢰성 있는 데이터 전송을 위한 프로토콜

신뢰성이란? 애플리케이션 계층에서 내려온 메시지가 유실되지 않고 에러 없이 상대 애플리케이션 프로세스에 전달되는 것을 의미한다.

TCP에서 reliable한 Data Transfer를 제공하기 위해 어떤 메커니즘이 필요한지 간단하게 RDT를 설계하면서 알아볼 것이다.

✔ rdt 1

No Error & No Loss

이미 reliable 하므로 어떤 메커니즘도 필요하지 않다.

✔ rdt 2

Error 존재

• Error Detection
  • checksum bits를 통해 받는 사람이 에러가 있는지 없는지를 체크할 수 있다.
• Feedback : 리시버가 잘 받았는지 여부
  • Acknowledgements(ACKs) : 패킷이 올바르게 도착했다는 피드백
  • Negative acknowledgements(NAKs) : 에러가 있다는 피드백
• 재전송 : 송신자가 에러가 있는 상황의 패킷을 다시 전송

** 문제점 **

리시버가 보낸 피드백 자체가 에러라면 어떻게 할까? 송신자(sender)는 이 피드백이 에러인지 확인할 길이 없으므로 에러가 발생했다고 온 패킷을 재전송할 것이다.(Duplicate Packets 발생) 이럴 경우 수신자(receiver) 서버는 중복된 데이터를 다시 받게 되며 이를 처리하는 방법에 대한 솔루션이 필요하다.

• Sequence Number
  • Sender가 헤더에 Sequence Number를 추가하여 중복 패킷을 리시버가 판단할 수 있도록 돕는다.
  • 0부터 증가시키는 방식은 헤더의 크기를 무한대로 키울 수 있으므로 0과 1로만 구분한다.

⇒ 피드백은 무조건 ACK로 하되, Seq num을 통해 ACK, NAK를 판단한다. 예를 들어, Sender가 0으로 패킷을 보냈는데 Seq num가 1로 돌아온다면 잘못 받았다는 의미로 받아들이는 것이다.

✔ rdt 3

Error 존재
Loss 존재

• Error Detection + Feedback + Sequence number
  • rdt 2에서 본 것과 동일한 매커니즘을 활용한다.
• Timer
  • segment를 보내면서 time를 동작시키고 timeout 발생 시 loss로 간주하고 재전송한다.

이 타이머의 시간은 어느 정도가 적당할까? 추후 TCP를 알아보며 이 문제에 대해 다룰 것이다.

 

---

Pipeline Protocol

이렇게 살펴본 rdt 방식은 신뢰성은 보장하나 효율성 면에서 떨어진다. 전체시간 중 송신자가 네트워크를 사용하는 비율이 크면 클수록 성능이 좋다고 판단하는데 이러한 프로토콜은 데이터를 하나씩 주고 받으며 확인하기 때문에 성능이 좋다고 볼 수 없다. 따라서 여러 데이터를 한꺼번에 주고 받는 Pipeline Protocol이 등장했다.

Pipeline 방식에는 전형적으로 Go-Back-N과 Selective Repeat 두 가지 방식이 존재한다. 이 두 방식은 현실 세계의 프로토콜은 아니고 파이프라인 방식을 구현하기 위한 접근 방식으로 볼 수 있다.

그럼 Pipeline 방식의 원리에 대해 하나씩 살펴보자

 

Go-Back-N

데이터를 한번에 많은 패킷을 쏟아 부어 주고 받는다. 이 때, 주고받는 데이터의 크기를 window size라고 한다.

• window size : 한 번에 주고 받는 데이터 양의 기준
• cumulative ACK
  • ACK(n) : n번까지의 데이터를 모두 잘 받았다는 피드백이다.
• receiver의 역할이 없다.
  • sender는 데이터를 순차적으로 보내겠지만 네트워크는 도착 순서를 보장하지 않는다. 이 때, receiver는 2, 3이 먼저 도착하더라도 1이 도착하지 않았다면 별다른 조치 없이 계속 1만 기다리게 된다.

이렇게 receiver의 역할이 없음으로써, 유실된 건 n번 뿐인데 이로 인해 다른 데이터까지 모두 버퍼에 다 들고 기다려야한다는 비효율적인 측면이 존재한다.

Selective Repeat

Go-Back-N의 비효율성을 개선한 방식이다.

• 선택적 재전송을 위해 달라진 ACK의 의미
  • ACK(n) : n번 패킷을 잘 받았다는 의미
• Receiver의 버퍼
  • 순서에 맞지 않게 들어온 패킷이더라도 에러가 없다면 버퍼에 저장해둔다.
• Sender는 ACK를 받지 못했다고 피드백 온 패킷에 대해서만 재전송을 한다.

이 방식 또한 문제점이 존재한다. 패킷을 개별적으로 선택하여 전송하기 위해서는 모든 패킷마다 타이머를 걸어둬야 한다는 것이다. 데이터 1,2개를 예시로 고려했을 때는 이게 왜 문제인지 와닿지 않겠지만 실제 네트워크 상황에서 Window Size는 훨씬 크다. 따라서 동시에 실행되는 많은 프로세스마다 모든 패킷에 타이머를 거는 것은 불가능에 가깝다.

헤더의 크기를 줄여야하는데 0과 1로만은 표현되지 않아 Seq가 최소 Window Size *2 이상은 되어야 한다는 문제가 발생한다.

---