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

Сервер

Данное руководство устарело. Актуальное руководство: Руководство по ASP.NET Core 7

Традиционно приложения 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:

public class Program
{
	public static void Main(string[] args)
	{
		BuildWebHost(args).Run();
	}

	public static IWebHost BuildWebHost(string[] args) =>
		WebHost.CreateDefaultBuilder(args)
			.UseStartup<Startup>()
			.UseIISIntegration()
			.Build();
}

Однако это необязательно делать, поскольку при запуске приложения через 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 для конфигурации сервера:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Logging;
using System.Net;
using Microsoft.AspNetCore.Server.Kestrel.Core;

namespace ServerApp
{
    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .UseKestrel(options =>
                {
                    options.Limits.MaxConcurrentConnections = 100;
                    options.Limits.MaxRequestBodySize = 10 * 1024;
                    options.Limits.MinRequestBodyDataRate =
                        new MinDataRate(bytesPerSecond: 100, gracePeriod: TimeSpan.FromSeconds(10));
                    options.Limits.MinResponseDataRate =
                        new MinDataRate(bytesPerSecond: 100, gracePeriod: TimeSpan.FromSeconds(10));
                    options.Listen(IPAddress.Loopback, 5000);
                })
                .Build();
    }
}

Для настройки 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:

public class Program
{
	public static void Main(string[] args)
	{
		BuildWebHost(args).Run();
	}

	public static IWebHost BuildWebHost(string[] args) =>
		WebHost.CreateDefaultBuilder(args)
			.UseStartup<Startup>()
			.UseHttpSys()
			.Build();
}

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

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

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

Если Kestrel рекомендуется запускать вместе с проксирующими веб-серверами типа IIS, Apache, то для HTTP.sys не требуется проксирующего веб-сервера (более того IIS не может работать с HTTP.sys), так как Http.Sys позволяет обеспечить безопасность и надежность.