MQTT server

Node.js <-----> MQTT 서버(브로커 역할) <--------> IoT 디바이스
↑
↓
DB

MQTT 서버도 당연히 서버 이기에 IP, Port가 있다.

• MQTT 서버는 1883 port
• 송신자(퍼블리셔), 수신자(서브스크라이버)

MQTT 프로토콜

• Broker Pattern을 이용한 메시징 프로토콜
  
  - 메시지를 해당 Topic에 발행(Publish), 해당 Topic에 구독(Subscribe)
  - Broker는 해당 클라이언트(Publisher, Subscriber)의 중개인
  - Publisher가 해당 Topic에 메시지 발행 시, 해당 Topic을 구독 중인 하나 이상의 Subscriber에게 Broker를 거쳐 메시지가 전달된다.
  
  
• IoT에서 사용하기 위해 낮은 전력, 낮은 대역폭 환경에서도 사용 할 수 있도록 설계되었다.
• MQTT Broker가 메시지 전달 및 세션 관리하기 때문에 IoT 디바이스 부하 분산

• Publisher가 데이터를 브로커에게 전달하면 각 Subscriber에서 데이터를 받아 올 수 있다.
• Topic을 보고 어디로 주고 받을지 정한다. (아래 그림과 같이)
  

Topic

• Publisher와 Subscriber는 Topic을 기준으로 메시지 발행하거나 구독한다.
• Topic은 문자열로 구성되어 있기 때문에 / 를 이용하여 쉽게 구분 지을 수 있다.
• 채팅을 구성할 때 방 개념을 구현할 시
  • "chat/room/1/Message", "chat/room/2/Message" 등 방법을 사용 가능
• 위와 같은 구조로 구분하기 때문에 대량의 센서 기기들을 관리하기 매우 효과적이다.

Message Bus

• 위 그림과 같이 MQTT Broker가 메시지 버스를 만들고 App들은 Message Bus에 연결한다.
• App은 관심있는 Topic을 등록하여 메시지를 Subscribe하거나 Publish하여 Message Bus를 통해 해당하는 일을 하게된다.

QoS

• QoS(Quality of Servie)란 서비스의 질을 보장해주는 레벨
• 서비스 종류에 따라서 적당한 QoS 레벨을 선택해야 한다.
  • 고려해야 할 서비스는 뭔가? 메시지 신뢰도, 속도
• MQTT 프로토콜의 핵심중 하나는 최대 한번, 적어도 한번, 정확히 한번이라는 세가지 QoS를 통해 No TCP 환경, 저전력, 신뢰할 수 없는 네트워크에서도 중요 메시지에 대한 전달을 보장
• IoT기반의 통신에는 신뢰성 또한 고려되어야만 하는데, No TCP 환경에서는 패킷 손실이 발생할 수 있다.
• 쉽게말해, No TCP 환경에서 신뢰성에 대해 보장할 수 없는 메시지를 신뢰할 수 있도록 서버단에서 구현했다고 보면된다.
  
• Level 0 (At most once)
  • 메시지는 한번만 전달된다.
    • Fire and Forget. 한번만 전달하고 전달 여부는 확인하지 않는다.
• Level 1 (At least once)
  • 메시지는 최소 한번은 전달된다.
    • (그림 참고) 메시지를 성공적으로 전달하면 Broker가 Publisher에게 PUBACK을 보내 전달 성공을 알리지만, Loss가 발생하여 PUBACK을 받지 못하면 Publisher는 적정 시간이 지나 실패로 알고 다시 메시지를 보냄(Subscribe에게 중복메시지를 보내는 경우가 생김)
• Level 2 (Exactly once)
  • 메시지는 반드시 한번 전달된다. 위에 있는 PUBACK 과정을 PUBREC으로 핸드 셰이킹을 함으로서 메시지가 정확히 한번만 가는 레벨
  • 만약 위 과정처럼 Broker가 PUBREC을 전달 받지 못해 Loss가 일어나게 되어도 Broker는 이미 보냈다는 사실을 알고 있기 때문에 새로 보내지 않는다.

• MQTT
• MQTT 브로커 분석
• Ubuntu에서 MQTT 설치