MQTT 개념 (1)

MQTT는 MOM 구축 프로토콜

 

MOM(Message Orientated Middleware) 이란?

두 장치 사이의 통신이 배포된 메세지 대기열을 사용해 이뤄진다는 것

 

MQTT

IP 기반 프로토콜의 목표

• 간단한 구축
• 서비스 품질 형식 제공
• 초경량 & 대역폭을 효율적으로 활용
• 데이터에 종속 X
• 지속적으로 세션 인지
• 보안 문제 처리

MQTT는 이와 같은 목표를 만족

 

표준 기구(mqtt.org)에서 정의하는 mqtt 프로토콜

"MQTT는 MQ 텔레메트리 전송(Telemetry Transport)을 의미한다. 매우 간편하면서도 가벼운 메세징 프로토콜인 발행/구독은 제약하의 장치와 대역폭이 좁고 레이턴시가 길거나 불안정한 네트워크를 위해 만들어졌다. 전송의 안정성과 어느 정도의 보장을 확보하려고 시도하는 동시에 네트워크 대역폭과 장치 자원 요구 사항은 최소화하는 것이 설계의 원칙이다. 이러한 원칙 덕분에 이 프로토콜을 새롭게 떠오르는 '기기간'(M2M) 또는 기기가 연결된 '사물 인터넷'분야, 대역폭과 배터리 전력이 매우 중요한 모바일 용도에 적합해진다."

 

MQTT 발행 - 구독

발행-구독 : 메세지를 수신하는 클라이언트와 메세지를 송신하는 클라이언트를 분리하는 방식 중 하나

VS 기존 클라이언트-서버 모델

: 발행-구독에서 클라이언트는 IP 주소나 포트와 같은 물리적 식별자를 인식 X

 

MQTT는 pub/sub 아키텍처이기는 하지만 메세지 큐는 X

→ 메세지 큐 : 메세지 저장

   반면, mqtt : 메세지 저장 X, 특정 토픽을 아무도 구독(or 수신)하지 않을 경우, 해당 토픽은 무시된 후 사라짐

 

* 구성

발행자(publisher) : 메세지를 전송하는 클라이언트

구독자(subscriber) : 메세지를 수신하는 클라이언트

브로커(broker) : 클라이언트끼리 연결하고 데이터를 필터링하는 중심적인 역할

• 제목 필터링(subject filtering) : 설계상 클라이언트는 여러 토픽을 구독하고 특정 토픽이 나뉘면 원하는 데이터 이외에는 수신 X, 발행된 각각의 메세지는 반드시 토픽을 포함해야 하며, 브로커는 이 메세지를 구독 중인 클라이언트로 다시 브로드캐스팅하거나 무시하는 역할 담당
• 콘텐츠 필터링(content filtering) : 중개자는 발행된 데이터를 탐색하고 필터링 할 수 있음. 따라서 암호화되지 않은 모든 데이터는 저장되거나 다른 클라이언트에 발행되기 전에 브로커가 관리할 수 있음
• 유형 필터링(type filtering) : 구독 중인 데이터 스트림을 수신하는 클라이언트는 자체 필터도 적용 가능. 수신 데이터는 구문 분석을 거치게 되며, 해당 데이터 스트림을 추가로 처리하거나 무시할 수 있음

 

 ** 발행자/구독자 컴퓨팅 모델의 주의점 : 발행자와 구독자 모두가 전송이 개시되기 전에 토픽 가지와 데이터 형식을 알고 있어야 함

 

MQTT는 소비자 / 발행자 분리

브로커가 발행자와 소비자 사이에 관리 주체로 존재

 -  발행자와 소비자는 (IP와 같은) 물리적 양상을 근거로 서로 직접 파악할 필요 X

 - 물리적 신원이 알려져 있지 않거나 유동적인 IoT 배포에 매우 유용한 특징

 

MQTT와 다른 sub/pub 모델은 시불변(time-invariant) 모델

 - 하나의 클라이언트에서 발행된 메세지는 언제든 구독자가 읽고 회신 가능

 - 구독자는 초저전력에 대역폭이 제한된 상태라서 메세지에 수분 또는 수시간 후에 회신하는 경우가 있을 수 있음

 - 물리적 시간 관계의 부재로 인해 pub/sub 모델은 극단적인 용량까지도 확장이 이뤄지곤 함

 

클라우드 관리형 MQTT 중개자는 시간당 수백만 건의 메세지를 입수하고 수만 개의 발행자를 지원할 수 있는 것이 일반적

 

MQTT는 데이터 형식에 구애 X

모든 유형의 데이터가 페이로드에 상주 가능

따라서 PUB와 SUB는 반드시 데이터 형식을 이해하고 합의해야 함

 > 텍스트 메세지, 이미지 데이터, 오디오 데이터, 암호화 데이터, 바이너리 데이터, JSON 객체 또는 페이로드에 있는 거의 모든 구조의 전송 가능. 이 중 JSON 텍스트 및 바이너리 데이터가 가장 일반적인 데이터 페이로드 유형에 해당

MQTT에서 허용되는 최대 패킷 크기 : 256MB, 최대 용량 페이로드도 지원. BUT 최대 데이터 페이로드 크기는 클라우드와 브로커에 따라 달라짐. 페이로드 필드는 선택사항이며, 페이로드 크기의 일치 여부를 클라우드 공급 업체에 확인해보는 것이 좋음

 

MQTT 아키텍처에 관한 자세한 내용

MQTT는 메세지 큐잉하는 것이 가능하지만 반드시 필요하지 않을 뿐더러, 프로토콜 자체에 메세지 큐가 없기 때문에 실행되지 않는 경우도 많음

MQTT는 TCP 기반 : 패킷의 안정적 전송 보장(이 부분적으로 가능)

 

MQTT : 비대칭 프로토콜(asymmetric protocol)

MQTT는 브로커에서 메세지를 무한히 유지 가능. 이 작동 모델은 일반 메세지 전송 모델의 플래그를 통해 제어되는데, 중개자에 유지된 메세지는 해당 MQTT 토픽 가지를 구독한 모든 클라이언트에게 보내지고 새로운 클라이언트로도 즉시 전송 됨. 덕분에 새로운 클라이언트는 새로 구독한 토픽의 상태나 신호를 기다리지 않고도 받아 볼 수 있게 됨

MQTT LWT(Last Will and Testament, 유언)

 

MQTT는 TCP 기반이기는 하나, 연결이 유실될 가능성 존재. 특히 무선 센서 환경에서는 가능성이 더욱 높다.

장치가 전원이나 신호 강도를 유실하거나 현장에서 충돌하게 되면 세션은 하프 오픈 상태로 들어간다. 그러나 이 경우에도 서버는 연결이 여전이 안정적이라고 간주하고 데이터를 기다린다. 

이 하프 오픈 상태를 해결하기 위해 MQTT는 keep-alive 시스템을 사용

keep-alive 시스템을 사용하면 한동안 전송이 이뤄지지 않았더라도 MQTT 중개자와 클라이언트는 모두 연결이 유효하다는 확신을 가질 수 있다.

클라이언트는 PINGREQ 패킷을 중개자에게 전송하고 PINGRESP가 포함된 메세지로 수신을 확인 받음

타이머가 클라이언트와 브로커 쪽에 사전 설정돼 있어, 메세지가 사전 지정된 제한 시간내에 전송되지 않을 경우, keep-alive 패킷이 전송됨

PINGREQ 또는 메세지는 모두 keep-alive 타이머를 재설정함

keep-alive가 수신되지 않고 타이머가 만료된 경우, 브로커는 연결을 닫고 모든 클라이언트로 LWT 패킷 전송

클라이언트는 나중에 재연결 시도 가능

이때는 중개자에 의해 하프 오픈 연결이 닫히고 클라이언트의 새로운 연결이 개시됨

keep-alive 최대 시간 : 18시간 12분 15초

keep-alive = 0 으로 설정하면 기능 비활성화

타이머는 클라이언트가 제어, 슬립 모드나 신호 강도의 변화를 반영하기 위해 동적으로 변할 수 있음

 

keep-alive : 망가진 연결 복구 지원

BUT 클라이언트의 구독과 QoS 매개 변수를 모두 재구축하는 일은 데이터가 제한돼 있는 연결에 불필요한 오버헤드를 발생시킬 수 있다. 이런 추가 데이터의 발생을 완화하기 위해 MQTT는 지속적 연결 지원

지속적 연결 덕분에 브로커 측에는 다음 내용이 저장됨

• 모든 클라이언트 구독
• 클라이언트가 확인하지 않은 모든 QoS 메세지
• 클라이언트가 놓친 모든 신규 QoS 메세지

위 정보는 client_id 매개 변수가 고유한 클라이언트를 식별하는데 참고

클라이언트는 지속적으로 연결을 요청할 수 있으나 브로커는 이러한 요청을 거절하고 빈 세션으로 다시 연결을 강제할 수 있다. 연결되면 브로커는 cleanSession 플래그를 사용해 지속적 연결을 허용하거나 거부한다. 클라이언트는 CONNACK 메세지를 사용해 지속적 연결을 저장할지 여부를 판단할 수 있다.