[프로토콜] MQTT Protocol

카테고리 : etc
태그: protocol · MQTT · MQTT Protocol · MQTT(Message Queueing Telemetry Transport) · QoS · push 알림

  • 1. MQTT(Message Queueing Telemetry Transport)

  • 작은 코드 공간이 필요하거나 네트워크 대역폭이 제한되는 원격 통신을 위하여 만들어진 프로토콜
  • 즉, IoT와 같은 제한 된 혹은 대규모 트래픽 전송을 위해 만들어진 프로토콜
    • TCP/IP 프로토콜 위에서 동작하지만 동시에 굉장히 가벼우며, 많은 통신 제약들을 해결해줌
  • 단, 메세지가 가벼운 만큼 메세지 유형이나 QoS(서비스 품질)에는 제약이 존재
  • MQTT 는 사물인터넷(IoT)를 위한 프로토콜
  • MQTT 는 디바이스의 리소스를 적게 사용하도록 설계되어 있고, 단방향 통신이 아니라, device와 cloud 간 송수신을 하는 양방향 통신을 지원
  • **HTTP 통신은 요청-응답 기반이어서 클라이언트가 먼저 요청을 보내야 서버와 통신이 가능함. 반면에 MQTT는 클라이언트 혹은 서버 둘 중 누구나 통신을 시작할 수 있음**

2. 특징

(1) 연결지향적

  • 연결이 끊어지면 재접속 가능
  • **Live 라는 하트비트와 Topic 에 발행되는 메세지를 통해 연결을 유지하고 메세지 송수신을 하게 됨**

(2) 브로커를 통한 통신

  • MQTT의 발행-구독 메시징 패턴은 오로지 브로커를 통해서만 통신할 수 있으며 개설된 Topic에 메세지를 발행하면 해당 Topic을 구독하는 클라이언트들에게 메세지를 발행할 수 있음.
  • 1:1, 多:多 통신 모두 가능

(3) QoS (Quality of Service)

  • 0 : 최대 1회 전송. Topic을 통해 메세지를 전송할 뿐 보장은 하지 않음. (보낸 다음 잊어버림)
  • 1 : 최소 1회 전송. 구독하는 클라이언트가 메세지를 받았는지 불확실하면 정해진 횟수만큼 재전송.
    • 메세지의 핸드셰이킹 과정을 엄밀하게 추적하지는 않으므로 중복의 위험성 존재 (확인 응답을 거치는 전달)
  • 2 : 구독하는 클라이언트가 요구된 메세지를 정확히 한 번 수신할 수 있도록 보장. 메시지의 핸드셰이킹 과정을 추적.
    • 높은 품질을 보장하지만 성능의 희생이 따른다. 보장된 전달
  • 이 필드는 기반이 되는 TCP/IP 데이터 전송의 처리에 영향을 주지 않으며, MQTT 송신자와 수신자 간에만 사용됨
  • 메세지는 글자 수 제한이 없으므로, 긴 메세지나 JSON 포맷 또는 파일도 전송이 가능함.

0~1 정도의 QoS 를 사용하며 메세지 손실의 위험은 상위 어플리케이션 차원에서 관리하는 방법이 널리 쓰임**

3. 메세지 유형

연결하기

: 서버와의 연결을 기다린 다음, 노드 간 링크를 생성한다.

연결끊기

: MQTT 클라이언트가 해야 할 일을 기다리고 인터넷 프로토콜 스위트 세션의 연결이 끊어지기를 기다림

발행하기

: MQTT 클라이언트에 요청이 전달된 직후 어플리케이션 스레드에 즉시 반환

4. MQTT 동작 구조

1

5. MQTT 브로커

  1. 발행/구독 구조를 사용해 다대다 전송이 용이
  2. QoS(Quality of Service)를 통해 메시지 전송을 보증
  3. 메세지 전송 후 전송한 메시지를 바로 삭제하지 않고 메시지 전송이 완료되었다는 패킷을 기다리기 때문에(PUBACK) 전송에 실패한 메세지를 주기적으로 재전송 할 수 있음
  4. 작은 패킷 크기로 인해 오버헤드가 적고 저전력 환경에서도 동작이 가능