Multiplexing & Demultiplexing

Dong-Hyeon Park·2023년 10월 17일

Network

목록 보기

5/8

본 글은 Computer Networking: a Top Down Approach의 Multiplexing 챕터를 정리한 글입니다.

한 컴퓨터에 FTP, Telnet 프로토콜로 실행되는 프로세스들과 HTTP 프로세스가 존재한다고 생각해보자.
그럼 전송 계층이 데이터를 수신했을 때, 여러 프로세스들 중 올바른 프로세스에게 전달해주어야 한다.
이것을 위해 소켓이 존재하며, 각 프로세스가 하나 이상의 소켓을 가질 수 있다.
- 소켓 : 프로세스 → 네트워크, 네트워크 → 프로세스로 데이터를 통과시키는 문.
  각 소켓은 자신만의 유니크한 ID를 갖는다.
그래서 전송 계층은 프로세스에게 즉각적으로 데이터를 전달하지 않고, 중간 소켓에게 전달한다.

각 segment는 올바르게 전달되기 위한 몇몇 field를 가진다.
전송 계층은 이 field 들을 확인해서 목적지 socket을 찾아내고,
그 socket에게 segment를 전달한다. 이것을 디멀티플렉싱이라고 한다.
그리고 멀티플렉싱은, 서로 다른 소켓들에게서 데이터를 수집하여 헤더 데이터와 함께 segment로 캡슐화하고, 네트워크 계층에게 전달하는 작업이다.

segment에는 source port number와 destination port number field가 존재한다.
각 port number는 16비트로, 0부터 65535까지 가능하다.
그러나 0부터 1023까지는 well-known port number로 불리며, 사용이 제한된다.
- 대표적인 예시로 HTTP는 80, FTP는 21을 사용한다.
각 소켓도 port number를 할당받기에, 전송 계층은 segment의 port number를 통해 소켓에게 segment를 전달한다. 그리고 소켓을 통해 데이터가 프로세스에게 전달된다.

UDP 19157 포트 프로세스를 갖는 호스트 A와
UDP 46428 포트 프로세스를 갖는 호스트 B가 있다고 하자.
여기서 source port number=19157,
destination port number=46428일 때,
호스트 A는 헤더 정보를 담은 segment를 생성하여 네트워크 계층에 전달한다. (=멀티플렉싱)
네트워크 계층은 segment를 IP datagram으로 캡슐화하여 수신 호스트(B)에게 전달한다.
호스트 B 측에 segment가 전달되면, 전송 계층은 destination port number 를 확인하고 46428 port number 소켓에 데이터를 전달한다. (=디멀티플렉싱)
(이때, 당연히 호스트 B는 다수의 프로세스를 실행 중일 수 있다.)
여기서 source port number 의 용도가 궁금할 수 있는데, source port number 는 return address 의 기능을 한다.
호스트 B가 답장을 보내고 싶다면, 수신 받은 source port number를 송신 segment의 destination port number로 설정한다.
UDP 소켓은 destination IP 주소, destination port number 두 가지에 의해 식별된다.
즉 source IP 주소 가 달라도 같은 소켓에게 segment를 전달할 수도 있다.

TCP 소켓은 UDP 소켓과 다르게, (source IP 주소, source port number, destination IP 주소, destination port number) 네 가지에 의해 식별된다.
그래서 호스트가 네트워크로부터 TCP segment를 전달받으면, 디멀티플렉싱 과정에서 위 네가지 field를 모두 활용한다.
TCP 어플리케이션은 welcoming socket을 가지고 있고, 클라이언트에 의해 연결이 생성될 때까지 대기한다. 더이상 연결을 생성하고 싶지 않다면 welcoming socket의 상태를 변경시키면 된다.
클라이언트가 소켓을 생성하여 연결을 만들면, segment에는 연결 생성에 쓰이는 특별한 비트값, source port number, destination port number가 기록된다.
서버 OS가 destination port number가 담긴 연결 요청 segment를 받으면,
해당 port number에 대기중인 process를 찾아내고, 해당 process는 새로운 소켓을 생성해낸다.
새롭게 생성된 소켓은 위에서 언급된 (source IP 주소, source port number, destination IP 주소, destination port number) 에 의해 식별된다.
그리고 이 네 개의 값이 동일한 소켓이 값이 일치하는 segment를 디멀티플렉싱한다.
결론적으로 서버는 동시에 수많은 TCP 소켓을 지원해야 하며,
각 소켓은 하나의 프로세스에 귀속되어 있다.

위 그림에서는 연결마다 새 프로세스를 생성하고 있다.
하지만 근래의 고성능 웹 서버는 하나의 프로세스와, 다중 스레드를 사용하고 있다. 그래서 하나의 새 연결에 프로세스가 아닌 스레드를 생성한다.
그리고 클라이언트와 서버가 persistent HTTP를 사용하면 연결시 생성된 소켓을 통해 계속해서 통신하지만, non-persistent HTTP를 사용하면 요청과 응답마다 소켓이 새롭게 생성된다. 이로 인해 non-persistent HTTP 방식은 부하가 높은 웹 서버에 큰 영향을 끼칠 수도 있다.

전송 계층의 가장 기본적인 역할은 네트워크 계층이 제공한 호스트 간의 연결을 프로세스 간의 연결로 확장시키는 것이다.
이것을 멀티플렉싱 및 디멀티플렉싱이라고 하며, 멀티플렉싱은 여러 개 존재할 수 있는 소켓들에게서 데이터를 모아 segment로 캡슐화 후 네트워크 계층에 전달하는 것이다. 디멀티플렉싱은 반대로 받아낸 segment에 기록된 정보를 통해 데이터를 올바른 소켓에게 전달하는 과정이다.
TCP를 사용하는지 UDP를 사용하는지에 따라서 식별에 사용하는 정보의 가짓수가 달라진다.