TCP / IPソケットが「オープンファイル」と見なされるのはなぜですか？

Linuxの基本概念であると確信していること、つまりオープンファイルの制限を把握するための支援が必要です。特に、開いているソケットがシステム上の「開いているファイル」の総数にカウントされる理由について混乱しています。

誰かがその理由を詳しく説明してもらえますか？これはおそらくLinuxの「すべてがファイルである」という原則全体に戻っていることを理解していますが、追加の詳細は歓迎されます。

「ファイルを開く」制限は、実際にはファイルだけではありません。これは、1つのプロセスが一度に使用できるカーネルハンドルの数の制限です。歴史的に、プログラムが通常多くのファイルを開くのはファイルだけだったため、これは開いているファイルの数の制限として知られるようになりました。プロセスが多くのファイルを開き、誤ってそれらを閉じるのを忘れることを防ぐための制限があり、これは最終的にシステム全体の問題を引き起こします。

ソケット接続もカーネルハンドルです。そのため、同じ制限が同じ理由で適用されます-プロセスがネットワーク接続を開き、それらを閉じるのを忘れる可能性があります。

コメントで述べたように、カーネルハンドルは伝統的にUnixライクなシステムではファイル記述子と呼ばれます。

理由はなぜTCP / IPソケットを使用しているファイルディスクリプタのソケットインタフェースは最初に（設計・実装されたとき、つまり1983年に、BSD Unixの中ですることができます- ）、その設計者は、ネットワーク接続がファイルに類似していたことを感じたread、writeとcloseの両方、そして、それは「すべてがファイルである」というUnixの考えにうまく適合するだろう。

他のTCP / IPネットワークスタック実装は、OSのファイルI / Oサブシステムと必ずしも統合されませんでした。例はMacTCPです。しかし、BSDソケットインターフェイスは非常に人気があったため、これらの他の実装でさえ、ソケットAPIをUnixライクな関数で複製することを選択したため、TCP / IP通信にのみ使用される「ファイル記述子」を取得しました。ファイル記述子があります。

あなたの質問の他の部分は、なぜ制限があるのですか？ファイル記述子のルックアップテーブルを実装する最も簡単な方法は配列を使用するからです。従来、制限はカーネルにハードコーディングされていました。

UNIXリリース7（1979）のコードは、プロセスごとに20個のファイル記述子をハードコーディングしています。

• user.h：struct file *u_ofile[NOFILE]
• param.h：#define NOFILE 20

比較すると、Linuxはプロセスのファイル記述子テーブルにスペースを動的に割り当てます。絶対制限のデフォルトは8192ですが、これを任意に設定できます。私のシステムは191072をリストしています/proc/sys/fs/file-max。

• fs / file.c：alloc_fdtable()
• fdtable.h：struct fdtable
• fs.h：#define NR_FILE 8192

Linuxには絶対的な制限はありませんが、それでもプログラムを狂わせたくないので、管理者（またはディストリビューションパッケージャー）は一般にリソース制限を設定します。をご覧になる/etc/security/limits.confか、実行してくださいulimit -n。

ファイルは、ディスクまたはメモリ内のファイルだけではありません。それらはデータのストリームであり、そのうちの2つの例にすぎません。

リモートエンドポイントは3番目の例であり、ソケットを使用してエンドポイントと対話します。