XMLは冗長であると言っても過言ではありませんが、XMLは意味論をカプセル化しているため、この冗長性がコンテンツに関してすべて「オーバーヘッド」ではないことを認識しておく必要があります。静的な構造ではなく動的な構造を強調するあらゆるプロトコルの兆候であるオーバーヘッドです。たとえば、HTMLは実際には、XMLのリラックスした形式であり、コンテンツの側面と見なすことができる動的な構造を持つコンテンツを伝達します。テーブルのコンテンツとテーブル自体を区別できますが、コンテンツが特定の関係を持つ表形式のデータであるという事実は、コンテンツに不可欠です。各セルを取り出してすべて1つの長い文字列として送信した場合、その構造とそれらの関係は失われ、情報が失われ、その内容ではないでしょうか。
いくつかのタブラデータを構成する可能性のある8バイトのメッセージを考えてみましょう。非常に静的なプロトコルを使用する場合、最低限、次のようなプロトコルを定義するだけで、追加のオーバーヘッドなしでそれを送信できます。
- 各メッセージは正確に8バイトであるため、長さを指定したり、終了シーケンスを含める必要はありません。
- 8バイトは常に、各セルに16ビット値が含まれる2 x 2グリッドを参照するために使用されます。
私のすべてのメッセージがまったく同じである場合、XML、HTML、またはXMPPを使用することはばかげていると見なされる可能性があります。常に同じであり、事前に決定されている構造コンポーネントの帯域幅を浪費し、両端で対応する計算時間を浪費してそれを作成および解析しています。各セルに2、3文字の2 x 2のテーブルを含む最小限の適切なHTMLページは、フォーマットとプロトコルのオーバーヘッドに対応するために、少なくとも100バイトになるでしょう。
ただし、すべてのメッセージがそうではない場合、メッセージの種類を指定することは、「ペイロード」の文字どおりの部分ではない可能性がありますが、コンテンツ的には必要なコンポーネントです。追加の2バイトだけでそれを行うことができ、より多くのダイナミズムを導入できます。
- メッセージは可変長の0〜255バイトになり、最初のバイトは長さを示します。
- 事前定義されたさまざまなメッセージタイプに対して（最大で）256のコードがあり、その1つが「2 x 2テーブル」で、2番目のバイトです。
現在、8バイトのテーブルコンテンツには2バイトのオーバーヘッドが必要ですが、このカスタムプロトコルを使用して送信できるメッセージの種類に関しては、はるかに幅広い可能性があります。
それでも、HTMLページやXML名前空間の仕様（またはXMPPが本質的には何であるか）の可能性に近いところはまだありません。
したがって、それに基づいて、ほとんどの場合、単純な8バイトのメッセージを送信する場合、XMPPはおそらくやり過ぎです。しかし、必ずしもそれほどではありません。「IOT CONNECTED DEVICEからサーバーに1バイトのデータを送信するための単一の要求/応答交換が0.5 kBを超える」という主張は、関連するRFCを一見すると、誇張されている可能性があると思われます（ただし、すべて、私はそれをちらっと見て、XMPPを実装または使用したことはありません）。あなたがそのような例を構築できることは間違いありませんが、それはおそらく最小限の例ではありません。
プロトコルはTCP指向であるため、「「jabber：client」名前空間で修飾されたXMLストリーム」の確立は、1つのことを行う場合にのみメッセージの一部と見なす必要があります。デバイスはサーバーに接続して8バイトを送信し、送信しますデータ、切断します。関係がより永続的で、IoTコンテキストにあることが多い場合は、デバイスが宛先への接続を既に確立していると想定できます。この場合、メッセージの最終的な宛先がサーバーである場合（サーバーがメッセージを渡す別のクライアントとは対照的）、プロトコルのオーバーヘッドは潜在的に最小限になります。
<message><body>8 bytes.</body></message>
わずか33バイトの「オーバーヘッド」。XMLはテキストであることをここで指摘する価値があります。そのため、メッセージがバイナリであることが多い場合は、そのデータを（たとえば、base64に）エンコードする必要があり、オーバーヘッドと計算量がさらに増えるため、あまり適切ではなくなります。要件。
つまり、最終的に：
XMPPには、IoTデバイスが短く頻繁にメッセージを送信するための大きなオーバーヘッドがありますか？
持続的な接続があり、メッセージがほとんど構造化されていない場合、私はそうは思いません。ただし、それが提供するもの（構造に関するダイナミズム）が必要ない場合は、おそらくより適切な方法論があります。
そのため、単一の中央サーバーがさまざまなデバイス間でメッセージを処理および/または依存するコンテキストがある場合、それらのデバイスのいずれかが常に単純で単純である場合でも、カプセル化できるプロトコルさまざまなメッセージがまだ役に立ちます。クライアントデバイスのリソースが限られている場合は、プロトコルの多くをハードコーディングでき、その端からの各メッセージをラップすることは非常に単純なタスクになります。私は、HTTPサーバーをデプロイする多くのIoTデバイスがそれを行うと信じています（これは、「単純なクライアント、複雑なサーバー」の逆です）。これらのサーバーは、どのような種類のHTTP要求も処理できず（事前にフォーマットされた拒否を除く）、実行する処理と送信する応答が非常に明確に定義され、焦点が絞られていますが、HTTPサーバーとして正しく機能するため、