The tortuous experience of IoT devices sending MQTT requests to the cloud

クラウドへの MQTT リクエスト送信における IoT デバイスの複雑なプロセス

IoT デバイスがセンサーからデータを取得し、ネットワークを通じてクラウドに送信するまでの一連のネットワークプロセスを理解するために、まずネットワーク階層モデルを確認しましょう。

上記の図は、ネットワーク階層で最も一般的なプロトコルを示しています。

・アプリケーション層：アプリケーションは、対応する規則 (プロトコル) に従ってデータをパッケージングし、トランスポート層に送信する役割を担います。

*MQTT: Message Queuing Telemetry Transport (メッセージキューテレメトリ転送)

*CoAP: 制約付きアプリケーションプロトコル

*HTTP: ハイパーテキスト転送プロトコル

*FTP: ファイル転送プロトコル

*SMTP: 簡易メール転送プロトコル

・トランスポート層：アプリケーション層から転送されたデータをグループ化する役割を担います。受信側でデータの順序と整合性を確保するため、各パケットにマーキングを施してネットワーク層に渡します。

*TCP: 伝送制御プロトコル

*UDP: ユーザーデータグラムプロトコル

・ネットワーク層：トランスポート層から送信されたデータパケットを宛先端末に送信する役割を担います。

*IP: インターネットプロトコル

*ICMP: インターネット制御通知プロトコル

*IGMP: インターネットグループ管理プロトコル

・リンク層：ネットワーク層のデータユニットの送受信を行います。

*ARP: アドレス解決プロトコル

*RARP: 逆アドレス解決プロトコル

パッケージングと転送

データが各層を通過する際、対応するプロトコルによってパッケージングされます。これをカプセル化と呼びます。宛先に到達すると、各層で順番にアンパッケージングされます。これをデマルチプレクシングと呼びます。

送信時、デバイスが収集したビジネスデータはアプリケーションプログラムによって MQTT メッセージとしてカプセル化されます。各層は上位層から転送されたメッセージを自層のデータブロックとして扱い、プロトコル識別子を含む独自のヘッダーを追加し、この全体が自層のメッセージとして下位層に転送されます。

受信時、データは下位層から上位層へ流れます。各層を通過する際、メッセージのヘッダーが取り外されます。メッセージ識別子に基づいて正しい上位層プロトコルが判定され、最終的にアプリケーション層のアプリケーションプログラムによって処理されます。

IoT デバイスが収集したビジネスデータは、デバイス側のアプリケーションプログラムによって MQTT メッセージとしてカプセル化されます。MQTT メッセージは、確立された TCP ロングコネクションを通じてデータストリームの形で順次転送されます。TCP はデータストリームを受信すると、小さなデータブロックに分割します。各ブロックに追加される TCP ヘッダーとデータブロックを合わせて TCP パケットを構成します。パケットはネットワーク層を通じて送信されます。ネットワーク層は IP プロトコルに従います。パケット送信要求を受信すると、パケットは IP データグラムに格納され、ヘッダー情報が入力され、データグラムはリンク層を通じて送信されます。

クラウド側では、リンク層からデータ要求を受信した後、ネットワーク層でデータを解析し、トランスポート層に渡してパケットの順序と整合性を検証します。クラウド側はデータブロックからデータを抽出して MQTT メッセージを取得し、アプリケーション層に渡して処理させます。このプロセスでは各層のヘッダーを順番に分割して取り外し、IoT デバイスが収集したビジネスデータを復元します。

アプリケーション層 MQTT プロトコル

MQTT はクライアントサーバーアーキテクチャ向けのパブリッシュ/サブスクライブモードのメッセージ転送プロトコルです。設計思想は軽量、オープン、シンプル、標準的であり、実装が容易です。これらの特性により、多くのシナリオ、特にマシンツーマシン通信 (M2M) や IoT のような制約のある環境に適しています。

MQTT プロトコルのパケットフォーマットは非常にシンプルで、固定ヘッダー、可変ヘッダー、ペイロードの 3 つの部分で構成されます。

固定ヘッダー：制御メッセージタイプ、フラグビット、残り長を含みます。

MQTT メッセージの最初のバイトの上位 4 ビット (bit7〜bit4) は制御メッセージタイプを示し、合計 16 種類のプロトコルタイプを表現できます。

MQTT メッセージの最初のバイトの下位 4 ビット (bit4〜bit0) は、データパケットのフラグビットを指定するために使用されます。PUBLISH 制御メッセージでのみ使用されます。

残り長：MQTT メッセージの 2 バイト目から始まり、MQTT パケットの長さを識別するフィールドで、最少 1 バイト、最大 4 バイトです。各バイトの下位 7 ビットが値を示し、範囲は 0〜127 です。

可変ヘッダー：一部の MQTT パケットタイプに存在し、具体的な内容はパケットの種類によって決まります。

ペイロード：一部の MQTT パケットに存在し、メッセージの具体的なビジネスデータを格納します。

トランスポート層 TCP プロトコル

MQTT 接続は TCP 接続を基盤としており、信頼性の高いデータ接続を提供します。MQTT メッセージを転送する際、メッセージデータは確立された TCP 接続を通じてストリームの形で順次転送されます。TCP は受信したデータストリームを小さなブロックに分割し、各ブロックが TCP パケットとなります。

データは小さなブロックで送信されるため、完全で信頼性の高いデータ転送は主に次の点に反映されます：パケットが完全であるか、パケットの順序が正常であるか、パケットが破損していないか、パケットデータが重複していないか。これらは TCP のチェックサム、シーケンス番号、確認応答、再送制御、接続管理、ウィンドウメカニズムによって制御されます。

TCP は伝送制御プロトコルです。伝送制御は主にヘッダーに含まれる 6 つのフラグに依存し、メッセージの転送状態と、送信者と受信者がデータを処理するために取るアクションを制御します。これらの値が 1 の場合、各フラグに対応する機能を実行できます。たとえば、URG が 1 の場合、メッセージヘッダーの緊急ポインタ部が有効になります。



・URG 緊急ポインタ

・ACK 確認応答：シーケンス番号が有効であることを示す

・PSH 受信者はこのメッセージセグメントをできるだけ早くアプリケーション層に渡す必要がある

・RST 接続再構築

・SYN 同期シーケンス番号：接続開始に使用

・FIN 送信側は送信タスクを完了する

ソースポートと宛先ポート：送信者と受信者のポート番号を識別します。TCP 接続はソース IP、ソースポート、宛先 IP、宛先ポートの 4 つの値で確立されます。ソース IP と宛先 IP は IP パケットに含まれます。

ヘッダー長：TCP ヘッダーのバイト長を示します。データ転送が必要なバイトの開始位置もマークできます。

TCP セグメントシーケンス番号：このセグメントで送信されるデータの最初のバイトのシーケンス番号です。各メッセージセグメントのデータのすべてのバイトにシーケンス番号があります。最初のバイトのシーケンス番号は 0 から始まり、1 ずつ増加し、2 の 32 乗に達すると 0 に戻ります。

TCP セグメント確認応答番号：ヘッダーフラグ ACK が 1 の場合、確認応答番号が有効になります。TCP セグメントを受信側が受信した後、送信側に確認応答番号を送り返します。この番号は受信した最後のバイトのシーケンス番号に 1 を加えた値です。

チェックサム：送信側で計算され、受信側で検証されます。受信側がチェックサムが正しくないことを検出した場合、TCP セグメントが破損している可能性を示し、破棄されます。同時に、受信側は重複確認応答番号 (最新の正しいメッセージ転送時の確認応答番号と同じ) を送り返し、受信した TCP セグメントが正しくないことを示し、次に受信したいシーケンス番号を伝えます。この時、送信側は誤りのある TCP セグメントを即座に再送する必要があります。

緊急ポインタ：ヘッダーフラグ URG が 1 の場合、緊急ポインタが有効になり、送信側が受信側に緊急データを送信することを示します。緊急ポインタは正のオフセットで、TCP セグメントのシーケンス番号に加算して緊急データの最後のバイトのシーケンス番号を計算します。たとえば、受信側がシーケンス番号 1000 のバイトから読み取りを開始し、緊急ポインタが 1000 の場合、緊急データはシーケンス番号 1000〜2000 のバイトです。その処理方法は受信側が決定します。

ウィンドウサイズ：TCP ブロックのデータストリームのスループットを決定します。注意点として、送信側が相手に対して送信を許可するデータ量を表します。たとえば、送信側のヘッダーのウィンドウサイズが 1000 の場合、送信側は相手から最大 1000 バイトのデータを受信できます。これは送信側のデータキャッシュスペースに関連し、TCP パフォーマンスに影響します。

ヘッダーフラグ PSH：受信側にすべてのデータを受信プロセスに即座に渡す必要がある場合、送信側は PSH を 1 に設定する必要があります。ここでいうデータとは、PSH と一緒に転送されるデータと、それ以前に受信したすべてのデータです。受信側が PSH が 1 のものを受信した場合、他のデータが到着するのを待たずに、データを即座に受信プロセスに渡す必要があります。

リセットフラグ RST：RST が 1 の場合、接続が異常であることを示し、受信側は接続を終了し、アプリケーション層に再接続を通知します。

SYN：接続の確立に使用され、3 ウェイハンドシェイクを含みます。

1: 接続確立時、クライアントはサーバーに TCP パケットを送信します。パケットのヘッダーの SYN は 1 で、初期シーケンス番号を含み、接続要求であることを示します。

2: サーバーが接続を受け入れる場合、クライアントに TCP パケットを送信します。パケットには SYN と ACK の両方が 1 で含まれ、確認応答番号も含まれます。その値はクライアントからの初期シーケンス番号 +1 で、接続を受け入れたことを示します。

3: 前のステップで送信されたパケットを受信した後、クライアントはサーバーに確認応答メッセージパケットを送信します。ACK は 1 で、確認応答番号が再度含まれます。その値はステップ 2 のサーバーからの確認応答番号 +1 です。確認応答メッセージを受信した後、サーバーは接続状態になります。

ステップ 3 の確認応答パケットには送信データを含めることができます。

接続終了フラグ FIN：接続を閉じるために使用されます。一方がデータ転送タスクを完了すると、FIN フラグを送信して接続を終了します。ただし、TCP は双方向 (C-S、S-C) にデータ転送があるため、各方向に独自の FIN 送信と確認応答によるクローズプロセスがあり、合計 4 回のやり取りが発生します。これは 4 ウェイ終了とも呼ばれます。

1: クライアントのアプリケーション層のデータ転送が完了した場合、クライアントの TCP メッセージは FIN を送信し、サーバーにデータ転送のクローズを伝えます。

2: サーバーはこのフラグを受信した後、ACK を送り返し、確認応答番号は受信したシーケンス番号 +1 で、TCP はアプリケーションにファイル終了文字も送信します。

3: この時点で、サーバーはこの方向の接続を閉じ、その結果サーバーの TCP も FIN を送信します。

4: クライアントはそれを受信した後、確認応答 ACK を送り返し、確認応答番号は受信したシーケンス番号 +1 で、接続は完全に閉じられます。

TCP セグメントのシーケンス番号と確認応答番号はデータの順序性を保証し、チェックサムはデータの整合性を保証し、緊急ポインタは緊急データが適時に処理されることを保証します。さらに、TCP にはタイムアウト再送、輻輳回避、スロースタートなどのメカニズムがあり、パケットデータが完全に順序通りに宛先に転送されることを確保できます。

ネットワーク層 - IP プロトコル

TCP パケットが貨物を詰めるコンテナであれば、IP はそのコンテナを運ぶトラックです。IP プロトコルは 2 つのノード間の接続を提供し、TCP データをソースから宛先までできるだけ速く転送できるようにしますが、転送の信頼性は保証しません。

IP 層は上位層から転送された TCP パケットをカプセル化し、独自のヘッダーを付加し、ルーティング、断片化、再構成を行って宛先に届けます。この過程で IP ヘッダーが重要な役割を果たします。ヘッダーの構造を確認しましょう。

Version：現在の IP プロトコルのバージョンを示します。現在のバージョン番号は 4 です。もう一つのバージョン番号 6 があり、それぞれ IPv4 と IPv6 です。送信側と受信側のバージョンが一致しない場合、現在の IP データグラムは破棄されます。

ヘッダー長：ヘッダー全体の長さを示し、最大 60 バイトです。

サービスタイプ (TOS)：サービス種類を区別するために使用されますが、実際の IP 層の動作では使用されていません。既存の TOS は 4 ビットのサブフィールドと 1 ビットの未使用ビットのみです。未使用ビットは 0 に設定する必要があります。TOS の 4 ビットのうち 1 つだけを 1 に設定でき、現在のサービスタイプを示します。4 ビットに対応する 4 つのサービスタイプは、最小遅延、最大スループット、最大信頼性、最小コストです。

全長：現在のデータグラムメッセージの全長をバイト単位で示します。ヘッダー長と組み合わせることで、メッセージ内のデータのサイズと開始位置を計算できます。

次の 3 つのヘッダーフィールドは、IP データグラムの断片化と再構成のプロセスに関連しています。ネットワーク層は通常、各データフレームの最大長を制限しているため、IP 層はデータグラムを送信すると同時に、ルーティングと並行して現在のデバイスネットワーク層の各データフレームの最大転送長を検索します。最大転送長を超えた場合、データグラムは断片化され、宛先到着後に再構成されます。この時、次の 3 つのフィールドが再構成の基準として使用されます。注意点として、ルーティングプロセスがあるため、データグラムが通過する各ルーティング機器の層のデータフレームの最大転送長は異なるため、どのルーティング段階でも断片化が発生する可能性があります。

パケット ID：この ID は識別子に相当します。IP 層は区画の送信が成功するたびに、このパケット ID に 1 を加算します。

フラグ：3 ビットを占め、R、D、M の 3 つです。R は未使用ですが、D と M は有効です。このフィールドはデータグラムの断片化動作を示します。D が 1 の場合、データを分割せずに一度で転送することを意味します。M が 1 の場合、データが断片化されており、後続のデータが存在することを意味します。0 の場合、現在のデータグラムが最後のフラグメントであるか、このフラグメントのみであることを意味します。

スライスオフセット：現在の区画から元のデータグラムの先頭までの距離を示します。区画化後、各フラグメントの全長はデータグラム全体の長さではなく、そのフラグメント自体の長さに変更されます。

生存時間：(TTL) はデータグラムを破棄するかどうかを判定できます。IP はデータをホップ単位で転送するため、データはルーティング機能が設定された異なる IP 層間で転送される可能性があります。生存時間はデータグラムが最大で何層のルーティングを経由できるかを示します。各ルーティング層を通過するたびに値が 1 減算されます。値が 0 になると、データグラムは破棄され、エラーメッセージを含むメッセージ (ICMP、IP 層のコンポーネントで、エラー情報を伝送するために使用) が送信元に送られます。生存時間は、データグラムがルーティングループ内で永久に転送され続ける問題を効果的に解決できます。

ヘッダーチェックサム：データグラムの整合性を検証します。送信側はヘッダーの合計を計算し、結果をチェックサムに格納し、受信側は再計算します。計算結果がチェックサムの値と一致すれば、転送プロセスは正常です。そうでなければ、データグラムは破棄されます。

上位層プロトコル：受信側がデータをどの上位層プロトコルに渡して処理するかを決定します。たとえば TCP や UDP です。

送信元 IP：送信者の IP アドレスを記録し、エラーメッセージを送り返す際に使用されます。

宛先 IP：宛先の IP を示し、各ルーティングの判断に使用されます。

ルーティング

IP ヘッダーには宛先 IP アドレスのみが含まれているため、完全なパスは反映されません。データ送信時、IP 層はローカルルーティングテーブルの宛先 IP の検索結果に基づいてルーティング判断を行います。データグラムはホップ単位で宛先に配信されます。各ホップが 1 回のルーティング選択です。

IP 層はルーターまたはホストとして設定できます。ルーティング機能が設定されている場合、データグラムを転送できます。宛先 IP が自機の IP でない場合、データグラムは破棄されます。

ルーティング機能を持つ IP 層の宛先 IP アドレスが自機のものでない場合、どのステーションに転送するかを判断する根拠は何でしょうか。この問題を理解するには、ルーティングテーブルの構造を理解する必要があります。以下は IP 層が管理するルーティングテーブルです。

宛先 IP：IP データグラムが最終的に到達または経由するネットワークアドレスまたはホストアドレスを示します。

ゲートウェイ (ネクストホップアドレス)：現在のルーティングテーブル管理デバイスの隣接ルーターのアドレスです。

Flags：現在のルートレコードの属性を示し、5 つの異なるフラグで表現されます。

U：このルートは使用可能

G：このフラグがあれば、ネクストホップがゲートウェイであることを示します。このフラグがなければ、ネクストホップが現在のデバイスと同じネットワークセグメントにあり、データグラムを直接送信できることを示します。

H：ネクストホップがホストかネットワークかを示します。このフラグがあればホストを、なければネクストホップのルートがネットワークであることを示します。

D：ルートがリダイレクトメッセージによって作成されたことを示します。

M：ルートがリダイレクトメッセージによって変更されたことを示します。

Interface：現在のルート項目の物理ポート

データグラムを受信するたびに、IP 層は宛先 IP アドレスに基づいてルーティングテーブルを検索し、検索状況に応じて 3 つの結果のいずれかになります。

宛先 IP に一致するルート項目が見つかり、メッセージはそのルート項目の次のステーションの Gateway または Interface に送信される

宛先 IP のネットワーク番号に一致するルート項目が見つかり、メッセージはそのルート項目の次のゲートウェイまたはネットワークインターフェイスに送信される

上記 2 つが見つからない場合、ルートテーブルにデフォルトルート項目があるかどうかに依存します。あれば、指定された次のステーションのルート (Gateway) に送信される

上記 3 つの結果のいずれでもない場合、データグラムは送信できません。IP データグラムはホップ単位で宛先ホストに送信されますが、固有の長さがあります。宛先ホストの MTU を超えると、断片化されます。

データグラム断片化の概念

TCP ハンドシェイク時、宛先の IP 層の最大転送単位 (MTU) に基づいて、TCP データが毎回转送できる最大データ量 (MSS) を決定します。その後、TCP は MSS に従ってデータをパケット化し、各パケットは IP データグラムにカプセル化されます。IP データグラムがルーティング過程でいずれかの層を通過する際、MTU の制限により断片化される可能性があります。この時、IP ヘッダーの 3 ビットフラグの M フラグを 1 に設定し、断片化が必要であることを示します。各区画のヘッダーは基本的に同じですが、スライスオフセットが異なります。スライスオフセットに基づいて、これらのフラグメントは宛先で完全な IP データグラム (1 つの TCP パケット) に再構成されます。IP 転送は順序不同のため、受信するデータグラムも順序不同です。ただし、データが完全であれば、TCP はヘッダーのフィールドに基づいて並べ替えます。IP フラグメントが損失して IP 層が完全なデータグラムを構成できない場合、TCP 層に再送を要求します。

リンク層 ARP プロトコル

IP 層がデータをカプセル化した後、宛先ホストの IP アドレスのみがあります。IP アドレスだけではデータグラムを直接送信できません。各ハードウェアデバイスには固有の MAC アドレスがあり、これは 48 ビットの値です。宛先 IP のアドレスが分かっているので、この IP に対応する MAC アドレスを見つける必要があります。このプロセスで、ルーティングテーブルの検索とリンク層の ARP プロトコルを組み合わせることで、宛先 IP に対応する MAC アドレスを最終的に取得します。

ARP プロトコルは IP アドレスから MAC アドレスへのマッピングを実現します。初期状態では、送信元は宛先の MAC アドレスを知らず、宛先 IP アドレスのみを知っています。このアドレスを取得するために、ARP リクエストとレスポンスのやり取りが行われます。同様に、ARP にも独自のパケット形式があります。まずそのパケットフォーマットを確認しましょう。

イーサネット宛先アドレス：宛先の MAC アドレスです。ARP キャッシュテーブルがない場合、これはブロードキャストアドレスです。

イーサネット送信元アドレス：送信側の MAC アドレスです。

フレームタイプ：異なるフレームタイプには異なるフォーマットと MTU 値があり、タイプごとに異なる番号があります。ここでは ARP に対応する番号は 0x0806 です。

ハードウェアタイプ：リンク層のネットワークタイプを指します。1 はイーサネットを示します。

プロトコルタイプ：変換対象のアドレスタイプを指します。0x0800 は IP アドレスです。たとえば、イーサネットアドレスを IP アドレスに変換します。

操作タイプ：ARP リクエスト (1)、ARP レスポンス (2)、RARP リクエスト (3)、RARP レスポンス (4) の 4 種類があります。

送信元 MAC アドレス：送信側の MAC アドレスを示します。

送信元 IP アドレス：送信側の IP アドレスを示します。

宛先イーサネットアドレス：宛先デバイスの MAC 物理アドレスを示します。

宛先 IP アドレス：宛先デバイスの IP アドレスを示します。

2 つのデバイスがメッセージを送信する前、ソースエンドのリンク層は ARP プロトコルを使用して宛先エンドの MAC アドレスを問い合わせます。ARP はブロードキャストリクエストを送信します。イーサネット上の各ホストがブロードキャストを受信します。ブロードキャストの目的は宛先 IP の MAC アドレスを問い合わせることで、主に自身の IP と MAC アドレスを紹介した上で、宛先 IP を持っている場合はハードウェアアドレスを返信してくださいと問い合わせます。ホストがブロードキャストを受信して宛先 IP アドレスを持っている場合、内部のアクティブな IP と MAC アドレスをリクエストし、ARP レスポンスでソースホストに応答します。宛先 IP アドレスがなければ、リクエストは破棄されます。リクエストはブロードキャストで外部に送信され、レスポンスは個別に応答されることが分かります。

ただし、通信のたびに毎回リクエストとレスポンスのプロセスを経るわけにはいきません。レスポンスを正常に受信した後、IP と MAC アドレスのマッピング関係は ARP キャッシュテーブルにキャッシュされます。有効期間は一般的に 20 分で、次回ネットワーク層が直接カプセル化できるようにします。したがって、完全なプロセスは次のようになります。

TCP パケットを受信した後、IP 層は送信またはカプセル化する前にルーティングテーブルを検索します。

宛先 IP と自身が同じネットワークセグメントにある場合、まず ARP キャッシュテーブルで宛先 IP に対応する MAC アドレスがあるか確認します。あれば、リンク層に送ってカプセル化します。キャッシュテーブルになければ、ブロードキャストして MAC アドレスを取得し、キャッシュします。IP 層は TCP をカプセル化してから、リンク層に送ってカプセル化します。

宛先 IP アドレスが自身と異なるネットワークセグメントにある場合、メッセージをデフォルトゲートウェイに送信する必要があります。ARP キャッシュテーブルにゲートウェイ IP に対応する MAC アドレスがあれば、リンク層に送ってカプセル化します。なければ、ブロードキャストしてアドレスを取得し、キャッシュします。IP 層は TCP をカプセル化してから、リンク層に送ってカプセル化します。

イーサネットデータフレーム

上記の準備がすべて整ったら、実際にカプセル化されて送信されるのはイーサネットデータフレームです。イーサネット宛先アドレス、イーサネット送信元アドレス、フレームタイプがフレームヘッダーを構成します。プリアンブルとフレーム開始デリミタはヘッダーの前に挿入され、受信側に準備を促します。フレーム末尾にはフレームチェックシーケンス (FCS) が追加され、フレームのエラーを検出します。

プリアンブル同期コード：受信アダプターのクロック周波数を調整し、送信側の周波数と同一にします。

フレーム開始デリミタ：フレームの開始を示すマーカーで、フレーム情報が到着するので受信準備をするよう示します。

宛先アドレス：フレームを受信するネットワークアダプターの MAC アドレスです。受信側はフレームを受信すると、まず宛先アドレスが自身のアドレスと一致するか確認します。一致しなければ破棄されます。

送信元アドレス：送信側デバイスの MAC アドレスです。

タイプ：フレーム受信後にデータを処理するプロトコルを決定します。

データ：上位層に渡されるデータです。このシナリオでは IP データグラムを指します。

フレームチェックシーケンス：このフレームにエラーがあるかどうかを検出します。送信側はフレームの巡回冗長検査 (CRC) 値を計算し、この値をフレームに書き込みます。受信側のコンピューターは CRC を再計算し、FCS フィールドの値と比較します。2 つの値が異なる場合、転送中にデータ損失または変更が発生したことを示します。この時、フレームの再送が必要です。

送信と受信



上位層からデータグラムを受信した後、MTU とデータグラムサイズに基づいて小さな断片に分割するかどうかを決定します。これが IP データグラムの断片化プロセスです。

データグラム (ブロック) をフレームにカプセル化し、下位コンポーネントに送信します。下位コンポーネントはフレームをビットストリームに変換して送信します。

イーサネット上のデバイスはフレームを受信し、フレーム内の宛先アドレスを確認します。自身のアドレスと一致すれば、フレームを処理して層ごとに転送します (共有プロセス)。

あとがき

以上で、IoT デバイスがセンサーからデータを収集し、エンドアプリケーションが MQTT メッセージにパッケージングし、ネットワークプロトコルを通じて層ごとにカプセル化し、クラウド受信システムで層ごとに分割するまでの完全なネットワークプロセスを整理しました。IoT に関連する MQTT、TCP、IP、ARP のネットワークプロトコルを理解する上で、お役に立てれば幸いです。