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

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

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

С точки зрения разработчика программного обеспечения (в отличие от клиента для веб-серверов), работает ли в режиме ядра интеллектуальное решение по производительности? Можно ли смягчить проблемы безопасности при разработке приложений, чтобы сделать сервер режима ядра чистой прибылью для потребителя?

— Джеймс Мишра
источник

«Ошибка сервера - это сайт вопросов и ответов для системных и сетевых администраторов». Системные администраторы и сетевые администраторы не пишут веб-серверы; они устанавливают и поддерживают их. Я думаю, что вопрос режима ядра / режима пользователя гораздо более актуален во время разработки, чем во время установки. Я не против, чтобы вопрос был перенесен куда-то более актуально, но я чувствую, что ошибка сервера не найдет его и по теме.

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

Хорошо, перечитывая вопрос еще раз, я думаю, что его можно интерпретировать как вопрос об общей архитектуре программного обеспечения, а не как вопрос о плюсах и минусах существующих веб-серверов, поэтому я отказался от своего близкого голоса. Но вы можете отредактировать свой вопрос, чтобы выделить общий аспект архитектуры программного обеспечения.

— Док Браун

Любой, кто думает, что веб-сервер в режиме ядра может улучшить производительность, так как ему не нужно переключать контекст, должен прочитать: числа задержек, которые должен знать каждый программист . Полное переключение контекста в Linux стоит около 3000 нс ( исходный код ), но многие системные вызовы на самом деле не нуждаются в полном переключении контекста и могут стоить всего 50 нс, у меня нет номеров для Windows. Это где-то вдоль 2-го / 3-го столбца. Вывод: минимизируйте сетевой запрос и диск, не беспокойтесь о переключениях контекста.

— Ли Райан

Ответы:

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

Это работает так, что вы регистрируете URL-адрес с ним и соответствующим приложением, и, когда на порт 80 делается запрос http, http.sys принимает его, но затем передает запрос любому приложению, зарегистрированному для обработки этого целевого URL-адреса.

Я сомневаюсь, что веб-сервер в режиме ядра имеет какой-то смысл - даже если производительность сокетов может быть улучшена таким образом, для выполнения какой-либо полезной работы логика приложения по-прежнему будет выполняться в пространстве пользователя, поэтому всегда есть переход - вы Мы просто переместили его вдоль стека вызовов.

— gbjbaanb
источник

Основное преимущество полноценного сервера в режиме ядра заключается в обслуживании статических файлов: это можно сделать без переключения в режим пользователя. Кеширование также возможно.

— Жюль

Я думаю, что HTTP.sys - это время, когда циклы ЦП были гораздо более скудными ... Даже при обслуживании небольших статических файлов (что является наиболее выгодным случаем для HTTP.sys), HTTP-сервер в полностью пользовательском режиме, вероятно, будет максимально использовать большинство сетей. ,

— usr

@usr Http.sys - это относительно новая вещь, появившаяся в Windows Server 2003. Я уверен, что она есть, так что вы можете одновременно запускать множество служб веб-API, прослушивающих порт 80.

— gbjbaanb

@gbjbaanb сервер пользовательского режима тоже может это учитывать. Windows имеет возможность совместно использовать память (для буферов) и передавать дескриптор сокета другому процессу.

— USR

@JamesMishra На мой взгляд, да. Тогда процессоры, вероятно, были в 10 раз менее мощными. Кроме того, мышления безопасности не было на самом деле. Сегодня это просто плохой звонок.

— usr

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

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

— Жюль
источник

Большая проблема с подходом Singularity состоит в том, что это означает, что но в JITter может легко привести к повышению привилегий.

— CodesInChaos

Статья Tux Wikipedia - интересное чтение. 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 снижает риск, поскольку существует такое четкое разделение ниже «низкого уровня» веб-обслуживания и кода приложения.

В правильно спроектированной установке компьютер (или виртуальный сервер), на котором работает веб-сервер, имеет очень ограниченный доступ к остальной части сети, поскольку это является целью высокого риска. Если ядро или веб-сервер пользовательского режима взломаны, то это мало что меняет, поскольку у сервера больше не должно быть «прав» в сети, тогда процесс пользовательского режима веб-сервера должен выполнять свою работу.

— Ян
источник

Приложения пользовательского режима часто пишутся на типобезопасных языках, что исключает большинство ошибок, связанных с повреждением памяти (обычно это те, которые приводят к удаленному выполнению кода).

— CodesInChaos

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

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