Implementações de servidor Web no ASP.NET Core

Por Tom Dykstra, Steve Smith, Stephen Haltere Chris Ross

Um aplicativo ASP.NET Core é executado com uma implementação de servidor HTTP em processo. A implementação do servidor percebe as solicitações HTTP e as disponibiliza à aplicação como um conjunto de funcionalidades de solicitação , estruturado em um HttpContext.

Windows

ASP.NET Core é fornecido com o seguinte:

• Kestrel servidor é a implementação padrão do servidor HTTP multiplataforma. Kestrel oferece o melhor desempenho e utilização de memória, mas não tem alguns dos recursos avançados em HTTP.sys. Para obter mais informações, consulte Kestrel vs. HTTP.sys na guia Windows.
• O Servidor HTTP do IIS é um servidor em processo para o IIS.
• HTTP.sys servidor é um servidor HTTP somente para Windows baseado no driver do kernel HTTP.sys e na API do Servidor HTTP.

Ao usar o IIS ou IIS Express, a aplicação pode funcionar:

• No mesmo processo que o processo de trabalho do IIS (o modelo de hospedagem em processo ) com o Servidor HTTP do IIS. em execução é a configuração recomendada.
• Num processo separado do processo de trabalho do IIS (o modelo de hospedagem fora de processo ) com o servidor Kestrel.

O ASP.NET Core Module é um módulo nativo do IIS que lida com solicitações nativas do IIS entre o IIS e o Servidor HTTP do IIS em execução ou Kestrel. Para obter mais informações, consulte Módulo ASP.NET Core (ANCM) para IIS.

Kestrel vs. HTTP.sys

Kestrel tem as seguintes vantagens em relação ao HTTP.sys:

• Melhor desempenho e utilização da memória.
• Multiplataforma
• Agilidade, é desenvolvido e corrigido independentemente do sistema operacional.
• Porta programática e configuração TLS
• Extensibilidade que permite protocolos como PPv2 e transportes alternativos.

Http.Sys opera como um componente de modo kernel compartilhado com as seguintes características que o Kestrel não tem:

• Partilha de portas
• Autenticação do Windows no modo kernel. Kestrel suporta apenas autenticação de modo de usuário.
• Proxy rápido por meio de transferências através de filas
• Transmissão direta de arquivos
• Cache de resposta

Modelos de hospedagem

Vários modelos de hospedagem estão disponíveis:

• Kestrel auto-hospedagem: O servidor Web Kestrel é executado sem a necessidade de qualquer outro servidor Web externo, como IIS ou HTTP.sys.

• HTTP.sys auto-hospedagem é uma alternativa ao Kestrel. Kestrel é recomendado sobre HTTP.sys, a menos que a aplicação exija recursos não disponíveis no Kestrel.

• Hospedagem em processo do IIS: um aplicativo ASP.NET Core é executado no mesmo processo que seu processo de trabalho do IIS. A hospedagem em processo do IIS oferece melhor desempenho em relação à hospedagem fora de processo do IIS porque as solicitações não são intermediadas por proxy pelo adaptador de loopback, uma interface de rede que retorna o tráfego de rede de saída de volta para a mesma máquina. O IIS gere a gestão de processos com o WAS (Serviço de Ativação de Processos do Windows).

• Hospedagem fora de processo do IIS: As aplicações ASP.NET Core são executadas num processo separado do processo de trabalho do IIS, e o módulo trata do gerenciamento do processo. O módulo inicia o processo para o aplicativo ASP.NET Core quando a primeira solicitação chega e reinicia o aplicativo se ele for desligado ou falhar. Esse é essencialmente o mesmo comportamento visto com aplicativos executados em processo gerenciados pelo Serviço de Ativação de Processos do Windows (WAS). O uso de um processo separado também permite hospedar mais de um aplicativo do mesmo pool de aplicativos.

Para obter mais informações, consulte o seguinte:

• Kestrel vs. HTTP.sys
• Alojar ASP.NET Core no Windows com o IIS
• Módulo ASP.NET Core (ANCM) para IIS

macOS

ASP.NET Core é fornecido com Kestrel servidor, que é o servidor HTTP padrão e multiplataforma.

Linux

ASP.NET Core é fornecido com o servidor Kestrel, que é o servidor HTTP padrão multiplataforma.

Kestrel

O servidor Kestrel é a implementação padrão do servidor HTTP multiplataforma. Kestrel oferece o melhor desempenho e utilização de memória, mas não tem alguns dos recursos avançados em HTTP.sys. Para obter mais informações, consulte Kestrel vs. HTTP.sys neste documento.

Use Kestrel:

• Por si só, como um servidor de borda processando solicitações diretamente de uma rede, incluindo a Internet.

  

• Com um servidor proxy reverso , como Internet Information Services (IIS), Nginxou Apache. Um servidor proxy reverso recebe solicitações HTTP da Internet e as encaminha para Kestrel.

  

A configuração de hospedagem — com ou sem um servidor proxy reverso — é suportada.

Para obter orientação para configuração de Kestrel e informações sobre quando usar Kestrel numa configuração de proxy reverso, consulte o servidor web Kestrel no ASP.NET Core.

Nginx com Kestrel

Para obter informações sobre como usar o Nginx no Linux como um servidor proxy reverso para Kestrel, consulte Host ASP.NET Core no Linux com Nginx.

HTTP.sys

Se os aplicativos ASP.NET Core forem executados no Windows, HTTP.sys é uma alternativa ao Kestrel. Kestrel é recomendado em vez de HTTP.sys a menos que a aplicação exija recursos não disponíveis no Kestrel. Para obter mais informações, consulte HTTP.sys implementação de servidor Web no ASP.NET Core.

HTTP.sys também pode ser usado para aplicativos que só estão expostos a uma rede interna.

Para obter orientação de configuração HTTP.sys, consulte a implementação de Servidor Web HTTP.sys no ASP.NET Core.

ASP.NET Infraestrutura de servidor principal

O IApplicationBuilder disponível no método Startup.Configure expõe a propriedade ServerFeatures do tipo IFeatureCollection. Kestrel e HTTP.sys expõem apenas um único recurso cada, IServerAddressesFeature, mas implementações de servidor diferentes podem expor funcionalidades adicionais.

IServerAddressesFeature pode ser usado para descobrir qual porta a implementação do servidor vinculou em tempo de execução.

Servidores personalizados

Se os servidores internos não atenderem aos requisitos do aplicativo, uma implementação de servidor personalizada poderá ser criada. O guia Open Web Interface for .NET (OWIN) demonstra como escrever uma implementação baseada em NowinIServer. Apenas as interfaces de funcionalidades que a aplicação usa exigem implementação, embora, no mínimo, IHttpRequestFeature e IHttpResponseFeature devam ser suportadas.

Inicialização do servidor

O servidor é iniciado quando o ambiente de desenvolvimento integrado (IDE) ou editor inicia o aplicativo:

• Visual Studio: Os perfis de inicialização podem ser usados para iniciar o aplicativo e o servidor com IIS Express/ASP.NET Core Module ou o console.
• Visual Studio Code: O aplicativo e o servidor são iniciados pelo Omnisharp, que ativa o depurador CoreCLR.
• Visual Studio para Mac: A aplicação e o servidor são iniciados pelo depurador Mono Soft-Mode.

Ao iniciar a aplicação a partir de um prompt de comando na pasta do projeto, o comando dotnet run inicia a aplicação e o servidor (Kestrel e somente HTTP.sys). A configuração é especificada pela opção -c|--configuration, que é definida como Debug (padrão) ou Release.

Um arquivo launchSettings.json fornece configuração ao iniciar um aplicativo com dotnet run ou com um depurador integrado em ferramentas, como o Visual Studio. Se os perfis de inicialização estiverem presentes em um arquivo de launchSettings.json, use a opção --launch-profile {PROFILE NAME} com o comando dotnet run ou selecione o perfil no Visual Studio. Para obter mais informações, consulte dotnet run e empacotamento de distribuição do .NET Core.

Suporte HTTP/2

HTTP/2 é suportado com o ASP.NET Core nos seguintes cenários de implantação:

• Kestrel
  • Sistema Operativo
    • Windows Server 2016/Windows 10 ou posterior†
    • Linux com OpenSSL 1.0.2 ou posterior (por exemplo, Ubuntu 16.04 ou posterior)
    • macOS 10.15 ou posterior
  • Estrutura de destino: .NET Core 2.2 ou posterior
• HTTP.sys
  • Windows Server 2016/Windows 10 ou posterior
  • Estrutura de destino: Não aplicável a implementações HTTP.sys.
• IIS (em processo)
  • Windows Server 2016/Windows 10 ou posterior; IIS 10 ou posterior
  • Estrutura de destino: .NET Core 2.2 ou posterior
• IIS (fora de processo)
  • Windows Server 2016/Windows 10 ou posterior; IIS 10 ou posterior
  • As conexões de servidor de borda orientadas ao público utilizam HTTP/2, mas a conexão de proxy reverso para Kestrel utiliza HTTP/1.1.
  • Estrutura de destino: Não aplicável a implantações fora do processo do IIS.

†Kestrel tem suporte limitado para HTTP/2 no Windows Server 2012 R2 e Windows 8.1. O suporte é limitado porque a lista de pacotes de codificação TLS suportados disponíveis nesses sistemas operacionais é limitada. Um certificado gerado usando um algoritmo de assinatura digital de curva elíptica (ECDSA) pode ser necessário para proteger conexões TLS.

Uma conexão HTTP/2 deve usar Application-Layer Negociação de Protocolo (ALPN) e TLS 1.2 ou posterior. Para obter mais informações, consulte os tópicos que dizem respeito aos cenários de implantação do servidor.

Padrões de aplicativos Web corporativos

Para obter orientação sobre como criar um aplicativo ASP.NET Core confiável, seguro, com desempenho, testável e escalável, consulte Padrões de aplicativos Web corporativos. Está disponível um aplicativo Web de exemplo completo com qualidade de produção que implementa os padrões.

Recursos adicionais

• Kestrel servidor web no ASP.NET Core
• ASP.NET Core Module (ANCM) para IIS
• Host ASP.NET Core no Windows com o IIS
• Implantar aplicativos ASP.NET Core no Serviço de Aplicativo do Azure
• Host ASP.NET Core no Linux com Nginx
• HTTP.sys implementação de servidor web no ASP.NET Core