汎用ソケットとは何ですか？それはネットワークデバイスとどのように関係しますか？

Question

Linuxでネットワークドライバーがどのように機能するかを理解しようとしています。このQ＆A は、Linuxのネットワークデバイスがデバイスファイルで表されていないことを示しています。ネットワークドライバーはsocketsで動作すると記載されています。

たとえば、 this は、ioctl呼び出しを介してネットワークデバイスをセットアップする方法を示します。 ioctlただしファイル記述子が必要、ネットワークドライバー用のデバイスファイルがない場合、渡すことができるファイル記述子はソケットからのものだけです。

これは私に問題のポイントをもたらします。これまでのところ、物理ネットワークカードのソフトウェア表現であるネットワークインターフェイスは、実際にはソケットよりも劣っているオブジェクトのようです。

しかし、この抽象的な意味でのソケットとは何ですか？それは、プッシュ通知をサポートするデバイスファイルの単なる別名ですか？ TCPソケットは、ユーザースペースアプリによってネットワークインターフェースのアドレス：ポートのペアにバインドされた接続ポイントに関して理解しています。ソケットをネットワークインターフェースをセットアップするための前提条件として理解していません。。
Linux上のネットワークインターフェース（ifconfigでリストされるeth0など）は、ソケットなしで存在できますか？
ifconfigまたは一部のネットワークマネージャーデーモンは、ソケットを開いたままにして、ネットワークインターフェイスオプションを設定できるようにしますか？

dirkt · Accepted Answer

デバイスファイルを簡単に確認してみましょう。Linuxでは、アプリケーションプログラムはradと書き込み操作をファイル記述子を介してカーネルに送信します。これはファイルに最適であり、文字のストリームを生成および消費するキャラクターデバイス、およびブロックデバイスは、ランダムアクセスアドレスで固定サイズのブロックを読み書きするもので、これらもファイルであるかのように振る舞います。

しかし、これらのデバイスを構成する方法（ボーレートの設定など）が必要であり、そのためにioctl呼び出しが発明されました。デバイスに固有のデータ構造とカーネルに使用されるI/O制御の種類を渡し、同じデータ構造で結果を取得するだけなので、非常に一般的な拡張可能なAPIであり、多くのことに使用できます。。

では、ネットワーク運用はどのように適合するのでしょうか。典型的なネットワークサーバーアプリケーションは、特定のポート（たとえば、HTTPの場合は80、22の場合は80）でlistenをbindして、 sshの場合）、そしてクライアントが接続する場合、sendデータをreceiveこのクライアントからのデータ。そして、クライアントのための二重の操作。

これをファイル操作に適合させる方法は明らかではありません（それは可能ですが、プラン9 を参照してください）。これが、UNIXデザイナーが新しいAPIを発明した理由です：ソケット。 socket、bind、listen、connect、sendおよびrecv。ファイルI/O APIとは異なりますが、socket呼び出しはファイル記述子も返します。 Webでソケットを使用する方法に関するチュートリアルは多数あります。

これまでのところ、これはすべて純粋なUNIXであり、ソケットが発明された当時、誰もネットワークインターフェイスについて話していませんでした。また、このAPIは非常に古いため、インターネットプロトコル以外のさまざまなネットワークプロトコル用に定義されています（AF_*定数）。ただし、Linuxでサポートされるのはごくわずかです。

しかし、コンピューターが複数のネットワークカードを取得し始めたので、これに対するいくつかの抽象化が必要でした。 Linuxでは、これはネットワークインターフェイス（NI）です。これは、ハードウェアの一部だけでなく、さまざまなトンネル、OpenVPNなどのトンネルとして機能するユーザーアプリケーションエンドポイントにも使用されます。説明したように、ソケットAPIは（特別な）ファイルに基づいておらず、ファイルシステムに依存しません。同様に、ネットワークインターフェースもファイルシステムに表示されません。ただし、NIは/procおよび/sysファイルシステム（および他のネットワーク調整パラメータ）。

NIは、ネットワークパケットがカーネルに出入りするエンドポイントの単純なカーネル抽象化です。一方、ソケットは、アプリケーションとパケットを通信するために使用されます。パケットの処理にソケットを含める必要はありません。たとえば、転送が有効になっている場合、パケットはあるNIに入り、別のNIから出ることがあります。その意味で、ソケットとネットワークインターフェイスは完全に独立しています。

しかし、ブロックデバイスとキャラクターデバイスを構成する方法が必要だったのと同じように、NIを構成する方法が必要でした。また、ソケットはすでにファイル記述子を返していたため、そのファイル記述子でioctlを許可することは多少論理的でした。それはあなたがリンクしたnetdeviceインターフェースです。

パケットフィルタリング、パケットキャプチャなど、同様の方法でシステムコールが悪用されることは他にも多数あります。

これらすべてが次々に成長しており、多くの場所で特に論理的ではありません。それが一度にすべて設計されていれば、おそらくより直交するAPIを作成できたはずです。