TCP / IPソケットが「オープンファイル」と見なされるのはなぜですか？
Linuxの基本的な概念であると確信しているもの、つまりオープンファイルの制限を把握するための支援が必要です。特に、オープンソケットがシステム上の「オープンファイル」の総数にカウントされる理由について、私は混乱しています。
誰かが理由を詳しく説明してもらえますか？これはおそらくLinuxの「すべてがファイルである」という原則に帰着することを理解していますが、追加の詳細があれば幸いです。
「ファイルを開く」の制限は、実際にはファイルだけではありません。 カーネルハンドルの数の制限です。1つのプロセスが一度に使用できます。歴史的に、プログラムが通常多くのファイルを開くことができるのはファイルだけだったため、これは開いているファイルの数の制限として知られるようになりました。多くのファイルを開き、誤ってそれらを閉じるのを忘れてプロセスが発言するのを防ぐのに役立つ制限があり、最終的にシステム全体の問題を引き起こします。
ソケット接続もカーネルハンドルです。したがって、同じ制限が同じ理由で適用されます-プロセスがネットワーク接続を開いて、それらを閉じるのを忘れる可能性があります。
コメントに記載されているように、カーネルハンドルは伝統的にファイル記述子と呼ばれます。
TCP/IPソケットがファイル記述子を使用する理由は、ソケットインターフェイスが最初に設計および実装されたとき（ BSD Unixでは、 198 ）、その設計者は、ネットワーク接続はファイルに類似していると感じました-read、write、およびcloseの両方が可能であり、それはうまく適合します「すべてがファイルである」というUnixの考えで。
他のTCP/IPネットワークスタックの実装は、必ずしも MacTCP のように、OSのファイルI/Oサブシステムと統合されていませんでした。しかし、BSDソケットインターフェースは非常に人気があったため、これらの他の実装でさえ、Unixのような機能でソケットAPIを複製することを選択したため、TCP/IP通信にのみ使用される「ファイル記述子」を、他の方法では使用しなかったシステムで取得しました。ファイル記述子があります。
あなたの質問の他の部分は、なぜ制限があるのですか？ファイル記述子ルックアップテーブルを実装する最も速い方法は配列を使用するためです。従来、この制限はカーネルにハードコードされていました。
これは、Unixリリース7（1979）のコードで、プロセスごとに20個のファイル記述子をハードコード化して制限しています。
対照的に、Linuxはプロセスのファイル記述子テーブルに動的にスペースを割り当てます。絶対制限のデフォルトは8192ですが、これを好きなように設定できます。私のシステムは_/proc/sys/fs/file-max_に191072をリストしています。
Linuxには絶対的な制限はありませんが、プログラムを狂わせたくないので、管理者（またはディストリビューションパッケージャ）は通常、リソースの制限を設定します。 _/etc/security/limits.conf_を確認するか、_ulimit -n_を実行します。
ファイルは、ディスクまたはメモリ内のファイルだけではありません。それらはデータのストリームであり、そのうちの2つは例にすぎません。
リモートエンドポイントは3番目の例であり、ソケットを使用してそれらと対話します。