IoT, 포그, 클라우드: 기술에 대해 이야기해볼까요?

소프트웨어와 하드웨어 분야의 기술 발전, 새로운 통신 프로토콜의 등장으로 사물인터넷(IoT)이 확산되고 있습니다. 기기의 수는 날이 갈수록 늘어나고 있으며, 이로 인해 엄청난 양의 데이터가 생성되고 있습니다. 따라서 이러한 데이터를 처리, 저장, 전송할 수 있는 편리한 시스템 아키텍처가 필요합니다.

이제 이러한 목적으로 클라우드 서비스가 사용됩니다. 그러나 점점 인기를 얻고 있는 포그 컴퓨팅 패러다임(Fog)은 IoT 인프라를 확장하고 최적화하여 클라우드 솔루션을 보완할 수 있습니다.

클라우드는 대부분의 IoT 요청을 처리할 수 있습니다. 예를 들어, 서비스 모니터링, 장치에서 생성된 모든 양의 데이터에 대한 빠른 처리 및 시각화를 제공합니다. 포그 컴퓨팅은 실시간 문제를 해결할 때 더 효과적입니다. 요청에 대한 빠른 응답을 제공하고 데이터 처리 시 지연 시간을 최소화합니다. 즉, Fog는 "클라우드"를 보완하고 그 기능을 확장합니다.

그러나 주요 질문은 다릅니다. 이 모든 것이 IoT의 맥락에서 어떻게 상호 작용해야 할까요? 결합된 IoT-Fog-Cloud 시스템에서 작업할 때 가장 효과적인 통신 프로토콜은 무엇입니까?

HTTP의 명백한 지배력에도 불구하고 IoT, Fog 및 클라우드 시스템에 사용되는 다른 솔루션도 많이 있습니다. IoT는 다양한 장치 센서의 기능과 보안, 호환성 및 기타 사용자 요구 사항을 결합해야 하기 때문입니다.

그러나 참조 아키텍처와 통신 표준에 대한 단일 아이디어는 없습니다. 따라서 특정 IoT 작업을 위해 새로운 프로토콜을 생성하거나 기존 프로토콜을 수정하는 것은 IT 커뮤니티가 직면한 가장 중요한 작업 중 하나입니다.

현재 사용 중인 프로토콜은 무엇이며 어떤 프로토콜을 제공할 수 있나요? 그것을 알아 봅시다. 하지만 먼저 구름과 안개, 사물인터넷이 상호작용하는 생태계의 원리에 대해 논의해 보겠습니다.

IoT F2C(Fog-to-Cloud) 아키텍처

IoT, 클라우드 및 포그의 스마트하고 조율된 관리와 관련된 장점과 이점을 탐색하는 데 얼마나 많은 노력이 들어가는지 눈치채셨을 것입니다. 그렇지 않다면 다음과 같은 세 가지 표준화 계획이 있습니다. 오픈포그 컨소시엄, 엣지 컴퓨팅 컨소시엄 и mF2C H2020 EU 프로젝트.

이전에는 클라우드와 최종 장치라는 두 가지 수준만 고려했다면 제안된 아키텍처는 새로운 수준인 포그 컴퓨팅을 도입합니다. 이 경우 포그 수준은 리소스의 세부 사항이나 이러한 하위 수준의 다양한 장치 사용을 결정하는 정책 집합에 따라 여러 하위 수준으로 나눌 수 있습니다.

이 추상화는 어떤 모습일까요? 다음은 일반적인 IoT-Fog-Cloud 생태계입니다. IoT 장치는 짧은 대기 시간이 필요한 문제를 해결하기 위해 더 빠른 서버와 컴퓨팅 장치로 데이터를 보냅니다. 동일한 시스템에서 클라우드는 대량의 컴퓨팅 리소스나 데이터 저장 공간이 필요한 문제를 해결하는 역할을 담당합니다.

스마트폰, 스마트 시계 및 기타 장치도 IoT의 일부가 될 수 있습니다. 그러나 이러한 장치는 일반적으로 대규모 개발자의 독점 통신 프로토콜을 사용합니다. 생성된 IoT 데이터는 REST HTTP 프로토콜을 통해 포그 레이어로 전송되며, 이는 RESTful 서비스 생성 시 유연성과 상호 운용성을 제공합니다. 이는 로컬 컴퓨터, 서버 또는 서버 클러스터에서 실행되는 기존 컴퓨팅 인프라와의 역호환성을 보장해야 한다는 점에서 중요합니다. "포그 노드"라고 불리는 로컬 리소스는 수신된 데이터를 필터링하고 로컬로 처리하거나 추가 계산을 위해 클라우드로 보냅니다.

클라우드는 다양한 통신 프로토콜을 지원하며 가장 일반적인 것은 AMQP 및 REST HTTP입니다. HTTP는 잘 알려져 있고 인터넷에 맞춰져 있기 때문에 "IoT 및 포그와 함께 작동하는 데 HTTP를 사용해야 하지 않을까?"라는 질문이 생길 수 있습니다. 그러나 이 프로토콜에는 성능 문제가 있습니다. 이에 대해서는 나중에 자세히 설명합니다.

일반적으로 필요한 시스템에 적합한 통신 프로토콜에는 두 가지 모델이 있습니다. 요청-응답과 게시-구독이 그것이다. 첫 번째 모델은 특히 서버-클라이언트 아키텍처에서 더 널리 알려져 있습니다. 클라이언트는 서버에 정보를 요청하고, 서버는 요청을 받아 처리한 후 응답 메시지를 반환합니다. REST HTTP 및 CoAP 프로토콜은 이 모델에서 작동합니다.

두 번째 모델은 데이터를 생성하는 소스와 이 데이터의 수신자 사이에 비동기식, 분산형, 느슨한 결합을 제공해야 할 필요성에서 탄생했습니다.

이 모델은 게시자(데이터 원본), 브로커(디스패처) 및 구독자(수신자)의 세 참가자를 가정합니다. 여기서, 가입자 역할을 하는 클라이언트는 서버에 정보를 요청할 필요가 없습니다. 요청을 보내는 대신 브로커를 통해 시스템의 특정 이벤트를 구독합니다. 브로커는 들어오는 모든 메시지를 필터링하고 게시자와 구독자 간에 메시지를 라우팅하는 일을 담당합니다. 그리고 게시자는 특정 주제와 관련하여 이벤트가 발생하면 이를 브로커에 게시하고, 브로커는 요청한 주제에 대한 데이터를 구독자에게 보냅니다.

기본적으로 이 아키텍처는 이벤트 기반입니다. 그리고 이 상호 작용 모델은 확장성을 제공하고 서로 다른 장치 간의 상호 연결을 단순화하고 동적 다대다 통신 및 비동기 통신을 지원하는 기능으로 인해 IoT, 클라우드, 포그의 애플리케이션에 흥미롭습니다. 게시-구독 모델을 사용하는 가장 잘 알려진 표준화된 메시징 프로토콜로는 MQTT, AMQP 및 DDS가 있습니다.

게시-구독 모델에는 분명히 다음과 같은 많은 장점이 있습니다.

• 게시자와 구독자는 서로의 존재에 대해 알 필요가 없습니다.
• 한 명의 구독자는 다양한 발행물로부터 정보를 받을 수 있으며, 한 명의 게시자는 여러 다른 구독자에게 데이터를 보낼 수 있습니다(다대다 원칙).
• 게시자와 구독자가 통신하기 위해 동시에 활성화될 필요는 없습니다. 브로커(대기열 시스템으로 작동)가 현재 네트워크에 연결되어 있지 않은 클라이언트에 대한 메시지를 저장할 수 있기 때문입니다.

그러나 요청-응답 모델에도 장점이 있습니다. 여러 클라이언트 요청을 처리하는 서버 측의 능력이 문제가 되지 않는 경우 입증되고 안정적인 솔루션을 사용하는 것이 합리적입니다.

두 모델을 모두 지원하는 프로토콜도 있습니다. 예를 들어 "서버 푸시" 옵션을 지원하는 XMPP 및 HTTP 2.0이 있습니다. IETF도 CoAP를 발표했습니다. 메시징 문제를 해결하기 위해 WebSockets 프로토콜이나 QUIC(Quick UDP Internet Connections)를 통한 HTTP 프로토콜 사용과 같은 몇 가지 다른 솔루션이 만들어졌습니다.

WebSocket의 경우 서버에서 웹 클라이언트로 실시간으로 데이터를 전송하고 동시 양방향 통신으로 지속적인 연결을 제공하는 데 사용되지만 컴퓨팅 리소스가 제한된 장치에는 적합하지 않습니다. 새로운 전송 프로토콜이 많은 새로운 기회를 제공하기 때문에 QUIC도 주목할 가치가 있습니다. 그러나 QUIC은 아직 표준화되지 않았기 때문에 가능한 적용과 IoT 솔루션에 대한 영향을 예측하는 것은 시기상조입니다. 따라서 우리는 미래를 염두에 두고 WebSocket과 QUIC를 염두에 두고 있지만 지금은 더 자세히 연구하지는 않을 것입니다.

세상에서 가장 귀여운 사람은 누구입니까? 프로토콜 비교

이제 프로토콜의 강점과 약점에 대해 이야기해 보겠습니다. 앞을 내다보면 뚜렷한 리더가 없다는 점을 즉각 유보하자. 각 프로토콜에는 몇 가지 장점/단점이 있습니다.

R'ремя откликР°

특히 사물 인터넷과 관련된 통신 프로토콜의 가장 중요한 특성 중 하나는 응답 시간입니다. 그러나 기존 프로토콜 중에는 다양한 조건에서 작업할 때 최소 지연 시간 수준을 보여주는 확실한 승자가 없습니다. 그러나 프로토콜 기능에 대한 수많은 연구와 비교가 있습니다.

예를 들어, 연구 결과 IoT 작업 시 HTTP와 MQTT의 효율성을 비교한 결과 MQTT 요청에 대한 응답 시간이 HTTP보다 짧은 것으로 나타났습니다. 그리고 언제 공부하는 MQTT와 CoAP의 왕복 시간(RTT)은 CoAP의 평균 RTT가 MQTT보다 20% 적은 것으로 나타났습니다.

다른 실험 MQTT 및 CoAP 프로토콜에 대한 RTT를 사용한 작업은 로컬 네트워크와 IoT 네트워크의 두 가지 시나리오에서 수행되었습니다. IoT 네트워크의 평균 RTT는 2~3배 더 높은 것으로 나타났습니다. QoS0을 적용한 MQTT는 CoAP에 비해 낮은 결과를 보였으며, QoS1을 적용한 MQTT는 애플리케이션 및 전송 계층의 ACK로 인해 더 높은 RTT를 나타냈습니다. 다양한 QoS 수준의 경우 혼잡이 없는 네트워크 대기 시간은 MQTT의 경우 밀리초, CoAP의 경우 수백 마이크로초였습니다. 그러나 신뢰성이 낮은 네트워크에서 작업할 때 TCP 위에서 실행되는 MQTT는 완전히 다른 결과를 표시한다는 점을 기억할 가치가 있습니다.

비교 페이로드를 늘려 AMQP 및 MQTT 프로토콜에 대한 응답 시간을 보면 로드가 적을 때 대기 시간 수준이 거의 동일한 것으로 나타났습니다. 그러나 대량의 데이터를 전송할 때 MQTT는 더 짧은 응답 시간을 보여줍니다. 하나 더 연구하다 CoAP는 가스 센서, 기상 센서, 위치 센서(GPS) 및 모바일 네트워크 인터페이스(GPRS)가 장착된 차량 위에 장치를 배포하는 기계 간 통신 시나리오에서 HTTP와 비교되었습니다. 모바일 네트워크를 통해 CoAP 메시지를 전송하는 데 필요한 시간은 HTTP 메시지를 사용하는 데 필요한 시간보다 거의 XNUMX배 짧았습니다.

두 개가 아닌 세 가지 프로토콜을 비교하는 연구가 수행되었습니다. 예를 들어, 비교 네트워크 에뮬레이터를 사용하는 의료 애플리케이션 시나리오에서 IoT 프로토콜 MQTT, DDS 및 CoAP의 성능. DDS는 다양한 열악한 네트워크 조건에서 테스트된 원격 측정 대기 시간 측면에서 MQTT보다 성능이 뛰어났습니다. UDP 기반 CoAP는 빠른 응답 시간이 필요한 애플리케이션에는 잘 작동했지만 UDP 기반이기 때문에 예측할 수 없는 상당한 패킷 손실이 있었습니다.

처리량

비교 대역폭 효율성 측면에서 MQTT와 CoAP는 메시지 당 전송되는 총 데이터 양으로 계산되었습니다. CoAP는 작은 메시지를 전송할 때 MQTT보다 낮은 처리량을 보여주었습니다. 그러나 전송된 총 바이트 수에 대한 유용한 정보 바이트 수의 비율 측면에서 프로토콜의 효율성을 비교할 때 CoAP가 더 효과적인 것으로 나타났습니다.

에 분석 MQTT, DDS(전송 프로토콜로 TCP 사용) 및 CoAP 대역폭을 사용하면 CoAP는 일반적으로 MQTT 및 DDS와 달리 네트워크 패킷 손실이 증가하거나 네트워크 대기 시간이 증가하더라도 대역폭 소비가 증가하지 않고 비교적 낮은 대역폭 소비를 나타내는 것으로 나타났습니다. 언급된 시나리오에서 대역폭 활용도가 증가합니다. 또 다른 시나리오에는 IoT 환경에서 일반적으로 발생하는 데이터를 동시에 전송하는 많은 수의 장치가 포함되었습니다. 그 결과, 활용도를 높이려면 CoAP를 사용하는 것이 더 나은 것으로 나타났습니다.

부하가 적은 경우 CoAP가 가장 적은 대역폭을 사용했고 MQTT와 REST HTTP가 그 뒤를 이었습니다. 그러나 페이로드 크기가 증가하면 REST HTTP가 가장 좋은 결과를 얻었습니다.

소비 전력

에너지 소비 문제는 항상 매우 중요하며, 특히 IoT 시스템에서는 더욱 그렇습니다. 만약에 비교 MQTT와 HTTP는 전력을 소비하지만 HTTP는 훨씬 더 많은 전력을 소비합니다. 그리고 CoAP는 그 이상입니다. 효율적인 에너지 MQTT와 비교하여 전력 관리가 가능합니다. 그러나 간단한 시나리오에서는 특히 전력 제한이 없는 경우 MQTT가 사물 인터넷 네트워크에서 정보를 교환하는 데 더 적합합니다.

다른 모바일 또는 불안정한 무선 네트워크 테스트베드에서 AMQP와 MQTT의 기능을 비교한 실험에서는 AMQP가 더 많은 보안 기능을 제공하는 반면 MQTT는 에너지 효율성이 더 높은 것으로 나타났습니다.

Безопасность

보안은 사물 인터넷과 포그/클라우드 컴퓨팅 주제를 연구할 때 제기되는 또 다른 중요한 문제입니다. 보안 메커니즘은 일반적으로 HTTP, MQTT, AMQP 및 XMPP의 TLS 또는 CoAP의 DTLS를 기반으로 하며 두 DDS 변형을 모두 지원합니다.

TLS와 DTLS는 지원되는 암호화 제품군과 키를 교환하기 위해 클라이언트와 서버 측 간의 통신을 설정하는 프로세스로 시작됩니다. 양 당사자는 보안 채널에서 추가 통신이 이루어지도록 세트를 협상합니다. 둘 사이의 차이점은 UDP 기반 DTLS가 신뢰할 수 없는 연결을 통해 작동할 수 있도록 하는 작은 수정에 있습니다.

에 테스트 공격 TLS와 DTLS의 여러 가지 구현에서는 TLS가 더 나은 성능을 발휘하는 것으로 나타났습니다. DTLS에 대한 공격은 오류 허용성으로 인해 더 성공적이었습니다.

그러나 이러한 프로토콜의 가장 큰 문제는 원래 IoT용으로 설계되지 않았으며 포그나 클라우드에서 작동하도록 의도되지 않았다는 것입니다. 핸드셰이킹을 통해 각 연결 설정에 추가 트래픽을 추가하므로 컴퓨팅 리소스가 소모됩니다. 평균적으로 보안 계층이 없는 통신에 비해 오버헤드가 TLS의 경우 6,5%, DTLS의 경우 11% 증가합니다. 일반적으로 다음 위치에 있는 리소스가 풍부한 환경에서 흐림 레벨에서는 문제가 되지 않으나, IoT와 포그 레벨의 연결에서는 이것이 중요한 한계가 됩니다.

무엇을 선택할까요? 명확한 대답은 없습니다. MQTT와 HTTP는 다른 프로토콜에 비해 상대적으로 더 성숙하고 안정적인 IoT 솔루션으로 간주되기 때문에 가장 유망한 프로토콜인 것 같습니다.

통합 통신 프로토콜 기반 솔루션

단일 프로토콜 솔루션을 실행하는 데는 많은 단점이 있습니다. 예를 들어, 제한된 환경에 적합한 프로토콜은 엄격한 보안 요구 사항이 있는 도메인에서는 작동하지 않을 수 있습니다. 이를 염두에 두고 MQTT 및 REST HTTP를 제외하고 IoT의 Fog-to-Cloud 생태계에서 가능한 거의 모든 단일 프로토콜 솔루션을 폐기해야 합니다.

단일 프로토콜 솔루션으로서의 REST HTTP

IoT-to-Fog 공간에서 REST HTTP 요청 및 응답이 상호 작용하는 방법에 대한 좋은 예가 있습니다. 스마트팜. 동물에는 웨어러블 센서(IoT 클라이언트, C)가 장착되어 있으며 스마트 농업 시스템(Fog 서버, S)에 의해 클라우드 컴퓨팅을 통해 제어됩니다.

POST 메서드의 헤더는 수정할 리소스(/farm/animals)와 HTTP 버전 및 콘텐츠 유형을 지정합니다. 이 경우 시스템이 관리할 동물 농장(Dulcinea/cow)을 나타내는 JSON 개체입니다. . 서버의 응답은 HTTPS 상태 코드 201(리소스 생성됨)을 전송하여 요청이 성공했음을 나타냅니다. GET 메서드는 서버에서 해당 ID를 가진 동물의 JSON 표현을 반환하는 URI(예: /farm/animals/1)에 요청된 리소스만 지정해야 합니다.

PUT 메소드는 특정 리소스 레코드를 업데이트해야 할 때 사용됩니다. 이 경우 리소스는 변경될 매개변수에 대한 URI와 현재 값(예: 소가 현재 걷고 있음을 나타냄, /farm/animals/1? state=walking)을 지정합니다. 마지막으로 DELETE 메소드는 GET 메소드와 동일하게 사용되지만 단순히 연산의 결과로 리소스를 삭제한다.

단일 프로토콜 솔루션으로서의 MQTT

동일한 스마트 팜을 사용하지만 REST HTTP 대신 MQTT 프로토콜을 사용합니다. Mosquitto 라이브러리가 설치된 로컬 서버는 브로커 역할을 합니다. 이 예에서는 간단한 컴퓨터(팜 서버라고 함) Raspberry Pi가 MQTT 클라이언트 역할을 하며 Mosquitto 브로커와 완벽하게 호환되는 Paho MQTT 라이브러리 설치를 통해 구현됩니다.

이 클라이언트는 감지 및 컴퓨팅 기능을 갖춘 장치를 나타내는 IoT 추상화 계층에 해당합니다. 반면 중재자는 더 높은 수준의 추상화에 해당하며 더 큰 처리 및 저장 용량을 특징으로 하는 포그 컴퓨팅 노드를 나타냅니다.

제안된 스마트 팜 시나리오에서 Raspberry Pi는 가속도계, GPS 및 온도 센서에 연결하고 이러한 센서의 데이터를 포그 노드에 게시합니다. 아시다시피 MQTT는 주제를 계층 구조로 처리합니다. 단일 MQTT 게시자는 특정 주제 집합에 메시지를 게시할 수 있습니다. 우리의 경우에는 세 가지가 있습니다. 동물우리의 온도를 측정하는 센서의 경우 클라이언트가 테마(동물농장/우리/온도)를 선택합니다. 가속도계를 통해 GPS 위치와 동물 움직임을 측정하는 센서의 경우 클라이언트는 (동물농장/동물/GPS) 및 (동물농장/동물/움직임)에 대한 업데이트를 게시합니다.

이 정보는 나중에 관심 있는 다른 가입자가 나타날 경우를 대비하여 로컬 데이터베이스에 임시로 저장할 수 있는 브로커에게 전달됩니다.

안개 속에서 MQTT 브로커 역할을 하고 MQTT 클라이언트 역할을 하는 Raspberry Pi가 센서 데이터를 보내는 로컬 서버 외에도 클라우드 수준에는 또 다른 MQTT 브로커가 있을 수 있습니다. 이 경우, 로컬 브로커로 전송된 정보는 로컬 데이터베이스에 임시 저장되거나 클라우드로 전송될 수 있다. 이 상황에서 포그 MQTT 브로커는 모든 데이터를 클라우드 MQTT 브로커와 연결하는 데 사용됩니다. 이 아키텍처를 사용하면 모바일 애플리케이션 사용자가 두 브로커에 모두 가입할 수 있습니다.

브로커 중 하나(예: 클라우드)에 대한 연결이 실패하면 최종 사용자는 다른 브로커(포그)로부터 정보를 받게 됩니다. 이는 포그와 클라우드 컴퓨팅 시스템이 결합된 시스템의 특징입니다. 기본적으로 모바일 앱은 포그 MQTT 브로커에 먼저 연결하고, 실패할 경우 클라우드 MQTT 브로커에 연결하도록 구성할 수 있습니다. 이 솔루션은 IoT-F2C 시스템의 많은 솔루션 중 하나일 뿐입니다.

다중 프로토콜 솔루션

단일 프로토콜 솔루션은 구현이 더 쉽기 때문에 널리 사용됩니다. 그러나 IoT-F2C 시스템에서는 서로 다른 프로토콜을 결합하는 것이 합리적이라는 것은 분명합니다. 아이디어는 서로 다른 프로토콜이 서로 다른 수준에서 작동할 수 있다는 것입니다. 예를 들어 IoT, 포그, 클라우드 컴퓨팅 계층이라는 세 가지 추상화를 생각해 보세요. IoT 수준의 장치는 일반적으로 제한된 것으로 간주됩니다. 이 개요에서는 IoT 계층을 가장 제한적인 계층으로, 클라우드를 가장 덜 제한적인 계층으로, 포그 컴퓨팅을 "중간"으로 생각해 보겠습니다. IoT와 포그 추상화 사이에 현재 프로토콜 솔루션에는 MQTT, CoAP 및 XMPP가 포함되어 있는 것으로 나타났습니다. 반면, 포그와 클라우드 사이에서 AMQP는 REST HTTP와 함께 사용되는 주요 프로토콜 중 하나이며 유연성으로 인해 IoT와 포그 레이어 간에도 사용됩니다.

여기서 가장 큰 문제는 프로토콜의 상호 운용성과 한 프로토콜에서 다른 프로토콜로 메시지를 쉽게 전송할 수 있다는 것입니다. 이상적으로는 미래에는 클라우드 및 포그 리소스를 갖춘 사물 인터넷 시스템의 아키텍처가 사용되는 통신 프로토콜과 독립적이며 다양한 프로토콜 간의 우수한 상호 운용성을 보장할 것입니다.

현재는 그렇지 않기 때문에 큰 차이가 없는 프로토콜을 결합하는 것이 합리적입니다. 이를 위해 하나의 잠재적인 솔루션은 동일한 아키텍처 스타일을 따르는 두 가지 프로토콜인 REST HTTP와 CoAP의 조합을 기반으로 합니다. 제안된 또 다른 솔루션은 게시-구독 통신을 제공하는 두 가지 프로토콜인 MQTT와 AMQP의 조합을 기반으로 합니다. 유사한 개념(MQTT와 AMQP 모두 브로커를 사용하고 CoAP와 HTTP는 REST를 사용)을 사용하면 이러한 조합을 더 쉽게 구현할 수 있고 통합 노력이 덜 필요합니다.

그림 (a)는 두 가지 요청-응답 기반 모델인 HTTP와 CoAP와 IoT-F2C 솔루션에서의 가능한 배치를 보여줍니다. HTTP는 현대 네트워크에서 가장 잘 알려져 있고 채택된 프로토콜 중 하나이기 때문에 다른 메시징 프로토콜로 완전히 대체될 가능성은 거의 없습니다. 클라우드와 포그 사이에 있는 강력한 장치를 나타내는 노드 중에서 REST HTTP는 스마트 솔루션입니다.

반면, Fog와 IoT 계층 간에 통신하는 컴퓨팅 리소스가 제한된 장치의 경우 CoAP를 사용하는 것이 더 효율적입니다. CoAP의 가장 큰 장점 중 하나는 실제로 HTTP와의 호환성입니다. 두 프로토콜 모두 REST 원칙을 기반으로 하기 때문입니다.

그림 (b)는 동일한 시나리오에서 MQTT 및 AMQP를 포함한 두 가지 게시-구독 통신 모델을 보여줍니다. 이론적으로 두 프로토콜 모두 각 추상화 계층의 노드 간 통신에 사용될 수 있지만 해당 프로토콜의 위치는 성능에 따라 결정되어야 합니다. MQTT는 컴퓨팅 리소스가 제한된 장치를 위한 경량 프로토콜로 설계되었으므로 IoT-Fog 통신에 사용할 수 있습니다. AMQP는 포그와 클라우드 노드 사이에 이상적으로 배치되는 보다 강력한 장치에 더 적합합니다. MQTT 대신 XMPP 프로토콜은 경량으로 간주되므로 IoT에서 사용할 수 있습니다. 그러나 그러한 시나리오에서는 그렇게 널리 사용되지 않습니다.

조사 결과

논의된 프로토콜 중 하나가 컴퓨팅 리소스가 제한된 장치부터 클라우드 서버에 이르기까지 시스템의 모든 통신을 포괄하는 데 충분할 가능성은 거의 없습니다. 연구에 따르면 개발자가 가장 많이 사용하는 가장 유망한 옵션 두 가지는 MQTT와 RESTful HTTP입니다. 이 두 프로토콜은 가장 성숙하고 안정적일 뿐만 아니라 잘 문서화되고 성공적인 구현과 온라인 리소스를 많이 포함하고 있습니다.

MQTT는 안정성과 간단한 구성으로 인해 제한된 장치를 사용하여 IoT 수준에서 사용할 때 시간이 지남에 따라 탁월한 성능이 입증된 프로토콜입니다. 일부 포그 도메인 및 대부분의 클라우드 컴퓨팅과 같이 제한된 통신 및 배터리 소비가 문제가 되지 않는 시스템 부분에서는 RESTful HTTP가 쉬운 선택입니다. CoAP도 IoT 메시징 표준으로 빠르게 발전하고 있으며 가까운 시일 내에 MQTT 및 HTTP와 유사한 수준의 안정성과 성숙도에 도달할 가능성이 높기 때문에 고려해야 합니다. 그러나 표준은 현재 발전하고 있으며 이로 인해 단기적인 호환성 문제가 발생합니다.

블로그에서 무엇을 더 읽을 수 있습니까? 클라우드4Y

→ 컴퓨터가 당신을 맛있게 만들어 줄 거예요
→ AI는 아프리카의 동물 연구를 돕습니다.
→ 여름이 거의 끝났습니다. 유출된 데이터가 거의 남아 있지 않습니다.
→ 클라우드 백업을 저장하는 4가지 방법
→ 인구에 대한 정보가 포함된 통합 연방 정보 자원

우리의 구독 텔레그램-다음 기사를 놓치지 않도록 채널을 구독하세요! 우리는 일주일에 두 번 이상 사업에 대해서만 글을 씁니다.

출처 : habr.com