MQTT 프로토콜 정의

MQTT Protocol 

 

Message Queue Telemetry Transport 약자

 

이 프로토콜은 사살상 IoT 대표적 프로토콜이라고 말할수 있다. 그 이유는 다음과 같은 장점을 지녔기 때문이다.

장점
1. 프로토콜이 자체적으로 차지하고 있는 리소스를 최소화 하였다. 그로인한 헤더 및 기본 프로토콜이 간소화됨 / 저전력 통신모델
2. 일정한 유선통신에 비해 느리고 낮은 무선 네트워크에 대한 처리방식 보완
3. 클라이언트의 단순화를 통해 동작할 수 있는 환경 및 자원활용에 극대화
4. Pub/Sub/Topic 방식을 채택하여 N 대 N 방식의 활용도가 매우 높음.
5. Qos (Quality of Service) 레벨 모델 적용

 

이와 같은 장점들을 통하여 대표적인 IoT기반 개방형 프로토콜로써의 자리를 잡게 됨.

 

 

상세 분석

 

1. 저전력과 프로토콜 최소화의 관계 ??????

 

   >>  프로토콜에 구조에 보면 보통의 경우 고정 헤더부분과 유동적으로 변하는 Payload영역이 존재한다. 대게 정교하고 정확도, 활용도에

         

         따라 고정 헤더의 기능과 분류가 되는데 MQTT 프로토콜의 경우 기본 고정헤더가 2Byte를 차지하는 아주 간소화된 프로토콜이다.

 

         이 말은 다르게 표현한다면 유, 무선통신에 있어서 통신을 할때 프로토콜의 크기와 양에따라 전력소모량이 많은 차이를 보이게 되는데

 

         최소한의 프로토콜규격으로 전력소모량을 줄인 대표적인 프로토콜이다.

 

 

2. 유선통신에 비해 느리고 낮은 무선 네트워크에 대한 처리방식 보완 = Qos모델

 

   >>  위의 장점중 2번과 5번은 연결되어있는 부분이라서 한꺼번에 설명하도록 한다.

 

         흔히 말하는 유선통신은 말그대로 선을 연결하여 고정적 속도와 안전성을 유지할 수 있다. 그에 비해 무선통신은 주변환경 및 현재

 

         무선통신을 하는 장비에 상황에 따라 통신환경이 좋을때와 좋지 못할때가 같이 존재하게 되는데, 통신환경이 좋을때는 상관없지만

 

         열악하거나 좋지못한 상황의 통신환경에서 최대한의 효율을 내고자 한것이 바로 Qos 방식을 사용한 것이다. 

 

         그럼 Qos란?????????

 

         우선 0~2레벨에 단계가 존재함

 

         - 0 단계 : 한번 전송 (전송 성공 여부와 상관없음)

 

         - 1 단계 : 최소 1번 전달 (중복으로 전달될 가능성이 있음)

 

         - 2 단계 : 정확히 한번만 전달

 

         각 단계별로 규칙을 정해서 고정헤더에 포함되어 전송되며 단계별 레벨에 의해서 방식이 결정된다.

 

 

3.  클라이언트의 활용 극대화와 Pub/Sub/Topic 방식또한 상호연결된다.

 

   >>  클라이언트의 활용 극대화라는 의미는 크게 대단한 기능이 부여되거나 하는 의미와는 조금 다르다. 쉽게 말해 저전력을 유지하기

 

         위한 아주 가벼운 프로세스로 동작하게 되어있어 디바이스나 장치에 있어서 활용도가 굉장히 높다는 의미이다.

 

 

 

         이미지 출처 : http://www.hardcopyworld.com/ngine/aduino/wp-content/uploads/sites/3/2016/01/0912embmqtt01.png

 

         위 그림과 같이 Pub, Sub가 등장하는데 둘다 클라이언트를 의미한다. 그런데 두개는 조금 다른 특징을 가진다.

 

         실제로 사용해 보면 Pub 클라이언트는 일방적으로 해당 메세지를 포함하여 데이터를 전송하고 끊어버린다.

 

         그와 다르게 Sub 클라이언트는 접속한 이후에 사용자가 접속을 종료하기 전까지는 계속해서 Broker에 붙어있다.

 

         이유는 간단하다. 설명했듯이 Pub 클라이언트의 경우 저전력과 데이터 소모량을 줄이기 위해 필요한 데이터만

 

         전송하고 이후에는 접속을 끊어버리는 방식

 

         Sub 클라이언트의 경우는 Pub 클라이언트에서 보낸 데이터를 수신 받는 ..... 즉, read 하기위한 클라이언트이다.

 

         그러면 데이터를 전송하면 Sub가 데이터를 수신하는 경우가 될것이고 필요한 데이터만 수신하고자 한다면 ???

 

         바로 Topic이라는 놈을 통해 원하는 데이터를 수신받도록 할수가 있다.

 

 

출처 : http://dalkomit.com/90

 

        

         위 그림과 같이 Topic의 구조이다. 쉽게 보면 윈도우의 폴더 경로 들어가는것과 유사해 보인다. 

 

         맞는 말이다. 저 트리형태의 구조를 따라 Pub가 원하는 경로( 즉, 데이터를 송신할 경로를 지정하고 Sub도 역시 읽을

 

         데이터의 해당 경로를 찾아가 수신하면 해당 데이터만 받을수 있는 형태이다.
         그럼 Sub의 경우 그룹 또는 상위에서 각각의 데이터들을 모두 읽을수 있지 않을까??????????
         그런 점을 고려하여 와일드카드라는 비장의 무기를 들고있다. +, * 두가지가 있는데 
         (+)의 경우는 같은 부모노드를 가진 형제노드 전부를 구독할때 사용한다.
         (*)의 경우는 단말노드가 아닌 경우 자식노드가 존재하면 해당 자식노드 전부를 동시에 구독할때 사용가능하다.
         

 

이상 간략한 설명 끝.(정리용)