2.1 MQTT

Message Queuing Telemetry Transport(MQTT)는 발행-구독(publish-subscribe) 통신 모델 기반의 비동기식 메시지 전송 프로토콜이다. MQTT는 주로 Machine to Machine (M2M) 과 Internet of Things (IoT) 컨텍스트와 같이 리소스가 제한된 환경을 포함해 다양한 상황에서 사용된다⁽⁴⁾. MQTT는 총 14개의 패킷으로 구성되어 있다. 14개의 패킷을 표시하기 위해 할당하는 바이트 수는 4바이트이며 그 중 0과 15는 사용하지 않는 번호이다. MQTT는 1부터 14까지를 각 패킷들에게 할당한다. MQTT는 신뢰도를 보장하기 위한 3개의 QoS 레벨을 지원한다.

MQTT에서 송신자가 특정한 토픽(topic)으로 메시지를 발행하면 해당 토픽을 구독중인 수신자들은 같은 토픽으로 발행된 모든 메시지를 받아볼 수 있다. 송신자들은 같은 방식으로 토픽에 메시지를 발행할 수 있다⁽⁵⁾. 클라이언트들은 서버를 사이에 두고 통신한다. 서버는 토픽들의 리스트와 각 토픽을 구독 중인 수신자들의 리스트를 가지고 있다. 송신자가 토픽을 설정해 둔 메시지를 발행하면 서버는 발행된 메시지의 토픽을 구독중인 수신자들에게 전달함으로써 메시지를 중계해준다.

토픽과 서버를 이용해 메시지를 중계하는 방식을 사용하기 때문에 송신자와 수신자는 IP주소와 같이 직접적으로 통신하기 위해 필요한 정보가 없어도 통신이 가능하다. 대신 송신자와 수신자는 서로의 정보 및 상태를 알 수 없다. 이 탓에 송신자는 자신이 보낸 메시지가 수신자에게 확실하게 전송되었는지 알 수 없다.

MQTT는 클라이언트와 서버 사이에서 메시지를 발행할 때의 신뢰도를 보장하기 위해 세 개의 QoS 레벨을 제공한다. 각 QoS 레벨은 송신자와 서버 사이, 혹은 서버와 수신자 사이에서 일어나는 통신에 대해 메시지가 얼마나 정확하게 전송될 것인가를 보장해 준다. 각 QoS 레벨은 그 이전의 단계를 포함한다⁽⁶⁾.

QoS 레벨 0에서는 메시지가 최대 한 번 전송된다. 송신자는 PUBLISH 패킷을 전송한 후 메시지가 제대로 도착했는지 확인하지 않는다. 메시지는 중간에서 손실될 수 있다⁽⁶⁾.

QoS 레벨 1과 2에서, 송신자가 PUBLISH 패킷 발행자(publisher)일 경우 수신자는 서버가 된다. 송신자가 서버일 경우엔 수신자가 토픽 구독자(subscriber)가 된다.

QoS 레벨 1은 메시지가 적어도 한 번 전송되는 것을 보장한다. 송신자는 자신이 보낼 PUBLISH 패킷을 저장한 후 수신자에게 전송한다. 수신자는 PUBLISH 패킷을 받았을 경우 PUBACK 패킷을 보내 메시지가 제대로 전송되었음을 알린다. PUBLISH, 혹은 PUBACK 패킷이 중간에서 손실되어 송신자가 응답 패킷인 PUBACK 패킷을 받지 못했을 경우 수신자에게 다시 PUBLISH 패킷을 전송한다. 송신자가 성공적으로 PUBACK 패킷을 받으면 저장했던 PUBLISH 패킷을 삭제한다.

QoS 레벨 2는 4-way handshaking을 통해 메시지가 정확하게 한 번 전송되는 것을 보장한다⁽⁷⁾. 송신자는 자신이 보낼 PUBLISH 패킷을 저장한 후 전송하고, 수신자는 받은 PUBLISH 패킷을 저장한 후 PUBREC 패킷으로 응답한다. PUBREC 패킷을 받은 송신자는 저장해 두었던 PUBLISH 패킷을 삭제한 후 PUBREL 패킷으로 응답한다. 수신자가 PUBREL 패킷을 받으면 저장해 두었던 PUBLISH 패킷을 삭제한 후 PUBCOMP 패킷으로 응답한다. 중간에 패킷이 손실되어 수신자가 PUBREC 패킷을 받지 못했을 경우 PUBLISH 패킷을 다시 한 번 보낸다. 수신자가 PUBCOMP 패킷을 받지 못했을 경우 PUBREL 패킷을 다시 한 번 보낸다.

클라이언트는 구독중인 토픽에 QoS 레벨을 각각 설정할 수 있다. 클라이언트가 서버와 통신하며 발행된 메시지를 받아볼 때 설정된 QoS 레벨이 적용된다. MQTT에서는 클라이언트와 서버 간의 통신에서만 QoS 레벨을 보장하며, 클라이언트와 클라이언트 간의 간접 통신에서는 QoS 레벨에 따른 신뢰도 보장을 지원하지 않는다.

2.2 MQTT의 적용/변형 사례

MQTT는 다양한 분야에서 사용된다. MQTT는 Floodnet, SmartLab, 페이스북 메신저와 같은 곳에서 사용되며⁽⁴⁾, 헬스케어(Healthcare), 에너지 및 유틸리티(Energy and utilities), 소셜 네트워킹(Social Networking)등의 분야에서도 사용된다⁽⁵⁾. 그 외에도 집의 상태를 원격으로 모니터링하고 필요한 작업을 수행할 수 있게 한 MQTT 기반의 홈 오토메이션 시스템에 대한 연구가 있다⁽⁸⁾.

Floodnet은 센서에서 수집한 수위 수치를 바탕으로 홍수가 날 가능성을 예측하는 일종의 홍수 경보 시스템으로, 그리드 기반(Grid-based) 홍수 예측 모델을 사용한다⁽²⁾. Floodnet에서 IBM의 ‘Micro서버’를 사용하기 때문에, 이에 대한 프로토콜로 TCP/IP를 통해 발행-구독 통신 모델을 사용 할 수 있는 MQTT를 선택해 적용했다⁽⁷⁾.

MQTT를 connected health에 사용한 사례는 다음과 같다. 클라이언트를 에이전트와 매니저로 나누어서 환자의 건강정보를 에이전트가 발행하면 서버를 거쳐 매니저가 구독하는 방식이다. 기존 MQTT를 변형/적용한 사례로, 새로운 에이전트를 자동으로 찾을 수 있고 에이전트는 연결 요청을 한번만 보내면 된다는 장점이 있지만, 대신 일반 클라이언트-서버 간 연결보다 패킷의 개수와 길이가 증가한다는 단점이 있다⁽⁹⁾.

페이스북은 MQTT를 페이스북 메신저에 사용해 왔다. MQTT가 얼마나 사용되고, 어디에 사용되는지는 불분명하며, 센서 애플리케이션이 아닌 전화 애플리케이션임을 고려해야 한다⁽⁴⁾.

목적을 가지고 특정 기능들을 추가해 MQTT를 변형한 사례들도 있다. 센서 네트워크에서, MQTT를 보다 작은 센서-액추에이터(SA) 기기들에서 활용하기 위해 변형한 MQTT-S⁽¹⁾와 기존의 MQTT에 geolocation 정보를 추가한 MQTT-G⁽¹⁰⁾가 대표적 예시이다. MQTT 패킷의 고정헤더에 priority-QoS 플래그를 추가해 우선순위를 고려할 수 있게 한 연구도 있다⁽¹¹⁾.

2.3 MQTT와 다른 프로토콜 간의 성능 비교분석

MQTT의 성능을 측정한 연구들도 있다. ⁽¹²⁾의 연구에서는 MQTT와 CoAP를 비교 분석했다. 패킷 손실이 적을 때는 MQTT가 CoAP보다 딜레이가 적다. 메시지 크기가 작고, 패킷 손실률이 25% 이하일 때, CoAP는 MQTT보다 적은 추가 트래픽으로 신뢰성 있는 전송을 보장한다⁽¹²⁾. 그 외에도 MQTT, CoAP, AMQP, HTTP를 메시지 크기와 오버헤드, 지연, 신뢰성 등의 항목에서 비교분석한 연구도 있다⁽¹³⁾.

2.4 CM과 비동기식 시스템에서의 동기식 통신 적용

CM은 분산시스템을 개발할 때 사용되는 애플리케이션 레벨의 통신 프레임워크이다. CM은 애플리케이션의 요구사항에 맞춰 다양한 옵션과 보다 유연한 통신 서비스를 제공한다. 애플리케이션 개발자는 CM이 제공하는 API(Application Pro- gramming Interface)와 설정 파일을 사용하여 CM 노드(CM의 통신 서비스를 이용하는 애플리케이션)가 상호작용을 할 수 있는 다양한 통신 기능을 쉽게 구현할 수 있다. CM 노드는 클라이언트와 서버로 나뉜다⁽³⁾. 본 논문에서는 CM 내에 동기식 통신을 추가한 MQTT를 동기식 발행-구독 통신 서비스로 구현했다.

⁽³⁾의 연구에서는 비동기식 통신을 사용하는 클라이언트-서버 시스템인 CM에서의 직간접 동기 통신을 고안했다. 직접 동기 통신은 직접적으로 연결된 클라이언트와 서버 간의 통신이며, 간접 동기 통신은 서버를 사이에 두고 연결된 클라이언트와 클라이언트 간의 동기식 통신이다. 해당 연구에서는 이벤트 동기화(Event synchronizer) 객체를 통해 직접/간접 동기식 통신을 구현했다. 우선, 메시지 송신측의 메인 스레드에서 이벤트 동기화 객체에 전송할 이벤트와 그에 대한 응답 이벤트의 타입, 기다릴 응답 이벤트의 수를 등록해 두고 wait()를 호출해 대기 상태가 된다. 메시지 송신측의 프로세싱 스레드에서 서버로부터 응답 이벤트를 수신하면 프로세싱 스레드는 수신한 이벤트가 이벤트 동기화 객체에 등록되어 있는 응답 이벤트의 타입과 같은지 확인한다. 수신한 이벤트가 기다리고 있던 응답 이벤트와 같을 경우 이벤트 동기화 객체에 등록한다. 이벤트 동기화 객체에 등록된 개수 이상의 응답 이벤트를 받을 경우, 송신측의 프로세싱 스레드는 notify()를 통해 송신측의 메인 스레드를 깨운다. 해당 연구에서 동기식 통신의 성능 분석 결과, 순차적으로 작업을 진행해야 할 필요가 있을 때는 동기식 통신이 비동기식 통신에 비해 효율적이었다.

3.1 동기식 통신 방법 개요

QoS 레벨 3에서는 서버를 사이에 두고 송신자와 수신자간의 4-way handshaking이 진행된다. 그림 1은 QoS 레벨 3의 동기식 통신 과정을 나타낸다. QoS 3의 전체적인 과정은 QoS 2와 유사하다. 우선 송신자는 자신이 기다릴 패킷의 수(waited_ packet_num)를 설정하고 자신이 보낼 PUBLISH 패킷을 저장한다. 이후 송신자는 PUBLISH 패킷을 토픽 T로 발행한다. 발행된 PUBLISH 패킷은 서버에게로 전송된다. PUBLISH 패킷 전송 후, 송신자는 대기 상태가 된다.

송신자가 보낸 PUBLISH 패킷을 받은 서버는 subscriber_id 필드를 확인해 송신자가 특정 수신자를 지목했는지 확인한다. 송신자가 특정 수신자를 지목했을 경우 서버는 송신자가 지목한 수신자들 중 토픽 T를 구독 중인 수신자들에게 PUBLISH 패킷을 전송한다. 송신자가 어떤 수신자도 지정하지 않았을 경우, 서버는 토픽 T를 구독 중인 모든 수신자들에게 PUBLISH 패킷을 전송한다. 이후 서버가 PUBREC, PUBRE, PUBCOMP 패킷을 받았을 경우, 서버는 송신자와 수신자의 메시지를 그대로 전달하기만 하고 별도의 추가적 처리는 하지 않는다.

수신자는 자신이 받은 PUBLISH 패킷을 저장한 이후 PUBREC 패킷으로 응답한다. PUBREC 패킷은 서버를 통해 송신자에게 전달된다. PUBREC 패킷을 받은 송신자는 수신자가 자신이 보낸 메시지를 받았음을 확인하고, PUBREC 패킷을 저장한다. 이때, 송신자가 받은 PUBREC 패킷의 개수가 미리 지정했던 기다릴 패킷의 수(waited_packet_num) 이상이 될 경우, 송신자는 notify()를 통해 동기식 통신을 종료하고 저장해 두었던 PUBLISH 패킷을 삭제한다.

PUBREC 패킷을 받은 직후 송신자는 수신자에게 PUBREL 패킷을 전송하고, PUBREL 패킷을 저장한다. PUBREL 패킷은 서버를 통해 수신자에게 전송된다. 수신자가 PUBREL 패킷을 받으면 저장해 두었던 PUBLISH 패킷을 삭제하고 PUBCOMP 패킷을 전송한다. PUBCOMP 패킷은 서버를 통해 송신자에게 전송된다. 송신자가 PUBCOMP 패킷을 받아 저장해 두었던 PUBREL 패킷을 삭제하면서 PUBLISH 과정이 끝난다.

메시지 전송 순서를 보장하기 위해 송신자가 PUBLISH 패킷을 보냈을 때부터 PUBREC을 받을 때 까지는 동기식으로 진행되며, 타임아웃 시간을 잡음으로써 패킷이 손실되었을 경우 무한히 기다리지 않도록 한다. 그 외의 전송 과정은 비동기식으로 진행한다.

3.2 패킷 구성

기존의 MQTT에서는 패킷의 종류를 표기하기 위해 bit 7-4, 4개의 비트를 할당한다. 패킷은 총 15개로, 0000부터 1110까지의 번호를 쓰고, 15는 비어있는 번호이다. 그림 2는 기존 MQTT의 PUBLISH 패킷 고정 헤더의 구조이다. 기존 PUBLISH 패킷의 경우 bit 7-4는 14가지의 패킷 타입을 표기하기 위해 사용하고, bit 3은 DUP 플래그(flag)를 표기하기 위해, bit 2-1은 QoS 레벨을 표기하기 위해 사용한다. 기존 QoS 레벨은 0-2까지 총 3개가 있으며, 3은 비어있는 자리이다.

그림 3은 PUBLISH QoS 2의 응답 패킷들인 PUBREC, PUBREL, PUBCOMP의 고정 헤더를 나타낸다. PUBREC, PUBREL, PUBCOMP의 경우, 총 8비트 중 bit 7-4, 4개의 비트는 패킷 타입을 표기하기 위해 사용하고, bit 3-0까지는 사용하지 않는다.

MQTT에서 패킷의 종류를 표기하기 위해 4비트를 할당하기 때문에, QoS 3을 위해 필요한 패킷을 추가할 경우 2개 이상의 패킷이 추가된다면 패킷 표시를 위해 할당하는 비트 수를 늘려야 한다. 패킷 지정을 위해 할당되는 비트 수를 고정하는 동시에 통일성을 주기 위해 QoS 레벨 3에서는 QoS 레벨 2에서의 패킷을 그대로 사용하는 대신 필요한 필드를 추가했다. 그림 4는 QoS 레벨 3을 구현하기 위해 수정한 PUBREC, PUBREL, PUBCOMP 패킷의 고정 헤더이다. 기존 MQTT의 PUBREC, PUBREL, PUBCOMP 패킷의 고정 헤더의 bit 2-1에 QoS 필드를 추가 했다. QoS 필드가 추가되는 위치는 bit 2-1로, 기존 PUBLISH 패킷에서 QoS 필드가 있는 자리와 동일하다. QoS 필드의 값이 2일때는 기존 MQTT QoS 2의 과정을 따르고, 3일때는 QoS 3의 과정을 따른다.

MQTT에 동기식 통신을 적용하기 위해 비동기식 통신을 사용하는 클라이언트-서버 시스템에서 직간접 동기 통신을 고안한 연구⁽³⁾을 참조했다. PUBLISH-PUBREC의 동기식 통신 과정에서, 송신자는 자신이 기다릴 메시지의 수를 지정할 수 있다. 예를 들어 송신자가 자신이 기다릴 메시지의 수를 2로 설정했을 경우, 송신자는 두 개의 응답메시지를 받은 이후 기다리는 것을 종료하고 다음 작업을 수행한다. 해당 파라미터는 반드시 값을 할당해야 하는 파라미터이며, 기다릴 메시지의 최소 개수는 1개이다.

상호작용이 필요한 상황이란 점을 고려해 해당 메시지를 받게 될 수신자 정보를 입력할 수 있는 필드를 PUBLISH 패킷 페이로드(payload)의 애플리케이션 메시지 필드 다음에 추가했다. 수신자 정보를 입력할 경우, 지정한 수신자에게 메시지가 전송된다. 해당 필드는 옵션 필드로, 입력하지 않아도 괜찮은 필드이다.

3.3 동기식 통신 세부 과정

그림 5는 송신자 측의 실행 과정을 나타낸 그림이다. 우선 송신자 측에서, 사용자가 MQTT PUBLISH QoS 3 요청을 보내면 CM의 메인 스레드에서 사용자의 발행 요청을 처리한다. 메인 스레드는 unackevent list에 PUBLISH 패킷을 등록한 후, 자신이 받은 요청을 서버에 보내기 위해 송신 스레드에 PUBLISH 이벤트를 전달한다. 송신 스레드는 PUBLISH 이벤트를 서버에 전송한다. 이후 메인 스레드는 이벤트 동기화(Event synchronizer) 객체에 PUBLISH QoS 3 이벤트를 등록하고, wait() 함수를 호출하여 알맞은 응답 패킷이 지정 개수 이상 올 때까지 대기한다. 이후 프로세싱 스레드가 notify() 함수를 통해 메인 스레드를 깨우면, 메인 스레드는 이벤트 동기화 객체에 등록되어 있는 PUBREC 이벤트를 확인한다.

송신자의 프로세싱 스레드는 수신 스레드로부터 들어오는 외부의 이벤트들을 처리하는 스레드이다. QoS 3 과정에서 메인 스레드가 잠든 이후 프로세싱 스레드가 수신 스레드로부터 PUBREC 이벤트를 받으면 프로세싱 스레드는 서버로 PUBREL 이벤트를 전송한 이후 unackevent list에 PUBREL 패킷을 등록한 후 이벤트 동기화 객체에 자신이 받은 PUBREC 이벤트를 등록한다. 등록되어 있는 PUBREC 이벤트의 개수가 송신자가 지정한 최소 응답 개수 이상일 경우 프로세싱 스레드는 unackevent list에서 PUBLISH 패킷을 삭제하고, notify() 함수를 호출해 메인 스레드를 깨운다. 프로세싱 스레드가 PUBCOMP 패킷을 받았을 경우, unackevent list에 저장되어 있는 PUBREL 패킷을 삭제하고 동기식 발행 처리 과정이 끝난다.

그림 6은 서버의 실행 흐름을 나타낸 그림이다. 서버가 송신자로부터 PUBLISH QoS 3 패킷을 받으면 자신이 받은 PUBLISH 이벤트에 수신자 ID가 지정되어 있는지 확인한다. 송신자가 지정한 수신자 ID가 있을 경우, 받은 PUBLISH 패킷에 입력되어 있는 토픽을 구독하는 수신자 중 지정한 ID를 가진 클라이언트들에게 PUBLISH 패킷을 전달한다. 수신자 ID가 지정되어 있지 않을 경우, PUBLISH 패킷에 입력되어 있는 토픽을 구독 중인 모든 클라이언트들에게 PUBLISH 패킷을 전달한다. 서버가 클라이언트로부터 QoS 3 PUBREC, PUBREL, PUBCOMP 패킷을 받은 경우에는, 이를 수신해야 하는 클라이언트들에게 해당 패킷을 그대로 전달한다.

그림 7은 수신자의 실행 흐름을 나타낸 그림이다. 수신자가 서버로부터 PUBLISH QoS 3 패킷을 받으면 unackevent list에 PUBLISH 패킷을 저장한 후 서버로 QoS 3 PUBREC 패킷을 전송한다. 수신자가 서버로부터 QoS 3 PUBREL 패킷을 받으면 unackevent list에서 같은 ID를 가진 PUBLISH 패킷을 삭제한 이후 서버에게 PUBCOMP 패킷을 전송한다.

4.1 클래스 및 메소드

QoS 3의 처리 과정에 있어 중요한 클래스들은 CMMqtt- Manager와 CMMqttEventHandler이다. 그림 8은 CMMqttManager와 CMMqttEventHandler의 클래스 다이어그램이다.

CMMqttManager 클래스는 CM 클라이언트 애플리케이션에서 MQTT 서비스를 요청했을 때 해당 요청을 처리하는 클래스이다. 클라이언트로부터 MQTT PUBLISH 요청이 들어오면 CMMqttManager 클래스는 우선 사용자가 PUBLISH 패킷을 발행하는 데에 필요한 파라미터를 전부 입력했는지 확인한다. 토픽과 메시지는 사용자가 반드시 입력해야 하는 파라미터이다. QoS, DUP 플래그와 retain 플래그, 수신자의 ID값과 기다릴 최소 응답 개수 파라미터는 사용자가 입력하지 않았을 경우 디폴트값을 넣는다. 이후 QoS 0-2의 경우 publishFromClient() 메소드에서, QoS 3의 경우 syncpubFromClient() 메소드에서 해당 발행 요청을 처리한다. 클라이언트에서 보낸 발행 요청을 서버가 받으면, 서버는 자신이 받은 PUBLISH 패킷의 QoS와 토픽, QoS 3일 경우 수신자를 지정하는 필드를 확인한다. QoS 레벨이 3이고 송신자가 수신자를 지정했을 때엔 송신자가 지정한 클라이언트들 중 같은 토픽을 구독 중인 클라이언트들에게, 그 이외의 경우일 때엔 같은 토픽을 구독중인 클라이언트들에게 전송받은 PUBLISH 패킷을 일제히 발행한다. 서버가 송신자에게서 받은 PUBLISH 패킷을 발행할 때, QoS 레벨이 0-2라면 publishFromServer() 메소드가, QoS 3이라면 syncpub- FromServer() 메소드가 사용된다.

CMMqttEventHandler 클래스는 CM이 외부에서 들어온 CM MQTT 이벤트를 받았을 때 해당 이벤트들을 프로세싱하는 클래스이다. CM이 MQTT 이벤트를 받으면 CMMqttEventHandler의 processEvent() 메소드가 호출된다. processEvent()는 받은 MQTT 이벤트의 패킷 타입을 구별하고 각 패킷 별 프로세싱 함수를 호출한다. 각 패킷의 처리 메소드들은 MQTT ver 3.1.1에 맞게 해당 패킷을 받았을 때 해야 하는 일들을 실행한다. processEvent()가 PUBLISH 이벤트를 받은 경우 처리 메소드로 processPUBLISH()가 호출된다. processPUBLISH() 메소드는 받은 PUBLISH 이벤트의 QoS 레벨을 확인한다. QoS 레벨이 0-2일 경우 processPUBLISH() 메소드는 MQTT 프로토콜에 따른 응답 패킷을 전송하는 함수를 호출한다. QoS 레벨이 3일 경우 processQoS3() 메소드를 호출해 QoS 3용 응답 패킷을 전송한다. PUBREC, PUBREL, PUBCOMP 패킷을 받았을 경우 pro- cessEvent()는 각 패킷에 맞는 처리 메소드들을 호출한다. PUBREC, PUBREL, PUBCOMP의 처리 메소드들은 우선 받은 패킷의 QoS 레벨을 확인한다. QoS 레벨이 2이면 해당 메소드에서 기존 MQTT 프로토콜에 따른 작업을 수행 한다. QoS 레벨이 3이면 QoS3 처리 메소드들을 호출한 이후 실행을 끝낸다. QoS3 처리 메소드들은 본 논문에서 고안한 QoS 3에 따른 작업을 수행한다. 처리 메소드들은 작업 수행 과정에서 MQTT 이벤트를 보낸 측에게 알맞은 응답 패킷에 해당하는 MQTT 이벤트를 보낸다. MQTT 이벤트를 보낼 때에는 전송 메소드들이 호출되어 알맞은 패킷을 지정된 대상에게 전송한다.

4.2 추가 필드(MQTT sender/receiver)

CM에는 메시지의 직접 송신 노드와 수신 노드를 지정하는 sender/receiver 파라미터가 있다. 이 때, 서버가 송신자 및 수신자가 된다. 그러나 QoS 3을 구현하기 위해서는 중간 단계의 서버가 아닌 클라이언트인 송신자(publisher)와 수신자(subscriber)를 지정하는 파라미터가 추가로 필요하다. 그러한 이유로, 실제 구현에서는 그림 9와 같이 최종 목적지를 나타내는 MqttSender/MqttReceiver 필드를 가변 헤더에 추가했다.

5.1 실험 환경

실험은 기기 두 대로 진행했다. 서버와 수신자는 데스크탑 PC에서, 송신자는 노트북 PC에서 실행시켰다. 서버와 수신자 애플리케이션을 실행시키는 PC를 PC1, 송신자 애플리케이션을 실행시키는 PC를 PC2라고 칭한다. PC1과 PC2의 기기 사양 및 네트워크 환경은 표 1과 같다. PC1은 이더넷을 통해 유선으로 네트워크에 연결했으며, PC2는 Wifi를 통해 무선으로 네트워크에 연결했다.

5.2 송신자-수신자 간의 라운드트립 지연시간

첫 번째 실험에서는 클라이언트들 간의 응답 확인이 필요한 경우, 즉 수신자가 메시지를 받았다는 사실을 송신자가 알아야 할 경우를 가정하고 응답 지연시간을 측정했다. QoS 3의 경우, 수신자는 응답을 위해 별도의 PUBLISH 패킷을 만들지 않아도 된다. QoS 3 PUBLISH에 대한 응답 패킷으로 수신자는 QoS 3 PUBREC을 전송한다. QoS 2의 경우, 수신자는 송신자가 보낸 PUBLISH 패킷을 받은 이후, 새로운 PUBLISH 패킷을 만들어 보냄으로써 송신자에게 응답해야 하므로, 전송 과정이 하나 더 추가된다. QoS 2와 QoS 3에서 이동하는 패킷 수의 차이를 최대한 줄이기 위해, 기존 MQTT QoS 레벨 중 가장 전송 과정이 단순한 QoS 0 PUBLISH 패킷을 QoS 2 PUBLISH 패킷의 응답 패킷으로 삼았다.

먼저 기존 MQTT의 QoS 레벨 2의 경우, 송신자는 수신자의 응답을 받기 위해 미리 토픽 B를 구독하고, 토픽 A로 QoS 2 PUBLISH 패킷을 발행한다. 수신자는 토픽 A를 구독하고 있다가 송신자가 보낸 QoS 2 PUBLISH 패킷을 받는 즉시 QoS 0 PUBLISH 패킷을 토픽 B로 발행함으로써 송신자에게 응답한다. 송신자는 토픽 B를 구독하고 있다가 수신자가 보내는 QoS 0 PUBLISH 패킷을 전달받고 수신자가 송신자가 발행한 QoS 2 PUBLISH 패킷을 제대로 전달받았음을 확인한다.

QoS 레벨 3의 경우 송신자는 토픽 A로 QoS 3 PUBLISH 패킷을 보내고, 수신자는 QoS 3 프로토콜대로 QoS 3 PUBREC 패킷을 보냄으로써 송신자에게 응답한다. 송신자는 QoS 3 PUBREC 패킷을 받음으로써 수신자의 응답 확인을 위한 별도의 토픽을 구독하지 않아도 수신자가 자신이 보낸 PUBLISH 패킷을 제대로 받았는지 확인할 수 있다.

QoS 레벨 2에서는 송신자가 QoS 2 PUBLISH를 보냈을 때부터 수신자가 QoS 0 PUBLISH를 보낼 때까지, QoS 레벨 3에서는 송신자가 QoS 3 PUBLISH를 보냈을 때부터 수신자가 QoS 3 PUBREC을 보낼 때까지의 시간을 측정했다. 클라이언트의 수를 1개에서 50개까지 늘려가며 첫 번째 실험을 진행했다. 그림 10은 해당 실험의 결과를 그래프로 나타낸 것이다.

실험 결과, 초반에는 QoS 3이 시간이 더 오래 걸렸으나, 수신자의 개수가 20개가 되면 QoS 2와 QoS 3의 지연시간이 비슷해지고, 25개가 넘어가면 QoS 3의 지연시간이 QoS 2의 지연시간보다 짧아졌다. QoS 3에서는 송신자 애플리케이션에서 동기화에 필요한 지연이 발생하는 반면 QoS 2에서는 그러한 비용이 발생하지 않는다. 다른 측면으로는, 애플리케이션 레이어가 아닌 CM의 MQTT 레이어에서 응답 과정이 처리되는 QoS 3과는 달리, QoS 2의 경우 수신자가 보내는 응답을 확인하기 위해 애플리케이션 레이어에서 추가적인 과정을 거치기 때문에 딜레이가 생긴다. 서버 애플리케이션에서는 송신자가 전달한 PUBLISH 패킷의 토픽을 확인하고 구독 중인 수신자들에게 전달하는 딜레이가 공통적으로 생기는데, QoS 2의 경우 이에 더해 수신자가 응답 패킷을 전달할 때도 해당 패킷의 토픽을 확인하고, 해당 토픽을 구독 중인 송신자에게 패킷을 전송하는 과정에서 생기는 딜레이가 추가된다. QoS 3에서는 수신자의 응답 패킷인 QoS 3 PUBREC을 수신할 경우 프로토콜대로 송신자에게 전달하기만 하면 되므로 QoS 2일 때 서버에서 생기는 추가적인 과정 또한 생략된다.

결국, 수신자의 수가 적을 경우에는 QoS 3의 동기화 비용의 영향이 커서 지연시간이 더 길었고, 수신자의 수가 증가하면서 메시지 송수신 과정에서 QoS 2의 지연 요인이 더 크게 작용하여 QoS 3의 지연시간이 짧아진 것으로 분석된다.

5.3 송신자의 발행 완료 지연시간

두 번째 실험에서는 클라이언트들 간의 응답 확인이 필요하지 않은 경우 송신자의 발행 완료 지연시간을 측정했다. 이는 송신자 측에서 인지하는 PUBLISH 전체 과정에 걸린 시간, 즉 송신자가 PUBLISH를 한 이후 서버로부터 PUBCOMP 패킷을 받기까지 걸린 시간이다. 시간은 송신자 측에서 측정 했고, 클라이언트의 수를 1개에서 50개까지 늘려가며 실험을 진행했다. 그림 11은 해당 실험 결과를 그래프로 나타낸 것이다.

실험 결과 QoS 3이 전체적으로 오래 걸렸다. QoS 2의 경우 송신자가 메시지를 발행하는 것과 수신자가 구독한 메시지를 받아보는 과정이 서로 무관하게 일어난다. 기존에 존재하는 MQTT의 QoS 2는 송신자가 서버에게 메시지를 정확히 한 번 발행하는 것을 보장한다. 송신자가 QoS 2 PUBLISH 패킷을 발행하면, 송신자와 서버 사이에 4-way handshaking이 일어나며, 송신자가 PUBLISH 패킷을 보냈을 때부터 서버에게 PUBCOMP 패킷을 받기까지의 통신과정에서 총 4번의 메시지 전송과정을 거친다. 반면 QoS 3의 경우 송신자의 메시지가 수신자에게 정확히 한 번 동기적으로 발행되는 것을 보장한다. 이 과정에서 서버는 송신자와 수신자 사이에 오가는 패킷을 전달하는 역할을 하며, QoS 2와는 달리 송신자에게 별도의 응답 패킷을 보내지 않는다. 그렇기 때문에 QoS 3에서는 송신자가 PUBLISH 패킷을 보냈을 때부터 서버에게 PUBCOMP 패킷을 받기위해 송신자와 서버, 서버와 수신자 간에 총 8번의 메시지 전송과정을 거쳐야 한다. 이 때문에 QoS 3에서 송신자가 PUBCOMP 패킷을 받기 까지 QoS 2에 비해 메시지 전송 과정이 두 배 정도 많다. 또한 QoS 3에서는 송신자가 PUBLISH 패킷을 보냈을 때부터 일정 개수 이상의 PUBREC 패킷을 받기까지의 과정을 동기식으로 처리하므로, 이로 인해 송신자가 수신자의 PUBREC 패킷을 기다리는 지연시간이 더해진다. QoS 2와 QoS 3의 발행완료 지연시간의 차이는 이러한 원인으로 인해 발생한 것으로 분석된다.

5.4 수신자의 발행 완료 지연시간

세 번째로, 상호작용이 필요하지 않은 상황에서 송신자가 PUBLISH 패킷을 보냈을 때부터 수신자가 서버를 통해 송신자의 메시지를 받고 응답 패킷을 보낼 때까지의 지연시간을 측정했다. 송신자와 수신자 애플리케이션을 실행하는 PC가 달라 송신자 측에서 수신자가 메시지를 받는 시간을 측정 하여 계산할 수 있는 방법이 없었으므로, 서버 측에서 송신자가 보낸 PUBLISH패킷을 받았을 때부터 수신자가 보낸 응답 패킷을 받을 때까지의 시간을 측정했다. 첫 번째 실험에서와 마찬가지로, QoS 2와 QoS 3에서 이동하는 패킷 수의 차이를 최대한 줄이기 위해 기존 MQTT QoS 레벨 중 가장 전송 과정이 단순한 QoS 0 PUBLISH 패킷을 QoS 2 PUBLISH 패킷의 응답 패킷으로 삼았다.

수신자가 QoS 2 PUBLISH 패킷을 받았을 경우, 그에 대한 응답 패킷으로 QoS 0 PUBLISH 패킷을 전송한다. 서버 애플리케이션에서는 송신자가 전송한 QoS 2 PUBLISH 패킷을 받았을 때부터 수신자가 전송한 QoS 0 PUBLISH 패킷을 받을 때까지의 시간을 측정한다. 수신자가 QoS 3 PUBLISH 패킷을 받았을 경우, 그에 대한 응답 패킷으로 QoS 3 PUBREC 패킷을 전송하므로, QoS 3 PUBLISH 패킷을 받았을 경우 수신자는 응답을 위해 새로운 PUBLISH 패킷을 만들어 보낼 필요가 없다. 서버 애플리케이션에서는 송신자가 전송한 QoS 3 PUBLISH 패킷을 받았을 때부터 수신자가 전송한 QoS 3 PUBREC 패킷을 받을 때까지의 시간을 측정한다. 세 번째 실험의 경우 QoS 2와 QoS 3 모두 송신자가 서버로 메시지를 발행하고, 서버가 수신자에게 해당 메시지를 전송하며, 메시지를 받은 수신자가 서버에게 응답 패킷을 보내기까지 총 3번의 메시지 전송과정을 거친다.

이전 실험들과 마찬가지로 클라이언트의 수는 1개에서 50개까지 늘려가며 실험을 진행했다. 그림 12는 해당 실험 결과를 그래프로 나타낸 것이다.

실험 결과, QoS 3이 시간을 좀 더 많이 소모했으나 두 번째 실험에 비해 QoS 2와 QoS 3의 지연시간의 차이가 적었다. 세 번째 실험의 경우 QoS 3과 QoS 2 모두 메시지를 총 3번 전송한다. 따라서 통신과정에서 메시지 전송 횟수에 의해 발생하는 지연시간의 차이는 없다. QoS 3의 지연시간이 QoS 2의 지연시간보다 큰 이유는 다음과 같이 분석된다. 우선, 실험을 진행할 때 메시지를 20회 연속으로 발행하는 것을 한 세트로 정하고 시간을 한 세트 단위로 측정했다. QoS 3의 경우 PUBLISH 패킷을 발행한 이후 수신자의 PUBREC 패킷이 도착할 때까지 기다린 이후에 다음 PUBLISH 패킷을 발행한다. QoS 2는 응답 패킷이 도착하는 것을 기다리지 않기 때문에 PUBLISH 패킷을 발행한 직후 바로 다음 PUBLISH 패킷을 발행하게 된다. 이로 인해 QoS 3에서는 동기식 통신으로 인한 지연시간이 발생 한다. 또한 QoS 2의 경우 첫 번째 실험과 마찬가지로 QoS 2의 경우 수신자가 보내는 응답을 확인하기 위해 애플리케이션 레이어에서 추가적인 과정을 거치기 때문에 생기는 지연시간이 추가된다. 이 두 딜레이들이 상충하며 두 번째 실험의 결과에 비해 QoS 2와 3의 지연시간의 차이가 작아진 것으로 분석된다. 세 번째 실험에서 나타난 지연시간의 차이는 이로 인해 발생한 것이며, 통신과정에서의 메시지 전송 횟수에 의한 차이가 없기 때문에 5.3에서 나타난 실험 결과에 비해 QoS 2와 QoS 3 간의 지연시간의 차이가 적다.

5.5 메시지 크기 측정

마지막으로, 최종 목적지인 수신자를 지정하지 않은 PUBLISH 과정에서 이동한 패킷들의 크기를 바이트 단위로 측정했다. PUBLISH, PUBREC, PUBREL, PUBCOMP 패킷의 고정 헤더, 가변 헤더, 페이로드의 크기를 각각 측정 했다. CM에서 MQTT 패킷을 발행할 때 MQTT 이벤트를 CM 이벤트로 감싸서 전송하기 때문에, 메시지 크기를 측정할 때 MQTT 패킷의 헤더 이외에 CM 헤더를 포함한 전체적인 패킷 크기를 측정했다. CM 헤더의 크기는 PUBLISH, PUBREC, PUBREL, PUBCOMP 패킷 모두 같다.

그림 13은 측정 결과를 그래프로 나타낸 것이다. PUBLISH 패킷의 경우, QoS 3에서 별도의 수신자 정보를 저장하지 않았기 때문에 QoS 2와 3 모두 토픽을 구독 중인 모든 수신자들에게 메시지를 보내게 된다. QoS 3에서 수신자 정보를 저장하지 않기 때문에 QoS 2와 3의 패킷 크기가 동일하게 측정 되었다. QoS 3 PUBREC, PUBREL, PUBCOMP 패킷들의 경우 통신 중인 대상 수신자의 정보를 저장하고 있기 때문에 가변헤더에서 메시지 크기가 2-4바이트 증가했다. 이는 QoS 3을 구현하기 위해 해당 패킷들의 가변 헤더에 이 패킷이 도달할 최종 목적지를 저장해 두어서 발생한 차이이다. QoS 2 PUBREC, PUBREL, PUBCOMP 패킷들에는 최종 목적지에 대한 정보가 별도로 저장되지 않았다. 최종 목적지에 해당하는 파라미터의 유무로 인한 차이 외에는 두 QoS 레벨 간의 차이는 없었다.

표 2는 송신자가 보낸 메시지를 받게 될 수신자 정보를 입력했을 경우, QoS 레벨과 미리 지정해 둔 수신자의 수(s_num)에 따른 각 패킷들의 크기를 바이트 단위로 측정한 결과이다. 해당 결과는 송신자가 QoS 3 패킷을 전송받을 수신자의 ID를 미리 지정하여 서버로 보냈을 경우의 결과로, 동기식 통신을 위해 몇 개의 응답 패킷을 기다릴 것인지 정하는 필드와는 무관하다. 몇 개의 응답 패킷을 기다릴 것인지 결정하는 필드는 패킷의 크기에 영향을 주지 않았다. 송신자 측에서 메시지를 발행할 때 지정한 수신자의 수(s_num)를 하나씩 늘려가며 패킷의 크기를 측정했다.

QoS 레벨 3에서 PUBLISH 패킷은 메시지를 전송받을 모든 수신자의 리스트를 저장 한다. 따라서 미리 지정해 둔 수신자의 수가 하나 증가할 때마다 PUBLISH 패킷의 크기는 3바이트씩 증가했다. PUBREC, PUBREL, PUBCOMP의 경우 모든 수신자의 리스트를 저장하는 PUBLISH 패킷과 달리 자신이 현재 통신 중인 대상의 정보만을 저장한다. QoS 3 PUBREC, PUBREL, PUBCOMP 패킷은 단 하나의 정보만을 저장하기 때문에 기존 QoS 2 PUBREC, PUBREL, PUBCOMP 패킷보다 패킷의 크기가 2-4바이트 더 컸고, 송신자 측에서 지정한 수신자의 수에 따른 증가 추세는 없었다.