MQTT 총 정리

앞서 영혼을 갈아 정리한 OSI 모델과 TCP/IP 정리는 MQTT를 위함이었다.

 

 

 

1. MQTT(메시지 큐잉 텔레메트리 트랜스포트, Message Queuing Telemetry Transport)란?

 - 우선, Telemetry Transport에 대해 알아보자면, 전송은 전송인데.. 텔레메트리 이게 합성어이다.

 - 원격을 의미하는 'Tele'와 측정을 의미하는 'Metry'의 합성어로 원격지의 상태를 감시 및 제어하기 위해 기계간 각종 데이터를 디지털 신호로 바꿔서 원격으로 송수신하는 것을 말한다. 

 - 즉, 애초에 M2M(Machine-to-Machine)을 위한 프로토콜인 셈이다. 또한, 요즘은 사물인터넷에도 쓰이는 경량 메세지 전송 프로토콜이다.

 - 위키피디아를 보면 MQTT를 7계층의 7번째인 응용계층으로 분류를 해놓았는데, 사실 No TCP/IP 환경에서도 쓸 수 있다보니, 경량의 기기와 통신을 할때는 MQTT가 기기쪽의 데이터를 전송하는 역할도 하는 프로토콜이라 봐도 될 것 같다.

 

2. 발행-구독 모델 (Pub/Sub Model)

출처 : https://medium.com/@jspark141515/mqtt%EB%9E%80-314472c246ee

 - MQTT는 기본적으로 발행-구독 모델인데, 이는 발행하는 발행 클라이언트와 구독 클라이언트 간의 통신모델이다.

 - 비동기 메시징 패러다임이며, 발신자의 메시지는 수신자가 특정되어 있지 않다. 대신 발행된 메시지는 정해진 범주에 따라 구독을 신청한 수신자에게 전달된다. 수신자는 발행자에 대한 지식이 없어도 원하는 메시지만을 수신할 수 있다. 

 - observer model과 비슷하지만 큰 차이는 발행 구독 모델에는 broker가 있다는 점이다.

 - 공간분리 : 게시자와 가입자가 서로를 알 필요가 없다. (예를 들어 IP주소라든지 포트라든지)

 - 시간 디커플링 : 게시자와 가입자를 동시에 연결할 필요가 없다.

 - 동기화 디커플링 : 메시지를 게시하거나 받는 동안 두 구성 요소에 대한 작업이 중단되지 않는다.

 

 (1) 작동 순서

    - Subscriber는 Broker에게 자신이 받을 Topic들에 대한 정보를 요청한다.(Subscribe)

    - Broker는 메모리에 Topic별로 subscribe하는 client의 정보를 갖고 있다가, Publisher가 해당 Topic으로 데이터를 전송하면 구독하고 있던 client 전원에게 데이터를 전달해준다.(Publish)

    - 한마디로, 발행자가 발행할거를 몽씬 발행하면, 브로커는 발행한 토픽들을 보고 알맞게 필터링해서 구독자에게 정보를 제공하는 것이다. 즉, 브로커는 들어오는 모든 메시지를 필터링해서 올바르게 구독자에게 배포한다.

 

 (2) Topic

출처 : https://khj93.tistory.com/entry/MQTT-MQTT%EC%9D%98-%EA%B0%9C%EB%85%90

    - 토픽은 문자열(UTF)로 구성되어있기 때문에 /를 이용하여 트리구조처럼 하향식으로 관리할 수 있어서, 대량의 센서 기기들을 관리할 때 효율적이다.

    - 와일드카드 : 토픽의 양념장인데, + 와 * 가 있다 만약에 구독자가 위의 사진에서 building/first/* 처럼 와일드카드를 사용하여 구독하면 restaurant와 bathroom의 하위 정보까지 다 받아갈 수 있는 것이다. 즉, * 이 와일드 카드는 같은 부모 노드를 가진 형제노드 전부를 동시에 구독할 수 있게 해준다. 하지만 이 예시가 틀린점은 자식노드가 없는 경우(단말노드)에만 쓸 수 있기 때문이다. 만약에 temperature와 Humidity가 없으면 * 이걸 쓸수 있다. 

    - 만약에 /first 부분의 하위 폴더와 똑같은 경로로 /second가 있다고 쳐보면 이경우 building/+/restaurant/temperature 를 하면 첫번째 두번째 식당의 온도를 다 가져오는 것이다.

 

3. QoS (Quality of Service)

출처 : https://khj93.tistory.com/entry/MQTT-MQTT%EC%9D%98-%EA%B0%9C%EB%85%90

   - 서비스의 질을 보장해주는 레벨을 의미하는데, 3레벨로 되어있다.

   - 네트워크 장애나 응용 프로그램 다시 시작 및 기타 예상치 못한 상황에서 안정석을 높이기 위해 추가 지속성 및 재전송 메커니즘을 제공한다.

   - Level 0 : 메시지는 한번만 전달되며 전달의 성공여부는 확인하지 않는 레벨이다. 한번에 전송이 성공하지 않으면 실패한 상태로 끝이나는, 사실상 QoS 보장을 하지 않는 레벨이다.

   - Level 1 : 메시지는 최소 한번 이상 전달되며, 발행자에게 PUBACK을 전달하여, 성공여부를 알린다.

     ****이 레벨에서 구독자에게 중복 메시지를 보낼 수 있는 시나리오

         1. 발행자가 브로커에게 정상적으로 보낸다

         2. 브로커는 받은 메시지를 구독자에게 정상적으로 보낸다. (구독자는 메시지 1회 받음)

         3. 브로커는 메시지를 보냈으므로 PUBACK을 발행자에게 보낸다.

         4. 그러나 PUBACK이 전달 중에 사라졌다. (LOSS 발생)

         5. 발행자는 PUBACK을 기다리다가, 시간이 지나자 전송이 실패한 줄 알고 다시 브로커에게 보낸다. (Duplicate Publish)

         6. 브로커는 메시지에 관한 정보를 지웠기 때문에, 처음 받는 메시지인 줄 알고 다시 구독자에게 보낸다. (구독자 똑같은 메시지 2번째 받음)

         7. 다시 PUBACK을 보내고, 정상종료된다.

         8. 발행자가 PUBACK을 받고, 통신은 종료된다.

   - Level 2 : PUBACK의 과정을 3Way Handshaking으로 바꿈으로써 정확히 1번만 가도록 구현하였다. 다만, 이 과정은 통신 오버헤드를 증가시키기 때문에 꼭 손실이나 복제가 허용되면 안될 때 사용하면 좋은 옵션이다.

      *****작동 시나리오

        1. 발행자 메시지 브로커에게 보냄

        2. 브로커가 구독자에게 메시지 전달한다. (구독자 메시지 1번 전달받음)

        3. Broker가 Publisher에게 PUB Recevied를 보낸다.

        4. PUBREC이 분실되어 Publisher가 다시 메시지를 보내도, Broker는 메시지를 이미 갖고 있기 때문에 Subscriber에게 다시 메시지를 보내지 않고 PUBREC를 다시 보낸다.

        5. Publisher는 PUBREC를 받으면, 이제서야 Publish Release 메시지를 보낸다.

        6. PUBREL이 loss되는 것은 문제가 없다. 브로커는 이미 보냈다는 사실을 알고 있기 때문에 새로 보내지 않는다.

        7. PUB REL을 받으면, 이제서야 메시지를 삭제한다.

        8. 메시지를 정상 종료하였으므로 PUBCOMPLETE를 보낸다.

 

4. MQ broker

 (1) Mosquitto 소개

    - C기반, 클러스터링이 안되는 MQ broker이다. 

    - 브리지 프로토콜을 통해 브로커를 서로 연결할 수 있다.

    - 일정시간 패킷이 안오면 하트비트 메세지를 보내기 시작하고, 메세지가 안오면 끊어버린다는데, 이부분은 회사 코드 까보면서 좀 더 이해할 필요가 있을 것 같다.

    - 여담이지만 놀랍게도 아파치 카프카도 MQ broker다 ㅎㄷㄷ

 

 (2) 세션 처리

    - 클라이언트가 MQTT 브로커에 연결하면 지속적 세션을 요청할 수 있다. 클라이언트가 지속적 세션을 요청한 경우 브로커는 클라이언트의 세션 정보를 저장한다. 클라이언트의 세션 정보에는 다음이 포함된다.

   - 클라이언트의 모든 구독

   - 아직 처리되지 않은 모든 QoS 1/2 메시지

   - 클라이언트가 오프라인 상태에서 놓친 모든 QoS 1/2 메시지

 

 (3) 하트비트

    - MQTT CONNECT 메시지는 클라이언트가 메시지 교환 사이의 최대 시간 종료를 지정할 수있는 keepAlive 값 (초)을 포함한다. 이로 인해 keepAlive 값이 값의 150 %를 초과하면 브로커가 반 개방 연결을 감지하고 (이미 연결이 끊긴) 클라이언트에 대한 연결을 닫을 수 있다. 따라서 브로커와 클라이언트 사이의 연결이 여전히 설정되어 있고 다른 메시지 교환이 발생하지 않으면 클라이언트는 keepAlive 간격 내에서 PINGREQ 메시지를 브로커로 보낸다. 브로커는 PINGRESP 메시지로 응답한다. 모든 클라이언트는 연결시 keepAlive 값을 지정하며 최대 값은 65535 초 (18 시간 12 분 15 초)이다.

 

 (4) MQTT control Packet 구조

출처 : https://wnsgml972.github.io/mqtt/2018/03/05/mqtt/

   - DUP는 PUBLISH 제어 패킷의 중복 전달을 나타내고, QoS는 PUBLISH 서비스 품질을 나타내며 RETAIN은 PUBLISH 플래그 유지를 나타낸다.

   - Flag란? 무엇인가를 기억해야 하거나 또는 다른 프로그램에게 약속된 신호를 남기기 위한 용도로 프로그램에서 사용되는 미리 정의된 비트를 의미. (예: ACK 응답플래그)

 

5. 같이 쓰는 프로그램

 

 (1) paho

    - 여러 언어를 지원하는 MQTT 클라이언트용 라이브러리로써, 브로커 기능은 없고 구독, 발행 클라이언트 생성을 위한 기능이 있다.

 

6. 응용 예제

출처 : https://roazium.tistory.com/146