Новые возможности ASP.NET Core 2.2

  • Статья

В этой статье описываются наиболее важные изменения в ASP.NET Core 2.2 со ссылками на соответствующую документацию.

Соглашения и анализаторы OpenAPI

OpenAPI (ранее Swagger) — это не зависящая от языка спецификация для описания REST API. В экосистеме OpenAPI представлены средства для обнаружения, тестирования и создания кода клиента в соответствии со спецификацией. Поддержка создания и визуализации документов OpenAPI в ASP.NET Core MVC обеспечивается за счет управляемых сообществом проектов, таких как NSwag и Swashbuckle.AspNetCore. В ASP.NET Core 2.2 представлены улучшенные средства и возможности среды выполнения для создания документов OpenAPI.

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

Поддержка сведений о проблеме

В ASP.NET Core 2.1 появился объект ProblemDetails, основанный на спецификации RFC 7807 и предназначенный для передачи сведений об ошибке в составе HTTP-ответа. В версии 2.2 ProblemDetails является стандартным ответом для кодов ошибок клиента в контроллерах с атрибутами ApiControllerAttribute. IActionResult, возвращающий код состояния ошибки клиента (4xx), теперь возвращает текст ProblemDetails. В результат также включается идентификатор корреляции, который может использоваться для сопоставления ошибки с помощью журналов запросов. В отношении ошибок клиентов ProducesResponseType по умолчанию использует тип ответа ProblemDetails. Это описывается в выходных данных Open API (Swagger), создаваемых с помощью NSwag или Swashbuckle.AspNetCore.

Маршрутизация конечных точек

В ASP.NET Core 2.2 используется новая система маршрутизации конечных точек, обеспечивающая оптимизированную диспетчеризацию запросов. Среди изменений представлены новые члены для создания ссылок API и преобразователи параметров маршрута.

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

Проверки работоспособности

Новая служба проверки работоспособности упрощает использование ASP.NET Core в средах с обязательной проверкой работоспособности, таких как Kubernetes. Служба проверки работоспособности включает ПО промежуточного слоя и набор библиотек, которые определяют абстракцию IHealthCheck и службу.

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

Проверки работоспособности предоставляются приложением в качестве конечной точки HTTP, используемой системами мониторинга. Проверки работоспособности можно настроить для различных сценариев мониторинга в реальном времени и систем мониторинга. Проверки работоспособности интегрируются с проектом BeatPulse. Это значительно упрощает добавление проверок в десятки распространенных систем и зависимых компонентов.

Дополнительные сведения см. в статье Проверки работоспособности в ASP.NET Core.

HTTP/2 в Kestrel

В ASP.NET Core 2.2 добавлена поддержка HTTP/2.

HTTP/2 является основной редакцией HTTP-протокола. В число важных функций HTTP/2 входят следующие:

  • Поддержка сжатия заголовка.
  • Полностью мультиплексные потоки через одно соединение.

Версия HTTP/2 сохраняет семантику HTTP (например, методы и заголовки HTTP), однако она заметно отличается от HTTP/1.x в отношении механизмов кадрирования и передачи данных между клиентом и сервером.

В связи с этим изменением механизмов кадрирования серверам и клиентам необходимо согласовывать используемую версию протокола. Согласование протоколов на уровне приложений (Application-Layer Protocol Negotiation, ALPN) — это расширение TLS, с помощью которого сервер и клиент могут согласовать версию протокола в рамках процесса подтверждения TLS. Даже при наличии у сервера и клиента сведений о версии протокола все основные браузеры поддерживают ALPN как единственное средство для установления соединения по протоколу HTTP/2.

Дополнительные сведения см. в статье Поддержка HTTP/2.

KestrelКонфигурация

В предыдущих версиях ASP.NET Core настройка параметров Kestrel осуществлялась путем вызова UseKestrel. В версии 2.2 для настройки параметров Kestrel вызывается метод ConfigureKestrel в построителе узла. Это изменение позволяет устранить проблему с порядком регистрации IServer для внутрипроцессного размещения. Дополнительные сведения см. на следующих ресурсах:

Внутрипроцессное размещение в службах IIS

В более ранних версиях ASP.NET Core службы IIS выступают в качестве обратного прокси-сервера. В версии 2.2 модуль ASP.NET Core может загружать CoreCLR и размещать приложение в рабочем процессе IIS (w3wp.exe). Внутрипроцессное размещение позволяет оптимизировать производительность и диагностику при работе со службами IIS.

Дополнительные сведения см. в статье Внутрипроцессное размещение для служб IIS.

Клиент Java SignalR

В ASP.NET Core 2.2 представлен клиент Java для SignalR. Этот клиент поддерживает подключение к серверу SignalR ASP.NET Core из кода Java, в том числе из приложений Android.

Дополнительные сведения см. в статье о клиенте Java для SignalR ASP.NET Core.

Усовершенствования CORS

В предыдущих версия ASP.NET Core ПО промежуточного слоя CORS обеспечивало отправку заголовков Accept, Accept-Language, Content-Language и Origin независимо от значений, настроенных в CorsPolicy.Headers. В версии 2.2 соблюдение политики ПО промежуточного слоя CORS возможно только в том случае, если отправляемые в Access-Control-Request-Headers заголовки точно соответствуют заголовкам, указанным в WithHeaders.

Дополнительные сведения см. в статье ПО промежуточного слоя CORS.

Сжатие ответов

ASP.NET Core 2.2 поддерживает сжатие ответов с использованием формата сжатия Brotli.

Дополнительные сведения см. в статье Поддержка сжатия Brotli для сжатия ответов в ПО промежуточного слоя.

Шаблоны проектов

Шаблоны веб-проектов ASP.NET Core обновлены до Bootstrap 4 и Angular 6. Новое оформление выглядит проще и позволяет более эффективно отображать важные структуры приложения.

Home or Index page

Производительность проверок

Модель MVC имеет расширяемую гибкую систему проверки, позволяющую на основе запросов определять, какие средства проверки применяются к конкретной модели. Эта возможность отлично подходит для разработки сложных поставщиков служб проверки. Тем не менее в большинстве распространенных случаев приложение использует только встроенные средства проверки и не нуждается в таких дополнительных возможностях. К встроенным средствам проверки относятся заметки к данным, такие как [Required] и [StringLength], а также IValidatableObject.

В ASP.NET Core 2.2 модель MVC может обойти проверку в случаях, когда определяется, что для указанного графа модели проверка не требуется. Пропуск проверки приводит к существенным улучшениям для моделей, в которых отсутствуют или не могут использоваться средства проверки. К ним относятся такие объекты, как коллекции примитивов (например, byte[], string[], Dictionary<string, string>) или сложные графы объектов с небольшим количеством средств проверки.

Производительность клиента HTTP

В ASP.NET Core 2.2 была повышена производительность SocketsHttpHandler за счет уменьшения числа конфликтов, связанных с блокировкой пула подключений. Была увеличена пропускная способность приложений, которые выполняют множество исходящих запросов HTTP, таких как некоторые архитектуры микрослужб. Под нагрузкой пропускная способность HttpClient может повышаться до 60 % в Linux и до 20 % в Windows.

Дополнительные сведения см. в статье, посвященной запросам на вытягивание, благодаря которым удалось добиться этого улучшения.

Дополнительная информация:

Полный список изменений см. в статье Заметки о выпуске ASP.NET Core 2.2.