Мне нужна помощь в понимании того, что, как я уверен, является фундаментальной концепцией в Linux: ограничение для открытых файлов. В частности, я запутался в том, почему открытые сокеты могут рассчитывать на общее количество «открытых файлов» в системе.
Может кто-нибудь уточнить, почему? Я понимаю, что это, вероятно, восходит ко всему принципу «все в файле» в Linux, но любые дополнительные подробности приветствуются.
Ответы:
Ограничение на «открытые файлы» на самом деле не только для файлов. Это ограничение на количество дескрипторов ядра, которые может одновременно использовать один процесс. Исторически единственное, что программы обычно открывали много, это файлы, поэтому это стало известно как ограничение на количество открытых файлов. Существует ограничение, позволяющее предотвратить процессы, скажем, открыв много файлов и случайно забыв их закрыть, что в конечном итоге приведет к общесистемным проблемам.
Соединение с сокетом также является дескриптором ядра. Таким образом, одни и те же ограничения применяются по тем же причинам - процесс может открыть сетевые соединения и забыть закрыть их.
Как отмечено в комментариях, дескрипторы ядра традиционно называются файловыми дескрипторами в Unix-подобных системах.
read/ write, который является основой того, что значит быть файлом.
shutdown(2)системный вызов на них, но не на файлах, и вы не можете читать из сокета с помощью cat- вот причина netcat, была создана. Я бы сказал, что (к счастью) сокеты в Unix-подобных ядрах ведут себя как файлы с точки зрения ввода / вывода, но сходство заканчивается тут же. (Честно говоря, я также хотел бы услышать от кого-то с опытом Plan 9, поскольку я слышал, что они получили объединение этих вещей дальше, чем традиционные объединения).
Причина , почему сокетов TCP / IP дескрипторы использование файлов является то , что, когда интерфейс сокетов был первым разработан и реализован ( в BSD Unix, в 1983 году ), его создатели считали , что сетевое соединение было аналогично файлу - вы можете read, writeи closeкак и что это хорошо согласуется с идеей Unix «все - файл».
Другие реализации сетевого стека TCP / IP не обязательно интегрировались с подсистемой файлового ввода-вывода их операционной системы, примером является MacTCP . Но поскольку интерфейс сокетов BSD был очень популярен, даже эти другие реализации решили реплицировать API сокетов с его Unix-подобными функциями, поэтому вы получили «файловые дескрипторы», используемые только для связи по протоколу TCP / IP, в системах, которые иначе не использовали есть файловые дескрипторы.
Другая часть вашего вопроса - почему существует ограничение? Это потому, что самый быстрый способ реализовать таблицу поиска файловых дескрипторов - использовать массив. Исторически, предел был жестко запрограммирован в ядре.
Вот код в Unix выпуск 7 (1979) с жестко заданным ограничением 20 файловых дескрипторов на процесс:
Для сравнения, Linux динамически распределяет пространство для таблицы дескрипторов файлов процесса. Абсолютный предел по умолчанию равен 8192, но вы можете установить его так, как вам нравится. Моя система списков 191072 в /proc/sys/fs/file-max.
alloc_fdtable()struct fdtable#define NR_FILE 8192Несмотря на то, что в Linux больше нет абсолютных ограничений, тем не менее, мы не хотим, чтобы программы сходили с ума, поэтому администратор (или дистрибутив дистрибутива) обычно устанавливает ограничения ресурсов. Взгляни /etc/security/limits.confили беги ulimit -n.
Файлы - это не просто файлы на диске или в памяти; это потоки данных, из которых это всего лишь два примера.
Удаленные конечные точки являются третьим примером, и вы взаимодействуете с теми, кто использует сокеты.