Compartilhar via

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

  • Artigo

Observação

Esta não é a versão mais recente deste artigo. Para a versão atual, consulte a versão .NET 9 deste artigo.

Aviso

Esta versão do ASP.NET Core não tem mais suporte. 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 9 deste artigo.

Importante

Essas informações relacionam-se ao produto de pré-lançamento, que poderá ser substancialmente modificado antes do lançamento comercial. A Microsoft não oferece nenhuma garantia, explícita ou implícita, quanto às informações fornecidas aqui.

Para a versão atual, consulte a versão .NET 9 deste artigo.

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:

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

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:

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.

    Kestrel se comunica diretamente com a Internet, sem um servidor proxy reverso

  • 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.

    Kestrel se comunica indiretamente com a Internet através de um servidor proxy reverso, tal como o IIS, o Nginx ou o Apache

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:

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:

Módulo do ASP.NET Core

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.

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 se comunica diretamente com a Internet

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

O HTTP.sys se comunica diretamente com a 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:

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.

  • 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
  • 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
  • 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.

Padrões de aplicativo Web corporativo

Para obter diretrizes sobre como criar um aplicativo ASP.NET Core confiável, seguro, com desempenho, testável e escalonável, consulte padrões de aplicativo Web Enterprise. Um aplicativo web de exemplo completo com qualidade profissional que implementa os padrões está disponível.

Recursos adicionais