Kestrel web server linux

Creating your first .NET Core project on Linux

And configuring Kestrel for a web environment

This post is the first of a series in which we’ll discuss about the experience of developing and running .NET web applications in Linux environments.

Introduction to .NET Core

.NET Core is an opensource, multiplatform version the .NET Framework which is officially supported and maintained by Microsoft.

This post will give an overview of how to run a .NET Core web project in Ubuntu, starting with its basic architecture and ending in the configuration of Kestrel for creating a web application.

.NET Core framework already provides scaffolding tools for bootstrapping your projects, but this time we’ll develop this from scratch starting from a basic console application.

Installing .NET Core on Linux

We’ll install .NET Core in Ubuntu, following Microsoft’s official website, but you can find installation instructions for most common distros. As a development IDE you can use any text editor, but we are going to use Visual Studio Code which, in my opinion, offers the best integration.

Creating my first “Hello world” in C # .NET Core

From the command console run these commands:

• dotnet new console (to create a console project in .NET Core)
• dotnet restore (to restore packages and project dependencies)
• dotnet run (to execute our code).

Configuring Kestrel

Kestrel is a multi-platform web server used to host .NET Core web applications.

To add Kestrel to our project we must add the it’s dependencies to the .csproj file as follows:

Now we will open our Program.cs file and in it’s Main method replace the following lines:

For these lines:

In order to use Kestrel and the HTTP context we will have to add these references:

Now we need to add the Startup.cs .

Using Startup.cs

With the file Startup.cs we are going to configure for the project host.

By now our Startup.cs should be looking something like this:

The Configure method is called at runtime and it is used to configure and channel HTTP requests.

IApplicationBuilder provides the mechanisms for configuring application requests. The middleware is also configured here.

Next, we will configure the app to use IIS/IIS Express for the web server and set the content root. To do this we will add the following lines before the Build() in Program.cs :

To use IIS with ASP.NET Core, both UseKestrel and UseIISIntegration must be specified. Kestrel is designed to run behind a proxy and should not be deployed without it.

Now let’s add the IIS package reference in .csproj , and run dotnet restore for updating dependencies.

We will add “Watcher” to see the changes reflected without needing to stop and re-run the project. For that we are going to add the following dependency:

As always we will have to run dotnet restore , and now if we run dotnet watch run we should be able to see our changes being reflected without us having to reload out application.

Congratulations!

You already have your .Net Core application running on Linux and you learned how to configure it from scratch using Kestrel and develop it in a web environment. In the next post, I explain how to build an MVC architecture application using the tools provided by .Net Core.

Источник

Сервер и публикация приложения

Сервер

Традиционно приложения ASP.NET развертывались на веб-сервере IIS. Однако поскольку ASP.NET Core имеет кроссплатформенную природу, потребовалось отвязать ASP.NET Core от IIS и в целом от Windows. И на данный момент для развертывания приложения ASP.NET Core поддерживает развертывание приложения на следующих веб-серверах:

IIS и IIS Express, а также предоставляет возможность запускать приложение без IIS в рамках собственного процесса с помощью двух дополнительных http-серверов, которые идут вместе с ASP.NET Core:

IIS HTTP Server

Microsoft.AspNetCore.Server.HttpSys (или просто WebListener) (в предыдущих версиях ASP.NET Core назывался WebListener)

Microsoft.AspNetCore.Server.Kestrel (или просто Kestrel)

HTTP.sys и Kestrel представляют два дополнительных http-серверов, которые идут вместе с ASP.NET Core. HTTP.sys работает только на платформе Windows, а Kestrel является кроссплатформенным.

Кроме того, если приложение использует Kestrel, то в качестве прокси-сервера оно может использовать также IIS, Apache и Nginx. То есть Apache, Nginx или IIS будут получать запросы и перенаправлять их приложению, которое работает на Kestrel. Такая схема, когда запросы идут не напрямую на Kestrel, проходят черех IIS/Apache/Nginx, позволяет нам задействовать возможности, которые есть у этих веб-серверов, но отсутствуют у Kestrel.

IIS и IIS Express

По умолчанию приложения ASP.NET работают с сервером IIS. Однако надо заметить, что по сравнению с предыдущими версиями ASP.NET при работе с ASP.NET Core IIS не использует инфраструктуру System.Web , что значительно повышает производительность приложения. Кроме того, IIS поддерживает множество различного функционала, имеет множество возможностей по администрированию и управлению сервером и размещенными на нем приложениями.

AspNetCoreModule

Хостирование приложений ASP.NET Core на IIS происходит с помощью нативного модуля IIS под названием AspNetCoreModule , который сконфигурирован таким образом, чтобы перенаправлять запросы на веб-сервер Kestrel. Этот модуль управляет запуском внешнего процесса dotnet.exe, в рамках которого хостируется приложение, и перенаправляет все запросы от IIS к этому хостирующему процессу.

При получении первого запроса к приложению AspNetCoreModule запускает процесс для этого приложения и перезапускает процесс, если приложение падает.

Вначале все входящие запросы проходят через драйвер Http.Sys, который перенаправляет их на IIS на основной порт (80) или на порт SSL (443). Затем запрос от IIS перенаправляется приложению ASP.NET Core на определенный порт, на котором запущено приложение (любой другой порт, отличный от 80/443). Веб-сервер Kestrel получает запрос и передает его в виде объекта HttpContext в конвейер middleware ASP.NET Core. Конвейер middleware в приложении обрабатывает запрос и возвращает IIS результат обработки, который затем посылается HTTP-клиенту (например, веб-бразеру).

Для использования модуля он должен быть установлен. Он распространяется в рамках пакета ASP.NET Core Server Hosting Bundle. Но при установки Visual Studio с ASP.NET Core модуль AspNetCoreModule уже автоматически устанавливается для IIS Express / IIS, поэтому разработчикам, как правило, не придется его дополнительно доустанавливать.

Также для использования модуля непосредственно в приложении в проекте должен быть установлен Nuget-пакет Microsoft.AspNetCore.Server.IISIntegration .

Для интеграции с IIS для объекта WebHostBuilder вызывается метод UseIISIntegration() . Этот метод ищет переменные окружения, которые устаналиваются модулем AspNetCoreModule, если подобных переменных не установлено, то метод по сути ничего не делает.

Мы можем вызвать этот метод явно в файле Program.cs:

Однако это необязательно делать, поскольку при запуске приложения через IIS система автоматически вызывает данный метод.

Среди преимуществ использования именно IIS, а не Kestrel следует отметить работу со статическими файлами. В стандартном веб-приложении ASP.NET Core за взаимодействие со статическими файлами отвечает middleware StaticFiles, которое было рассмотрено в одной из предыдущих тем. Но на данный момент оно слабо отптимизировано и не поддерживает кэширование. И если мы используем чистый Kestrel, то он при обращении к статическим файлам каждый раз считывает их из файловой системы. А если мы используем IIS в качестве прокси для сервера, то мы можем воспользоваться встроенными возможностями IIS по кэшированию. В частности, IIS кэширует ранее считанный с диска статический файл и при последующих обращениях к нему берет этот файл из кэша, тем самым увеличивая производительность.

Kestrel

Kestrel представляет кроссплатформенный веб-сервер, основанный на кросплатформенной библиотеке асинхронного ввода/вывода libuv. Kestrel по умолчанию включается в проект ASP.NET Core.

При инициализации хоста у объекта WebHostBuilder вызывается метод UseKestrel() , который позволяет задействовать Kestrel. Несмотря на то, что по умолчанию исходный код в файле Program.cs не содержит этого вызова, этот метод вызывается автоматически.

Однако при настройке хоста мы можем явным образом вызвать метод UseKestrel для конфигурации сервера:

Для настройки Kestrela применяются свойства и методы объекта KestrelServerOptions . В частности, метод Listen позволяет установить порт, по которому Kestrel будет запускаться.

Свойство Limits устанавливает предельные значения для различных конфигурационных настроек. Так, свойство MaxConcurrentConnections задает максимально количество оновременно открытых соединений.

Свойство MaxRequestBodySize устанавливает максимальный размер для запроса в байтах.

Свойство MinRequestBodyDataRate задает минимальную скорость передачи данных в запросе в байтах в секунду.

Свойство MinResponseDataRate задает минимальную скорость передачи данных в исходящем потоке в байтах в секунду.

При развертывании на Windows Kestrel может применять IIS в качестве прокси-сервера, а при развертывании на Linux как прокси-серверы могут использоваться Apache и Nginx. Но также Kestrel может работать самостоятельно внтури своего процесса без IIS.

Так, по умолчанию в Visual Studio доступны две возможности для запуска: с проксированием через IIS и напрямую.

При выборе возможностей вариантов запуска мы можем по умолчанию встретить два профиля:

IIS Express (запуск с проксированием через IIS Express)

Профиль, который совпадает с названием проекта (в моем случае это HelloApp) — тот пункт, который позволяет запускать приложение в отдельном процессе без всякого проксирования через IIS. Так как в файле Program.cs установлен в качестве сервера Kestrel (методом UseKestrel() ), то в данном случае приложение будет запускать именно Kestrel. Причем по умолчанию приложение будет запускаться на 5000-порту.

И если мы выберем для запуска второй пункт, то у нас запустится консольное приложение dotnet.exe , которое запустит наше приложение. И после этого мы сможем обращаться к нашему приложению из любого браузера:

Запуск приложения с помощью Kestrel довольно прост, нам не надо устанавливать и настраивать другие веб-серверы. Однако специалисты Microsoft рекомендуют такой способ запуска преимущественно в рамках локальной внутренней сети. А если приложение открыто для глобальной сети интернет, то рекомендумым способом запуска для обеспечения большей безопасности является именно проксирование через IIS, Apache, Nginx. Подобный метод имеет ряд преимуществ по сравнению с обычным запуском приложения на Kestrel в виде самохостирующегося процесса. В частности, прокси-серверы позволяет скрыть приложения, если они не должны быть доступны напрямую. Кроме того, веб-серверы позволяет управлять нагрузкой ко всем приложениям, и предоставляют другие функции по управлению приложениями.

Собственно при создании проекта ASP.NET Core в Visual Studio такой способ используется по умолчанию.

HTTP.sys

HTTP.sys представляет HTTP-сервер для ASP.NET Core, который работает только в ОС Windows. Ранне данный сервер назывался WebListener. Он запускается поверх драйвера ядра Http.Sys . Весь функционал сервера сосредоточен в пакете Microsoft.AspNetCore.Server.HttpSys .

Итак, изменим файл Program.cs, чтобы в нем использовался не Kestrel, а HttpSys:

Если метод UseKestrel() задает в качестве сервера Kestrel, то вызов метода UseHttpSys() аналогичным образом устанавливает в качестве сервера HTTP.sys.

Теперь запустим приложение, выбрав профиль, который совпадает с названием проекта:

И у нас запустится та же самая консоль, что и при работе через Kestrel, только теперь все вызовы к приложению будут идти через WebListener.

Источник

Реализации веб-сервера в ASP.NET Core

Авторы: Том Дисктра (Tom Dykstra), Стив Смит (Steve Smith), Стивен Хальтер (Stephen Halter) и Крис Росс (Chris Ross)

Приложение ASP.NET Core выполняется вместе с внутрипроцессной реализацией HTTP-сервера. Реализация сервера прослушивает HTTP-запросы и передает их в приложение как набор функций запросов, объединенных в HttpContext.

В состав ASP.NET Core входит следующее:

• Kestrel сервер представляет собой кроссплатформенную реализацию HTTP-сервера по умолчанию. Kestrel обеспечивает максимальную производительность и использование памяти, но обладает некоторыми дополнительными функциями в HTTP.sys. Для получения дополнительной информации см. Раздел Kestrel и HTTP.sys в следующем разделе.
• HTTP-сервер IIS — это внутрипроцессный сервер для службы IIS.
• Сервер HTTP.sys — это HTTP-сервер, предназначенный только для Windows и основанный на драйвере ядра HTTP.sys и API HTTP-сервера.

При использовании IIS или IIS Express приложение запускается одним из следующих способов:

• В том же процессе, что и рабочий процесс IIS (модель внутрипроцессного размещения), с использованием HTTP-сервера IIS. Внутрипроцессное размещение является рекомендуемой конфигурацией.
• В процессе, отдельном от рабочего процесса IIS (внепроцессная модель хостинга) с Kestrel сервером.

Модуль ASP.NET Core представляет собой собственный модуль IIS, который обрабатывает собственные запросы IIS между IIS и внутрипроцессным HTTP-сервером IIS или Kestrel. Для получения дополнительной информации см. Модуль ASP.NET Core.

Kestrel в сравнении с HTTP.sys

Kestrel имеет следующие преимущества перед HTTP.sys:

• Повышенная производительность и более эффективное использование памяти.
• Кроссплатформенные
• Гибкость, поскольку разработка и установка исправлений осуществляется независимо от операционной системы.
• Программный порт и конфигурация TLS.
• Расширяемость, обеспечивающая использование таких протоколов, как PPv2, и альтернативные транспорты.

HTTP.sys выступает в качестве общего компонента режима ядра со следующими функциями, которыми не обладает Kestrel:

• Совместное использование портов
• Проверка подлинности Windows в режиме ядра. Kestrel поддерживает аутентификацию только в пользовательском режиме.
• Быстрое проксирование с помощью передачи очередей
• Прямая передача файлов
• Кэширование откликов

Модели размещения

При внутрипроцессном размещении приложение ASP.NET Core выполняется в том же процессе, что и рабочий процесс IIS. При этом повышается производительность по сравнению с внепроцессным размещением, так как запросы не передаются через адаптер замыкания на себя (сетевой интерфейс, который возвращает исходящий сетевой трафик на тот же компьютер). IIS обрабатывает управление процессом с помощью службы активации процессов Windows (WAS).

При внепроцессном размещении приложения ASP.NET Core выполняются в процессе, отделенном от рабочего процесса IIS, а модуль управляет процессами. Модуль запускает процесс для приложения ASP.NET Core при поступлении первого запроса и перезапускает приложение при сбое или завершении работы. Это, по сути, совпадает с поведением приложений, выполняемых внутрипроцессно и управляемых службой активации процессов Windows (WAS).

Дополнительные сведения и инструкции по настройке см. в следующих статьях:

ASP.NET Core поставляется с Kestrel сервером, который является межплатформенным HTTP-сервером по умолчанию.

ASP.NET Core поставляется с Kestrel сервером, который является межплатформенным HTTP-сервером по умолчанию.

Kestrel

Kestrel сервер представляет собой кроссплатформенную реализацию HTTP-сервера по умолчанию. Kestrel обеспечивает максимальную производительность и использование памяти, но обладает некоторыми дополнительными функциями в HTTP.sys. Дополнительные сведения см. в разделе Kestrel и HTTP.sys настоящего документа.

Используйте Kestrel в следующих случаях:

Сам по себе как пограничный сервер обработки запросов непосредственно из сети, включая Интернет.

С обратным прокси-сервером, таким как службы IIS, Nginx или Apache. Обратный прокси-сервер получает HTTP-запросы из Интернета и пересылает их на Kestrel.

Поддерживается любая из этих конфигураций размещения — с обратным прокси-сервером и без него.

Инструкции по настройке Kestrel и информацию о том, когда следует использовать Kestrel в конфигурации обратного прокси, см. в разделе Реализация веб-сервера Kestrel в ASP.NET Core.

В состав ASP.NET Core входит следующее:

• Kestrel сервер представляет собой кроссплатформенный HTTP-сервер по умолчанию.
• Сервер HTTP.sys — это HTTP-сервер, предназначенный только для Windows и основанный на драйвере ядра HTTP.sys и API HTTP-сервера.

При использовании IIS или IIS Express приложение запускается в процессе, отдельном от рабочего процесса IIS (внепроцессный) с Kestrel сервера.

Так как приложения ASP.NET Core выполняются в процессе, отделенном от рабочего процесса IIS, этот модуль обрабатывает управление процессами. Модуль запускает процесс для приложения ASP.NET Core при поступлении первого запроса и перезапускает приложение при сбое или завершении работы. Это, по сути, совпадает с поведением приложений, выполняемых внутрипроцессно и управляемых службой активации процессов Windows (WAS).

На следующей схеме показана связь между IIS, модулем ASP.NET Core и приложением, размещенным вне процесса.

Запросы поступают из Интернета в драйвер HTTP.sys в режиме ядра. Драйвер направляет запросы к службам IIS на настроенный порт веб-сайта — обычно 80 (HTTP) или 443 (HTTPS). Модуль перенаправляет запросы в Kestrel на случайный порт для приложения, который не является портом 80 или 443.

Модуль задает порт с помощью переменной среды во время запуска, а ПО промежуточного слоя для интеграции IIS настраивает сервер для прослушивания http://localhost: . Выполняются дополнительные проверки, и запросы не из модуля отклоняются. Модуль не поддерживает переадресацию по HTTPS, поэтому запросы переадресовываются по протоколу HTTP, даже если были получены IIS по протоколу HTTPS.

После того, как Kestrel получает запрос от модуля, запрос передается в конвейер промежуточного программного обеспечения ASP.NET Core. Конвейер ПО промежуточного слоя обрабатывает запрос и передает его в качестве экземпляра HttpContext в логику приложения. ПО промежуточного слоя, добавленное посредством интеграции IIS, обновляет схему, удаленный IP-адрес и базу путей с учетом пересылки запроса на Kestrel. Отклик приложения передается обратно в службу IIS, которая отправляет его обратно в HTTP-клиент, инициировавший запрос.

Инструкции по настройке модуля ASP.NET Core и IIS см. в следующих статьях:

ASP.NET Core поставляется с Kestrel сервером, который является межплатформенным HTTP-сервером по умолчанию.

ASP.NET Core поставляется с Kestrel сервером, который является межплатформенным HTTP-сервером по умолчанию.

Nginx с Kestrel

Для получения информации о том, как использовать Nginx в Linux в качестве обратного прокси-сервера для Kestrel, см. Среда размещения ASP.NET Core в операционной системе Linux с Nginx.

Apache с Kestrel

Для получения информации о том, как использовать Apache в Linux в качестве обратного прокси-сервера для Kestrel, см. Размещение ASP.NET Core в операционной системе Linux с Apache.

HTTP.sys

Если приложения ASP.NET Core запускаются в Windows, HTTP.sys является альтернативой Kestrel. Kestrel рекомендуется для HTTP.sys, если приложению не требуются функции, недоступные в Kestrel. Для получения дополнительной информации см. Реализация веб-сервера HTTP.sys в ASP.NET Core.

HTTP.sys можно также использовать для приложений, которые имеют доступ только к внутренней сети.

Инфраструктура сервера ASP.NET Core

IApplicationBuilder, доступный в методе Startup.Configure , предоставляет свойство ServerFeatures типа IFeatureCollection. Kestrel и HTTP.sys предоставляют только одну функцию каждый, IServerAddressesFeature, однако разные реализации сервера могут предоставлять дополнительные функции.

IServerAddressesFeature можно использовать для того, чтобы узнать, какой порт в реализации сервера привязан к среде выполнения.

Пользовательские серверы

Если встроенные серверы не отвечают требованиям приложения, можно создать реализацию пользовательского сервера. В руководстве по открытому веб-интерфейсу .NET (OWIN) демонстрируется запись реализации IServer на основе Nowin. Требуют реализации только интерфейсы компонентов, используемых приложением, но как минимум должны поддерживаться IHttpRequestFeature и IHttpResponseFeature.

Запуск сервера

Сервер запускается, когда интегрированная среда разработки (IDE) или редактор запускает приложение:

• Visual Studio. Вы можете использовать профили запуска для запуска приложения и сервера с помощью IIS Express/модуля ASP.NET Core или консоли.
• Visual Studio Code. Приложение и сервер запускаются решением Omnisharp, которое активирует отладчик CoreCLR.
• Visual Studio для Mac. Приложение и сервер запускаются отладчиком «мягкого режима» Mono Soft Debugger.

При запуске приложения из командной строки в папке проекта dotnet run запускает приложение и сервер (только Kestrel и HTTP.sys). Конфигурация определяется параметром -c|—configuration , который может принимать значение Debug (по умолчанию) или Release .

Файл launchSettings.json предоставляет конфигурацию при запуске приложения с помощью dotnet run или с помощью отладчика, встроенного в инструментарий, например Visual Studio. Если профили запуска указаны в файле launchSettings.json, используйте параметр —launch-profile с командой dotnet run или выберите профиль в Visual Studio. Дополнительные сведения см. в статьях dotnet run и Упаковка дистрибутивов .NET Core.

Поддержка HTTP/2

HTTP/2 поддерживается в ASP.NET Core для следующих сценариев развертывания:

• Kestrel
  • Операционная система
    • Windows Server 2016 / Windows 10 или более поздних версий†
    • Linux с OpenSSL 1.0.2 или более поздней версии (например, Ubuntu 16.04 или более поздней версии).
    • HTTP/2 будет поддерживаться для macOS в будущих выпусках.
  • Требуемая версия .NET Framework: .NET Core версии 2.2 или более поздней
• HTTP.sys
  • Windows Server 2016 / Windows 10 или более поздних версий
  • Целевая платформа: неприменимо к развертываниям HTTP.sys.
• IIS (внутрипроцессный)
  • Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
  • Требуемая версия .NET Framework: .NET Core версии 2.2 или более поздней
• IIS (внепроцессный)
  • Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
  • Общедоступные подключения пограничного сервера используют HTTP/2, однако обратное прокси-соединение с Kestrel использует HTTP/1.1.
  • Целевая платформа: неприменимо к внепроцессным развертываниям IIS.

† Kestrel имеет ограниченную поддержку HTTP/2 в Windows Server 2012 R2 и Windows 8.1. Поддержка ограничена из-за небольшого числа поддерживаемых комплектов шифров TLS, доступных для этих операционных систем. Для обеспечения безопасности TLS-подключений может потребоваться сертификат, созданный с использованием алгоритма ECDSA.

• Kestrel
  • Операционная система
    • Windows Server 2016 / Windows 10 или более поздних версий†
    • Linux с OpenSSL 1.0.2 или более поздней версии (например, Ubuntu 16.04 или более поздней версии).
    • HTTP/2 будет поддерживаться для macOS в будущих выпусках.
  • Требуемая версия .NET Framework: .NET Core версии 2.2 или более поздней
• HTTP.sys
  • Windows Server 2016 / Windows 10 или более поздних версий
  • Целевая платформа: неприменимо к развертываниям HTTP.sys.
• IIS (внутрипроцессный)
  • Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
  • Требуемая версия .NET Framework: .NET Core версии 2.2 или более поздней
• IIS (внепроцессный)
  • Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
  • Общедоступные подключения пограничного сервера используют HTTP/2, однако обратное прокси-соединение с Kestrel использует HTTP/1.1.
  • Целевая платформа: неприменимо к внепроцессным развертываниям IIS.

† Kestrel имеет ограниченную поддержку HTTP/2 в Windows Server 2012 R2 и Windows 8.1. Поддержка ограничена из-за небольшого числа поддерживаемых комплектов шифров TLS, доступных для этих операционных систем. Для обеспечения безопасности TLS-подключений может потребоваться сертификат, созданный с использованием алгоритма ECDSA.

• HTTP.sys
  • Windows Server 2016 / Windows 10 или более поздних версий
  • Целевая платформа: неприменимо к развертываниям HTTP.sys.
• IIS (внепроцессный)
  • Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
  • Общедоступные подключения пограничного сервера используют HTTP/2, однако обратное прокси-соединение с Kestrel использует HTTP/1.1.
  • Целевая платформа: неприменимо к внепроцессным развертываниям IIS.

Подключение HTTP/2 должно использовать согласование протокола уровня приложений (ALPN) и TLS 1.2 или более поздней версии. Дополнительные сведения см. в разделах, о конкретных сценариях развертывания сервера.

Источник