Linuxの基本概念であるオープンファイルの制限を理解するのに役立ちます。特にオープンソケットがシステムの「オープンファイル」の総数に含まれるのはなぜか混乱しています。
なぜそれを詳しく説明できる人がいますか？私はこれがおそらくLinuxの「すべてがファイルです」という原則全体に戻ることを知っていますが、追加の詳細があれば大いに感謝します。
答え1
「ファイルを開く」制限は、実際にはファイルにのみ適用されるものではありません。数量制限カーネルハンドル単一のプロセスを同時に使用できます。歴史的に、プログラムはしばしば多数のファイルを開いていたので、これは開かれたファイルの数に対する制限として知られています。制限を設定すると、プロセスで大量のファイルを開いたり、誤ってそのファイルを閉じたりすることを忘れて、最終的にシステム全体に問題が発生する可能性がある状況を回避できます。
ソケット接続はカーネルハンドルでもあります。したがって、同じ制限が同じ理由で適用されます。つまり、プロセスがネットワーク接続を開閉するのを忘れる可能性があります。
コメントで指摘したように、カーネルハンドルは伝統的に呼び出されます。ファイル記述子Unixシリーズシステムで。
答え2
理由TCP/IP ソケットがファイル記述子を使用する理由さて、ソケットインタフェースが最初に設計され実装されたとき（BSD Unix、1983）、デザイナーはネットワーク接続をファイルに似ていると考えました。 、 、 と両方が可能で、read「writeすべてcloseがファイルです」というUnix哲学によく合います。
他のTCP / IPネットワークスタックの実装は、必ずしもオペレーティングシステムのファイルI / Oサブシステムと統合されるわけではありません。MacTCP。しかし、BSDソケットインタフェースは非常に人気があるため、これらの他の実装でさえ、Unixと同様の機能を使用してソケットAPIを複製することを選択したため、システム内のTCP / IP通信にのみ使用される「ファイル記述子」が得られます。ファイル記述子があります。
質問の他の部分はなぜ制限があるのですか？ファイル記述子ルックアップテーブルを実装する最速の方法は、配列を使用することです。歴史的に、この制限はカーネルにハードコードされています。
以下は、1プロセスあたり20個のファイル記述子にハードコードされた制限を持つUnixリリース7（1979）のコードです。
対照的に、Linux はプロセスのファイル記述子テーブルにスペースを動的に割り当てます。絶対制限のデフォルト値は 8192 ですが、必要な値に設定できます。私のシステムは/proc/sys/fs/file-max。
- ファイルシステム/file.c:
alloc_fdtable() - FDTable.h:
struct fdtable - FS.h:
#define NR_FILE 8192
Linuxには絶対的な制限はありませんが、プログラムを中断したくないので、管理者（または配布パッケージの作成者）はしばしばリソース制限を設定します。見たり/etc/security/limits.conf走ったりしてくださいulimit -n。
答え3
ファイルは、ディスクまたはメモリ内の単純なファイルではなくデータストリームです。これは2つの例です。
リモートエンドポイントは3番目の例であり、ソケットを使用してリモートエンドポイントと対話できます。