Кестрел против IIS + Кестрел (обратный прокси) против Nginx - PullRequest
0 голосов
/ 15 апреля 2019

Когда я исследовал хостинг механизма ядра .NET, я увидел этот комментарий на многих форумах и веб-сайтах: «Microsoft предлагает всегда использовать любой веб-сервер перед Kestrel для веб-сайтов». Зачем? Из-за проблем с безопасностью? Я удивился, потому что, если kestrel используется отдельно, производительность в секунду лучше, чем IIS + Kestrel?

1 Ответ

0 голосов
/ 24 июля 2019

@ RickStrahl написал этот приятный пост Ядро ASP.NET в процессном хостинге на IIS с ASP.NET Core 2.2 , в котором обсуждается хостинг InProcess в IIS, который доступен с ASP.NET 2.2.

Там он также упомянул, почему хорошо иметь веб-сервер перед Kestrel.

Короче говоря, встроенный веб-сервер Kestrel в ядре ASP.NET не предназначен для веб-сервера с выходом в Интернет, а скорее выступает в качестве сервера приложений или пограничного сервера, который выполняет очень специфические задачи обработки данных. Kestrel оптимизирован для сценариев приложений, но не оптимизирован для других целей, таких как статическая обработка файлов или управление временем жизни сервера

По этой причине вы обычно не хотите запускать Kestrel непосредственно в веб-приложении. Это верно для Windows с IIS, а также для Linux, где вы склонны использовать веб-сервер nginx или ha-proxy для решения проблем, не связанных с приложениями. Я написал о том, как настроить правила перезаписи IIS для маршрутизации общих статических файлов, а не позволять Kestrel обрабатывать их. Речь идет не только о скорости, но и позволяет вашему веб-приложению сосредоточиться на выполнении динамических задач, для которых оно предназначено, а IIS выполняет работу, для которой оно было разработано.

Вот несколько аргументов о том, почему вы хотите использовать полноценный веб-сервер, а не запускать приложение, напрямую подключенное к сети:

  • Совместное использование портов В настоящее время Kestrel не может осуществлять совместное использование портов так же, как IIS и http.sys в Windows. В настоящее время эта функциональность поддерживается только через IIS в Windows. (AFAIK, вы даже не можете использовать сервер HttpSys для этого). Кроме того, хотя в ASP.NET Core можно использовать маршрутизацию заголовков узлов, в настоящее время это не совсем легко или просто настроить.

  • Управление жизненным циклом Если вы запустите свое приложение без какой-либо инфраструктуры поддержки, любой сбой или сбой приведет к закрытию приложения и отключению вашего сайта. Независимо от того, что вам нужно, вам нужен какой-нибудь монитор хоста, чтобы гарантировать, что ваше приложение продолжит работу, если оно выйдет из строя, и IIS предоставит его из коробки. Преимущество ASP.NET Core с модулем ASP.NET Core заключается в возможности перезапуска пулов приложений, которые могут перезапустить ваше приложение при сбоях.

  • Статическое обслуживание файлов Kestrel не очень хорошо справляется со статической обработкой файлов, и по сравнению с оптимизированной инфраструктурой кэширования и сжатия статических файлов IIS Kestrel сравнительно медленный. IIS полностью использует преимущества кэширования в режиме ядра и встроенную инфраструктуру сжатия, которая гораздо эффективнее, чем сегодняшний обработчик статических файлов ASP.NET (".UseStaticFiles ()").

Существуют дополнительные причины: безопасность и усиление безопасности сервера, функции администрирования, управление сертификатами SSL, полная регистрация и средства трассировки Http-запросов, и этот список можно продолжить. Все веские причины, чтобы сидеть за выделенной платформой веб-сервера, а не запускать и управлять экземпляром собственного сервера.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...