Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Note
Esta não é a versão mais recente deste artigo. Para a versão atual, consulte a versão .NET 10 deste artigo.
Warning
Esta versão do ASP.NET Core não é mais suportada. Para obter mais informações, consulte a Política de suporte do .NET e do .NET Core. Para a versão atual, consulte a versão .NET 10 deste artigo.
Por Tom Dykstra, Steve Smith, Stephen Halter e 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.
ASP.NET Core é fornecido com o seguinte:
- Kestrel server é 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 kernelHTTP.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 execução é a configuração recomendada.
- Em um processo separado do processo de trabalho do IIS (o modelo de hospedagem fora do processo) com o Kestrel servidor.
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 processo ou Kestrel. Para obter mais informações, consulte ASP.NET ANCM (Core Module) 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.
- Várias plataformas
- 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
- Caching 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 lida com o gerenciamento de processos com o Serviço de Ativação de Processos do Windows (WAS).
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
Kestrel server é 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.
Utilize 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 os Serviços de Informações da Internet (IIS), Nginx ou 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 Kestrel obter orientações de configuração e informações sobre quando usar Kestrel numa configuração de proxy reverso, consulte Kestrel servidor web no ASP.NET Core.
ASP.NET Core é fornecido com o seguinte:
- Kestrel server é o servidor HTTP padrão multiplataforma.
- HTTP.sys servidor é um servidor HTTP somente para Windows baseado no driver do kernelHTTP.sys e na API do Servidor HTTP.
Ao usar o IIS ou o IIS Express, o aplicativo é executado em um processo separado do processo de trabalho do IIS (fora do processo) com o Kestrel servidor.
Como ASP.NET aplicativos principais são executados em um processo separado do processo de trabalho do IIS, o módulo lida com 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 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 diagrama a seguir ilustra a relação entre o IIS, o ASP.NET Core Module e um aplicativo hospedado fora do processo:
As solicitações chegam da web para o driver HTTP.sys do modo do kernel. O driver roteia as solicitações para o IIS na porta configurada do site, geralmente 80 (HTTP) ou 443 (HTTPS). O módulo encaminha as solicitações para Kestrel em uma porta aleatória para o aplicativo, que não é a porta 80 ou 443.
O módulo especifica a porta por meio de uma variável de ambiente na inicialização e o de Middleware de Integração do IIS configura o servidor para escutar http://localhost:{port}. Verificações adicionais são realizadas e solicitações que não são originadas do módulo são rejeitadas. O módulo não oferece suporte ao encaminhamento HTTPS, portanto, as solicitações são encaminhadas por HTTP, mesmo se recebidas pelo IIS por HTTPS.
Após o Kestrel apanhar a solicitação do módulo, a solicitação é encaminhada para o pipeline intermediário do ASP.NET Core. O pipeline de middleware lida com a solicitação e a transmite como uma instância HttpContext para a lógica da aplicação. O middleware adicionado pela Integração do IIS atualiza o esquema, o IP remoto e a base de caminho para levar em conta o encaminhamento da solicitação para Kestrel. A resposta do aplicativo é passada de volta para o IIS, que a envia de volta para o cliente HTTP que iniciou a solicitação.
Para obter as diretrizes de configuração do IIS e do ASP.NET Módulo Principal, consulte os seguintes tópicos:
Nginx com Kestrel
Para obter informações para usar o Nginx no Linux como servidor proxy reverso para Kestrel, veja 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 sobre 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 HTTP.sys orientação de configuração, consulte HTTP.sys implementação de servidor Web 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 emIServer Nowin. Apenas as interfaces de funcionalidades que a aplicação usa exigem implementação, embora, no mínimo, IHttpRequestFeature e IHttpResponseFeature devam ser suportadas.
Arranque 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 a aplicação e o servidor com o IIS Express/, o Módulo Core do ASP.NET ou o console.
- Visual Studio Code: O aplicativo e o servidor são iniciados pelo Omnisharp, que ativa o depurador CoreCLR.
Ao iniciar a aplicação a partir de um prompt de comando na pasta do projeto, dotnet run inicia a aplicação e o servidor (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 pacote de distribuição .NET.
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
- Sistema operativo
-
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.
- 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)
- HTTP/2 será suportado no macOS em uma versão futura.
- Estrutura de destino: .NET Core 2.2 ou posterior
- Sistema operativo
-
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.
- 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)
- HTTP/2 será suportado no macOS em uma versão futura.
- Estrutura de destino: .NET Core 2.2 ou posterior
- Sistema operativo
-
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.
-
HTTP.sys
- Windows Server 2016/Windows 10 ou posterior
- Estrutura de destino: Não aplicável a implementações HTTP.sys.
-
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.
Uma conexão HTTP/2 deve usar Application-Layer Protocol Negotiation (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.