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

Por Tom Dykstra, Steve Smith, Stephen Halter e Chris Ross

Um aplicativo ASP.NET Core é executado com uma implementação do servidor HTTP em processo. A implementação do servidor escuta solicitações HTTP e apresenta-as para o aplicativo como um conjunto de recursos de solicitação compostos em um HttpContext.

Windows

O ASP.NET Core vem com os seguintes itens:

• Kestrel O servidor é a implementação padrão do servidor HTTP multiplataforma. Kestrel fornece o melhor desempenho e a 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 do Windows.
• O servidor HTTP do IIS é um servidor em processo do IIS.
• O servidor HTTP.sys é um servidor HTTP somente do Windows com base no driver do kernel HTTP.sys e na API do servidor HTTP.

Ao usar o IIS ou o IIS Express, o aplicativo é executado:

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

O módulo do ASP.NET Core é um módulo nativo do IIS que manipula as solicitações nativas do IIS entre o IIS e o servidor HTTP do IIS em processo ou o Kestrel. Para obter mais informações, confira Módulo do ASP.NET Core (ANCM) para o IIS.

Kestrel vs HTTP.sys

Kestrel tem as seguintes vantagens sobre HTTP.sys:

• Melhor desempenho e utilização de memória.
• Plataforma cruzada
• Agilidade, ele é desenvolvido e corrigido independentemente do sistema operacional.
• Configuração de TLS e porta programática
• Extensibilidade que permite protocolos como PPv2 e transportes alternativos.

Http.Sys opera como um componente de modo kernel compartilhado com os seguintes recursos que o Kestrel não tem:

• Compartilhamento de porta
• Autenticação do Windows no modo kernel. Kestrel dá suporte apenas à autenticação de modo de usuário.
• Proxy rápido por meio de transferências de fila
• Transmissão direta de arquivo
• Cache de resposta

Modelos de hospedagem

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

• Kestrel auto-hospedagem: o Kestrel servidor Web é executado sem exigir outros servidores Web externos, como IIS ou HTTP.sys.

• A auto-hospedagem HTTP.sys é uma alternativa para Kestrel. Kestrel é recomendado em HTTP.sys, a menos que o aplicativo exija recursos não disponíveis.Kestrel

• Hospedagem no processo do IIS: um aplicativo ASP.NET Core é executado no mesmo processo que o processo de trabalho do IIS. A hospedagem no processo do IIS fornece um desempenho aprimorado em relação à hospedagem fora do processo do IIS porque as solicitações não são feitas por proxie no adaptador de loopback, um adaptador de rede que retorna o tráfego de rede de saída de volta para o mesmo computador. O IIS manipula o gerenciamento de processos com o WAS (Serviço de Ativação de Processos do Windows).

• Hospedagem fora do processo do IIS: os aplicativos ASP.NET Core são executados em um processo separado do processo de trabalho do IIS e o módulo manipula o gerenciamento de processos. O módulo inicia o processo para o aplicativo ASP.NET Core quando a primeira solicitação chega e reinicia o aplicativo se ele é desligado ou falha. Isso é basicamente o mesmo comportamento que o dos aplicativos que são executados dentro do processo e são gerenciados pelo WAS (Serviço de Ativação de Processos do Windows). O uso de um processo separado também permite hospedar mais de um aplicativo do mesmo pool de aplicativos.

Para saber mais, consulte o seguinte:

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

macOS

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

Linux

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

Kestrel

Kestrel O servidor é a implementação padrão do servidor HTTP multiplataforma. Kestrel fornece o melhor desempenho e a 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 documentação.

Use Kestrel:

• Sozinho, como um servidor de borda que processa solicitações diretamente de uma rede, incluindo a Internet.

  

• Com um servidor proxy reverso como IIS (Serviços de Informações da Internet), Nginx ou Apache. Um servidor proxy reverso recebe solicitações HTTP da Internet e encaminha-as para o Kestrel.

  

Qualquer configuração de hospedagem – com ou sem um servidor proxy reverso – é compatível.

Para obter Kestrel diretrizes de configuração e informações sobre quando usar Kestrel em uma configuração de proxy reverso, consulte Kestrel servidor Web no ASP.NET Core.

Nginx com Kestrel

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

HTTP.sys

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

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

Para obter diretrizes de configuração do HTTP.sys, consulte Implementação do servidor Web do HTTP.sys no ASP.NET Core.

Infraestrutura de servidor do ASP.NET Core

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

IServerAddressesFeature pode ser usado para descobrir a qual porta a implementação do servidor se acoplou durante o runtime.

Servidores personalizados

Se os servidores internos não atenderem aos requisitos do aplicativo, um servidor personalizado poderá ser criado. O Guia de OWIN (Open Web Interface para .NET) demonstra como gravar uma implementação com base em NowinIServer. Somente as interfaces de recurso que o aplicativo usa exigem implementação, embora no mínimo IHttpRequestFeature e IHttpResponseFeature devam ser compatíveis.

Inicialização do servidor

O servidor é iniciado quando o IDE (Ambiente de Desenvolvimento Integrado) ou o editor inicia o aplicativo:

• Visual Studio: os perfis de inicialização podem ser usados para iniciar o aplicativo e o servidor com o IIS Express/Módulo do ASP.NET Core 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: o aplicativo e o servidor são iniciados pelo Depurador de modo suave Mono.

Ao iniciar o aplicativo usando um prompt de comando na pasta do projeto, o dotnet run inicia o aplicativo e o servidor (apenas Kestrel e 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 interno em ferramentas, como o Visual Studio. Se os perfis de inicialização estiverem presentes em um arquivo 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, confira dotnet run e pacote de distribuição do .NET Core.

Suporte do HTTP/2

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

• Kestrel
  • Sistema operacional
    • 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 versões posteriores
  • 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 implantações de 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 do processo)
  • Windows Server 2016/Windows 10 ou posterior; IIS 10 ou posterior
  • Conexões de servidor de borda voltadas para o público usam HTTP/2, mas a conexão de proxy reverso para o Kestrel usa HTTP/1.1.
  • Estrutura de destino: não aplicável a implantações IIS fora de processo.

†Kestrel tem suporte limitado para HTTP/2 no Windows Server 2012 R2 e Windows 8.1. O suporte é limitado porque a lista de conjuntos de codificação TLS disponível nesses sistemas operacionais é limitada. Um certificado gerado usando um ECDSA (Algoritmo de Assinatura Digital Curva Elíptica) pode ser necessário para proteger conexões TLS.

Uma conexão HTTP/2 precisa usar ALPN (Application-Layer Protocol Negotiation) e TLS 1.2 ou posterior. Para obter mais informações, consulte os tópicos referentes aos seus cenários de implantação do servidor.

Recursos adicionais

• Servidor web Kestrel no ASP.NET Core
• Módulo do ASP.NET Core(ANCM) para IIS
• Hospedar o 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
• Implementação do servidor Web HTTP.sys no ASP.NET Core