ASP.NET e IIS - Anatomia de uma aplicação Web - Como funciona o IIS

Bruno Brito -

Se o HTTP é síncrono, por que uma aplicação Web responde diversas requests ao mesmo tempo? Entenda o que acontece desde que o browser faz uma request HTTP, chega no IIS, é processada pela aplicação e retorna para o usuário.

Veja a seguinte conversa que tive a honra de participar:

  • Quando devo utilizar async?
  • De maneira geral o async é para quando há operações de IO.
  • Então o HTTP é assincrono.
  • Não, o HTTP é sincrono.
  • Se ele é sincrono, então por que ele responde várias requisições simultaneamente?
  • É o browser quem faz varias requests HTTP. O IIS é assincrono, por isso consegue gerenciar e responder todas.
  • Então se o IIS é assincrono, por que preciso colocar Task ou async Task na minha Controller?
  • Para aumentar a escalabilidade da tua aplicação.

Esse é um resumo da conversa, apesar de curto, expõe a complexidade da programação assincrona e, que para entender o async, precisa antes saber como o IIS gerencia as requests.

Este post será dividido em duas partes.

  1. Explorar a anatomia de uma Request Web com ASP.NET e IIS.
  2. Explicar como Actions assincronos influenciam o Thread Pool do Worker Process no IIS.

IIS

O IIS é um WebServer. Um software que expões um site na internet através do protocolo HTTP. Simplificando, um WebServer é um software que permite que recursos (páginas da web, imagens, etc.) sejam solicitados através do protocolo HTTP.

Um WebServer é um "computador normal". Que executa um software especial que o torna um WebServer. Que nesse caso é o IIS. A grosso modo é possivel dizer que o IIS é um programa que escuta a porta 80.

Escutar significa que está pronto para aceitar conexões HTTP.

Protocolo HTTP

Numa comunicação web há sempre dois agentes: O Client e o Server.
Para se comunicar precisam de uma conexão e um conjunto comum de regras para poderem se entender. As regras são chamadas de protocolos.

Conceitualmente, ao falar com alguém, é através de um protocolo. Os protocolos na comunicação humana são regras sobre aparência, fala, escuta e compreensão. Trabalham juntos para ajudar as pessoas a se comunicarem com sucesso.

A necessidade de protocolos também se aplica a sistemas de computação. Um protocolo de comunicações é uma descrição formal dos formatos de mensagens digitais e das regras para troca dessas mensagens nos sistemas de computação.

O HTTP conhece toda a "gramática", mas não sabe nada sobre como enviar uma mensagem ou abrir uma conexão. É por isso que o HTTP está no topo do TCP/IP.

O HTTP é um protocolo connectionless. Significa que o client não se importa se o server está pronto para aceitar uma solicitação e, por outro lado, o server não se importa se o client está pronto para receber a resposta. Mas é necessário uma conexão.

IIS não é ASP.NET

O IIS não sabe nada sobre o ASP.NET, pode funcionar independente. Pode hospedar outras aplicações. Por exemplo, páginas HTML e páginas em PHP.

Arquitetura

HTTP.sys é um listener HTTP. Faz parte do Windows. Ele está na camada Kernel. Sua tarefa é interceptar as requests HTTP e enviá-las ao IIS. Depois que a solicitação é processada, o IIS retorna a resposta ao HTTP.sys e, por sua vez, retorna a resposta ao client.

A arquitetura do IIS tem duas camadas:

Kernel Mode e User Mode.

  • Kernel Mode: Tem acesso total a todos os dados de hardware e sistema.
  • User Mode: Não pode acessar o hardware diretamente e tem acesso limitado aos dados do sistema.

Rodar em modo Kernel ou User há desdobramentos até o nível de arquitetura do processador, prioridade de processamento e etc. No fim indico o livro do IIS para aqueles que quiserem entender mais.

Ao receber um request o HTTP.sys põe em uma Queue para processamento. Se não houver nenhum Worker Process atribuído a fila, o HTTP.sys sinaliza o WWW Service para criar um.

Quando um Application Pool é criado, o IIS cria uma fila de solicitações no HTTP.sys e registra-as no Worker Process que atende ao Application Pool.

As responsábilidades do WWW Service são:

  • Configura o HTTP.sys
  • Atualiza o HTTP.sys quando há alterações na configuração.
  • Notifica o WAS quando uma request entrar na Queue do kernel mode
  • Fornece indicadores de performance.

O WAS gerencia a configuração do Application Pool e o Worker Process. Lê informações do ApplicationHost.config e passa as informações ao WWW Service.

Application Pool

Um Application Pool pode conter um ou mais Worker Process. Com ele é possivel configurar um nível de isolamento entre aplicativos da Web. Por exemplo, se há dois WebSites no mesmo IIS e cada um com seu Application Pool. Os erros em um não afetara o outro.

Worker Process

É esse processo que executa o ASP.NET no IIS. É responsável pelo gerenciamento de todas as requests provenientes HTTP.sys. O Worker Process é onde o ASP.NET é executado no IIS.

Processando Requisições

O HTTP.sys intercepta a request HTTP e passa para o IIS. Toda vez que um Application Pool é criado é, também, registrados no HTTP.sys. Que mantêm seus IDs. Assim O HTTP.sys identifica o Application Pool da Request.

Obrigatoriamente cada aplicativo hospedado no IIS esta atrelado a um Application Pool.

O HTTP.sys passa a Request para o WAS e, por sua vez, passa a solicitação para o respectivo Application Pool.

Se o Application Pool não tiver um Worker Process em execução, o WAS iniciará um.

Se o Worker Process estiver ocupado executando outras requests, esta será armazenada na Queue do kernel-mode no HTTP.sys. O Worker Process vai atender a Request assim que tiver uma Thread disponível.

O Worker Process lê a URL da Request e o ISAPI Filter carrega a ISAPI extension correta.

Caso seja uma aplicação ASP.NET MVC 5 a ISAPI Extension vai iniciar o HttpRuntime.Se for uma aplicação ASP.NET Core, o AspNetCoreModule ou AspNetCoreModuleV2 (NET Core 2.2).

Após isso a request é processada pela Aplicação WEB, retornando essa resposta para o Client através do HTTP.sys.

Conclusão

Para entender a importancia de Async e Await no ASP.NET, primeiro é necessário entender o básico do IIS. Por isso essa primeira parte do artigo foca em fazer um overview de como os componentes do IIS se comportam.

O artigo inicia com um dialogo que deu inicio ao post. E nesse momento só foi explicado porque apesar do HTTP ser sincrono, um servidor web consegue responder a diversas chamadas HTTP feita pelo Browser.

Na segunda parte será abordado a Thread Pool. E como programação assíncro no Backend aumenta a escalabilidade.

Dúvidas? Observações? Vamos bater um papo!

Parte 2 disponivel!

Se quiser entender o desfecho desse artigo, leia a Parte 2

Referências