IoT デバイスが MQTT メッセージをクラウドに送信するという複雑なエクスペリエンス

IoT デバイスがセンサーからデータを取得し、それをネットワーク経由でクラウドに送信するネットワーク プロセス全体を理解するために、まずネットワーク階層化モデルを見てみましょう。

9cc3b7894eb58d07d69e74326921384c.png

上の図は、ネットワーク レイヤ化における最も一般的なプロトコルを示しています。

  • アプリケーション層: アプリケーションは、対応するルール (プロトコル) を使用してデータをパッケージ化し、トランスポート層に送信する責任があります。

    • MQTT: メッセージ キュー テレメトリ トランスポート

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

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

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

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

  • トランスポート層: アプリケーション層から送信されたデータのグループ化を担当し、端末が受信したデータの順序と完全性を保証するために、各パケットにマークが付けられ、ネットワーク層に渡されます。

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

    • UDP: ユーザーデータプロトコル

  • ネットワーク層: トランスポート層からターゲット端末へのデータパケットの送信を担当します。

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

    • ICMP: インターネット制御メッセージ プロトコル

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

  • リンク層: ネットワーク層のデータユニットを送受信します。

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

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

  カプセル化と分解  

データが各層を通過する際には、対応するプロトコルでパッケージ化する、つまりカプセル化(Encapsulation)し、端末に到達する際には層ごとに解凍する、つまり逆多重化(Demultiplexing)する必要があります。

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

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

98dc51e0ee924849be6e5cb1b5ded141.png

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

クラウド システムはリンク層からデータ要求を受信すると、ネットワーク層に入りデータを分析し、トランスポート層に渡し、パケットの順序と整合性を検証し、データ ブロックからデータを取り出し、 MQTT メッセージを取得し、それをアプリケーション層に渡して処理します。このプロセスでは、ヘッダーをレイヤーごとに削除して、IoT デバイスによって収集されたビジネス データを復元します。

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

MQTT は、クライアント サーバー アーキテクチャのパブリッシュ/サブスクライブ モードでのメッセージ送信プロトコルです。その設計哲学は、軽量、オープン、シンプル、標準化されており、実装が簡単です。これらの特性により、多くのシナリオ、特にマシンツーマシン通信 (M2M) やモノのインターネット (IoT) 環境などの制約のある環境に適しています。

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

86ae2669f51d478b3c45aa729455656f.png

固定ヘッダー: 制御メッセージ タイプ、フラグ ビット、残りの長さが含まれます。

9fcfc72cc86bb8723482da88e9f9a6ac.png

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

598fe8f3a34387c7a2bffdf888722155.png

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

af7f38023ebe6987a0492ac0d5330d2f.png

残りの長さ:  MQTT メッセージの 2 番目のバイトは、MQTT パケットの長さを識別するために使用されるフィールドで、最小 1 バイト、最大 4 バイトであり、各バイトの下位 7 ビットは値を識別するために使用されます。範囲は 0 ~ 127 です。

11bcde1d7dd3037920d22c2b25ac6b7e.jpeg

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

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

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

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

データは小さなブロックで送信されるため、完全で信頼性の高いデータ送信は主に、パケットが完全かどうか、パケットのシーケンスが正常かどうか、パケットが破損していないか、パケット データが繰り返されているかどうかに反映されます。これらは、TCP チェックサム、シーケンス番号、確認応答、再送信制御、接続管理、およびウィンドウ メカニズムを通じて制御できます。

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

  • URG 緊急ポインタ

  • ACK はシーケンス番号が有効であることを確認します

  • PSH 受信側は、このセグメントをできるだけ早くアプリケーション層に配信する必要があります。

  • RST で再接続する

  • SYN 同期シーケンス番号は、接続を開始するために使用されます。

  • FIN の送信者が送信タスクを完了する

97c1a3a8cd536fbb6bab7699bd12ca11.png

送信元ポートと宛先ポート: 送信者と受信者のポート番号を識別します。TCP 接続は、送信元 IP、送信元ポート、宛先 IP、宛先ポートの 4 つの値によって確認されます。送信元 IP と宛先 IP は IP パケットに含まれます。 。

ヘッダー長: TCP ヘッダーのバイト長を示し、送信する必要のあるデータが何バイトであるかをマークすることもできます。

TCP セグメント番号: メッセージのこのセグメントで送信されるデータの最初のバイトのシリアル番号。メッセージの各セグメントのデータの各バイトにはシリアル番号があります。最初のバイトのシリアル番号は 0 から始まり、1 ずつ増加します。 1を順番に加えて、2の32乗-1を足し、また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 : TCP の 3 ウェイ ハンドシェイクを伴う接続を確立するために使用されます。

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

  2. サーバーが接続を受け入れると、TCP パケットがクライアントに送信されます。パケットには、SYN と ACK (どちらも 1) が含まれ、また、クライアントからの最初のシーケンス番号 + 1 である確認シーケンス番号も含まれます。 、接続が受け入れられたことを示します。

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

3段階目の確認パケットには、送信するデータを乗せることができる。

接続終了フラグ FIN : 接続を閉じるために使用され、一方の端がデータ送信タスクを完了すると、FIN フラグを送信して接続を終了しますが、TCP は 2 方向 (CS、SC) でデータを送信するため、各方向には自分の FIN と確認を送信するとプロセスが終了するため、4 つのウェーブとも呼ばれる 4 つのインタラクションが発生します。

  1. クライアント アプリケーション層のデータが送信されると、クライアントの TCP メッセージが FIN を送信し、サーバーにデータ送信を閉じるように指示します。

  2. サーバーはこのフラグを受信すると、シリアル番号が受信したシリアル番号に 1 を加えたものであることを確認する ACK を返し、同時に TCP はファイルの終わり文字もアプリケーションに送信します。

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

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

TCP セグメントのシーケンス番号と確認応答番号はデータの順序を保証し、データの整合性をチェックして保証します。また、緊急ポインタは緊急データが時間内に処理できることを保証します。さらに、TCP にはタイムアウト再送信、輻輳回避、およびスロー スタート メカニズムもあり、これらすべてにより、パケット データがターゲット エンドに順番に完全に送信されることが保証されます。

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

TCP グループが商品を梱包するコンテナである場合、IP はコンテナを配送するトラックです。IP プロトコルは、TCP データが送信元から端末にできるだけ早く送信されるように 2 つのノード間の接続を提供しますが、送信の信頼性は保証できません。

IP 層は、上位層から送信された TCP パケットをカプセル化し、独自のヘッダーを持ち、フラグメント化と再結合を行うかどうかのルーティングを実行し、最終的に宛先に到達します。このプロセスでは、IP ヘッダーが重要な役割を果たします。ヘッダーの構造を見てみましょう。

a1b8708c08168f83ab6633861a03e063.png

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

ヘッダー長: ヘッダー全体の長さ (最大 60 バイト)。

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

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

次の 3 つのヘッダー フィールドは、IP データグラムのフラグメンテーションと再構成のプロセスに関連しています。一般にネットワーク層は各データ フレームの最大長を制限するため、IP 層はデータグラムを送信し、ルートを選択しながら現在のデバイス ネットワーク層の各データグラムをクエリします。データ フレームの最大送信長。これを超えると、データグラムは断片化され、宛先に到着した後に再組み立てされます。このとき、次の 3 つのフィールドが再組み立ての基礎として使用されます。経路選択プロセスにより、データ フレームの最大送信長はデータグラムが通過するルーティング機器の層ごとに異なるため、経路選択プロセス中に断片化が発生する可能性があることに注意してください。

グループ ID : この ID は ID に相当し、フラグメントが正常に送信されるたびに、IP 層はグループ ID に 1 を加算します。

フラグ: R、D、M の合計 3 ビットが占有されています。R はまだ使用されておらず、D と M は有用です。このフィールドは、データグラムの断片化動作を示します。D が 1 の場合、データを断片化する必要がなく、一度で送信が完了することを意味し、M が 1 の場合、データが断片化されており、その後ろにまだデータが存在することを意味します。 0 は、現在のデータグラムが最後のフラグメントであること、またはこの 1 つのシャードだけであることを意味します。

フラグメント オフセット: 元のデータグラムの先頭から現在のフラグメントの位置を識別します。フラグメント化後、各フラグメントの合計長は、データグラム全体の長さではなく、このフラグメントの長さの値に変更されます。

Time to Live : (TTL) は、データグラムがドロップされたかどうかを決定できます。IP はデータをホップバイホップで送信するため、データはルーティング機能が設定された異なる IP 層間で転送される可能性があるため、存続時間はデータグラムが最大でいくつのルートを通過できるかを示し、データグラムがルーティング層を通過するたびに、値から 1 を引いた値。値が 0 の場合、データグラムは破棄され、エラー メッセージを含むメッセージが送信元に送信されます (IP 層のコンポーネントである ICMP は、エラー メッセージの伝達に使用されます)。Time to Live は、データグラムが常にルーティング ループ内で転送されるという問題を効果的に解決できます。

ヘッダーチェックサム: データグラムの整合性をチェックし、送信者がヘッダーを合計し、結果をチェックサムに格納し、受信者が再度計算します。計算結果がチェックサムの結果と一致する場合、送信プロセスが正常であることを意味します。 OK、そうしないとデータグラムは破棄されます。

上位層プロトコル: 受信側が処理のためにデータを渡す上位層プロトコル (TCP や UDP など) を決定します。

送信元 IP : 送信者の IP が記録され、エラー メッセージを送り返すときに使用されます。

宛先 IP : 各ルート選択の決定に使用される宛先 IP を示します。

ルーティング

IP ヘッダーには宛先 IP アドレスのみが含まれており、完全なパスは反映されていないため、データが送信されると、IP 層はローカル ルーティング テーブル内の宛先 IP のクエリ結果とデータグラムに基づいてルーティングを決定します。ホップは宛先に転送され、ここでの各ホップはルーティングの選択となります。

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

対象IPがローカルアドレスではない場合、ルーティング機能を持つIP層がどの局へ転送するかを判断する場合は?この問題を理解するには、IP 層によって維持されるルーティング テーブルの構造を理解する必要があります。

01086963fbb3113afca5a65a240c137e.png

  • 宛先 (宛先 IP): IP データグラムが最終的に到着するか通過するネットワーク アドレスまたはホスト アドレスを示します。

  • ゲートウェイ (ネクストホップ アドレス): 現在ルーティング テーブル デバイスを維持している隣接ルーターのアドレス

  • フラグ: 現在のルート レコードの属性を示します。具体的には、次の 5 つの異なるフラグで表されます。

    • U: ルートは使用できます

    • G: このフラグがある場合は、ネクスト ホップがゲートウェイであることを意味します。フラグがない場合は、ネクスト ホップが現在のデバイスと同じネットワーク セグメントにあることを意味します。つまり、データグラムを直接送信できることを意味します。

    • H:ネクストホップがホストかネットワークか、このマークがあればホスト、なければネクストホップの経路がネットワークであることを示します

    • D: ルートはリダイレクト メッセージによって作成されます

    • M: ルートはリダイレクト メッセージによって変更されました

  • インターフェイス: 現在のルーティング エントリの物理ポート

データグラムを受信するたびに、IP 層は宛先 IP に従ってルーティング テーブルにクエリを実行し、クエリのステータスに応じて 3 つの結果が得られます。

  • 宛先 IP に正確に一致するルーティング エントリが見つかり、パケットはルーティング エントリのネクストホップ ルート (ゲートウェイ) またはネットワーク インターフェイス (インターフェイス) に送信されます。

  • 宛先 IP のネットワーク番号に一致するルーティング アイテムを検索し、ルーティング アイテムのネクストホップ ルート (ゲートウェイ) またはネットワーク インターフェイス (インターフェイス) にメッセージを送信します。

  • 最初の 2 つが見つからない場合は、ルーティング テーブルにデフォルト ルーティング項目 (デフォルト) があるかどうかに依存し、存在する場合は、指定された次の停止ルート (ゲートウェイ) に送信します。

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

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

TCP はハンドシェイクを実行するときに、宛先 IP 層の最大送信単位 (MTU) に従って、TCP データが毎回送信できる最大データ サイズ (MSS) を決定し、その後、TCP はデータをグループ化します。 MSS: 各パケットは IP データグラムにパックされます。IP データグラムがルーティング処理のいずれかの層を通過する際、MTU による制限を受けてフラグメント化される場合があり、このとき、IP ヘッダーの 3 ビットのフラグ内の M フラグが 1 に設定され、IP データグラムがルーティングされていることを示します。断片化が必要です。各スライスのヘッダーは基本的に同じですが、スライスのオフセットが異なります。フラグメント オフセットに従って、これらのフラグメントは宛先で完全な IP データグラム (TCP パケット) に再組み立てされます。IP 送信の順序が乱れているため、結果のデータグラムも順序が乱れていますが、データが完全であれば、TCP はヘッダー内のフィールドに従ってデータを並べ替えます。IP フラグメントが失われ、IP 層が完全なデータグラムを形成できなくなると、TCP 層に通知され、TCP が再送信されます。

  リンク層 - ARP プロトコル  

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

ARP プロトコルは、IP アドレスから MAC アドレスへのマッピングを実装します。開始時点では、開始点はターゲットの MAC アドレスを知らず、ターゲット IP のみを認識しており、このアドレスを取得するには ARP 要求と応答が必要です。同様に、ARP にも独自のパケットがあります。まずパケットのフォーマットを確認します。

2cee7bd928212041f2ccef596297def0.png

イーサネット宛先アドレス: 宛先エンドの 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 であることを確認し、要求に送信元 IP と MAC アドレスが含まれている場合、送信元ホストへの ARP 応答で応答します。ターゲット IP が存在しない場合、リクエストは破棄されます。リクエストは外部にブロードキャストされ、応答は別の応答であることがわかります。

ただし、すべての通信の前に要求と応答のプロセスを実行することはできません。応答が正常に受信された後、IP アドレスと MAC アドレス間のマッピング関係が ARP キャッシュ テーブルにキャッシュされます。有効期間は通常 20 分です。直接カプセル化するため、完全なプロセスは次のようになります。

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

  • ターゲット IP がそれ自体と同じネットワーク セグメントにある場合、まず ARP キャッシュ テーブルに移動してターゲット IP に対応する MAC アドレスがあるかどうかを調べ、存在する場合はカプセル化して送信するためにリンク層に送信します。キャッシュテーブルにない場合はブロードキャストされ、MACアドレスを取得した後にキャッシュされ、IP層でTCPをカプセル化し、リンク層に渡してカプセル化して送信します。

  • ターゲット IP がそれ自体と同じネットワーク セグメントにない場合、パケットはデフォルト ゲートウェイに送信される必要があります。ARP キャッシュ テーブルにゲートウェイ IP に対応する MAC アドレスが存在する場合、それはカプセル化のためにリンク層に渡されて送信されます。そうでない場合は、ブロードキャストし、アドレスを取得した後にキャッシュし、IP 層で TCP をカプセル化し、リンク層に渡してカプセル化して送信します。

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

上記のものはすべて準備ができており、カプセル化されて送信されるのは実際にはイーサネット データ フレームです。イーサネット宛先アドレス、イーサネット送信元アドレス、およびフレーム タイプがフレーム ヘッダーを形成します。プリアンブルとフレーム開始デリミタもヘッダーの前に挿入され、受信者に何らかの準備をするように通知します。フレームが間違っているかどうかを検出するために、フレームチェックシーケンスFCSが最後に追加されます。

ed354871adeb2e2688dc9b64f42d5133.jpeg

プリアンブル: 受信端末のアダプタのクロック周波数が送信端末の周波数と同じになるように調整します。

フレーム開始デリミタ: フレームの開始の記号。フレーム情報が到着し、受信の準備ができていることを示します。

宛先アドレス: フレームを受信するネットワーク アダプターの MAC アドレス。受信側はフレームを受信すると、まず宛先アドレスがローカル アドレスと一致するかどうかを確認し、一致しない場合はフレームを破棄します。

送信元アドレス: 送信デバイスの MAC アドレス。

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

データ: 上位層に渡されるデータ。この記事の文脈では、これは IP データグラムを指します。

フレーム チェック シーケンス: フレームが間違っているかどうかを検出するために、送信側はフレームの巡回冗長検査 (CRC) 値を計算し、この値をフレームに書き込みます。受信側コンピュータは CRC を再計算し、FCS フィールドの値と比較します。2 つの値が同じでない場合は、送信中にデータの損失または改ざんが発生しました。このとき、フレームを再送する必要がある。

送信と受信

  • 上位層からデータグラムを受け取った後、MTUとデータグラムのサイズに応じてデータグラムを細かく分割するかどうかを決定します。これがIPデータグラムをフラグメント化するプロセスです。

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

  • イーサネット上のデバイスはフレームを受信し、フレーム内の宛先アドレスを確認し、ローカル アドレスと一致する場合、フレームは処理されてレイヤごとに渡されます(多重分離プロセス)。

エピローグ

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

過去の推薦

☞ IDC China 2022 IoT プラットフォーム評価レポート

☞ 2022年のIoTプラットフォームのトレンド:民営化

☞ モノのインターネットのスタートアップについて共有する価値のある 5 つの失敗した教訓

☞ 国内IoTプラットフォーム4社の選定と比較

☞ クラウドベンダーの【IoTプラットフォーム】は普及していない?

7de3979f21edff5597664320b66b9129.png

d9200b11b685b44aef2bfb3e4bf20f0b.gif

d788a5c856fbee730613310c696ca9fc.gif

969330fbf80e2fe871a9b498f471ba41.gif

51c1af2611e8e658b43efd197ea74d39.gif

Supongo que te gusta

Origin blog.csdn.net/klandor2008/article/details/131820839
Recomendado
Clasificación