Partilhar via

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

  • Artigo

Observação

Esta não é a versão mais recente deste artigo. Para informações sobre a versão vigente, confira a Versão do .NET 8 deste artigo.

Aviso

Esta versão do ASP.NET Core não tem mais suporte. Para obter mais informações, confira .NET e a Política de Suporte do .NET Core. Para informações sobre a versão vigente, confira a Versão do .NET 8 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 informações sobre a versão vigente, confira a Versão do .NET 8 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.

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

Recursos adicionais