Internet Information Services от Microsoft — одна из старейших платформ веб-серверов. Первоначально выпущенный в 1995 году, он регулярно обновлялся вместе с Windows Server. Однако прошло много времени с момента выхода последнего основного выпуска, когда в ноябре 2018 года был выпущен IIS 10 версии 1809. Хотя в Windows Server 2022 добавлена поддержка QUIC и TLS 1.3, основная платформа веб-сервера не изменилась.
Тем временем Microsoft незаметно разрабатывает две альтернативные платформы веб-серверов как часть .NET, уделяя особое внимание созданию современных динамических веб-приложений. Первый из них, Http.sys, — это сервер только для Windows, который идеально подходит для запуска приложений ASP.NET Core, размещенных в Windows, в любом масштабе. Второй, Kestrel, является веб-сервером ASP.NET Core по умолчанию и работает на всех платформах .NET Core, включая macOS. Он предназначен для работы с балансировщиками нагрузки, такими как Nginx, а также для поддержки современных веб-технологий, таких как gRPC.
Представляем пустельгу
Kestrel — интересный вариант для всех, кто занимается созданием веб-приложений .NET. Это относительно легкий сервер по сравнению с IIS, и, поскольку он кроссплатформенный, он упрощает выбор хостинговой платформы. Он также подходит в качестве инструмента разработки, работающего на настольном оборудовании для тестирования и экспериментирования. Имеется поддержка HTTPS, HTTP/2 и предварительная версия QUIC, поэтому ваш код готов к будущему и будет работать безопасно.
Сервер устанавливается как часть ASP.NET Core и используется по умолчанию для сайтов, которые явно не размещаются в IIS. Вам не нужно писать какой-либо код для запуска Kestrel, кроме использования знакомого WebApplication.CreateBuilder метод. Microsoft разработала Kestrel для работы с минимальной конфигурацией: либо с использованием файла настроек, создаваемого при использовании dotnet new для настройки каркаса приложения или при создании нового приложения в Visual Studio.
Настройка пустельги
Приложения могут настраивать Kestrel с помощью API в WebApplication и WebApplicationBuilder, например, добавив дополнительные порты. Поскольку Kestrel не запускается до тех пор, пока не запустится код ASP.NET Core, это относительно простой способ сделать конфигурацию сервера динамической, при этом любое изменение требует просто нескольких строк кода. Аналогичным образом вы можете добавить новый URL-адрес конечной точки из dotnet run командой или отредактировав ваше приложение appsettings.json файл. Альтернативно можно установить переменную среды ASP.NET Core для управления используемыми портами. Эта гибкость делает Kestrel удивительно простым в управлении; вы просто выбираете метод, который лучше всего подходит для вашего кода.
Другие параметры управляют IP-адресами, по которым сервер прослушивает соединения, с возможностью прослушивания всех доступных интерфейсов. Если вы работаете с HTTPS и вам необходимо протестировать приложение перед запуском его в производство, Kestrel поставляется в комплекте со встроенным тестовым сертификатом, который поможет вам начать работу. Он устанавливается как часть ASP.NET Core SDK, и им можно управлять из dotnet инструмент командной строки. Приступив к работе, используйте различные инструменты настройки, чтобы выбрать подходящий сертификат.
Благодаря поддержке сокетов Unix Kestrel совместим с большинством балансировщиков нагрузки, включая Nginx. Это делает его идеальным для использования в контейнерах как под Linux, так и в контейнере Windows. Здесь поддержка сокетов Unix позволит вам добавлять в ваш код сетевые функции и функции безопасности через сервисную сетку.
Настройте свой сервер по-своему
Полезно иметь веб-сервер, настраиваемый программно; вы можете добавлять функции по мере необходимости. Например, рабочий сервер может работать с минимальным журналированием. В случае возникновения проблем вы можете быстро настроить Kestrel для добавления альтернативных поставщиков журналов, чтобы получить более подробную информацию об операциях. Другие варианты включают добавление поддержки альтернативных служб, например доставки статического контента из файловой системы.
В ASP.NET Core имеется множество вариантов поддерживаемых служб, поэтому вы можете выйти за рамки минимальной конфигурации API по умолчанию, например, добавив инструменты управления сеансами или кэширование ответов. Важно помнить, что добавление новых сервисов добавляет на ваш сервер больше API, что расширяет поверхность атаки, поэтому добавляйте только те функции, которые, как вы знаете, вы собираетесь использовать, и которые, как вы знаете, будут защищены вашей платформой безопасности.
Поскольку Kestrel обладает широкими возможностями настройки, вы можете управлять HTTP-командами, которые поддерживаются при приеме запросов от браузеров, а также управлять тем, как ваш сервер отвечает на определенные структуры URI. Здесь вы можете воспользоваться преимуществами примитивов .NET, таких как лямбда-выражения, для анализа данных и использования их в своих приложениях, уменьшая сложность кода за счет передачи функций серверу. Это может упростить использование кодирования URI для обработки состояния приложения, используя маршруты для захвата параметров в URI. Таким образом, Kestrel и ASP.NET могут создавать и запускать одностраничные веб-приложения, используя структуру URI для определения содержимого, доставляемого пользователям.
Microsoft разработала гибкий и мощный веб-сервер, который является полезной альтернативой IIS для приложений ASP.NET. Благодаря минимальному подходу API для создания веб-сервера, который может использовать маршруты и параметры для обслуживания статического контента наряду с функциями ASP.NET Core, требуется очень мало кода — именно то, что необходимо для создания современных приложений, которые можно масштабировать в облаке. родные контейнеры.
Как Microsoft заменила IIS на Kestrel
Как всегда, интересно посмотреть, что Microsoft делает со своими инструментами. Недавно Kestrel был объединен с обратным прокси-сервером .NET YARP с открытым исходным кодом, чтобы заменить базовую веб-платформу в службах приложений Azure. Этот процесс описывается как «тяжелая работа». В интересном сообщении в блоге подробно описан процесс управления миграцией, на который стоит обратить внимание, если вы думаете о том, чтобы сделать то же самое со своими собственными приложениями и сервисами.
Хотя к службам приложений Azure предъявляются дополнительные требования: они должны быть масштабируемой мультиарендной платформой, в процессе миграции Microsoft есть уроки, которые можно применить к любому переходу на Kestrel. Это не первая служба, в которой произошел такой сдвиг: Bing, Azure Active Directory и Dynamics 365 уже используют один и тот же сервер.
Масштаб служб приложений Azure огромен, даже для таких гипермасштабируемых служб, как Azure. В настоящее время он поддерживает более 160 миллиардов HTTP-запросов в день и размещает более 14 миллионов доменных имен. Базовая архитектура типична для облачных служб: платформа стоит за набором балансировщиков нагрузки, а код службы приложений выполняется на наборе рабочих процессов и доставляется через веб-сервер. В глобальном масштабе это означает, что на веб-серверах работают более 200 000 ядер.
До обновления это работало на IIS и HTTP.sys. Перейдя на Kestrel и YARP, Microsoft сможет предложить своим пользователям более широкий набор протоколов HTTP, улучшить параметры безопасного соединения и при этом позволить разработчикам использовать выбранные ими платформы приложений.
Процесс миграции интерфейсной службы, которая работает с традиционными браузерами, а также с клиентами REST и gRPC API, выявил некоторые проблемы с Kestrel, которые с тех пор были устранены, что сделало его более подходящим для приложений, ориентированных на пользователя. Пожалуй, самое интересное изменение привело к тому, что Kestrel стал вести себя менее строго. Первоначально написанный в соответствии со спецификацией HTTP, он отклонял запросы, содержащие начальные символы новой строки. Команда Kestrel теперь ослабила требования к соблюдению требований, и новые версии теперь принимают этот класс запросов.
Переход на новую платформу с той, которая использовалась с самых первых дней существования Azure, позволяет нам получить некоторые интересные результаты: пропускная способность для стандартных HTTP-запросов увеличилась почти на 80%. Это приводит к значительному сокращению использования ЦП во всем парке хостов внешнего обслуживания, за которым команда продолжает следить в надежде в конечном итоге сократить количество используемых ими ядер, сэкономив как затраты, так и ресурсы центра обработки данных.
Поскольку Kestrel является кроссплатформенным, тот же код теперь может поддерживать рабочие нагрузки Linux, что позволяет Azure удалить серверы Nginx, которые предоставляли рабочие интерфейсы Linux. Наличие одинаковой инфраструктуры для Linux и Windows должно снизить накладные расходы на управление благодаря общей базе кода для службы и общему набору функций. По мере обновления Kestrel и YARP новые функции будут доступны всем пользователям Службы приложений Azure, а не только для подмножества, специфичного для ОС.
Работа, которую Microsoft проводит по внедрению Kestrel и YARP в Службу приложений Azure, принесет пользу всем, кто использует Kestrel. Поместив его в основу одной из самых требовательных платформ Azure, вы быстро выявите крайние случаи, которые могут быть не видны ASP.NET Core — по крайней мере, без необходимости значительной отладки.
Это беспроигрышный сценарий для Kestrel и ASP.NET Core, повышающий вероятность того, что ваш следующий проект будет нацелен на Kestrel, а не на устаревший IIS. Результатом должны стать веб-серверы, которые легче настраивать и управлять, которые работают на большинстве распространенных серверных платформ или в контейнерах, без необходимости компромисса между простотой и безопасностью, что слишком часто становится проблемой при масштабной работе.
