MQTT 프로토콜

이는 Lightweight 하고  iot에 적합한 프로토콜이다. 

전반적인 구조와 상세 동작에 대해서 알아보자.

 

MQTT의 역사는 2000년도에 유비쿼터스와 함께 등장했다. 

MQTT의 Full name은 Message Queuing Telemetry Transport Lightweight messaging이다

메시지 큐를 쓰며 Lightweight 한 iot용 프로토콜이라는 뜻이다.

 

특징은 위와 같은데 몇 가지만 언급 하면...

1. 네트워크 Edge단에 특화단 경량 프로토콜

2. TCP/IP를 쓰고 Pub/sub구조를 가진다. 

3. 지연되는 상황에도 Working 한다.

4. iot환경에 적합하다.

동작 구조는 위와 같다. 

센싱 된 데이터를 Publisher가 Publish 하면 MQTT브로커(= gateway에 구현)가 관리하고 이를 Subscribe하는 Consumer가 데이터를 받아간다.

 

위 그림은 온도센서가 연결되어 있고 온도를 Publish하면 PC나 Mobile이 Subscribe 해서 받아오는 것이다.

이때  Connecting이 끊어져도 MQTT Broker가 가지고 있던 데이터를 토대로 적절히 서비스를 해준다. 

장점은 produer/consumer입장에서 많은 기기들이 연결돼도 이에 대한 것은 알 수가 없으며 상호운용성이 높다. 

즉 여러 기기들이 모두 운용 가능하다는 것이다. 

이때 Publish 하고 Subscribe 하는 단위는 Topic이라고 한다. 

즉 Topic형태로 데이터를 보내고 이를 제공하는 것이다. 

위 그림을 보면 home/rooms/kitchen/temperature로 결국 temperature을 받아오게 된다.

 

다른 예제를 보자. 

두 가지 두론이 있는 걸 짐작할 수 있다. 

하나는 Hobby/Mihai/Drone1이고 하나는 Drone2이다. 

저 드론에 맞는 Position, BatterCharege 등을 subscribe 하여 데이터를 받아올 수 있다.

 

이때 wildcard개념이 만들어진다. 

여러 토픽들에 대한 구독 개념으로 이해하면 된다. 

+은 해당 single level을 대체해준다.

ex> /Hobby/Mihai/+/Position은 Drone1,2를 모두 포함하는, Drone level을 대체해준다.

 

#은 multiple level을 대체한다.

ex> /Hobby/Mihai/#은 Mihai아래 level모두를 포함하는 개념이 된다.

 

 

Subscription개념을 조금 더 살펴보자.

 

Durable은 연속적인 구독 - QOS1이라고 한다.

그림을 보면 connected가 일어났다가 끊어져도 계속 살아 있다. 

subscription이 끊을땐 clean session명령어 통해서 끊어지게 된다.

 

Non-Durable은 Transient라고도 하며 비연속적인 구독이다. 이는 QOS0이라고 부른다

구독하다가 네트워크 끊어지면 구독이 끝난다.(브로커와의 연결연결) 즉 다시 재 구독을 해야함

Connection time = subscription time

 

하나의 Broker가 이러한 구독을 관리하는데 여러 Client에 따른 구독 방법이 차이가 있다. 

따라서 각각에 대해서 버퍼 관리를 하게 된다.

위에선 Subscription에서의 qos를 보았는데 이번에는 Publishing에서의 Qos이다.

0이면 udp와 같은 메커니즘을 가진다. 받든 말든 딱 한번 보내고 나면 끝이다. 

1이면 적어도 한번 이상. 복제된 형태로 보내게 된다. 

2는 딱 한번 전송되며 TCP와 같은 Handshake과정을 거치게 된다. 

 

 

이는 MQTT에 상태를 Retain 한다는 개념으로 가용성을 높여준다.

위 그림을 보면 Disconnect가 일어난다. 

하지만 Subscribe는 계속해서 값을 받게 되는데 이는 마지막 Publish의 값인 93을 MQTT Broker가 Retain 하기 때문이다.

이 값을 보내줌으로써 연속적으로 데이터를 받을 수 있다.

이는 조금 다른 방식으로도 활용되는 개념인데 

2,3,4,5번 흐름을 보자. 

Server는 MQTT Broker로서 하나의 값을 Retain 하고 있다.

그리고 이 값을 Subscribe 하고 있는 A에게 전달하게 된다. 

B는 뒤늦게 구독을 하게 되지만 이에 대한 Retain값을 받아볼 수가 있다. 

또 다른 개념은 LWT이다. 이는 유언장이라는 뜻으로 network가 끊어졌을 때 전달하는 말을 미리 보내는 것이다.

 

위 그림을 보면 2는 Subscribe Thing1의 status를 받고자 한다. 

1은 MQTT Broker와 통신하며 LWT를 주기적으로 보낸다. 

그러다 어느 순간에 Device1의 연결이 안 되는 순간이 생긴다. 

Thing2는 이때 Broker에게 Thing1이 남긴 유언을 듣는다. 

 

이번엔 MQTT의 보안적 특성에 대해 살펴보자.

크게 두 가지가 있다. 

첫 번째는 Username/password로 연결하는 것이고

두 번째는 SSL/TLS를 사용하는 것이다. 

MQTT의 메시지 포맷은 위와 같다. 

첫 2 byte는 헤더용 필수이고 그 이상이 될 수도 있다. 

이후에는 메시지에 대한 내용이 들어온다. 

첫 byte의 4 bits를 통해서 총 16개의 메시지 타입이 정해지는데 PUB관련한 Name은 Publisher와 MQTT Broker간의 메세지 교환에서 쓰이는 타입이라고 생각하면 된다. 

 

QOS0는 Publish

QOS1는 Publish - Puback

QOS2는 Publish - Pubrec - PubRel - Pubcomp 

로 이루어지며 이는 위 메세지 타입에서도 찾아볼 수 있다. 

 

QOS0은 단순하게 Publisher가 publish 하고 이를 전달하고 끝이다.

QOS1는 메시지를 Broker에게 보내고 Broker는 이를 저장 후 Subscriber에게 보낸다. 

이후 Publisher에게 PUBACK을 하면 Publisher는 이를 다시 보내지 않게 된다.

만약 이 PUBACK이 늦게 오면 Publisher는 다시 보내게 된다.

 

Publisher가 보내면 Store 하고 Subscriber에게 준다.

그리고 PUBREC를 Publisher에게 보내준다. 

이는 제대로 도착했다는 끝이고 Publisher는 PUBREL을 통해 Broker도 메시지를 지우게 된다. 

그리고 마지막에 PUBCOMP까지 하여 완료됐음을 알린다. 

Remaining Length는 total number of bytes in the message로 메시지의 바이트 길이이다.

 

헤더의 두번째 바이트를 주목할 필요가 있다. 이게 1바이트에서 4바이트를 쓴다.

왼쪽 아래그림을 보면 CB0, CB1, CB2 이런 식으로. 

 

CB라는 것이 byte별로 연결을 시키다고 보면된다보면 된다.  

어떤 건바이트 어떤건 4바이트까지 갈수도 있다. 

 

만약에 127 bytes보다 1byte로도 된다.

만약 이보다 길면 CB0를 사용한다

 

CB0가 1이면 두번째 byte도 확인해서 128에 뭘 곱할건지 확인하고 첫번째 바이트 값을 더한다

두 번째내용이 2이면 128*2이고 첫번째 바이트 값을 더한다.

이에 대한 예시 그림이다.

 

이는 전체적인 Message Flow를 확인하기 위한 그림이다. 

Publisher와 subscriber가 MQTT에게 Connect 하고 싶다고 함 

이에 대한 Ack를 통해 허락을 한다

Subscriber는 Events 토픽을 Subscribe 한다고 이에 대해 허락한다.

Publisher가 Topic에 대해 Broker는 Subscriber들에 대한 큐에 이 데이터를 저장시켜놓고

관리한다. 관리방법에는 QOS에 따라 durable 하게도 trasient 하게도 가능하다.

그리고 ack를 보내고 전달함 

만약 clean session flag가 1로 setting 된 경우 transient subscription이다

즉 connection 끊어지면

만약 Clean session flag가 0으로 경우 = durable이다

이건 connection 끊어져도 unsubscribe 할 때까지

즉 session만 죽지 subscription은 유지된다.

Publisher가 publish 하고 어느 시점 다시 보낸다. (qos1,2인 경우)

이때 내부적으로 타이머가 돌아간다. 이때 시간 기준이 keep alive interval이다. 

Keep alive타임의 1.5배 정도가 지났는데도 데이터가 안오면 server는 해당 client의 연결을 끊을수 있다.

필요에 의해서 데이터는 없지만 pingreq을 보내면 이를 끊지 않고 유지시켜준다.