IoTアプリケーションに適したプロトコルの選択
Thing / Constrained DeviceがGPS位置を一定の間隔で特定のサーバーに送信するIoTシナリオが機能しています。制約のあるデバイスは、バッテリー駆動で接続にGSM / SIMシールドを使用するArduinoのようなボードです。これらは私たちの設計目標です： バッテリー寿命を最大化 データ転送を最小限に抑える テストの目的で、HTTPを使用して約500バイトのメッセージを生成しましたが、データ転送にはより適切なプロトコルを使用する時が来ました。データ転送の特徴のいくつかは次のとおりです。 ペイロードは、通常、かなり小さい未満50バイト（かなり遠く離れて、典型的なのMTUから、すなわちすべてがIPパッケージに収まる必要があります） データは約1分に1回送信されます。一部の差異は重要ではありません。 いくつかのメッセージを失うことはOK 現在、デバイスはサーバーからの応答を必要としません（ただし、将来的に変更される可能性があります）。サーバーはデバイスとの会話を開始する必要もありません。 これまでのところ、これらの可能性について考えてきました。 TCPを介したカスタムプロトコル。これにより、HTTPヘッダーが削除され、メッセージが10分の1に小さくなります。これは私たちの信頼できる/保守的なアプローチです。 UDP経由のカスタムプロトコル。UDPのヘッダーは小さく、信頼性のためのオーバーヘッドがないため、かなり効率的であることが期待されます。コメントされているように、ここで1つのメッセージが失われることも、心配することもありません...しかし、私たちが認識していない非信頼性に関する他の問題がある可能性があります。 MQTT（TCP経由の標準）：TCPと比較して既存のオーバーヘッドがほとんどないため、これもオプションとなる可能性があります...しかし、GSM / SIMテクノロジーの経験があまりなく、方法継続的なMQTT接続はこのように機能し、接続のハートビート帯域幅がこのような低頻度のデータ転送に適しているかどうかを示します。 CoAP（UDP 経由の標準）：有望であるようです。ヘッダーとUDPを介して動作するためのオーバーヘッドはわずか4バイト。ただし、UDPの未知のリスクがあります。 誰かが何かヒントを与えることはできますか？前もって感謝します。