Веб-сервери в режимі ядра: розумна оптимізація чи кошмар безпеки?

Я читав тему новин Hacker News, де один користувач розміщує посилання з 2011 року, пояснюючи, що IIS набагато швидше, ніж більшість інших (* nix) веб-серверів. Інший користувач відповідає, пояснюючи, що IIS отримує цю перевагу, маючи модуль ядра під назвою HTTP.sys . Наскільки мені відомо, більшість інших популярних веб-серверів 2015 року цього не роблять.

Я ніколи не хотів би писати веб-сервер в режимі ядра, тому що я ніколи не міг довіряти собі, щоб зробити це звільненим від подвигів безпеки (що було б менш серйозним запуском у нижньому захисному кільці).

З точки зору інженера-програмного забезпечення (на відміну від клієнта для веб-серверів), чи працює в режимі ядра розумне рішення про продуктивність? Чи можна пом'якшити проблеми щодо безпеки при розробці додатків до того, щоб сервер режиму ядра став чистим прибутком для споживача?

— Джеймс Мішра
джерело

"Помилка сервера - це сайт із запитаннями та відповідями для системних та мережевих адміністраторів." Sysadmins та мережеві адміністратори не пишуть веб-серверів; вони встановлюють і підтримують їх. Я думаю, що питання режиму ядра / режиму користувача набагато актуальніше на час розробки, ніж час установки. Я не проти того, щоб питання перенесли кудись більш актуальним, але я відчуваю, що помилка сервера теж не знайде його на тему.

— Джеймс Мішра

Гаразд, перечитавши це питання ще раз, я думаю, що це можна трактувати як загальне питання архітектури програмного забезпечення, а не як питання про плюси та мінуси існуючих веб-серверів, тому я відмовився від мого близького голосу. Але ви можете відредагувати своє питання, щоб виділити загальний аспект архітектури програмного забезпечення.

— Док Браун

Кожен, хто думає, що веб-сервер у режимі ядра міг би підвищити продуктивність, оскільки йому не потрібно перемикатися на контекст, слід прочитати: Номери затримки, які повинні знати всі програмісти . Повний контекстний комутатор в Linux коштує близько 3000 нс ( джерело ), але багатьом системним дзвінкам насправді не потрібен повний контекстний комутатор і він може бути низьким, як 50н, у мене немає номерів для Windows. Це десь уздовж 2-ї / 3-ї колонки. Висновок: мінімізуйте мережевий запит та диск, не турбуйтеся про контекстні комутатори.

— Лі Лі Раян

Відповіді:

Http.sys - це не стільки веб-сервер, скільки проксі-експедитор. Його розроблено для того, щоб у вікні Windows спільно існувало багато веб-серверів, тому у вас може бути IIS, який працює на веб-сайті, а також кілька служб WCF, що працюють з інтерфейсами http / REST або SOAP, і все це на стандартному порті 80. (саме тому ви не можна запустити Apache в Windows без невеликих дріжджів, Apache не було змінено для роботи з цією системою реєстрації, прикро, що він не став більш прозорим для додатків і вимагає деяких досить складних модифікацій, щоб підключити його).

Як це працює, ви реєструєте URL-адресу з нею та відповідну програму, а коли http-запит зроблено на порт 80, http.sys приймає його, але потім передає запит на те, що зареєстрована програма для обробки цієї цільової URL-адреси.

Я сумніваюся, що веб-сервер у режимі ядра має сенс - навіть якщо продуктивність сокета може бути покращена таким чином, для виконання будь-якої корисної роботи логіка програми все одно буде виконуватися в просторі користувача, тому завжди є перехід - ви ' я трохи змістив його вздовж стопки дзвінка.

— gbjbaanb
джерело

Основна перевага повного сервера в режимі ядра полягає в обслуговуванні статичних файлів: це можна зробити без переходу на режим користувача. Також можливе кешування.

— Жуль

Я думаю, що HTTP.sys - це час, коли цикли процесора були набагато дефіцитнішими ... Навіть при обслуговуванні невеликих статичних файлів (що є найвигіднішим випадком для HTTP.sys) сервер HTTP повністю користувальницького режиму, ймовірно, максимум у більшості мереж .

— usr

@usr Http.sys - це відносно нова річ, представлена в Windows Server 2003. Я впевнений, що її існує, тому ви можете одночасно запускати багато служб веб-API, слухаючи порт 80.

— gbjbaanb

@gbjbaanb сервер режиму користувача також може це дозволити. Windows має можливість ділитися пам'яттю (для буферів) та передавати ручку сокета іншому процесу.

— usr

@JamesMishra На мій погляд, так. Тоді процесори, ймовірно, були> 10x менш потужними. Крім того, міркувань щодо безпеки насправді не було. Сьогодні це лише поганий дзвінок.

— usr

Http.sys - не єдиний доступний веб-сервер у режимі ядра: під Linux є також tux . Як ви правильно визначили, безпека викликає занепокоєння з такими типами серверів, що призвело до того, що tux не включається до основного ядра Linux (і я вважаю, що не оновлюється для останніх версій ядра).

Кращим рішенням буде використання операційної системи, яка не покладається на апаратний захист для забезпечення безпеки процесу, наприклад, особливості Microsoft: така система дозволила б підвищити ефективність роботи сервера в режимі ядра без ризиків для безпеки. На жаль, жодні операційні системи, готові до виробництва, засновані на цьому принципі, не доступні станом на 2015 рік, і AFAIK ніхто над цим серйозно не працює (проект Singularity був скасований).

— Жюль
джерело

Велика проблема підходу до сингулярності полягає в тому, що це означає, що, але в JITter легко може призвести до ескалації привілеїв.

— CodesInChaos

Стаття Вікіпедії Tux - цікаве прочитання. Tux може пересилати HTTP-запити на нестатичний вміст на "справжній" веб-сервер, наприклад Apache, який звучить як те, для чого використовується Http.sys. Я не можу сказати, чи був Tux таким ефективним, як Http.sys, але, виходячи з того, що мало читаю, це здається, що розробники ядра Linux різко не погоджуються з рішенням Microsoft.

— Джеймс Мішра

Http.sys є низьким ризиком, оскільки він не може виконувати будь-яку копію, надану третьою стороною.

Http.sys виконує кілька завдань.

Він виконує функцію переадресації проксі-сервера, завдяки чому багато процесів можуть відповідати на запит у різні частини простору імен HTTP. Відповідь gbjbaanb це добре висвітлює.
Він обслуговує статичні файли безпосередньо з кешу файлів Windows. Це забезпечує велике прискорення статичних файлів невеликих файлів, оскільки немає контекстних комутаторів.
Він буде кешувати вихід з будь-якої програми, на яку він пересилає HTTP-запит, і повертає кешований результат. Додаток перебуває в повному контролі над тим, як довго (якщо є) триває кешування.

Http.sys призначений для виконання простих завдань ДУЖЕ швидко, передаючи все інше процесу в просторі користувача.

У відповідь на коментар

"низький ризик, оскільки він не може запустити будь-який код, наданий третьою стороною" - Це те, що вони завжди говорять, і це майже ніколи не відповідає дійсності.

Проблема полягає в тому, що ви повинні довірити Microsoft написати складний код ядра, щоб задати це питання, інакше ви вирішите взагалі не використовувати Windows для веб-хостингу . Http.sys додає дуже мало ризику помилок ядра, враховуючи, наскільки складним є ядро.

Якщо що-небудь Http.sys знижує ризик, оскільки існує чітке розділення нижче "низького рівня" веб-сервісу та коду програми.

У добре продуманій установці машина (або віртуальний сервер), який працює з веб-сервером, має дуже обмежений доступ до решти мережі, оскільки це ціль з високим ризиком. Це дуже сильно відрізняється, якщо ядро або веб-сервер в режимі користувача зламано, оскільки сервер не повинен мати більше «прав» в мережі, тоді процес користувачу в режимі користувача веб-сервера повинен виконувати свою роботу.

— Ян
джерело

Програми Usermode часто пишуться на безпечних мовах, що виключає більшість помилок на основі пошкодження пам'яті (це, як правило, ті, що призводять до віддаленого виконання коду).

— CodesInChaos

Я не впевнений, чи купую я аргумент, що якщо я довіряю Microsoft писати код ядра, це невеликий стрибок довіряти їм писати код веб-сервера в режимі ядра. Я досить наївний з точки зору інформаційної безпеки, але гадаю, що набагато простіше озброїти переповнення буфера в Http.sys, ніж у драйвері пристрою чи якійсь іншій частині ядра далі від Інтернету.

— Джеймс Мішра