mir.pe (일반/어두운 화면)
최근 수정 시각 : 2024-10-24 04:36:22

다중화

1. 통신에서의 다중화
1.1. 다중화 요구사항1.2. IP Diagram 방식 역다중화1.3. 비연결성 역다중화1.4. RDT(Reliable Data Transfer)
1.4.1. RDT 1.01.4.2. RDT 2.01.4.3. RDT 2.11.4.4. RDT 2.21.4.5. RDT 3.0
1.5. 둘러보기

1. 통신에서의 다중화

하나의 회선 또는 전송로(유선의 경우 1조의 케이블, 무선의 경우 1조의 송수신기)를 분할하여 개별적으로 독립된 신호를 동시에 송수신할 수 있는 다수의 통신로(채널)를 구성하는 기술. 대표적인 다중화 방식으로는 하나의 회선을 다수의 주파수 대역으로 분할하여 다중화하는 주파수 분할 다중 방식( FDM)과 하나의 회선을 다수의 아주 짧은 시간 간격(time interval)으로 분할하여 다중화하는 시분할 다중 방식( TDM) 등이 있다.

일반적으로 여러개의 소켓에서부터 출발지 호스트로부터 얻은 데이터를 처리하고 전송계층 헤더를 붙이고 이를 네트워크 계층으로 전달한다. 반대로 역다중화의 경우 수신자는 하위 계층에서 수신받은 헤더 정보를 통해 어플리케이션 계층의 올바른 소켓에 전달하는 역할을 한다. 소켓은 네트워크에서 프로세스로 데이터를 전달하며, 또한 프로세스로부터 네트워크로 데이터를 전달하는 출입구 역할을 한다. 이 식별자의 포맷은 소켓이 UDP 소켓인지 또는 TCP 소켓인지에 따라 달라진다.

1.1. 다중화 요구사항

트랜스포트 계층에서 다중화하는 데에는 요구사항이 있다. 소켓은 유일한 식별자를 가지고, 각 세그먼트는 세그먼트가 전달될 적당한 소켓을 가리키는 특별한 필드를 요하는데, 이는 UDP TCP 세그먼트에서 찾아볼 수 있는 송신지 포트번호와 수신지 포트번호로서 표현되며 각 송신지와 수신지 각각 16비트로 표현된다.
Source Port # Destination Port #
Other header fields
Application Data (Message)

아래는 전달계층에서 사용되는 UDP/TCP 번호 패킷 형식이다. 각 포트 번호는 0 ~ 65535까지 16 비트 정수이고, 그중에서 0 ~ 1023까지의 포트 번호를 잘 알려진 포트 번호라고 하여 사용을 엄격하게 제한하고 있다. 즉, HTTP(포트 번호 80)와 FTP(포트 번호 21)처럼 잘 알려진 애플리케이션 프로토콜에서 사용되도록 예약되어 있는 셈이다.

1.2. IP Diagram 방식 역다중화

IP 다이어그램에는 출발지와 도착지 IP 주소가 존재하며 이는 하나의 전송계층 세그먼트로 전달된다. 각 세그먼트에는 출발지와 도착지의 포트 번호가 존재하는데, 호스트는 수신받은 데이터의 아이피 주소와 세그먼트 포트 번호를 통해 적절한 소켓을 취득할 수 있다.

1.3. 비연결성 역다중화

소켓을 생성하는 경우 소켓의 포켓번호가 지정되어야 하며 UDP를 예로 드는 경우 도착지 IP주소, 포트번호, 체크섬을 요한다. 따라서 수신자가 UDP 세그먼트를 수신받을 때 세그먼트의 도착지 포트번호를 확인하고 이를 통해 소켓을 전달하는 방식으로 이루어진다.

1.4. RDT(Reliable Data Transfer)

신뢰적 전송으로, 전송 프로토콜의 복잡성이 신뢰할 수 없는 채널 특성에 따라 다르고[1] 채널 상호통신을 통해 현 상태를 체크하지 않는 이상 상호 상태르 파악할 수 없다. 이를 위해 손실의 경우 보상 방식은 세그먼트의 체크섬, 수신기에서의 ACK/NAK 여부를 통해 보완할 수 있고, 패킷 손상의 경우 송신기 타이머를 통해 타임아웃을 이용하는 방식, 재전송 방식, 시퀀스 넘버를 지정하는 방식으로 보상한다. 이를 위해 사용한 프로토콜이 RDT이다.

RDT는 전송 데이터가 손상, 손실되지 않으며 모든 데이터는 수신 순서대로 전달된다고 가정한다. 이때 단방향 전송만 고려하며 유한 상태 머신을 사용한다고 가정한다. RDT 프로토콜을 사용하는 데이터 흐름도를 보면 영어로 되어 있어 이해하기 어려운데, 명령어를 다음과 같이 정의할 수 있다.

1.4.1. RDT 1.0

신뢰적인 채널에서의 신뢰적인 전송을 의미하며 이때 비트 에러 및 손실이 없고, FSN은 송신자가 데이터를 전송하고 수신자가 데이터를 수신한다고 가정한다. 이때 송신자는 상위계층의 호출을 기다리다가 데이터를 rdt_send로 받게 되면 데이터를 패킷으로 만들어 전송한다. 반대로 수신기는 하위 계층의 호출을 기다리다가 프로시저 호출로 rdt_rcv() 패킷을 받으면 패킷으로부터 역 캡슐화를 통해 패킷으로부터 메시지를 추출한다.

1.4.2. RDT 2.0

RDT 환경에서 비트에러가 존재하는 통신 에러채널로서 비트 오류가 발생하는 경우를 확인한 경우이다. 이때 세그먼트에서는 체크섬을 사용하지만 복구를 위해 패킷을 확적히 수신했음을 알려주는 ACK, 오류를 포함한 패킷이 들어옴을 알리는 NAK을 사용하며 이를 받으면 재전송을 진행한다. 다만 이 경우도 ACK/NAK을 1비트이다 보니 재전송할 수밖에 없고, 결국 오류가 발생할 수밖에 없다.

이때 스톱-앤-웨이트(Stop-and-wait) 방식을 사용하는 경우가 있는데, 하나의 패킷을 보낸다음 수신자의 응답을 기다리면서 수신 메시지를 받을 때까지 데이터를 수신하지 않는 방식이다. 이때 아래와 같은 명령어를 하나 더 만든다. 송신자의 경우 우선 상위 레이어에서 데이터를 받을 때 기다렸다가 데이터와 체크섬이 함유된 패키지를 하나 만든다. 이를 만들고 패킷을 생성 후 전송하는 데, 이후 ACK, NAK 여부에 따라 NAK인 경우 재전송을 만들고, ACK을 수신받았을 경우 다음 데이터를 송신한다. 수신자의 경우 패킷을 수신한 후 ACK를 보내는 경우, 데이터를 추출하여 이를 상위 계층으로 이관하고, ACK를 보내는 방식으로 진행한다.

1.4.3. RDT 2.1

RDT 2.0에서 ACK/NAK에서 오류가 발생하는 경우를 확인한 경우이다. 오류가 발생한 경우 패킷 재전송을 포함한 패킷번호를 적어서 보낸다. 다음과 같은 함수가 추가된다.
송신자의 경우, 0번째 패킷에 대해 우선 대기한다. 이후 패킷을 만들되 데이터, 체크섬, 패킷번호를 뭉쳐서 보내고 수신부로부터 NAK이나 패킷이 오류가 난 것이 확인되면 재전송을 수행한다. 만약 ACK이 수신되었다면 패킷번호에 1을 부여하여 다음 데이터를 전송한다. 수신자의 경우 오류가 있거나 패킷 내에 문제가 있다고 판단한 경우 NAK이나 NotCorrupt를 사용하여 문제가 있음을 송신자에게 알린다. 오류가 없는 경우 데이터 추출을 전달하고, ACK과 함께 패킷을 전달한다.

1.4.4. RDT 2.2

RDT 2.0에서 ACK/NAK에서 오류가 발생하지만 NAK은 쓰고 싶지 않은 경우에 대해 이야기한다. RDT 2.1의 업그레이드판과 같은 의미로, 중복 ACK을 받으면 RDT 2.1에서 NAK을 받은 것과 같이 행동한다. 송신부에서는 데이터를 보낸 경우 0+데이터+체크섬으로 수신부에게 보내고, 내용에러, ACK(1)[2]을 받으면 데이터를 재송하도록 패킷(1)에 보낸다. 그 외에는 ACK(0)을 보낸다[3].

1.4.5. RDT 3.0

패킷 오류, 손실오류 모두 생기는 경우를 의미한다. 체크섬, 시퀀스 번호, ACK 등만으로는 불충분하다고 판단하는 경우로 송신자가 타이머를 사용하여 특정 시간이 초과될때 재전송하도록 만드는 경우이다. 이때 성능은 L이 링크 속력, R이 패킷 크기, 전송지연이 RTT으로 표현되는 경우, (L/R)/(RTT+L/R)이 된다. 송신자에게 확인응답을 기다리기 전에 패킷을 추가전송할 수 있는 파이프라인 프로토콜 방식이 있고, 이때 각 파이프의 크기에 따라 성능이 n배로 늘어난다. 파이프라인 프로토콜 방식도 두가지 방식이 있는데, Go-back-N선택적 반복(Selective Repeating)이 있다.[4]

1.5. 둘러보기



[1] 주로 손실, 손상, 재정렬 요소에 따라 다르다. [2] 그전 패킷까지는 잘 받았다는 의미. [3] 현 패킷까지 잘 받았다는 의미 [4] Go Back N이 하노이 탑이라면, 선택적 반복은 샌드위치 방식이다.