ICMP はレイヤー 3 より上のプロセスを使用しますか?

Question 1

アプリケーション層 (モデルに応じて 7 または 4) と 3 以下を使用します。ICMP は TCP や UDP ほど柔軟なプロトコルではないため、提供される機能セットはかなり限られています。情報処理最大サポート255 コマンドメッセージタイプ上位層プロトコルを使用してネットワーク IO をプロセスに分散するのではなく、内部的に分散します。

したがって、アプリケーションはコマンドメッセージを使用してネットワークを制御します。たとえば、Ping は ICMP パケットに適したデータ構造を作成し、それを OS に送信して IP に送信するアプリケーションです。次に、IO が返されるのを待ちます。IP スタックがエコー応答を受信すると、その IO をプログラムに渡し、プログラムがユーザーにメッセージを出力できるようになります。

TCP/IP と同様に、アプリケーション層はネットワークスタックによって提供されるすべての基本的な操作を制御および調整し、現代のユーザーにとって価値のある機能を構築します。

コード志向の人なら、このコードスニペットSO で、ICMP メッセージをリッスンし、プログラム出力に出力します。ICMP 用の「raw ソケット」を確立し、そのソケットを IP インターフェイスにバインドし (両方ともレイヤー 3 操作)、いくつかのデータ構造を確立し、ソケット IO から読み取り、応答を探します。ICMP メッセージを受信すると、そのデータ領域がプログラムの IO ストリームに表示され、画面に出力されます。これは非常に便利です。

リクエストに応じて編集します:

したがって、OSI モデルは、タスクが前提条件 (その下の層で使用されるプロトコルの特性) と満たさなければならない事後条件を持つという責任についての考え方を抽象的に表現したものです。このモデルが行うもう 1 つのことは、これらの各タスクにデータをパイプする手段を確立することです。

OSI モデルの主な目的は、アプリケーションがネットワークメッセージを簡単に送受信するための手段を記述することです。この手段はシステムの構成から抽象化され、システム間で移植可能になります。初期の頃は、アプリケーションがすべてを自分で行う必要があったため、他のプラットフォームや構成で動作するようにアプリケーションを書き直す必要がありました。責任を分離することで、プログラムは自分の仕事に集中でき、システム間で大きな違いはなくなります。さらに、システム管理者とネットワーク管理者は、アプリケーションにまったく影響を与えることなく、システムが他のシステムに接続する方法を変更できます。

OSI スタックの一番下は、システムの相互接続に不可欠なネットワーク標準に関するものです。誰もが同じ方法でこれらのことを行わなければ、何も機能しません。販売できる製品を作るために、すべてのメーカーにはこれらのルールに従う義務があります。

しかし、OS ベンダーは、自社のプラットフォームが他から抜きん出ることを妨げる厳格なルールや構造にはそれほど熱心ではありません。OSI に完全に準拠したシステムがこれまで存在しなかった理由は、OS ベンダーがそのようなシステムを開発しようとしないからです。

したがって、OSI レイヤー 1 ～ 4 は堅牢で、予測可能で、不可欠です。ただし、レイヤー 5 と 6 は完全にオプションです。アプリケーションは、必要に応じて、レイヤー 5 と 6 を利用するためのコードを作成するか、作成しないかのいずれかになります。

最近のアプリケーションのほとんどは、トランスポートプロトコルセグメントからデータを読み取るだけです。このような場合、L5/L6 用のカプセル化されたデータグラムはありません。セグメントペイロード内のデータはアプリケーションデータであるため、アプリケーションは IO ストリームを L4 ポートに接続し、そこから読み取り/書き込みを行うだけです。

ICMP の場合、Layer4 を使用しないため、アプリケーションは生の IP ソケットを読み取るだけです。概念は同じです。

レイヤー5ネットワークプロキシまたはトンネリングを必要とするアプリケーションにのみ使用されます。このデータグラムのペイロードは、多くの場合、トンネルを介して送信される別のフレームまたはパケット、または SOCKS プロキシを介してプロキシされるセグメントです。アプリケーションは通常、プロキシが動作していることを認識しないか、そのシステムに適用可能な場合は OS を使用してレイヤー 5 を処理しますが、一部の OS 上の一部のアプリケーションは、実際に L5 データグラムのカプセル化解除を制御する場合があります。多くの場合、L5 操作は、ドライバー (VPN 仮想ネットワークアダプター、システムプロキシなど) を使用してカーネルで処理されます。

注目すべきは、ほとんどのレイヤー 5 プロトコルが、アプリケーションのメッセージの送受信の要求とは無関係な相互作用を制御するために使用され、通常は通信に関与するどちらのシステムにとっても意味がないということです。通常は、2 つのシステムが通信できるようにネットワークを制御するために使用されます。実際、ほとんどの場合、アプリケーションのデータストリームは OS によって傍受され、システムアプリケーションが外部データグラムのカプセル化を処理します。そのため、アプリケーションパケットが取得され、アプリケーションが存在すら知らない他のパケットに入れられます。その時点では、システムアプリケーションがデータを制御しています。

レイヤー6実際には使用されていません。私が使用したどのプログラミングフレームワークでも、エンコードは適切なライブラリを使用してアプリケーションで処理されます。アプリケーションは、必要に応じて OS のエンコーダ/デコーダを使用したり、独自のエンコーダ/デコーダを提供したりして、レイヤー 6 操作を記述できますが、私の経験では、これは通常アプリケーションによって処理され、データグラムのカプセル化には影響しません。

つまり、結局のところ、これらすべては、ネットワークがどのように機能するかをほとんど事前に知らなくても、ネットワーク経由でメッセージを送受信するために、アプリケーションに読み取りおよび書き込み可能な IO ストリームを提供することを目的としています。これが、現代のネットワークの 100% の目的です。

システムがシステム全体のプロキシまたは VPN を使用する場合、通常は L5 データグラムが自動的にカプセル化されるため、送信アプリケーションはデータグラムの存在すら認識しません。受信側では、プロキシサーバーまたは VPN エンドポイントによって処理されているため、受信時には L5 ヘッダーがすでに削除されているため、リモート OS はレイヤー 4 ペイロードからデータをアプリケーションにパイプするだけです。

したがって、特定のパケットには、ジョブを実行するために必要な数のレイヤーのみがカプセル化されます。レイヤー 2 のみで動作し、L3+ コンポーネントを含まない低レベルのアプリケーションがあります。L4+ を使用しないインターネットワークレイヤーアプリケーションがあり、それらのアプリケーションは、それより上位のレイヤー (ICMP など) をカプセル化しません。操作するレイヤーより下のレイヤーはすべて必要ですが、それより上のレイヤーは必要ありません。最も一般的なアプリケーションは、レイヤー 4 での読み取りと書き込みに重点を置き、必要に応じてレイヤー 5 と 6 については OS に任せます。

最後に、あなたが混乱している理由と、このトピックに関する適切な情報を見つけるのが難しい理由が理解できます。すべてを本当に理解するには、ネットワーク、アプリケーションプログラミング、および OS 設計についてある程度理解する必要があります。そのため、すべてが機能する仕組みを十分に理解していると感じるまでに何年もかかりました。

Answer