기존 HTTP 프로토콜과 비교하여 MQTT의 장점은 무엇입니까?

HTTP는 가장 널리 사용되고 널리 사용되는 프로토콜입니다. 그러나 MQTT는 지난 몇 년 동안 빠르게 입지를 다졌습니다. IoT 개발을 논의할 때 개발자는 이 둘 중 하나를 선택해야 합니다.

MQTT는 데이터에 초점을 맞추고 HTTP는 문서에 초점을 맞춥니다. HTTP는 클라이언트-서버 컴퓨팅을 위한 요청-응답 프로토콜로, 모바일 장치에 항상 최적화되어 있지는 않습니다. 이러한 측면에서 MQTT의 주요 장점은 경량(MQTT는 바이트 배열 형식으로 데이터를 전송함)과 게시/구독 모델입니다. 이는 MQTT를 리소스가 제한된 장치에 매우 적합하게 만들고 배터리 절약에 도움이 됩니다. 또한 게시/구독 모델을 통해 클라이언트가 서로 독립적일 수 있으므로 전체 시스템의 안정성이 향상됩니다. 클라이언트 장애가 발생하더라도 전체 시스템은 계속해서 정상적으로 작동한다.

MQTT에는 다음과 같은 많은 장점이 있다.

1. 낮은 프로토콜 오버헤드인 MQTT는 메시지당 헤더가 2바이트만큼 짧을 수 있다는 점에서 독특합니다. MQ와 HTTP 모두 메시지당 오버헤드가 훨씬 높습니다. HTTP를 사용하면 각각의 새 요청 메시지에 대해 HTTP 연결을 다시 설정하면 상당한 오버헤드가 발생합니다. MQ 및 MQTT에서 사용되는 영구 연결은 이러한 오버헤드를 크게 줄여줍니다.

2. 불안정한 네트워크에 대한 내성, MQTT 및 MQ는 연결 끊김과 같은 오류로부터 복구할 수 있으며 추가 코드 요구 사항이 없습니다. 그러나 HTTP는 이를 기본적으로 수행할 수 없으므로 클라이언트가 인코딩을 다시 시도해야 하므로 멱등성 문제가 추가될 수 있습니다.

3. 낮은 전력 소비, MQTT는 낮은 전력 소비를 위해 특별히 설계되었습니다. HTTP는 이를 고려하지 않아 전력 소모가 증가합니다.

4. 수백만 개의 연결을 가진 클라이언트가 HTTP 스택에서 수백만 개의 동시 연결을 유지하려면 지원을 제공하기 위해 많은 작업이 필요합니다. 이러한 지원이 가능하지만 대부분의 상용 제품은 이 정도 크기의 지속적인 연결을 처리하도록 최적화되어 있습니다. IBM은 MQTT를 통해 동시에 연결된 최대 1백만 개의 장치를 처리하도록 테스트된 단일 랙 마운트 서버인 IBM MessageSight를 제공합니다. 반면에 MQTT는 많은 수의 동시 클라이언트를 위해 설계되지 않았습니다.

5. 푸시 알림은 적시에 고객에게 알림을 전달할 수 있어야 합니다. 이를 위해서는 일종의 주기적인 폴링이나 푸시가 사용되어야 합니다. 푸시는 배터리, 시스템 로드 및 대역폭 측면에서 최고의 솔루션입니다.

우리 회사는 제3자의 중개 없이 민감한 정보를 전송해야 할 수도 있습니다. 이로 인해 기본 전송 메커니즘인 OS별 솔루션(예: Apple iOS, Google Play 알림)의 가치가 감소합니다.

HTTP는 지속적인 HTTP 요청을 사용하여 푸시를 수행하는 COMET라는 한 가지 방법만 허용합니다. 이 접근 방식은 클라이언트와 서버 관점 모두에서 비용이 많이 듭니다. MQ와 MQTT 모두 푸시를 기본 기능으로 지원합니다.

6. 클라이언트 플랫폼의 차이점, HTTP 및 MQTT 클라이언트 모두 다수의 플랫폼에서 구현되었습니다. MQTT의 단순성은 매우 적은 노력으로 추가 클라이언트에서 MQTT를 구현하는 데 도움이 됩니다.

7. 방화벽 내결함성, 일부 회사 방화벽은 정의된 일부 포트에 대한 아웃바운드 연결을 제한합니다. 이러한 포트는 일반적으로 HTTP(포트 80), HTTPS(포트 443) 등으로 제한됩니다. HTTP는 분명히 이러한 상황에서 작동할 수 있습니다. MQTT는 HTTP 업그레이드 요청으로 나타나는 WebSockets 연결로 래핑될 수 있으므로 이러한 경우 작업이 가능합니다. MQTT는 이 패턴을 허용하지 않습니다.

HTTP에 비해 MQTT 프로토콜은 높은 전송 속도를 보장합니다. 서비스 품질에는 세 가지 수준이 있습니다.

A. 최대 1회: 배송을 확인하세요.

B. 최소 한 번: 이메일이 한 번 이상 전송되는지 확인하세요. 메시지는 두 번 이상 전송될 수도 있습니다.

C. 한 번만: 각 메시지가 상대방에게 한 번만 수신되도록 합니다.

실제로 MQTT가 널리 사용됩니다. Facebook, BP, alibaba, Baidu 등 거의 모든 대규모 하드웨어 및 인터넷 회사에서 MQTT를 찾을 수 있습니다.

MQTT 자체의 다양한 기술적 이점으로 인해 점점 더 많은 회사가 MQTT를 선택하는 경향이 있습니다. MQTT는 IoT 제품 통신을 위한 표준 프로토콜입니다. 따라서 엔지니어들은 MQTT 프로토콜이 대규모로 상용화되려면 개선이 필요한 몇 가지 기능을 가지고 있다는 사실을 점차 발견해 왔습니다. 예:

1. 완전한 SDK는 없으며 다양한 이기종 터미널이 MQTT 서버와 통신하려면 해당 소프트웨어 SDK 패키지가 필요합니다. 예를 들어 MCU, Linux, Android, IOS, WEB 등을 상호 연결하려면 서로 다른 SDK 패키지가 필요합니다.

2. 파일 및 AV는 지원되지 않습니다. 일부 응용 시나리오에서는 전송되는 정보가 파일 및 AV를 통해 통신해야 하는 오디오 신호 및 비디오 신호와 같은 명령으로 제한되지 않을 수 있습니다.

3. 타사 HTTP와의 통합을 지원하지 않습니다. 그럼에도 불구하고MQTT 프로토콜은 일반 HTTP 프로토콜보다 우수하며 기존 HTTP 프로토콜을 기반으로 하는 WEB 서버는 여전히 주류 시장을 점유하고 있으므로 이러한 서버는 업그레이드를 줄이기 위해 MQTT 프로토콜과의 상호 연결을 실현해야 합니다. 비용도 중요합니다.
< br/>4. 로드 밸런싱을 지원하지 않습니다. 높은 동시성 및 악의적인 공격을 방지하기 위해서는 로드밸런싱 서버도 필수입니다.

5. 사용자 관리 인터페이스를 지원하지 않습니다. 특히, 인더스트리 4.0, 빅데이터 시대의 필수 요구사항인 디바이스 동작 데이터를 사용자가 분석하는 것이 중요하다.

6. 오프라인 메시지를 지원하지 않으며, 기기가 오프라인 상태가 되면 MQTT 서버가 기기의 제어 정보를 잃어버리는 문제를 보완한다.

7. 지점 간 통신은 지원되지 않으며 표준 MQTT 프로토콜이 채택됩니다. 이론상으로는 상호 가입을 통해 Point-to-Point 통신을 구현할 수 있지만, 로직이 상대적으로 복잡하고, 기기의 보안에 대한 우려도 있습니다. 기기 B와 기기 C가 동일한 주제에 관한 경우 기기 A는 메시지를 보낸 사람이 기기 B인지 기기 C인지 알 수 없으며, 기기 D가 메시지를 도청할 수도 있습니다.

8. 그룹 커뮤니케이션 및 그룹 관리를 지원하지 않으며, 그룹 구성원 관리를 실현하며, 그룹 구성원은 서로 소통할 수 있습니다. 하나의 장치를 여러 사람이 제어하거나, 한 사람이 여러 장치를 제어하는 경우 특히 유용합니다.