IoT 애플리케이션에 적합한 프로토콜 선택

Thing / Constrained Device가 일정한 간격으로 GPS 위치를 주어진 서버로 보내는 IoT 시나리오가 있습니다. 제한된 장치는 배터리로 작동하며 연결을 위해 GSM / SIM 쉴드를 사용하는 Arduino와 유사한 보드입니다. 이것이 우리의 디자인 목표입니다.

• 배터리 수명 최대화
• 데이터 전송 최소화

테스트 목적으로 HTTP를 사용하여 약 500 바이트의 메시지가 생성되었지만 이제는 데이터 전송에보다 적합한 프로토콜을 사용해야합니다. 데이터 전송의 일부 특성은 다음과 같습니다.

• 페이로드는 일반적으로 매우 작고 적은 50 바이트보다 (꽤 멀리 전형적인 MTU가에서, 즉 모든 것이 IP 패키지에 맞아야합니다)
• 데이터는 약 1 분에 한 번 전송 되어야합니다 . 약간의 차이는 중요하지 않습니다.
• 이다 일부 메시지를 잃게 OK
• 현재 장치는 서버 의 응답이 필요 하지 않습니다 (단, 향후 변경 될 수 있음). 서버가 장치와의 대화를 시작하지 않아도 됩니다.

지금까지 우리는 이러한 가능성을 생각했습니다.

• TCP를 통한 사용자 정의 프로토콜 . 이것은 메시지를 10 배 작게 만드는 HTTP 헤더를 제거합니다. 이것은 우리의 신뢰할 수 있고 보수적 인 접근 방식입니다.
• UDP를 통한 사용자 정의 프로토콜 . UDP는 헤더가 작고 안정성을위한 오버 헤드가 없으므로 매우 효율적일 것으로 예상됩니다. 언급했듯이, 여기에서 하나의 메시지를 잃어 버리거나 걱정할 필요는 없습니다 ... 그러나 우리가 알지 못하는 비 신뢰성에 다른 문제가있을 수 있습니다.
• MQTT (표준 over TCP) : TCP와 비교할 때 기존 오버 헤드가 거의 없기 때문에 옵션 일 수도 있지만 GSM / SIM 기술에 대한 경험이 많지 않으며 방법을 모릅니다. 지속적인 MQTT 연결은 이런 방식으로 작동하며 연결 ​​하트 비트 대역이 저주파 데이터 전송에 가치가 있는지 여부입니다.
• CoAP (UDP를 통한 표준) : 유망한 것으로 보입니다. 헤더에 대해 4 바이트의 오버 헤드 만 발생하고 UDP를 통해 작동합니다. 그러나 알려지지 않은 UDP 위험이 있습니다.

아무도 힌트를 줄 수 있습니까? 미리 감사드립니다.

TCP, UDP 및 MQTT에 대한 내 경험과 검토 할 추가 리소스에 대한 몇 가지 생각.

UDP를 사용하면 하나의 네트워크 노드, 클라이언트의 응용 프로그램에서 보낸 UDP 메시지 중 일부만 볼 수있는 자동 실패 문제가 발생했습니다. 네트워크 트래픽이 잘못 될 수있는 이유는 너무 많습니다. UDP의 문제점은 패킷 생산자와 패킷 소비자 사이의 네트워크 경로에있는 노드가 필요할 때마다 패킷을 거의 버릴 수 있다는 것입니다. Wikipedia 주제 패킷 손실을 참조하십시오 .

문제는 현재 네트워크 상황에 상관없이 손실률은 얼마입니까? 따라서 LAN 또는 하위 네트워크 내에서 통신하는 경우 손실률이 낮을 수 있습니다. WAN 또는 인터넷에서 손실률이 상당히 높을 수 있습니다. UDP 패킷은 여러 가지 이유로 버려지지만 라우팅되지만 네트워크 조건에 따라 홉 수가 감소합니다. 책임이없는 상태로 패킷을 큰 빈 공간으로 보내면 자동 실패 가능성이 있습니다.

귀하의 경우에는 시간 초과 후 재전송이있는 간단한 ack가 충분하지 않은 것처럼 들립니다.

유지 관리 된 TCP 연결을 통해 XML 메시지를 작성했으며 훌륭하게 작동했습니다. 처리 할 응용 프로그램 계층으로 버퍼에 각각 완전한 메시지를 전달하는 계층이있었습니다. XML을 사용하여 메시지 시작을위한 XML 시작 태그와 전체 메시지 수신시기를 알기위한 XML 끝 태그로 메시지를 패키지했습니다.

TCP에는 순차적 순서의 패킷, 반복 없음과 같은 몇 가지 기능이 있으며 연결된 전송 메커니즘은 다른 쪽 끝이 사라지는 지 알아내는 데 시간이 걸릴 수 있음을 의미합니다. 네트워크 상태로 인해 TCP 처리 속도가 느려질 수 있지만 연결 및 연결 해제로 인해 지연이 발생할 수 있지만 일반적인 조건에서는 부담이되지 않습니다.

MQTT는 네트워크 전송 계층 (일반적으로 TCP)에 의해 전송되는 프로토콜입니다. MQTT는 발행 / 구독 모델을 사용하므로 메시지 저장이 없습니다. 따라서 구독자가 당시에 연결되지 않았을 때 게시자가 메시지를 게시하면 연결될 때 메시지가 표시되지 않습니다. MQTT는 거의 실시간으로, 그것이 약어의 원격 측정 부분이 전부라고 생각합니다. 작은 메시지에 대해서는 MQTT를 좋아하고 Mosquitto를 사용하여 MQTT를 통해 JSON 페이로드로 몇 가지 실험을 해왔습니다. MQTT 및 서비스 품질에 대한 개요를 제공하는 Mosquitto (MQTT)를 사용한 안정적인 메시지 전달 기사를 참조하십시오 . 또한 샘플 애플리케이션 IoT – MQTT 공개 및 가입자 C 코드를 포함한 자원에 대한 링크가있는이 간략한 기사를 참조하십시오 .

메시지를 저장하기 위해 구독자에서 JSON 텍스트와 SQLite3 데이터베이스를 사용하여 MQTT를 사용한 실험은 https://github.com/RichardChambers/raspberrypi/tree/master/mqtt에 있지만 소스는 C이고 상당히 지저분합니다.

13 분짜리 비디오 # 144 인터넷 프로토콜 : CoAP vs MQTT, 네트워크 스니핑 및 IKEA Tradfri 해킹 준비 . CoAP, Constrained Application Protocol 에 대한 흥미로운 기사입니다 . CoAP는 IoT의 '현대적인'프로토콜 입니다. CoAP의 요약은 다음과 같습니다.

얼리 어답터는 제한된 애플리케이션 프로토콜이 제한된 네트워크 및 장치에 매우 효과적이라는 데 동의합니다. 잘 알려지지 않은 내용 : "혼잡 한 무선 네트워크 (Wi-Fi 또는 셀룰러)에서 CoAP는 MQTT와 같은 TCP (Transmission Control Protocol-based) 프로토콜이 핸드 셰이크를 완료 할 수없는 곳에서도 계속 작동 할 수 있습니다. "버 밀라 드는 말했다.

다른 대부분의 IoT 프로토콜과 달리 CoAP는 UDP를 기반으로하기 때문입니다. 즉, TCP에서 발생하는 프로토콜 핸드 셰이크 또는 오류 수정이 없음을 의미합니다. Matthieu는 "CoAP는 HTTP만큼 안정적이지 않거나 MQTT와 같은 메시지 전달을 보장하지만 매우 빠르다"고 지적했다. "일부 메시지가 수신되지 않으면 동일한 시간 내에 더 많은 메시지를 보낼 수 있습니다."

AMQP, STOMP 및 CBOR과 같은 다른 항목도 있습니다. CBOR 프로토콜의 논문, 구현 및 평가 뿐만 아니라 CBOR 표준 웹 사이트 를 참조하십시오 . AMQP, MQTT 및 STOMP 를 비교 및 ​​대조하고 RabitMQ 브로커에 대한 메모로 끝나는 메시징 프로토콜 선택 : AMQP, MQTT 또는 STOMP 문서를 참조하십시오 .

다행히도 많은 사용자가 각 사용 사례마다 프로토콜 수프를 탐색하는 데 도움이 될 수 있습니다. 회사가 서로 다른 요구를 가진 많은 응용 프로그램을 갖는 것이 일반적이므로 여러 응용 프로그램에서 세 개의 브로커가 모두 필요할 수 있습니다. 바로 RabbitMQ와 같은 견고한 멀티 프로토콜, 폴리 글 로트 브로커가 들어오는 곳입니다. STOMP, MQTT 또는 AMQP를 보내고 다른 하나를 가져올 수 있기 때문입니다. 이러한 프로토콜 중 하나에 의해 고정 될 필요는 없습니다.이 3 가지 모두 RabbitMQ 브로커에서 지원되므로 애플리케이션 간 상호 운용성을위한 이상적인 선택입니다. 플러그인 아키텍처를 통해 RabbitMQ는 향후 이러한 프로토콜의 추가 또는 업데이트 버전을 지원하도록 발전 할 수 있습니다.

약 60 개의 슬라이드로 구성된이 슬라이드 공유 패키지는 신뢰성과 견고성에 대한 요구가 다른 두 가지 다른 IoT 그룹 (소비자 및 산업)의 요구를보고있는 4 개의 다른 IoT 프로토콜을 비교 및 ​​대조합니다. IoT에 적합한 메시징 표준은 무엇입니까? .

UDP에 대한 완벽한 응용 프로그램처럼 들립니다. 클라이언트-서버 토폴로지 (pub / sub는 필요하지 않음), 패킷 손실에 견딜 수 있고 단일 패킷 전송 사이의 큰 간격은 순서가 잘못된 도착이 문제가되지 않음을 의미합니다.

연결 설정 및 패킷 오버 헤드를 절약하면 유리합니다.

자동 실패 문제에 대해 완화하면됩니다. 이 작업을 수행하는 많은 방법이 있지만 x (예 : 10) 패킷을 수신 할 때마다 서버가 응답하도록하는 것이 좋습니다. 이렇게하면 클라이언트는 얼마나 많은 패킷이 통과하고 있는지 알 수 있으며 임계 값 미만이면 전송 빈도를 높여 패킷 손실을 막을 수 있습니다. 아무것도 통과하지 못하면 TCP는 어쨌든 도움이되지 않으므로 조건이 사라질 때까지 클라이언트를 조난 모드로 두는 것이 좋습니다.

인터넷을 통한 UDP 패킷 손실은 일반적으로 높지 않으며 일반적으로 일시적인 현상입니다. GSM은 일부 버퍼링 및 무선 신호 평가를 제공하므로 스퓨리어스 노이즈에 대한 내성을 제공합니다.

GSM / SIM을 사용하도록 외부 적으로 제한되어 있습니까?

대안은 다음과 같은 LoRa 네트워크를 사용하는 것입니다.

• 작은 페이로드에 매우 최적화
• 최소한의 에너지 사용 (따라서 최대 배터리 수명)을 위해 설계되었습니다
• 설계 상 장거리
• 연결 클래스가 있어야합니다 (항상 켜져 있고, 승인되고, 승인되지 않은)
• 다운로드 창을 예약했습니다 (예 : 펌웨어 업데이트 또는 RX ACK)

대부분의 국가에서 기존 커뮤니티 또는 상업용 LoRa 인프라에 연결하거나 더 적합한 경우 고유 한 LoRa 허브를 배포 할 수 있습니다.

전 세계적으로 활발한 개발이 진행되고 있으며 프로토 타이핑 쉴드 (예 : Arduino)를 쉽게 이용할 수 있습니다.

JSON 데이터로 최소 HTTP 응답을 선호합니다. HTTP 응답은 500 바이트 HTTP 전송보다 훨씬 낮을 수 있으며 RESTful 웹 애플리케이션을 위해 많은 클라이언트와의 호환성을 유지합니다.

aprox 130 바이트 HTTP 데이터가 포함 된 최소 HTTP 메시지 (예 : JSON 결과)는 다음과 같습니다.

HTTP/1.1 200 OK
Server: ProprietaryAndroid
Connection: close
Content-Type: application/json
{
  "lat": "42.00000",
  "long": "10.00000"
}

앱에서 서버로 데이터를 보내려면 위도 / 경도를 URL 매개 변수로 설정하는 HTTP GET을 사용하면됩니다. 요청에 응답보다 적은 데이터가 있습니다.

GET /?lat=42.00000&long=10.0000 HTTP/1.1
Host: 192.168.0.2 
User-Agent: Proprietary
Accept: */* 
Connection: close

"최상의"프로토콜은 없습니다. 고려해야 할 많은 절충점 :

• 임의의 포트가 차단 된 임의의 네트워크에 장치가 있습니까? 그렇다면 HTTPS를 사용하는 것이 좋습니다.

• UDP를 전송하면 항상 매번 마지막 N 개의 측정 값을 보낼 수 있으므로 작은 패킷 손실이 무시됩니다. UDP를 안정적인 프로토콜로 전환하여 ACK 패킷을 보낼 수도 있습니다. (UDP 위에있는 대부분의 프로토콜이이를 수행합니다.)

• 고객의 데이터가 암호화되지 않은 상태로 노출 되나요? 해커가 암호화되지 않은 연결에 잘못된 데이터를 주입 할 수 있는지 고객이 걱정합니까? (그렇다면 암호화가 필요할 수 있습니다.)

• 누군가 프로토콜을 스니핑하고 데이터를 조작하면 어떻게됩니까? 한 장치가 다른 장치의 데이터를 덮어 쓰지 못하게 할 수 있습니까?

• 최대 몇 대의 장치를 사용 하시겠습니까? 모든 장치를 어떻게 다룰 것인가? 데이터를 어디로 이동해야합니까? 서버 인프라의 유지 관리 및 업그레이드를 어떻게 처리합니까? 경험이 없으면 많은 동시 연결을 처리 할 수있는 능력을 과대 평가했을 수 있습니다. 공급 업체에 아웃소싱하고 AWS IoT와 같은 프로토콜을 사용하는 것이 가장 좋습니다.

현재 시나리오에서 HTTP와 MQTT 전송 속도를 비교하는 정확한 테스트가 있습니다. test2를 참조하십시오. MQTT는 HTTP보다 트래픽 (및 배터리)이 50 배 줄어 듭니다.

기본적으로 MQTT와 일반 TCP (메시지 크기)에는 차이가 없습니다. MQTT 페이로드에서 일반 TCP와 이진 메시지와 JSON 사이에는 기본적으로 차이가 없다고 말할 수도 있습니다. 이러한 방식으로 MQTT + JSON을 사용하는 것이 훨씬 편리하며 데이터 전달 및 표현을 위해이 기술에 의존합니다. 키 이름을 짧거나 짧게 지정하십시오.

UDP와 관련하여 전송이 분당 한 번이면 TCP를 사용하는 것이 좋습니다. 전송이 10-20 분 이상 한 번이면 UDP를 더 많은 트래픽 / 배터리 효과적인 솔루션으로 간주 할 수 있습니다. ACK를 사용하여 자체 프로토콜을 개발하려는 경우 MQTT 또는 TCP를 사용하고 비즈니스 사례에만 집중하는 것이 좋습니다.

일반적으로 구현이 간단할수록 가장 짧은 시간에 최상의 결과를 얻을 수 있습니다. 내가 당신이라면,이 경우 UDP + 자체 바이너리 형식과 MQTT + JSON을 테스트하고 그중 하나를 선택하는 것이 좋습니다. 또는 심지어 MQTT + JSON에서 시작한 다음 제 경우에는 괜찮을지 생각하십시오.