MQTT(Message Queuing Telemetry Transport)는 사람이 말하는 메시지 큐 원격 측정 전송(Message Queuing Telemetry Transport)을 의미합니다. 몇 년 전만 해도 PC 쪽이 널리 보급된 엔지니어들은 단순히 우회적인 용어를 듣지 못했지만, 사물 인터넷(IoT) 기술이 점진적으로 발전하면서 이 프로토콜은 주요 엔지니어들의 눈에 점점 더 자주 등장했습니다. 이로 인해 많은 엔지니어들은 이름만 알고 의미를 알지 못했으며, IoT의 발전과 함께 개발된 일종의 프로토콜이라고 생각하는 사람들도 많았습니다. 실제로 MQTT 프로토콜은 20여년 전에 처음 발명되었으며, 1999년에 IBM의 Andy Stanford Clark과 Cirrus Link의 Alan Nippe가 프로토콜의 첫 번째 버전을 작성했습니다. 이후 이 프로토콜은 ISO 표준(ISO/IEC PRF 20922)에 따라 게시/구독-기반 메시징 프로토콜로 국제적으로 표준화되었습니다. IBM은 2013년에 MQTT 버전 3.1 사양을 구조적 정보 표준 촉진 조직(Structured Information Standards Facilitation Organization)에 제출했으며, 사양에 소수의 변경만 허용되도록 하는 헌장과 함께 MQTT 프로토콜은 여러 곳에서 사용되었습니다. 그 이후로 틈새 시장. IoT의 기술 인프라가 완성되자 이 고대 프로토콜은 첫 번째 봄을 맞이하기 시작했습니다.
네트워크의 전송 및 애플리케이션 계층
우리 모두가 알고 있듯이, 지금까지의 사물 인터넷의 급속한 발전은 통신 네트워크 인프라를 벗어날 수 없었습니다. 이제는 집 안의 전등 스위치 하나로 세계 어느 곳이든 제어할 수 있으며, 산업용 제어를 위해서는 로봇의 움직임을 원격으로 제어할 수도 있습니다. 이 기술의 성숙도는 네트워크 통신을 기반으로 합니다. 현재 네트워크 기술의 주요 기술은 OSI 7{1}}레이어 모델이지만 실제 애플리케이션은 실제로 TCP/IP 4{2}}레이어 네트워크 모델을 사용하고 있습니다.
세 번째 전송 계층의 TCP/IP 4{0}}계층 네트워크 모델은 유명한 TCP/IP 프로토콜이며, 프로토콜의 주요 목적인 이 계층은 위의 다른 컴퓨터의 지정된 IP 주소(예: IP 주소 "192.168.137.19")로 네트워크 통신 데이터 전송을 통해 컴퓨터를 보내는 데 사용됩니다. 예를 들어, IP 주소가 "192.168.137.19"인 컴퓨터가 16바이트 바이너리 패킷을 IP 주소가 "192.168.137.10"인 시스템으로 전송하면 TCP/IP 프로토콜을 사용하여 전송할 수 있습니다. 대신 TCP를 사용하여 데이터를 전송할 때 일반적으로 소켓을 사용합니다.
그러나 "192.168.137.19" 기계의 IP 주소가 "192.168.137.10" 기계로 데이터를 보낼 때 데이터 내부의 이 TCP 패킷 패킷은 실제로 "192.168.137.10" 기계의 수신 측 IP 주소의 수신 측의 의미를 대신하여 이 데이터 패킷을 구문 분석하는 방법에 대해 이 문제는 계층 위의 전송 계층에 남아 있습니다. 해결해야 할 프로토콜이 바로 애플리케이션 계층 프로토콜입니다. 물론, 귀하의 프로토콜이 일반적인 컴퓨터 네트워크에 해상도를 제공하고 싶지 않다면 자체 응용 프로그램 계층 프로토콜 중 일부를 개발할 수도 있습니다. 전송 계층의 목적은 단지 그 위에 있는 대상 시스템에 데이터를 전달하는 것입니다.
우리의 일상 업무, 엔터테인먼트는 종종 웹 페이지를 열 때 그림이 해당 위치에 표시되고 아래로 향하는 버튼이 어떤 기능을 수행하는지와 같은 다양한 애플리케이션 계층 프로토콜에 직면하게 됩니다. 이는 HTML HyperText Transfer Protocol(영어: HyperTextTransferProtocol, 약어: HTTP)에 의해 동의됩니다. 이렇게 하면 어떤 기기에서든 웹사이트의 페이지를 요청할 때 해당 기기에서 해당 페이지를 올바르게 표시할 수 있습니다. HTTP 외에도 DNS, FTP 등과 같은 다른 응용 계층 프로토콜이 많이 있으며 오늘날 우리의 주인공인 MQTT 프로토콜이 그중 하나입니다.
IoT가 MQTT를 선호하는 이유
기존 애플리케이션에 사용할 수 있는 모든 훌륭한 애플리케이션 계층 프로토콜을 통해 MQTT가 IoT 공간에서 빛나는 이유는 무엇입니까? MQTT 프로토콜의 선택은 근거가 없습니다. MQTT는 IoT 개발자를 위한 올바른 균형을 유지하기 위해 노력하는 가볍고 유연한 네트워킹 프로토콜입니다.
이 경량 프로토콜은 엄격하게 제한된 장치 하드웨어와 높은 대기 시간/대역폭이 제한된 네트워크에서 구현될 수 있습니다.
유연성을 통해 IoT 장치 및 서비스에 대한 다양한 애플리케이션 시나리오를 지원할 수 있습니다.
대부분의 개발자는 이미 HTTP 웹 서비스에 익숙합니다. 그렇다면 IoT 장치를 웹 서비스에 연결하는 것은 어떨까요? 장치는 HTTP 요청 형식으로 데이터를 보내고 HTTP 응답 형식으로 시스템으로부터 업데이트를 받을 수 있습니다. 이 요청 및 응답 모델에는 몇 가지 심각한 제한 사항이 있습니다.
HTTP는 동기화 프로토콜입니다. 클라이언트는 서버가 응답할 때까지 기다려야 합니다. 웹 브라우저에는 이러한 요구 사항이 있지만 확장성이 희생됩니다. IoT 공간에서는 신뢰성이 낮거나 대기 시간이 긴 다수의 장치와 네트워크로 인해 동기식 통신이 문제가 됩니다. 비동기 메시징 프로토콜은 IoT 애플리케이션에 더 적합합니다. 센서는 판독값을 전송하고 네트워크가 이를 대상 장치 및 서비스에 전달할 최적의 경로와 시간을 결정하도록 합니다.
HTTP는 단방향입니다. 클라이언트가 연결을 시작해야 합니다. IoT 애플리케이션에서 장치나 센서는 일반적으로 클라이언트입니다. 즉, 네트워크에서 명령을 수동적으로 수신할 수 없습니다.
HTTP는 일{0}}대-프로토콜입니다. 클라이언트가 요청하고 서버가 응답합니다. 네트워크의 모든 장치에 메시지를 전달하는 것은 어려울 뿐만 아니라 비용도 많이 듭니다. 이는 IoT 애플리케이션의 일반적인 사용 사례입니다.
HTTP는 헤더와 규칙이 많은 헤비급 프로토콜입니다. 제한된 네트워크에는 적합하지 않습니다.
이러한 이유로 대부분의 고성능 확장형 시스템은 내부 데이터 교환을 위해 웹 서비스 대신 비동기식 메시지 버스를 사용합니다.
구독/게시 모델
흥미롭게도 이 MQTT 프로토콜 서버는 효율적인 서비스를 추구하므로 실제로 웹 서버보다 훨씬 단순한 디자인입니다. MQTT가 주로 메시지를 보내고 받는 메커니즘은 당사의 공개 웹사이트와 독자인 귀하 간의 관계와 다소 유사합니다.
현실 세계에서 나와 당신은 통합 서버에 연결된 MQTT 장치를 가지고 있고, 당신은 우리의 공개 번호에 대한 관심이나 어떤 종류의 애정으로 우리를 구독하고, 매일 내가 푸시 문자를 보낼 때 당신은 내가 푸시한 메시지를 휴대폰에 나타나게 될 것입니다. 이 과정에서 당신은 '구독'이라는 방식으로 내 정보를 얻습니다. 그리고 모든 사람이 내 기사를 볼 수 있고, 나에게 메시지를 자유롭게 남길 수 있습니다. 이러한 행동은 모든 사람의 "게시" 행동이며, 저는 항상 모든 사람의 메시지를 보려고 푸시를 유지합니다. 이것은 일종의 "구독" 행동입니다. 이 프로세스에서 모든 외부 정보는 우리와 관련이 없으며 단순히 정보 흐름과 양방향으로 통신합니다. MQTT의 메시징 메커니즘도 Publish - Subscribe 모델을 기반으로 합니다. MQTT 메시지 전달 메커니즘도 "게시" - "구독" 모델을 기반으로 합니다.
MQTT 관련 단계는 다음과 같습니다.
1단계:첫 번째를 사용하여 MQTT 서버를 얻은 다음 새 MQTT 통신 제품을 만듭니다.
2단계:그런 다음 이 서버에 연결하려면 서버에 연결하기 위한 두 가지 중요한 매개 변수는 호스트 번호(도메인 이름 또는 IP 주소)와 포트 번호입니다.
3단계:타사{0}}클라우드 서버 플랫폼을 사용하는 경우 Device Cloud의 백엔드에서 찾을 수 있는 제품 ID와 인증 정보를 사용하여 이 기기에 로그인해야 할 수도 있습니다.
이 세 단계를 완료하면 해당 주제를 구독하거나 메시지를 게시할 수 있습니다.
China Mobile 장치 클라우드 개방형 액세스 플랫폼을 "창녀로 삼는" 방법을 보여주는 문서를 작성하겠습니다.
이 세 단계는 애플리케이션 소프트웨어 개발과 마이크로컨트롤러 개발 모두에 적용됩니다. 마이크로 컨트롤러 개발에서 AT 명령과 외부 WIFI 모듈 통신을 사용하는 경우 일반 모듈에 AT + MQTT 명령이 제공될 수 있으며 이는 마이크로 컨트롤러에 대한 부담을 크게 줄이는 가장 좋은 방법입니다. 또는 TCP/IP 전송 계층 데이터에 직접 액세스한 다음 MQTT를 구문 분석할 수 있습니다. 이를 위해서는 사용자가 MQTT 프로토콜에 대한 깊은 이해가 있어야 자신의 Json 데이터도 구문 분석할 수 있습니다. 따라서 일반적으로 임베디드 기기를 수행할 때 MQTT 프로토콜과 함께 미리 만들어진 모듈을 직접 사용하는 것이{3}}권장되며, AT 명령을 직접 구문 분석하는 것이 더 편리합니다.
사례 연구:
조명을 원격으로 제어하고 현재 실내 온도를 가져옵니다.
이 경우는 실제로 MQTT의 가장 간단한 애플리케이션 중 하나입니다. 우선, 방에 내장된 제어 보드는 주로 WIFI를 통해 서버에 연결되어 전등 스위치를 제어하고 온도도 수집할 수 있습니다. 멀리 있는 최종 장치는 휴대폰이다.
통신이 계속 작동하려면 먼저 동일한 MQTT 서버에 연결되어야 합니다.
기기 측의 온도 정보는 기기에서 수집되므로 수집된 데이터를 "Temperature" 주제에 게시해야 하고, 휴대폰은 온도 정보를 가져오므로 "Temperature" 주제를 구독해야 합니다. 장치가 온도 정보를 "온도 주제"로 전송하면 해당 주제가 휴대폰으로 수신됩니다.
기기 측의 조명 제어는 기기에 의해 실행되므로 "전등 스위치" 주제를 구독해야 하고, 휴대폰은 전등 스위치를 제어하므로 이 "전등 스위치" 주제에 제어 정보를 게시해야 합니다. 휴대폰이 "light on" 주제에 light on 메시지를 보내면 터미널이 해당 주제를 수신한 다음 light on 명령이 실행됩니다.