[네크워크] 멀티플렉싱과 디멀티플렉싱 - TCP, UDP, 연결지향

 

전송 계층 서비스

• 서로 다른 호스트에서 실행되는 애플리케이션 프로세스 간의 논리적인 통신(logical communication)을 제공하는 것이 목적이다.
• 실제 물리적인 연결이 아닌, 사용자 입장에서는 애플리케이션 간 직접적인 통신처럼 보이게 한다.

 

Transport Layer vs Network Layer

• Transport Layer는 애플리케이션 간의 논리적 연결(Logical Communication) 제공
• Network Layer는 데이터를 목적지까지 전달(Routing)
• 호스트: 집 (Host = House)
• 프로세스: 사용자(자녀) (Process = Kid)
• 메시지: 편지 (Message = Letter)
• 주소: IP + Port
• Multiplexing: 여러 프로세스 데이터를 하나로 모음
• Demultiplexing: 도착한 메시지를 포트번호 기준으로 해당 프로세스에게 전달

 

전송 계층의 동작 (종단 시스템에서)

• 송신 측 (Sender):
  • 애플리케이션으로부터 전달받은 메시지를 segment 단위로 분할한다.
  • 이 segment를 네트워크 계층(Network Layer) 으로 전달한다.
• 수신 측 (Receiver):
  • 네트워크 계층으로부터 받은 segment들을 원래 메시지로 재조립(reassemble) 한다.
  • 조립된 메시지를 애플리케이션 계층에 전달한다.

 

전송 계층 프로토콜의 종류

TCP (Transmission Control Protocol)

• 연결 지향 (Connection-oriented)
• 신뢰성 보장 (Reliable)
• 흐름 제어 및 혼잡 제어 제공

UDP (User Datagram Protocol)

• 비연결형 (Connectionless)
• 신뢰성 없음 (Unreliable)
• 빠르고 단순한 구조

 

 

전송 계층의 송신자와 수신자 측 동작

송신자 측 동작

• 응용 계층으로부터 메시지를 전달받는다.
• 메시지를 세그먼트(segment)로 분할한다.
• 세그먼트에 필요한 헤더 필드 값을 결정한다.
• 세그먼트를 생성한다.
• 세그먼트를 네트워크 계층(IP 계층)으로 전달한다.

 

수신자 측 동작

• 네트워크 계층으로부터 세그먼트를 전달받는다.
• 세그먼트의 헤더 값을 확인한다.
• 세그먼트에서 응용 계층 메시지를 추출한다.
• 소켓을 기준으로 디멀티플렉싱(demultiplexing)을 수행하여 메시지를 올바른 응용 계층 프로세스에 전달한다.

---

Multiplexing과 Demultiplexing

기능	설명
Multiplexing	여러 애플리케이션의 데이터를 하나의 전송 경로로 통합 (송신 측)
Demultiplexing	수신한 데이터를 올바른 애플리케이션으로 분배 (수신 측)
구분 기준	포트 번호 (송신 포트, 수신 포트)
사용 예	TCP와 UDP 모두 이 기능 사용

 

 

 

Multiplexing as Sender (송신 측에서의 멀티플렉싱)

멀티플렉싱은 송신 측에서 여러 프로세스의 데이터를 각각의 소켓을 통해 전송 계층으로 전달받아, 이를 하나의 전송 흐름으로 결합하는 과정이다. 이때 각 애플리케이션 메시지에는 전송 계층 헤더(transport header)가 추가되며, 이는 이후 수신 측에서 디멀티플렉싱(demultiplexing) 시 어떤 프로세스에 도착해야 할 데이터인지 식별하는 데 사용된다.

 

구조 및 동작 흐름 설명

• 송신 호스트(중앙 컴퓨터 기준)에서는 애플리케이션 프로세스 P1, P2가 각각의 소켓을 통해 전송 계층에 메시지를 전달한다.
• 전송 계층은 각각의 메시지에 전송 계층 헤더(TCP/UDP 헤더)를 붙이고, 이를 네트워크 계층(IP)으로 전달한다.
• 이렇게 만들어진 세그먼트는 하나의 물리 채널을 통해 수신 측으로 전송된다.
• 수신 측(오른쪽 컴퓨터 기준)에서는 해당 세그먼트를 받아서, 헤더 정보를 확인한 후 어떤 소켓(P4)에 전달해야 할지 결정한다.
• 결국, 멀티플렉싱을 통해 다수의 애플리케이션 프로세스 데이터를 하나로 모아 전송하고, 수신 측에서는 다시 분리하여 전달하는 구조가 구현된다.

이 구조는 논리적 end-to-end 통신을 실현하기 위한 기반 역할을 하며, 다수의 애플리케이션을 효율적으로 네트워크 상에서 동작시키는 핵심 메커니즘이다.

 

 

Demultiplexing as Receiver (수신 측 디멀티플렉싱)

수신 측에서는 네트워크 계층(IP)으로부터 전달받은 세그먼트를 적절한 애플리케이션 프로세스에 연결된 소켓으로 전달하기 위해 헤더 정보를 사용한다. 이 과정을 디멀티플렉싱(demultiplexing)이라 한다.

 

구체적인 처리 과정은 다음과 같다:

• 수신자는 IP 계층으로부터 세그먼트를 전달받는다.
• 세그먼트에 포함된 포트 번호(헤더 필드)를 확인하여, 이 세그먼트가 어떤 소켓으로 전달되어야 하는지를 판단한다.
• 이 포트 번호는 송신 측에서 설정한 소켓의 식별자와 연결되어 있으며, 해당 소켓은 특정 애플리케이션 프로세스와 연결되어 있다.
• 따라서 전송 계층은 이 정보를 기반으로 세그먼트를 정확한 소켓으로 디멀티플렉싱하여, 결국 해당 애플리케이션 프로세스(P1, P2, P4 등)로 전달한다.

 

이 메커니즘을 통해, 하나의 호스트에서 여러 애플리케이션이 동시에 동작하더라도 각 세그먼트는 정확한 목적지 프로세스로 전달된다.

 

 

디멀티플렉싱의 예시

전송 계층이 정확히 Firefox 프로세스로 HTTP 메시지를 전달할 수 있었던 이유는, 세그먼트 헤더에 포함된 수신 포트 번호를 기반으로 적절한 소켓을 찾아내고, 그 소켓에 연결된 애플리케이션 프로세스(Firefox)에 메시지를 전달했기 때문이다.

이 과정이 바로 디멀티플렉싱(demultiplexing)이다.

 

 

• 각각의 애플리케이션은 서로 다른 소켓을 사용한다.
• 소켓은 (IP 주소, 포트 번호)로 식별되며, 전송 계층은 이 정보를 통해 정확한 대상 프로세스를 식별한다.
• 예를 들어,
  • Firefox: 포트 5001
  • Netflix 앱: 포트 5002
  • Skype: 포트 5003
• HTTP 메시지 세그먼트가 포트 5001로 도착하면, 이는 Firefox와 연결된 소켓임을 의미하며, 다른 프로세스로는 전달되지 않는다.

 

•  

세그먼트 내부 구조

• 상단에는 32비트 크기의 포트 번호 정보가 있으며, 여기서:
  • 왼쪽은 출발지 포트 번호
  • 오른쪽은 목적지 포트 번호
• 그 아래에는 기타 헤더 필드들과 애플리케이션 데이터(payload)가 포함된다.
• 전송 계층은 이 포트 번호 정보를 이용해 정확한 프로세스에 데이터 전달을 수행한다.

 

---

Connectionless Demultiplexing (UDP 기반 디멀티플렉싱)

연결 없는 디멀티플렉싱은 UDP 프로토콜을 사용할 때 발생하는 데이터 수신 방식이다. 이는 포트 번호 기반으로 세그먼트를 식별하며, TCP처럼 연결 상태를 유지하지 않는다.

송신 측에서의 준비

• 소켓을 생성할 때, 반드시 호스트 내부에서 고유한 포트 번호(host-local port number) 를 지정해야 한다.

예시:

DatagramSocket mySocket1 = new DatagramSocket(12534);

 

• 그리고 데이터그램을 보낼 때는 다음 정보를 명시해야 한다:
  • 목적지 IP 주소 (destination IP address)
  • 목적지 포트 번호 (destination port number)

수신 측에서의 동작

• 수신자는 UDP 세그먼트를 수신하면, 다음 절차를 수행한다:
  • 세그먼트의 목적지 포트 번호를 확인한다.
  • 해당 포트 번호에 바인딩된 소켓으로 세그먼트를 전달한다.

특징: 동일한 포트 번호 → 동일한 소켓

• 여러 송신자(즉, 서로 다른 source IP 주소나 source port 번호)가 동일한 destination port로 데이터를 보낸다면,
• 이 모든 세그먼트는 하나의 동일한 소켓으로 수신된다.

즉, UDP 기반 디멀티플렉싱은 오직 목적지 포트 번호만을 기준으로 세그먼트를 분배하며, 송신자의 정보는 소켓 선택에 영향을 주지 않는다. 이 때문에 단순하지만 신뢰성, 순서 보장 등은 제공하지 않는다.

 

이 예제는 UDP의 단순하고 lightweight한 구조를 잘 보여주는 동시에, 송신자 식별 없이도 수신 포트 번호만으로 처리하는 방식의 한계를 드러낸다.

 

---

Connection-oriented demultiplexing

TCP 기반의 연결 지향형 디멀티플렉싱은 4-튜플(4-tuple) 정보를 기반으로 작동한다.이 네 가지 정보는 하나의 TCP 소켓을 고유하게 식별하는 데 사용된다.

 

4-tuple 구성 요소

• source IP address: 데이터를 보내는 쪽의 IP 주소
• source port number: 데이터를 보내는 쪽의 포트 번호
• destination IP address: 데이터를 받는 쪽의 IP 주소
• destination port number: 데이터를 받는 쪽의 포트 번호

demux (demultiplexing)

• 수신 측은 이 4개의 정보를 모두 확인하여 도착한 세그먼트를 정확한 소켓에 전달한다.

동시 연결 지원

서버는 여러 개의 TCP 소켓을 동시에 지원할 수 있다.

• 각각의 소켓은 고유한 4-tuple로 식별되므로 충돌 없이 관리 가능하다.
• 각 소켓은 서로 다른 클라이언트와의 연결에 대응된다.

 

세부 동작 예시

클라이언트 A에서 온 세그먼트:

• source IP: A
• source port: 9157
• dest IP: B
• dest port: 80
• → 서버의 소켓 P4로 전달됨

클라이언트 C에서 온 세그먼트 (source port 5775):

• source IP: C
• source port: 5775
• dest IP: B
• dest port: 80
• → 서버의 소켓 P5로 전달됨

클라이언트 C에서 온 세그먼트 (source port 9157):

• source IP: C
• source port: 9157
• dest IP: B
• dest port: 80
• → 서버의 소켓 P6로 전달됨

세그먼트들은 모두 같은 목적지 포트(80)와 목적지 IP(B)를 갖고 있지만, 송신자의 IP 및 포트 번호가 다르기 때문에 서로 다른 소켓으로 분리(demultiplex)된다. 이것이 TCP가 각 연결을 고유하게 관리할 수 있는 이유이다.

요약:

TCP에서는 단순히 목적지 포트 번호만 보는 것이 아니라, 송수신 IP 주소 및 포트 번호까지 모두 고려하여 해당 세그먼트를 어떤 소켓에 전달할지를 정확히 판단한다.

이로 인해 하나의 서버가 여러 클라이언트로부터 오는 요청을 동시에, 정확하게 처리할 수 있다.