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.
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
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.
O ASP.NET Core vem com os seguintes itens:
- KestrelO servidor é o servidor HTTP padrão multiplataforma.
- 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 em um processo separado do processo de trabalho do IIS (fora do processo) com o servidorKestrel.
Como os aplicativos ASP.NET Core são executados em um processo separado do processo de trabalho do IIS, o módulo realiza 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 diagrama a seguir ilustra a relação entre o IIS, o Módulo do ASP.NET Core e um aplicativo hospedado de fora d processo:
As solicitações chegam da Web para o driver do HTTP.sys no modo kernel. O driver roteia as solicitações ao IIS na porta configurada do site, normalmente, a 80 (HTTP) ou a 443 (HTTPS). O módulo encaminha as solicitações ao Kestrel em uma porta aleatória do aplicativo, que não seja a porta 80 ou 443.
O módulo especifica a porta por meio de uma variável de ambiente na inicialização e o middleware de integração do IIS configura o servidor para escutar em http://localhost:{port}. Outras verificações são executadas e as solicitações que não se originam do módulo são rejeitadas. O módulo não é compatível com encaminhamento de HTTPS, portanto, as solicitações são encaminhadas por HTTP, mesmo se recebidas pelo IIS por HTTPS.
Depois que o Kestrel coleta a solicitação do módulo, a solicitação é enviada por push ao pipeline do middleware do ASP.NET Core. O pipeline do middleware manipula a solicitação e a passa como uma instância de HttpContext para a lógica do aplicativo. O middleware adicionado pela integração do IIS atualiza o esquema, o IP remoto e pathbase para encaminhar a solicitação para o Kestrel. A resposta do aplicativo é retornada ao IIS, que a retorna por push para o cliente HTTP que iniciou a solicitação.
Para obter as diretrizes de configuração do IIS e do módulo do ASP.NET Core, confira os tópicos a seguir:
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.
Apache com Kestrel
Para obter informações sobre como usar Apache no Linux como um servidor proxy reverso para Kestrel, veja Hospedar o ASP.NET Core no Linux com o Apache.
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
- Sistema operacional
- 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.
- 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)
- O HTTP/2 será compatível com macOS em uma versão futura.
- Estrutura de destino: .NET Core 2.2 ou posterior
- Sistema operacional
- 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.
- 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)
- O HTTP/2 será compatível com macOS em uma versão futura.
- Estrutura de destino: .NET Core 2.2 ou posterior
- Sistema operacional
- 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.
- HTTP.sys
- Windows Server 2016/Windows 10 ou posterior
- Estrutura de destino: não aplicável a implantações de HTTP.sys.
- 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.
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
- Hospedar o ASP.NET Core no Linux com o Apache
- Implementação do servidor Web HTTP.sys no ASP.NET Core
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de