Традиционно приложения asp. Net развертывались на веб-сервере iis. Однако поскольку asp. Net core имеет кроссплатформенную природу, потребовалось отвязать asp. Net core от iis и в целом от Windows

Сервер
Традиционно приложения 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()
.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()
.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()
.UseHttpSys()
.Build();
}
Если метод UseKestrel() задает в качестве сервера Kestrel, то вызов метода UseHttpSys() аналогичным образом устанавливает в качестве сервера HTTP.sys.
Теперь запустим приложение, выбрав профиль, который совпадает с названием проекта:
И у нас запустится та же самая консоль, что и при работе через Kestrel, только теперь все вызовы к приложению будут идти через WebListener.
Если Kestrel рекомендуется запускать вместе с проксирующими веб-серверами типа IIS, Apache, то для HTTP.sys не требуется проксирующего веб-сервера (более того IIS не может работать с HTTP.sys), так как Http.Sys позволяет обеспечить безопасность и надежность.
Публикация на IIS
После завершения работы над приложением приложение его можно опубликовать, чтобы оно стало доступно широкому кругу пользователей. Как правило, для хостирования приложения будет применяться один из внешних хостингов, список которых можно посмотреть здесь. В данном же случае рассмотрим основные моменты публикации и развертывания приложения на локальном компьютере.
Традиционно веб-сервер IIS (Internet Information Services) применялся для развертывания веб-приложений. Для хостирования веб-приложений ASP.NET Core также может применяться IIS, только в отличие от предыдущих версий ASP.NET теперь его роль будет сводиться к прокси-серверу. Хостирование приложений ASP.NET Core на IIS происходит с помощью нативного модуля AspNetCoreModule, который сконфигурирован таким образом, чтобы перенаправлять запросы на веб-сервер Kestrel. Этот модуль управляет запуском внешнего процесса dotnet.exe, в рамках которого хостируется приложение, и перенаправляет все запросы от IIS к этому хостирующему процессу.
При разработке в Visual Studio публиковать приложения очень легко - среда разработки имеет для этого весь необходимый инструментарий. Так, возьмем какой-нибудь проект и в Visual Studio нажмем на него правой кнопкой мыши и в появившемся контекстном меню выберем пункт Publish:
И перед нами откроется окно публикации приложения:
Здесь нам доступно несколько вариантов публикации:
Microsoft Azure App Service: публикация в облаке Azure
IIS, FTP, etc: публикация через FTP
Folder: публикация в виде отдельного пакета в файловой системе текущей рабочей машины
Import Profile: импорт профиля, который содержит настройки публикации
Microsoft Azure Virtual Machines: публикация в облаке Azure, по сравнению с первой опцией обладает большими возможностями по управлению инфраструктурой развертывания
В данном случае выберем опцию Folder для создания пакета для публикации в файловой системе. И также укажем путь, по которому будет находиться пакет. В моем случае это каталог "C:\CoreApp". И в конце нажмем на кнопку Publish.
Далее откроется окно, где будут оображаться выбранные настройки конфигурации, и для продолжения публикации нажмем в нем кнопку Publish:
И после окончания публикации по указанному пути (в моем случае это каталог C:\CoreApp) появятся опубликованные файлы.
Настройка IIS
Прежде всего нам надо включить функциональность Web Server (IIS) и настроить роли сервера. Для этого перейдем по пути Панель управления -> Программы и компоненты -> Включение или отключение компонентов Windows. В списке компонентов найдем Службы IIS (Internet Information Services) и отметим ее:
Здесь также надо отметить подпункт "Службы Интернета" (World Wide Web Services) и все его подпункты, а также подпункт "Консоль управления IIS" (IIS Management Console).
Нажмем на ОК, и весь необходимый функционал будет добавлен в операционную систему.
Затем нам необходимо установить специальный пакет .NET Core Windows Server Hosting. Его можно найти, перейдя на страницу https://www.microsoft.com/net/download/all. Далее на этой странице надо выбрать нужную версию .NET Core Runtime (.NET Core Runtime > .NET Core Runtime x.y.z. Далее на странице выбранной версии .NET Core Runtime перейти к подразделу Windows и выбрать Server Hosting Installer. После этого загрузится нужный пакет. Этот пакет устанавливает .NET Core Runtime, .NET Core Library и модуль ASP.NET Core Module. Данный модуль, как говорилось выше, как раз и создает проксирование между IIS и сервером Kestrel.
После установки этого пакета выполним в командной строке команду iisreset или вручную перезапустим IIS, чтобы сервер применил изменения.
Конфигурация сервера
Для конфигурации IIS перейдем к консоли управления веб-сервером. Для этого перейдем по пути Панель управления -> Администрирование -> Диспетчер служб IIS:
Нажмем правой кнопкой на узел "сайты" и в контекстном меню выберем пункт "Добавить веб-сайт...". После этого нам откроется окно для добавления нового сайта:
В поле "Физический путь" здесь укажем каталог, в котором опубликовано приложение. А в качестве имени узла определим "localhost". Нажмем на OK, и приложение будет запущено.
Теперь перейдем к пункту Пулы приложений. Выберем пул нашего приложения и справа нажмем на ссылку Основные настройки:
В открывшемся окне для параметра Версия среды CLR .NET установим значение Без управляемого кода:

После этого пул будет перезапущен, и мы сможем обращаться к нашему приложению по адресу localhost.