Мені потрібна допомога, яка сприймає те, що я впевнений, що це основна концепція в Linux: ліміт відкритих файлів. Зокрема, мене бентежить питання, чому відкриті сокети можуть рахувати загальну кількість "відкритих файлів" у системі.
Може хтось, будь ласка, детальніше пояснив причину? Я розумію, що це, ймовірно, стосується всього принципу "все є файлом" в Linux, але будь-які додаткові деталі будуть вдячні.
Відповіді:
Обмеження на "відкриті файли" насправді не лише для файлів. Це обмеження на кількість ручок ядра, якими може користуватися один процес одночасно. Історично єдине, що програми зазвичай відкривали багато файлів, тому це стало відомо як обмеження кількості відкритих файлів. Існує обмеження, яке допоможе запобігти процесам, скажімо, відкрити безліч файлів і випадково забути їх закрити, що з часом спричинить загальносистемні проблеми.
Підключення до гнізда - це також ручка ядра. Тож ті самі обмеження діють з тих же причин - це можливо, щоб процес відкривав мережеві з'єднання і забував їх закрити.
Як зазначається в коментарях, ручки ядра традиційно називають дескрипторами файлів у Unix-подібних системах.
read/ writeінтерфейс, який є серцем того, що означає бути файлом.
shutdown(2)системний виклик на них, але не у файлах, і ви не можете читати з сокета за допомогою cat- ось причина netcatстворена. Я б сказав, що (на щастя) сокети в ядрах, схожих на Unix, ведуть себе як файли з точки зору вводу-виводу, але подібність закінчується саме там. (Чесно кажучи, я також хотів би почутись від когось із досвідом Плану 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.
Файли - це не просто файли на диску чи пам'яті; це потоки даних, з яких - лише два приклади.
Віддалені кінцеві точки - третій приклад, і ви взаємодієте з тими, хто використовує сокети.