맨위로가기

MQTT

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

MQTT는 1999년 IBM과 Eurotech에서 개발한 경량 메시지 전송 프로토콜이다. 게시-구독 모델을 기반으로 하며, 대역폭 효율성과 낮은 전력 소비를 목표로 설계되었다. MQTT는 다양한 버전으로 발전해 왔으며, 2010년 버전 3.1부터 로열티 없이 공개되었고, 2014년 OASIS에서 표준으로 채택되었다. MQTT는 세 가지 QoS(Quality of Service) 레벨을 지원하며, 메시지 재배포, Will 메시지, Retain 기능 등을 제공한다. MQTT 브로커는 클라이언트 간 메시지 라우팅을 담당하며, 보안, 확장성, 클라이언트 연결 상태 관리 등의 장점을 제공한다. 페이스북 메신저, IECC 시그널링 제어 시스템 등 다양한 분야에서 활용되며, 2019년에는 MQTT 5.0이 발표되었다.

2. 역사

MQTT는 1999년 IBM의 앤디 스탠포드-클라크와 당시 유로테크, Inc.의 전신인 Arcom Control Systems 소속의 알렌 니퍼가 처음 개발했다.[5][35] 초기에는 SCADA 산업 제어 시스템 내에서 자원 제약이 심한 원격 장치를 연결하기 위한 목적으로 설계되었다.[6][7]

'MQTT'라는 이름은 IBM MQ 제품군에서 유래했으며, 여기서 'MQ'는 'Message Queue'(메시지 큐)를 의미한다. 하지만 실제 프로토콜은 이름과 달리 큐(Queue) 방식이 아닌 게시-구독 패턴 방식을 사용한다.[8] IBM이 공개한 초기 사양에서는 이 프로토콜을 "MQ 텔레메트리 전송"(MQ Telemetry Transport)이라고 불렀다.[9][10] 2013년 OASIS로 표준화 작업이 이관된 이후에는 공식적으로 특정 단어의 약자가 아닌 고유 명칭 "MQTT"로 사용된다.[4][11][8] 기술 위원회의 공식 명칭은 "OASIS 메시지 큐잉 텔레메트리 전송 기술 위원회"이다.[4]

프로토콜은 여러 버전을 거쳐 발전해왔다. 2010년 버전 3.1이 로열티 없이 공개되었고,[35][37] 2013년 IBM은 MQTT v3.1을 OASIS 표준화 기구에 제출했다.[4] OASIS는 2014년 10월 29일에 버전 3.1.1을 발표했으며,[12][13] 이는 2016년 ISO/IEC 표준(ISO/IEC 20922:2016)으로도 채택되었다.[41][42] 이후 여러 새로운 기능이 추가된 버전 5.0이 2019년 3월 7일에 출시되었다.[1][43][44]

2. 1. 초기 개발 (1999년)

IBM의 앤디 스탠포드-클라크와 당시 유로테크, Inc.(Arcom Control Systems)[35]에 근무하던 알렌 니퍼가 1999년에 MQTT 프로토콜의 첫 번째 버전을 개발했다.[5][35] 이 프로토콜은 SCADA 산업 제어 시스템 내에서 오일 파이프라인을 모니터링하기 위해 처음 사용되었다.[6] 당시 사용된 장치들은 비용이 많이 드는 위성 링크를 통해 연결되었기 때문에, 개발 목표는 대역폭 사용량이 적고 가벼우며 배터리 소모를 최소화하는 프로토콜을 만드는 것이었다.[7]

역사적으로 'MQTT'의 'MQ'는 IBM MQ(당시 'MQSeries') 제품군에서 유래했으며, 'MQ'는 'Message Queue'(메시지 큐)를 의미한다. 하지만 실제 프로토콜은 이름과 달리 큐(Queue) 방식이 아닌 게시-구독 메시징 방식을 사용한다.[8] IBM이 공개한 초기 사양에서는 이 프로토콜을 "MQ 텔레메트리 전송"(MQ Telemetry Transport)이라고 불렀다.[9][10]

1999년에는 첫 버전 이후 Version 2가 정의되었고, 같은 해 10월 22일에는 Version 2.3으로 업데이트되어 이후 Version 3.1.1에 해당하는 패킷 구조를 갖추게 되었다.[35][36]

2. 2. 버전 발전

1999년 IBM의 앤디 스탠포드-클라크와 당시 유로테크, Inc.의 전신인 Arcom Control Systems 소속의 아렌 니퍼가 프로토콜의 첫 번째 버전을 만들었다.[5][35] 이는 SCADA 산업 제어 시스템 내에서 송유관을 모니터링하는 데 사용되었다.[6] 그 해에 Version 2를 정의하고, 1999년 10월 22일에 업데이트한 Version 2.3으로 Version 3.1.1 상당의 패킷을 갖추게 되었다.[35][36]

2000년에는 Version 3.0이 출시되었다.[35] 2007년에 Eurotech에 인수된 Arcom Control Systems는 사명도 Eurotech로 변경되었기 때문에, MQTT의 사양은 IBM과 Eurotech가 관리하게 되었다.

2010년에 Version 3.1이 출시되었다.[35] 이 버전부터 로열티 없이 공개되었다.[37] IBM이 버전 3.1로 공개한 사양에서 이 프로토콜은 "MQ 텔레메트리 전송"으로 언급되었다.[9][10] OASIS에서 출시한 후속 버전에서는 프로토콜을 단순히 "MQTT"라고만 언급하지만, 기술 위원회 자체는 "OASIS 메시지 큐잉 텔레메트리 전송 기술 위원회"라고 명명되었다.[4] 2013년 이후, "MQTT"는 아무것도 의미하지 않는다.[11][8]

2011년에 Eclipse Foundation이 설립한 Paho 프로젝트에 IBM으로부터 MQTT 클라이언트의 구현이 제공되었다.[38]

2013년, IBM은 사양에 대한 사소한 변경만 허용하도록 보장하는 헌장과 함께 MQTT v3.1을 OASIS 사양 기구에 제출했다.[4] IBM으로부터 표준 유지 관리를 인수한 후, OASIS는 2014년 10월 29일에 Version 3.1.1을 출시했다(11월 13일 발표).[12][13][39][40] 또한, 2016년 6월에 ISO/IEC 표준인 ISO/IEC 20922:2016으로 채택되었다.[41][42]

여러 새로운 기능을 추가하여 MQTT Version 5로의 보다 실질적인 업그레이드는 2019년 3월 7일에 출시되었다(2019년 3월 19일 발표).[1][43][44] Version 5.0에는 다음과 같은 주요 새 기능이 포함되어 있다:[23]

  • 이유 코드(Reason Code): 응답은 이제 실패 이유를 제공하는 반환 코드를 지원한다.
  • 공유 구독(Shared Subscriptions): 클라이언트 간에 부하 분산을 허용하여 부하 문제의 위험을 줄인다.
  • 메시지 만료(Message Expiry): 메시지에는 만료 날짜를 포함할 수 있으며, 이 기간 내에 전달되지 않으면 삭제된다.
  • 토픽 별칭(Topic Alias): 토픽의 이름을 단일 숫자로 대체할 수 있다.


MQTT-SN (센서 네트워크용 MQTT)은 Zigbee와 같은 비 TCP/IP 네트워크의 배터리 구동 임베디드 장치를 대상으로 하는 주요 프로토콜의 변형이다.[15][16]

3. 특징

MQTT 프로토콜은 메시지 브로커를 중심으로 다수의 클라이언트가 메시지를 주고받는 게시-구독 모델을 기반으로 한다.[17][18] 정보는 토픽(Topic)이라는 계층적 주소 체계를 통해 분류되며, 메시지를 발행하는 클라이언트(게시자)는 특정 토픽으로 메시지를 보내고, 브로커는 해당 토픽을 구독하고 있는 클라이언트(구독자)들에게 메시지를 전달한다. 이 구조 덕분에 게시자와 구독자는 서로에 대한 정보를 알 필요 없이 브로커를 통해 통신할 수 있다.

주요 기능적 특징으로는 메시지 전달의 신뢰성 수준을 정하는 서비스 품질(QoS), 클라이언트의 비정상적인 연결 종료를 대비한 Will 메시지, 그리고 특정 토픽의 최신 메시지를 저장하여 새로운 구독자에게 즉시 전달하는 보존 메시지(Retained Message) 기능 등이 있다.[19]

기술적으로 MQTT는 최소한의 데이터만으로 통신이 가능한 경량 프로토콜로 설계되었다. 주로 TCP/IP 위에서 동작하며, UDP나 블루투스 등 다른 전송 환경을 위한 MQTT-SN이라는 변형도 존재한다. 기본적인 프로토콜 자체에는 암호화나 인증 기능이 포함되어 있지 않으므로, 보안이 필요한 경우에는 전송 계층 보안(TLS)과 같은 별도의 보안 계층을 함께 사용해야 한다. MQTT의 기본 TCP 포트는 1883번이며, TLS를 사용할 경우 8883번 포트를 사용한다.[20] 또한, 시스템 확장을 위해 여러 브로커 서버를 연동하여 구성하는 것도 가능하다.

3. 1. 경량 프로토콜

MQTT 프로토콜은 전송되는 메시지 사양이 가볍고 단순하게 설계되었다. 최소 제어 메시지는 2바이트의 데이터만으로 구성될 수 있으며,[18] 헤더 크기는 최소 2바이트이다.[45] 필요한 경우, 하나의 제어 메시지는 최대 약 256메가바이트의 데이터를 담을 수 있다. 클라이언트와 메시지 브로커 간의 연결 설정 및 해제, 데이터 발행, 수신 확인, 연결 상태 감독 등에 사용되는 14가지 종류의 메시지 유형이 정의되어 있다.

MQTT는 기본적으로 데이터 전송의 신뢰성을 위해 TCP/IP 프로토콜에 의존한다.[46] 즉, 데이터 손실 없이 순서대로 전달되는 양방향 통신 프로토콜 위에서 동작하는 것을 전제로 한다. 사양에서는 TCP/IP 외에도 TLS나 웹소켓 위에서의 동작도 언급하고 있지만, 반드시 이 프로토콜들에만 국한되는 것은 아니다.[46] IANA에는 TCP 포트로 TLS를 사용하지 않는 경우 1883번, TLS를 사용하는 경우 8883번이 등록되어 있다.[47][20]

기본적으로 MQTT는 연결 자격 증명을 암호화하지 않고 일반 텍스트로 전송하며, 자체적인 보안이나 인증 기능을 포함하지 않는다. 따라서 전송되는 정보의 암호화 및 보호를 위해서는 TLS 사용이 권장된다.

한편, UDP나 블루투스와 같이 TCP/IP 외의 다른 전송 방식을 사용하는 환경을 위해 MQTT-SN이라는 변형 프로토콜도 존재한다.

3. 2. 유연한 메시지 배포 (구독)

MQTT는 게시-구독(Pub/Sub) 모델을 기반으로 메시지를 유연하게 배포한다. 이 시스템은 메시지 브로커와 다수의 클라이언트로 구성된다.[17][18] 정보를 게시하는 클라이언트(게시자)는 특정 토픽(Topic)에 메시지를 발행하고, 메시지 브로커는 해당 토픽을 구독하고 있는 클라이언트(구독자)들에게 메시지를 전달하는 역할을 한다. 이 구조 덕분에 메시지를 보내는 게시자는 구독자가 누구인지 또는 몇 명인지 알 필요가 없으며, 메시지를 받는 구독자 역시 게시자에 대한 정보를 알 필요 없이 필요한 정보를 수신할 수 있다.

정보가 분류되고 전달되는 기준인 토픽은 마치 파일 시스템의 경로처럼 `/` 문자를 사용하여 계층 구조로 구성된다.[48] 예를 들어, `집/거실/온도` 또는 `공장/A라인/센서/압력`과 같이 구체적인 정보의 위치나 종류를 나타낼 수 있다. 구독자는 특정 토픽을 정확히 지정하여 구독할 수도 있지만, 와일드카드를 사용하여 여러 토픽을 한 번에 구독하는 것도 가능하다.[48] 와일드카드를 사용하면 특정 패턴에 맞는 여러 토픽의 메시지를 효율적으로 수신할 수 있다.

이러한 토픽 기반의 게시-구독 방식을 통해 MQTT는 1:1 (하나의 게시자가 하나의 구독자에게), 1:N (하나의 게시자가 여러 구독자에게), N:N (여러 게시자가 여러 구독자에게) 등 다양한 형태의 메시지 배포 시나리오를 효과적으로 지원한다.

일반적으로 브로커는 메시지를 수신했을 때 해당 토픽을 구독하는 클라이언트가 없으면 메시지를 폐기한다. 하지만 보존된 메시지(retained message) 기능을 사용하면 특정 토픽의 가장 마지막 메시지를 브로커에 저장해 둘 수 있다.[19] 보존 플래그가 설정된 메시지가 게시되면, 브로커는 이 메시지를 저장하고 있다가 해당 토픽을 새로 구독하는 클라이언트에게 즉시 전달한다. 이를 통해 새로운 구독자는 게시자의 다음 업데이트를 기다리지 않고도 가장 최신 상태 값을 바로 알 수 있다. 브로커는 각 토픽별로 가장 마지막의 보존된 메시지 하나만 저장한다.[19]

3. 3. 메시지 배포 품질 (QoS)

브로커에 대한 각 연결은 QoS(Quality of Service) 기준을 지정할 수 있다.[49] QoS 레벨은 부하(오버헤드)가 늘어나는 순서에 따라 다음과 같이 세 가지로 분류된다.

  • 최대 한 차례 (At most once, QoS 0): 메시지는 한 번만 보내며, 클라이언트와 브로커는 전달 확인 응답을 위한 추가 단계를 밟지 않는다. 메시지가 손실될 수 있다. (보낸 다음 잊어버림, fire and forget)
  • 최소 한 차례 (At least once, QoS 1): 메시지는 확인 응답(ACK)을 수신할 때까지 송신자로부터 여러 번 재시도될 수 있다. 메시지 전달은 보장되지만, 중복 전달이 발생할 수 있다. (확인 응답을 거치는 전달, acknowledged delivery)
  • 정확히 한 번 (Exactly once, QoS 2): 송신자와 수신자는 2단계 핸드셰이크를 통해 오직 하나의 메시지 사본만을 수신하는 것을 보장한다. 가장 신뢰도가 높지만 성능 부하도 가장 크다. (보장된 전달, assured delivery)[114]


이 QoS 설정은 기반이 되는 TCP 데이터 전송의 처리에 영향을 주지 않으며, MQTT 송신자와 수신자 간의 메시지 전달 보장 수준을 정의하는 데만 사용된다.

QoS 레벨은 단일 송신자(sender)와 단일 수신자(receiver) 간, 즉 한 구간(hop)에 대해서만 적용된다.[50] 따라서 서버(브로커)가 동일한 메시지를 여러 클라이언트에 배포하는 경우, 각 클라이언트와의 연결에서 서로 다른 QoS 레벨이 사용될 수 있다.[51] 마찬가지로, 메시지를 발행하는 클라이언트와 서버 간의 QoS 레벨과, 해당 토픽을 구독하는 클라이언트에게 메시지를 전달하는 서버와 클라이언트 간의 QoS 레벨이 다를 수 있다. 이는 QoS가 종단 간(end-to-end) 메시지 전달 품질을 보장하는 것이 아니라 각 구간에서의 전달 품질을 정의함을 의미한다.

3. 4. 메시지 재배포 기능

MQTT의 메시지 배포는 사용하는 전송 계층의 성능에 따라 이루어진다.[53] 기본적으로 최대 한 번의 전송 시도만 수행하며[52], 메시지가 수신자에게 확실하게 도달한다는 보장은 없다. 메시지 배포에 실패하더라도 재전송을 하지 않는다.

3. 5. Will 메시지

게시 클라이언트가 브로커에 처음 연결할 때, Will 메시지라는 특별한 메시지를 미리 설정해 둘 수 있다. 만약 클라이언트와 브로커 간의 연결이 예기치 않게 끊어졌다고 브로커가 감지하면, 브로커는 미리 설정된 이 Will 메시지를 해당 클라이언트를 구독하고 있던 다른 클라이언트들에게 대신 전송한다. 이를 통해 다른 클라이언트들은 특정 클라이언트의 연결 상태에 문제가 발생했음을 인지할 수 있게 된다.

3. 6. Retain

클라이언트가 Retain 플래그를 활성화하여 배포한 메시지는 브로커에 의해 토픽별로 저장된다.[63] 이 메시지는 '보존 메시지'(Retained Message)라고 불리며, Retain 플래그가 참(true)으로 설정된 일반 MQTT 메시지이다. 브로커는 각 토픽별로 마지막으로 수신된 보존 메시지만을 저장하며, 새로운 보존 메시지가 도착하면 이전 메시지를 덮어쓴다.[19]

만약 어떤 클라이언트가 특정 토픽을 구독할 때, 해당 토픽에 저장된 보존 메시지가 있다면 브로커는 구독 즉시 해당 메시지를 클라이언트에게 전송한다. 이를 통해 클라이언트는 토픽을 구독하기 전의 마지막 상태나 값을 즉시 알 수 있으며, 다음번 발행될 메시지를 기다릴 필요가 없다.[19] 일반적인 메시지(Retain 플래그가 비활성화된 메시지)는 구독자가 없는 토픽으로 발행될 경우 브로커에 의해 폐기되지만, 보존 메시지는 저장된다는 차이점이 있다.

4. 보안

MQTT 프로토콜 사양 자체에는 구체적인 보안 규정이 명시되어 있지 않다. 보안은 기본적으로 구현 방식에 따라 달라지며, 하위 통신 계층에서 제공하는 TLS[73]나 VPN[73]과 같은 기존의 보안 기술을 활용하도록 권장된다.

사양에서는 CONNECT 패킷에 사용자 이름과 비밀번호를 포함시켜 기본 인증[64][65][66]을 수행하거나, 클라이언트 식별자, 호스트 이름, IP 주소 등을 인가[72]에 활용할 수 있음을 언급한다. 또한 통신 내용 보호를 위해 암호화[73] 적용이 가능하다. OASIS로 표준 관리 역할이 이관된 이후에는 NIST의 사이버 보안 프레임워크를 MQTT 환경에 적용하기 위한 가이드라인도 마련되었다[74][75].

그러나 실제 운영 환경에서는 비밀번호 미설정 서버 노출[99], 프로토콜 취약점을 이용한 DoS 공격[100][101], 도청 및 변조 위험[102] 등 다양한 보안 문제가 보고되고 있어 주의가 필요하다.

4. 1. 인증

MQTT 사양 자체에는 구체적인 보안 규정이 명시되어 있지 않다. 기본적으로 구현에 따라 달라지며, 하위 계층의 기존 보안 기술을 활용하도록 되어 있다.

CONNECT 패킷에는 사용자 이름과 비밀번호를 포함시킬 수 있다[64][65]. 이를 통해 기본 인증을 수행할 수 있다[66]. 다만, 이 필드들이 반드시 기본 인증에만 사용되는 것은 아니며, 예를 들어 비밀번호 필드를 Bearer 토큰 전달에 사용하는 것도 가능하다[67][68][69]. MQTT Version 5.0부터는 클라이언트가 사용자 이름 없이 비밀번호만 서버로 전송하는 것도 허용된다[70][71].

인가 과정에서는 앞서 언급된 사용자 이름과 비밀번호 외에도 CONNECT 패킷에 포함된 클라이언트 식별자나, 하위 프로토콜 계층에서 얻을 수 있는 호스트 이름 및 IP 주소 정보가 활용될 수 있다[72].

4. 2. 암호화

MQTT 사양 자체에는 암호화에 대한 구체적인 규정이 없다. 대신 하위 계층의 TLS나 VPN과 같은 기존 보안 기술을 이용하여 암호화를 적용할 수 있다고 언급하고 있다[73]. OASIS로 관리가 이관된 MQTT Version 3.1.1부터는 NIST의 사이버 보안 프레임워크를 MQTT에 적용할 때의 가이드라인도 마련되었다[74][75].

4. 3. 사이버 보안 프레임워크

MQTT는 사양 자체에 구체적인 보안 규정을 가지고 있지 않다. 기본적으로 구현에 따라 달라지며, 하위 통신 계층이 제공하는 기존의 보안 기술을 활용하도록 되어 있다.

다만, 다음과 같은 보안 관련 언급이 있다.

  • 인증: CONNECT 패킷에 사용자 이름과 비밀번호를 포함시켜 기본 인증을 수행할 수 있다[64][65][66]。 이러한 필드는 기본 인증 외에도 Bearer 토큰 전달 등 다른 목적으로도 사용될 수 있음이 언급된다[67][68][69]。 MQTT 버전 5.0부터는 사용자 이름 없이 비밀번호만 클라이언트에서 서버로 보내는 것도 가능해졌다[70][71]。
  • 인가: 인증에 사용되는 사용자 이름과 비밀번호 외에도, CONNECT 패킷의 클라이언트 식별자나 하위 계층 프로토콜에서 얻을 수 있는 호스트 이름 및 IP 주소 등을 인가에 활용할 수 있다고 언급한다[72]。
  • 암호화: 통신 내용을 보호하기 위해 TLS 또는 VPN을 사용할 수 있다고 언급한다[73]。


OASIS로 관리가 이관된 MQTT 버전 3.1.1부터는 NIST의 사이버 보안 프레임워크를 MQTT 환경에서 사용할 때 참고할 수 있는 가이드라인이 마련되었다[74][75]。

4. 4. 보안 문제

MQTT 사양 자체에는 구체적인 보안 규정이 명시되어 있지 않다. 보안은 기본적으로 구현에 따라 달라지며, 하위 통신 계층이 제공하는 기존의 보안 기술을 활용하도록 되어 있다. 다만, 다음과 같은 보안 관련 기능 및 고려 사항이 언급된다.

CONNECT 패킷에는 사용자 이름과 비밀번호를 포함할 수 있으며[64][65], 이를 이용해 기본 인증을 수행할 수 있다[66]. 하지만 이 필드들이 반드시 기본 인증에만 사용되는 것은 아니며, 예를 들어 비밀번호 필드를 Bearer 토큰 전달에 사용하는 방식도 가능하다[67][68][69]. MQTT 버전 5.0부터는 클라이언트가 서버로 사용자 이름 없이 비밀번호만 전송하는 것도 허용된다[70][71].

인가를 위해서는 앞서 언급된 사용자 이름과 비밀번호 외에도 CONNECT 패킷에 포함된 클라이언트 식별자나, 하위 계층 프로토콜에서 얻을 수 있는 호스트 이름 및 IP 주소 등이 활용될 수 있다[72].

암호화의 경우, TLS나 VPN을 이용할 수 있다고 언급되어 있다[73].

OASIS로 관리가 이관된 MQTT 버전 3.1.1부터는 NIST의 사이버 보안 프레임워크를 MQTT 사용 시 적용하기 위한 가이드라인이 마련되었다[74][75].

그러나 실제 운영 환경에서는 여러 보안 문제가 보고되었다.

  • 비밀번호 미설정 문제: 2018년 8월, 아바스트(Avast Software)는 스마트 홈 시스템 제어에 사용되는 MQTT 서버 중 상당수가 비밀번호로 보호되지 않아 외부 공격에 취약하다고 보고했다.[99] 전 세계적으로 49,000개 이상의 MQTT 서버가 공개되어 있었고, 그중 32,000개 이상은 비밀번호가 설정되지 않아 통신 내용을 쉽게 들여다볼 수 있는 상태였다. 보고서는 이것이 MQTT 사양이나 구현된 소프트웨어의 문제가 아닌, 시스템 구성상의 문제라고 지적했다.
  • 프로토콜 취약점: 2018년 12월, 트렌드마이크로(Trend Micro)는 M2M 통신 프로토콜의 취약점에 관한 보고서에서 MQTT 관련 문제를 지적했다.[100] MQTT 토픽에 비정상적인 UTF-8 문자열을 삽입하여 DoS 공격을 유발하거나, 남은 문자 수(Remaining Length) 필드를 조작하여 버퍼 오버플로우 공격을 일으킬 수 있는 가능성이 제기되었다.[101]
  • 서비스 거부 공격: 2020년 이탈리아 연구진은 MQTT 프로토콜을 대상으로 느린 DoS 공격을 성공시켜 보안 취약점을 입증했다 (CVE-2020-13849 참조).
  • 도청 및 변조 위험: 2024년 3월, 트렌드마이크로는 TLS를 사용하여 통신을 암호화하더라도 인증 절차가 없는 MQTT 서버가 다수 존재하여 도청 및 변조 위험에 노출되어 있다고 보고했다.[102] 보고서에 따르면, 이러한 서버가 수만 대에 달하며 그중 약 9,000대가 실제로 운영 중인 것으로 파악되었다. 보고서는 고객들이 벤더에게 보안 강화를 요구하지 않거나 보안 문제 자체를 인식하지 못하는 것이 주요 원인이라고 분석했다.

5. 메시지 유형

MQTT 프로토콜은 클라이언트와 브로커 간의 통신을 위해 정의된 메시지 유형들을 사용한다. 이 메시지들은 클라이언트와 브로커 연결 및 해제, 데이터 게시, 데이터 수신 확인, 연결 상태 감독 등 다양한 목적으로 활용된다.[18] MQTT 버전 5.0을 기준으로 총 15가지 종류의 제어 메시지(패킷 타입)가 정의되어 있다.[76]

각 MQTT 메시지 패킷은 일반적으로 고정 헤더(Fixed header), 가변 헤더(Variable header), 페이로드(Payload)의 세 부분으로 구성된다.[77][78] 메시지의 최소 크기는 2바이트이며, 필요에 따라 최대 256메가바이트에 가까운 데이터를 포함할 수 있다.

MQTT의 메시지 유형은 크게 세 가지 범주로 나눌 수 있다.[79] 각 범주와 해당 메시지 유형에 대한 자세한 내용은 아래 하위 섹션에서 설명한다.


  • 연결 관리: 클라이언트와 브로커 간의 연결 설정, 유지, 종료 및 인증 관련 메시지
  • 메시지 배포: 실제 메시지(데이터)를 게시하고 전달하며, 전달 보증 수준(QoS)에 따른 확인 절차를 수행하는 메시지
  • 토픽 관리: 클라이언트가 특정 토픽을 구독하거나 구독을 취소하는 요청 및 응답 메시지

5. 1. 연결/연결 해제

MQTT 연결(QoS 0) 예시. 연결(CONNECT, CONNACK), 게시/구독, 연결 해제(DISCONNECT) 과정을 보여준다.


MQTT 클라이언트는 서버와의 연결이 설정될 때까지 기다린 후 노드 간의 링크를 생성한다. 모든 작업이 완료되면 TCP/IP 세션이 종료될 때까지 대기한다.

클라이언트와 서버 간의 연결 설정, 유지, 해제 및 인증과 관련된 주요 메시지 유형은 다음과 같다.[80][81]

MQTT 연결/연결 해제 관련 메시지
메시지 유형설명버전발신자/수신자
CONNECT클라이언트가 서버에 연결을 요청하며 자신의 능력과 관련된 매개변수를 포함하여 전송한다.[82]모든 버전클라이언트 → 서버
CONNACK서버가 클라이언트의 연결 요청에 대한 결과를 반환한다.[82] MQTT 5.0부터는 서버의 옵션 기능을 클라이언트에 알리는 매개변수가 추가되었다.[83]모든 버전서버 → 클라이언트
DISCONNECT클라이언트의 종료나 오류 발생 시 클라이언트가 연결 종료를 위해 전송한다.[84] MQTT 5.0부터는 서버 측에서도 특정 상황에서 DISCONNECT를 전송할 수 있다.[85]모든 버전클라이언트 → 서버
(v5.0부터 서버 → 클라이언트도 가능)
PINGREQ클라이언트가 설정된 Keep Alive 시간 내에 서버로 전송하여 연결 유지를 확인한다.[86][87]모든 버전클라이언트 → 서버
PINGRESP서버가 PINGREQ 메시지에 응답하여 연결이 유지되고 있음을 알린다.[87]모든 버전서버 → 클라이언트
AUTHMQTT 5.0에서 추가된 메시지로, 인증 강화를 위해 사용된다.[88] 두 번 이상의 핸드셰이크가 필요한 인증 알고리즘을 수행하거나 통신 중 재인증이 필요할 때 사용되며, 클라이언트와 서버 양쪽에서 시작될 수 있다.[89]v5.0양방향 가능



기본적으로 클라이언트가 `CONNECT` 메시지를 보내고 서버가 `CONNACK`으로 응답하면서 통신이 시작된다.[82] 연결 유지가 필요할 경우, Keep Alive 타이머가 만료되기 전에 클라이언트는 `PINGREQ`를 보내고 서버는 `PINGRESP`로 응답하여 접속 상태를 유지한다.[86][87] 통신 종료는 주로 클라이언트가 `DISCONNECT` 메시지를 보내면서 이루어진다.[84]

5. 2. 메시지 배포

메시지 전송 및 확인과 관련된 메시지 유형으로는 PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP가 있다.[90]

메시지 배포는 PUBLISH 메시지로 시작된다.[91] PUBLISH 메시지는 클라이언트가 브로커에게 메시지를 게시할 때 사용될 뿐만 아니라, 브로커가 구독하는 클라이언트에게 메시지를 전달할 때도 사용된다. 따라서 PUBLISH 패킷은 클라이언트와 서버 양쪽에서 송신하거나 수신할 수 있다.

메시지 전달 보장 수준(QoS)에 따라 메시지 확인 절차가 달라진다.

  • QoS 1: 메시지를 수신한 측에서는 메시지 배포 완료를 알리기 위해 PUBACK 메시지를 전송한다.[92]
  • QoS 2: 보다 정교한 확인 절차를 따른다. 메시지를 수신한 측은 먼저 PUBREC 메시지를 보내고, 이를 받은 송신 측은 PUBREL 메시지를 보낸다. 마지막으로 수신 측이 PUBCOMP 메시지를 보내 메시지 배포와 관련된 모든 과정이 완료되었음을 최종 확인한다. 이를 통해 메시지 중복 및 누락을 방지하는 가장 높은 수준의 전달을 보장한다.[93]

5. 3. 토픽 구독/취소

MQTT 클라이언트는 특정 토픽의 메시지를 수신하기 위해 브로커에게 구독 요청을 보낸다. 이때 사용하는 메시지가 `SUBSCRIBE`이다. 클라이언트는 구독하려는 토픽 필터를 UTF-8로 인코딩된 문자열 형태로 `SUBSCRIBE` 메시지에 담아 브로커에게 전송한다.[95] 브로커는 이 요청을 처리한 후, 구독 요청의 성공 여부와 같은 결과를 `SUBACK` 메시지를 통해 클라이언트에게 응답한다.[95]

반대로, 특정 토픽에 대한 구독을 중단하고 싶을 때는 클라이언트가 `UNSUBSCRIBE` 메시지를 브로커에게 보낸다.[96] 브로커는 해당 토픽에 대한 구독 취소 요청을 처리하고, 그 결과를 `UNSUBACK` 메시지로 클라이언트에게 회신한다.[96]

이처럼 `SUBSCRIBE`, `SUBACK`, `UNSUBSCRIBE`, `UNSUBACK` 네 가지 메시지 유형은 MQTT 프로토콜에서 클라이언트가 특정 토픽을 구독하거나 구독을 취소하는 과정을 관리하는 데 사용된다.[94]

6. MQTT 브로커

MQTT 프로토콜은 메시지 브로커와 다수의 클라이언트라는 두 가지 유형의 네트워크 개체를 정의한다.[17] MQTT 브로커는 클라이언트로부터 모든 메시지를 수신한 다음, 해당 메시지를 받아야 할 적절한 대상 클라이언트로 라우팅하는 서버 역할을 한다. 메시지를 보내는 클라이언트(게시자)와 받는 클라이언트(구독자) 사이에서 메시지를 중개하며, 이들은 토픽이라는 주제를 기반으로 통신한다. 게시자와 구독자는 서로의 존재를 알 필요 없이 브로커를 통해 분리되어 통신할 수 있다.

MQTT 브로커는 소프트웨어 형태로 구현되며, 기업 내부 서버(온프레미스)나 클라우드 컴퓨팅 환경에서 실행될 수 있다. 직접 개발하여 사용하거나 상용 솔루션을 이용할 수도 있으며, 오픈 소스로 공개된 브로커들도 존재한다. 브로커는 메시지 라우팅 외에도 보안, 고가용성, 세션 관리 등 다양한 기능을 제공하며, 이를 통해 안정적이고 확장 가능한 메시징 시스템을 구축하는 데 핵심적인 역할을 수행한다.

6. 1. 역할

MQTT 프로토콜은 크게 두 가지 종류의 네트워크 구성 요소, 즉 메시지 브로커와 다수의 클라이언트로 이루어진다. 메시지 브로커는 클라이언트로부터 오는 모든 메시지를 수신한 뒤, 해당 메시지를 받아야 할 적절한 대상 클라이언트에게 전달하는 서버 역할을 수행한다.[17] 이는 마치 우체국이 편지를 받아 수신자에게 배달하는 것과 유사한 역할이라고 비유할 수 있다.

정보는 '토픽(topic)'이라는 주제 계층 구조로 관리된다. 어떤 클라이언트(게시자)가 새로운 데이터를 배포하고자 할 때, 해당 데이터를 포함한 제어 메시지를 연결된 브로커에게 보낸다. 그러면 브로커는 그 토픽을 구독(subscribe)하고 있는 모든 클라이언트(구독자)에게 이 정보를 전달한다. 이 과정에서 게시자는 구독자가 누구인지, 몇 명인지 알 필요가 없으며, 구독자 역시 게시자에 대한 정보를 알 필요가 없다. 이처럼 브로커를 중심으로 통신함으로써 게시자와 구독자는 서로 분리(decoupling)된다.

클라이언트는 마이크로컨트롤러와 같은 소형 장치부터 일반적인 서버에 이르기까지 다양하며, MQTT 라이브러리를 실행하여 네트워크를 통해 브로커에 연결된다.[18] 각 클라이언트는 데이터를 게시할 수도 있고, 특정 토픽을 구독하여 데이터를 수신할 수도 있다. 이는 사물인터넷(IoT) 장치가 센서 데이터를 브로커로 보내는 동시에, 원격으로 제어 명령이나 설정 정보를 받을 수 있는 양방향 통신을 가능하게 한다.

브로커는 단순히 메시지를 중계하는 것 외에도 여러 유용한 기능을 제공한다.

  • 보존된 메시지 (Retained Message): 브로커는 특정 토픽에 대해 가장 최근에 게시된 메시지 중 '보존' 플래그가 설정된 메시지를 저장할 수 있다. 만약 어떤 토픽에 대해 현재 구독자가 없는 상태에서 메시지가 도착하면, 이 메시지가 '보존'되도록 설정되지 않는 한 브로커는 메시지를 폐기한다. 하지만 보존된 메시지가 있다면, 새로운 클라이언트가 해당 토픽을 구독하는 즉시 브로커는 저장해 둔 최신 메시지를 전달해준다. 이를 통해 새 구독자는 게시자의 다음 업데이트를 기다릴 필요 없이 가장 최신 값을 바로 받을 수 있다.[19]
  • 유언 메시지 (Last Will and Testament): 게시 클라이언트가 처음 브로커에 연결할 때, 만약 예기치 않게 연결이 끊어지는 경우를 대비하여 특정 메시지를 미리 설정해 둘 수 있다. 브로커는 해당 클라이언트의 연결이 비정상적으로 종료되었음을 감지하면, 이 '유언' 메시지를 해당 클라이언트가 지정한 토픽의 구독자들에게 대신 전달한다.
  • 영구 세션 (Persistent Session): 브로커는 클라이언트가 접속을 끊었다가 다시 연결해도 이전 상태를 기억하는 '영구 세션' 기능을 지원한다. 이를 통해 브로커는 각 클라이언트의 연결 정보, 구독 중인 토픽 목록, 그리고 아직 전달되지 않은 메시지(특히 서비스 품질(QoS) 수준이 1 또는 2인 메시지)를 저장하고 관리한다.[22]


MQTT 브로커는 소프트웨어 형태로 구현되며, 기업 내부 서버(온프레미스)나 클라우드 컴퓨팅 환경에서 실행될 수 있다. 직접 개발하여 사용하거나, 상용 솔루션을 이용할 수도 있으며, 오픈 소스로 공개된 브로커들도 많이 존재한다.

브로커를 사용하는 MQTT 아키텍처는 다음과 같은 주요 장점을 가진다.

  • 클라이언트 분리: 클라이언트 장치와 서버 애플리케이션이 브로커를 통해 분리되어 서로의 상세 정보를 알 필요 없이 통신할 수 있다.
  • 확장성: 단일 장치 환경에서 수천 개의 장치가 연결되는 대규모 환경까지 쉽게 확장할 수 있다.
  • 상태 관리 및 보안: 브로커는 클라이언트의 연결 상태, 보안 자격 증명 등을 효과적으로 관리하고 추적하며, 전송 계층 보안(TLS)을 통한 암호화 및 인증서, 사용자 이름/암호 기반의 인증을 통해 취약하고 안전하지 않은 클라이언트 연결을 방지할 수 있다 (적절한 설정 필요). 기본적으로 MQTT는 포트 1883을 사용하며, TLS로 암호화된 통신은 포트 8883을 사용한다.[20]
  • 네트워크 효율성: 셀룰러나 위성 네트워크와 같이 대역폭이 제한적인 환경에서도 통신 부담을 줄여 효율적으로 작동할 수 있다 (적절한 설정 필요).
  • 고가용성: 장애 발생 시, 자동으로 백업 브로커로 작업을 넘기거나(failover), 여러 서버에 부하를 분산시키는(load balancing) 구성이 가능하다.


브로커는 표준 MQTT 프로토콜뿐만 아니라 Sparkplug와 같은 관련 규격도 동시에 지원할 수 있다.[21] 또한, 시스템은 필요에 따라 여러 브로커 서버를 포함하여 구성될 수 있으며, 이 브로커들은 서로 데이터를 교환하며 클라이언트의 구독 정보에 따라 메시지를 전달한다.

6. 2. 아키텍처

MQTT 프로토콜은 메시지 브로커와 다수의 클라이언트라는 두 가지 유형의 네트워크 개체를 정의한다.[17] MQTT 브로커는 서버 역할을 하며, 클라이언트로부터 모든 메시지를 받아 적절한 대상 클라이언트로 전달한다. MQTT 클라이언트는 마이크로컨트롤러부터 서버까지 다양한 장치로, MQTT 라이브러리를 실행하고 네트워크를 통해 MQTT 브로커에 연결된다.[18] 이 구조에서 클라이언트들은 서로 직접 통신하지 않고 브로커를 통해서만 정보를 교환하며, 서로의 존재나 정보를 알 수 없다.

정보는 '토픽(Topic)'이라는 계층 구조로 구성된다. 게시자(Publisher)는 새로운 데이터를 배포할 때, 해당 데이터를 포함한 제어 메시지를 연결된 브로커로 보낸다. 브로커는 이 정보를 해당 토픽을 구독(Subscribe)한 모든 클라이언트에게 전달한다. 게시자는 구독자의 수나 위치를 알 필요가 없고, 구독자 역시 게시자에 대한 정보를 알 필요가 없다.

브로커는 현재 구독자가 없는 토픽에 대한 메시지를 받으면 기본적으로 폐기하지만, 게시자가 메시지를 '보존 메시지(Retained Message)'로 지정하면 예외이다. 보존 메시지는 보존 플래그가 참(true)으로 설정된 일반 MQTT 메시지이며, 브로커는 각 토픽별로 마지막 보존 메시지와 해당 서비스 품질(QoS)을 저장한다.[19] 새로운 구독자는 구독 즉시 해당 토픽의 마지막 보존 메시지를 받아 최신 값을 바로 얻을 수 있다.

게시 클라이언트는 브로커에 처음 연결할 때, 예기치 않게 연결이 끊어질 경우를 대비해 구독자에게 전송될 기본 메시지(Last Will and Testament)를 설정할 수 있다. 클라이언트는 오직 브로커와만 상호 작용하지만, 시스템은 여러 브로커 서버를 포함하여 현재 구독자의 토픽에 따라 데이터를 교환할 수도 있다.

MQTT 제어 메시지는 최소 2바이트부터 최대 약 256메가바이트까지 데이터를 전달할 수 있다. 연결 설정 및 해제, 데이터 게시, 수신 확인, 연결 감독 등에 사용되는 14가지 메시지 유형이 정의되어 있다.

MQTT는 데이터 전송을 위해 기본적으로 TCP 프로토콜을 사용한다. 변형인 MQTT-SN은 UDP나 블루투스 같은 다른 전송 방식을 사용하기도 한다.

기본적으로 MQTT는 연결 정보를 일반 텍스트로 전송하며 자체적인 보안 조치는 포함하지 않는다. 보안 강화를 위해서는 전송 계층 보안(TLS)을 사용하여 전송되는 정보를 암호화하고 보호해야 한다. 추가적으로 인증서나 사용자 이름/비밀번호를 통한 인증 방식도 사용할 수 있다. 기본 암호화되지 않은 MQTT 포트는 1883이며, TLS로 암호화된 포트는 8883이다.[20]

MQTT 브로커는 온프레미스나 클라우드 환경의 컴퓨터에서 실행되는 소프트웨어로, 직접 구축하거나 호스팅 서비스를 이용할 수 있으며, 오픈 소스 및 상용 구현 모두 존재한다. 브로커는 마치 우체국처럼 작동하여, 클라이언트는 특정 수신자의 주소 대신 '토픽'을 사용하여 메시지를 보내고, 해당 토픽을 구독하는 모든 클라이언트는 메시지 사본을 받는다. 여러 클라이언트가 한 브로커의 토픽을 구독할 수 있고(일대다), 한 클라이언트가 여러 브로커의 토픽을 구독할 수도 있다(다대일).

각 클라이언트는 게시와 구독을 모두 수행할 수 있어 양방향 통신이 가능하다. 예를 들어, 장치는 센서 데이터를 게시하면서 동시에 구성 정보나 제어 명령을 수신할 수 있다. 이는 데이터 공유, 장치 관리 및 제어에 유용하다.

MQTT 브로커 아키텍처는 클라이언트 장치와 서버 애플리케이션을 분리한다. 장애 발생 시, 브로커 소프트웨어와 클라이언트는 예비 브로커로 자동 전환(Failover)될 수 있다. 또한, 여러 서버에 걸쳐 클라이언트 부하를 분산하도록 설정할 수도 있다. 브로커는 표준 MQTT와 Sparkplug와 같은 규정 준수 사양을 동시에 지원할 수 있다.[21]

브로커는 "영구 세션(Persistent Session)" 기능을 통해 장치가 켜고 꺼지는 동안에도 세션 정보를 추적한다. 이 상태에서 브로커는 각 클라이언트의 연결 정보, 구독한 토픽 목록, QoS 1 또는 2 레벨의 메시지를 저장한다.[22]

MQTT 브로커를 사용함으로써 얻는 주요 이점은 다음과 같다.

# (적절히 구성된 경우) 취약하고 안전하지 않은 클라이언트 연결 제거

# 단일 장치에서 수천 개로 쉽게 확장 가능

# (적절히 구성된 경우) 보안 자격 증명 및 인증서를 포함한 클라이언트 연결 상태 관리 및 추적

# (적절히 구성된 경우) 보안을 유지하면서 셀룰러 또는 위성 네트워크의 부담 감소

MQTT 클러스터링은 MQTT 배포 환경에서 고가용성, 내결함성, 확장성을 확보하기 위한 기술이다.[26] 클러스터링을 통해 상호 연결된 브로커 노드 네트워크를 구성하여, 하드웨어 오류나 네트워크 중단 시에도 지속적이고 안정적인 메시지 전달을 보장할 수 있다.

6. 3. 주요 기능

MQTT 메시지 브로커는 메시지 전달의 효율성과 신뢰성을 높이는 다양한 기능을 제공한다. 주요 기능은 다음과 같다.

  • '''영구 세션 (Persistent Sessions)''': 클라이언트의 연결이 불안정하거나 장치가 재시작되는 경우에도 서비스 연속성을 보장하기 위해, 브로커는 '영구 세션' 정보를 저장한다. 여기에는 클라이언트의 연결 상태, 구독하고 있는 토픽 목록, 그리고 서비스 품질(QoS) 레벨 1 또는 2로 전송 중이던 메시지 등이 포함된다.[22] 이를 통해 클라이언트는 브로커에 다시 연결했을 때 이전 세션 상태를 복구하여 중단 없이 작업을 이어갈 수 있다.

  • '''자동 백업 및 중복화''': 시스템 안정성을 높이기 위해 MQTT는 브로커의 중복 구성을 지원한다. 주 브로커에 장애가 발생하면, 클라이언트는 자동으로 예비(백업) 브로커로 연결을 전환(핸드오버)할 수 있다. 또한, MQTT 클러스터링 기술을 통해 여러 브로커를 묶어 고가용성과 결함 허용성을 갖춘 네트워크를 구축할 수 있으며,[26] 이를 통해 하드웨어 문제나 네트워크 중단 시에도 메시지 전달이 끊기지 않도록 보장한다. 백업 브로커는 온프레미스, 클라우드 등 다양한 환경에 구성 가능하며, 여러 서버에 걸쳐 부하를 분산시키는 역할도 수행한다.

  • '''다양한 MQTT 사양 지원''': 표준 MQTT 프로토콜 외에도, 특정 산업 분야나 요구사항에 맞춰 확장된 MQTT 사양을 지원할 수 있다. 예를 들어, 산업용 사물인터넷(IIoT) 환경에서 주로 사용되는 Sparkplug 규약을 지원하는 브로커도 있다.[21] 브로커는 이러한 여러 사양을 동일한 서버에서 동시에, 동일한 보안 정책 하에 운영할 수 있어 유연성이 높다.

  • '''보존 메시지 (Retained Messages)''': 특정 토픽에 대해 가장 최근에 발행된 메시지를 브로커가 '보존'하도록 설정할 수 있다. 새로운 클라이언트가 해당 토픽을 구독하는 경우, 다음 번 메시지가 발행될 때까지 기다릴 필요 없이 즉시 이 보존된 메시지를 수신하여 해당 토픽의 최신 상태를 빠르게 파악할 수 있다.[19] 브로커는 각 토픽별로 마지막 하나의 보존 메시지만 저장한다.

  • '''최후 유언 (Last Will and Testament - LWT)''': 클라이언트는 브로커에 연결할 때 '최후 유언' 메시지를 미리 등록할 수 있다. 만약 해당 클라이언트의 연결이 비정상적으로 끊어지면, 브로커는 이 유언 메시지를 미리 지정된 토픽으로 발행하여 다른 클라이언트들이 해당 클라이언트의 상태 변화(연결 끊김)를 인지할 수 있도록 돕는다.

  • '''보안 강화''': MQTT 자체는 TCP를 기반으로 동작하며 기본적인 보안 기능을 포함하지 않지만, 전송 계층 보안(TLS) 프로토콜을 함께 사용하여 통신 내용을 암호화하고 데이터의 기밀성과 무결성을 보장할 수 있다. 또한 사용자 이름과 비밀번호, 또는 디지털 인증서를 이용한 클라이언트 인증 기능을 통해 허가된 사용자 및 장치만 브로커에 접속하도록 제한할 수 있다. 변형인 MQTT-SN은 UDP나 블루투스 같은 다른 전송 방식을 사용하기도 한다.

  • '''확장성 및 분리''': MQTT 아키텍처는 메시지를 보내는 게시자(Publisher)와 메시지를 받는 구독자(Subscriber)를 브로커를 통해 분리시킨다. 이로 인해 시스템 구성 요소 간의 의존성이 낮아지고, 단일 장치 환경에서 수천, 수만 개의 장치가 연결되는 대규모 시스템으로 쉽게 확장할 수 있다.

6. 4. 주요 장점

MQTT 브로커를 사용했을 때 얻을 수 있는 주요 장점은 다음과 같다.

# 취약하거나 안전하지 않은 클라이언트 연결을 제거할 수 있다 (적절하게 구성된 경우).

# 단일 장치에서 수천 개의 장치로 쉽게 확장할 수 있다.

# 보안 자격 증명 및 인증서를 포함하여 클라이언트 연결 상태를 관리하고 추적할 수 있다 (적절하게 구성된 경우).

# 보안을 유지하면서 셀룰러 네트워크나 위성 네트워크의 부담을 줄일 수 있다 (적절하게 구성된 경우).

6. 5. 종류

MQTT 브로커는 컴퓨터(온프레미스 또는 클라우드에서 실행)에서 실행되는 소프트웨어로, 직접 구축하거나 타사에서 호스팅할 수 있다. 오픈 소스 및 상용 구현 모두 사용할 수 있다.

MQTT를 지원하는 브로커(MQ 서버)는 다수 존재하며, 각 서버는 기본 기능 외에 고유한 기능을 지원할 수 있다.[97] 주요 MQTT 브로커는 다음과 같다.

종류이름비고
오픈 소스Mosquitto-
오픈 소스RabbitMQ플러그인 필요
오픈 소스Apache ActiveMQ-
오픈 소스[https://github.com/dotnet/MQTTnet MQTTnet].NET 기반 라이브러리, 짧은 코드로 확장 가능한 자체 브로커 구현 가능
상용IBM MessageSight하드웨어
상용IBM WebSphere MQ Telemetry-
상용MqttDesk MQTT Client-[98]


7. 활용 사례

(내용 없음)

7. 1. 페이스북 메신저

페이스북 메신저에서 MQTT를 사용하고 있다.

7. 2. IECC Scalable

델타레일 그룹(현재: Resonate Group)의 IECC 시그널링 제어 시스템 최신 버전은 시스템과 시그널링 시스템의 다른 구성 요소 간 통신에 MQTT를 사용한다.

8. 버전 5.0

2019년, OASIS는 공식 MQTT 5.0 표준을 발표했다.[1] 버전 5.0에는 다음과 같은 주요 새 기능이 포함되어 있다:[23]


  • 이유 코드: 응답 메시지에 실패 이유를 명확히 알리는 반환 코드가 포함된다. 이를 통해 오류 처리 및 디버깅이 용이해진다.
  • 공유 구독: 여러 클라이언트가 동일한 구독을 공유하여 메시지를 분산 처리할 수 있게 한다. 이는 특정 클라이언트에 부하가 집중되는 것을 방지하고 시스템 확장성을 높이는 데 도움이 된다.
  • 메시지 만료: 메시지에 유효 기간을 설정할 수 있다. 설정된 시간 내에 구독자에게 전달되지 않은 메시지는 자동으로 삭제되어 불필요한 데이터 축적을 막는다.
  • 토픽 별칭: 자주 사용되는 긴 토픽 이름을 짧은 숫자로 대체하여 사용할 수 있다. 이는 메시지 크기를 줄여 네트워크 대역폭 사용량을 절감하는 효과를 가져온다.

참조

[1] 웹사이트 MQTT Version 5.0 https://docs.oasis-o[...] OASIS 2019-03-07
[2] 웹사이트 ISO/IEC 20922:2016 Information technology — Message Queuing Telemetry Transport (MQTT) v3.1.1 https://www.iso.org/[...] 2024-10-27
[3] 웹사이트 MQTT SN Subcommittee https://www.oasis-op[...] OASIS 2020-12-15
[4] 웹사이트 OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee Charter https://www.oasis-op[...] OASIS 2020-12-15
[5] 웹사이트 10th birthday party http://mqtt.org/2009[...] 2009-07
[6] 웹사이트 Transcript of IBM podcast https://www.ibm.com/[...] 2011-11
[7] 웹사이트 Getting Started with MQTT https://www.hivemq.c[...] HiveMQ 2020-04-24
[8] 웹사이트 Introducing the MQTT Protocol - MQTT Essentials: Part 1 https://www.hivemq.c[...]
[9] 웹사이트 MQTT v3.1 and MQTT v3.1.1 Differences https://www.oasis-op[...] OASIS Message Queuing Telemetry Transport (MQTT) TC 2015-02-12
[10] 웹사이트 MQTT V3.1 Protocol Specification https://public.dhe.i[...] Eurotech, International Business Machines Corporation (IBM) 2010
[11] 웹사이트 OASIS MQTT Technical Committee Minutes of for the meeting of Thursday, 25th April 2013 Teleconference https://www.oasis-op[...]
[12] 웹사이트 MQTT Version 3.1.1 http://docs.oasis-op[...] 2014-10-29
[13] 웹사이트 6 facts why it's worth upgrading to the brand new MQTT 3.1.1 version https://www.hivemq.c[...] 2014-10-30
[14] 웹사이트 Differences between 3.1.1 and 5.0 https://github.com/m[...]
[15] 웹사이트 MQTT For Sensor Networks (MQTT-SN) Protocol Specification Version 1.2 https://www.oasis-op[...] OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee 2013-11-14
[16] 웹사이트 Introduction to MQTT-SN (MQTT for Sensor Networks) http://www.steves-in[...] 2017-01-25
[17] 웹사이트 Getting to know MQTT https://developer.ib[...] 2019-10-13
[18] 웹사이트 Client, Broker / Server and Connection Establishment - MQTT Essentials: Part 3 https://www.hivemq.c[...] 2019-07-17
[19] 웹사이트 Retained Messages - MQTT Essentials: Part 8 https://www.hivemq.c[...] 2015-03-02
[20] 웹사이트 FAQ - Frequently Asked Questions {{!}} MQTT http://mqtt.org/faq
[21] 웹사이트 MQTT Sparkplug/Tahu https://www.cirrus-l[...] 2019-11-05
[22] 서적 MQTT For Complete Beginners 2020
[23] 웹사이트 What is MQTT? Definition and Details https://www.paessler[...]
[24] 웹사이트 IBM Knowledge Center - IBM MQ - Using MQTT with IBM Integration Bus - Quality of service and connection management https://www.ibm.com/[...] 2018-01-30
[25] 논문 SlowITe, a novel denial of service attack affecting MQTT Sensors, 20(10), 2932 2020
[26] 웹사이트 High availability MQTT Cluster - Bevywise Networks https://www.bevywise[...]
[27] 웹사이트 APIs & Protocols https://solace.com/p[...]
[28] 웹사이트 MQTT 5.0 Support 🎉 https://solace.commu[...] 2021-01-04
[29] 웹사이트 OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee Charter https://www.oasis-op[...] OASIS 2020-12-15
[30] 웹사이트 MQTT SN Subcommittee https://www.oasis-op[...] OASIS 2020-12-15
[31] 문서 MQTT Version 5.0
[32] 문서 MQTT Version 5.0
[33] 웹사이트 Introducing the MQTT Protocol – MQTT Essentials: Part 1T https://www.hivemq.c[...] HiveMQ 2024-02-14
[34] 문서 MQTT Specifications https://mqtt.org/mqt[...]
[35] 웹사이트 The Origin of MQTT https://www.hivemq.c[...] HiveMQ 2024-06-20
[36] 문서 MQ Integrator Pervasive Device Protocol Protocol Version 2
[37] Cite Introducing the MQTT Protocol – MQTT Essentials: Part 1T https://www.hivemq.c[...] HiveMQ 2024-10-27
[38] Cite Introducing the MQTT Protocol – MQTT Essentials: Part 1T https://www.hivemq.c[...] HiveMQ 2024-10-27
[39] 문서 MQTT Version 3.1.1
[40] 웹사이트 Foundational IoT Messaging Protocol, MQTT, Becomes International OASIS Standard https://www.oasis-op[...] OASIS 2024-08-03
[41] 문서 ISO/IEC 20922:2016
[42] 웹사이트 OASIS MQTT Internet of Things Standard Now Approved by ISO/IEC JTC1 https://www.oasis-op[...] OASIS 2024-08-03
[43] 문서 MQTT Version 5.0
[44] 웹사이트 "#MQTT V5.0 Committee Specification 02 approved & published" https://www.oasis-op[...] OASIS 2024-08-03
[45] 문서 MQTT Version 3.1
[46] 문서 MQTT Version 5.0
[47] 문서 MQTT Version 5.0
[48] 문서 MQTT Version 5.0
[49] 문서 MQTT Version 5.0
[50] 문서 MQTT Version 5.0
[51] 문서 MQTT Version 5.0
[52] 문서 MQTT Version 5.0
[53] 문서 MQTT Version 5.0
[54] 문서 MQTT Version 5.0
[55] 문서 MQTT Version 5.0
[56] 문서 MQTT Version 5.0
[57] 문서 MQTT Version 5.0
[58] 문서 MQTT Version 5.0
[59] 문서 MQTT Version 5.0
[60] 문서 MQTT Version 5.0
[61] 문서 MQTT Version 3.1
[62] 블로그 MQTTのLWTを利用してリアルタイムにAWS IoTに接続するデバイスの切断を検出する https://aws.amazon.c[...] Amazon Web Services ブログ 2024-07-21
[63] 문서 MQTT Version 5.0
[64] 문서 MQTT Version 5.0
[65] 문서 MQTT Version 5.0
[66] 문서 MQTT Version 5.0
[67] 문서 MQTT Version 5.0
[68] 문서 MQTT Version 5.0
[69] 문서 MQTT Version 5.0
[70] 문서 MQTT Version 3.1.1에서는User Name Flagが0の場合Password Flagも0にする必要があった。
[71] 문서 MQTT Version 3.1.1
[72] 문서 MQTT Version 5.0
[73] 문서 MQTT Version 5.0
[74] 문서 MQTT and the NIST Cybersecurity Framework Version 1.0
[75] 웹사이트 How MQTT 3.1.1 Was Standardized https://www.hivemq.c[...] HiveMQ 2024-07-17
[76] 문서 MQTT Version 5.0
[77] 문서 MQTT Version 5.0
[78] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[79] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[80] 문서 MQTT Version 3.1.1より前の仕様では定義されていない
[81] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[82] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[83] 문서 MQTT Version 5.0
[84] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[85] 문서 MQTT Version 5.0
[86] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[87] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[88] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[89] 문서 MQTT Version 5.0
[90] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[91] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[92] 문서 MQTT Version 5.0
[93] 문서 MQTT Version 5.0
[94] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[95] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[96] 웹사이트 MQTT Packets: A Comprehensive Guide https://www.hivemq.c[...] HiveMQ 2024-07-22
[97] 문서 MQTT Broker Feature Comparison https://github.com/m[...]
[98] 웹사이트 Cross-Platform MQTT Client https://ja.ioctrl.co[...] 2021-09-04
[99] 웹사이트 Are smart homes vulnerable to hacking? https://blog.avast.c[...] Avast Software 2018-08-16
[100] 웹사이트 マシン・ツー・マシン（M2M）技術における設計および実装上の脆弱性 https://blog.trendmi[...] トレンドマイクロ 2018-12-04
[101] 웹사이트 CVE-2018-17614 https://cve.mitre.or[...] The MITRE Corporation 2018-09-28
[102] 웹사이트 第三者によるデータの盗聴や改ざんの可能性も：MQTTプロトコルやM2M通信におけるリスク https://www.trendmic[...] トレンドマイクロ 2024-03-01
[103] 웹인용 MQTT Version 5.0 https://docs.oasis-o[...] OASIS 2019-03-07
[104] 웹인용 MQTT SN Subcommittee https://www.oasis-op[...] OASIS
[105] 웹인용 OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee Charter https://www.oasis-op[...] OASIS
[106] 웹인용 MQTT 3.1.1 specification http://docs.oasis-op[...] OASIS 2015-12-10
[107] 웹인용 ISO/IEC 20922:2016 Information technology -- Message Queuing Telemetry Transport (MQTT) v3.1.1 https://www.iso.org/[...] 국제 표준화 기구 2016-06-15
[108] 웹인용 10th birthday party http://mqtt.org/2009[...] 2009-07
[109] 웹인용 OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee https://www.oasis-op[...] OASIS 2014-05-09
[110] 웹인용 MQTT For Sensor Networks (MQTT-SN) Protocol Specification Version 1.2 http://mqtt.org/MQTT[...] MQTT 2013-11-14
[111] 웹인용 IBM MQ https://www.ibm.com/[...] IBM 2013-11-18
[112] 웹인용 Choosing Your Messaging Protocol: AMQP, MQTT, or STOMP http://blogs.vmware.[...] VM웨어 Blogs 2013-02-19
[113] 웹인용 Cross-Platform MQTT Client https://www.ioctrl.c[...] 2021-09-04
[114] 웹인용 IBM Knowledge Center https://www.ibm.com/[...] 2018-01-30


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com