私が知っている限り、AF_NETLINKソケットプロトコルはカーネルとユーザースペース間の通信に使用され、AF_UNIXは2つのユーザースペースプロセス間の通信に使用されます。
Linuxに別々のAF_NETLINKが必要なのはなぜですか？カーネルとユーザー間の通信にUNIXソケットを使用できないのはなぜですか？
答え1
原産地とデザインの特徴が異なります。プロトコルを最初から設計する方が良い考えです。これは、レガシープロトコルの問題を経験することなく、ニーズに合わせて特別にカスタマイズできるためです。
私は、これらの選択は、UNIXドメインソケットのカーネル実装がユーザーのカーネル通信に適切に移植するにはあまりにも異なるためだと思います。 AF_NETLINKのプロトコルリストは、ioctlと同様の制御を提供するように特別に設計されています。 AF_UNIXは、socket関数の「プロトコル」パラメータも使用しません。別のプロトコルを許可するように定義を拡張した場合、既存のアプリケーションがクラッシュする可能性があり、カーネルの新しいプロトコルをカーネル制御コードにリダイレクトするのは非常に厄介です。この2つの機能を重ねることもセキュリティリスクになる可能性があります（特にAF_UNIXはもともとこれを念頭に置いて設計されていないため）。
最後に、UNIXドメインソケットはファイルシステムを名前空間として使用します（「匿名」ソケットを許可するハックがありますが）。したがって、そのソケットに対する権限を持つすべてのユーザーはすぐに使用できます。カーネルと通信するには、ユーザーが使用できるファイルシステム（おそらくsys？）のどこかに常に開いている「ファイル」が必要です。カーネルに接続します。
簡単に言えば、彼らは他の目的にのみ使用されます。 2つのユーザースペースプロセスに対してAF_NETLINKを再利用できますが（AF_UNIXとは異なります）、その逆は実際には機能しません。