Talvez você esteja acostumado com o Internet Information Services, talvez conheça-o, assim como eu, desde o tempo do Personal Web Server. Entre amor e ódio o IIS ajudou muita gente, mas seus dias de apogeu estão chegando ao fim.
TL;DR;
IIS morreu ou vai morrer? Não! Mas você precisa abrir os olhos para outras possibilidades, cada vez mais .NET se desconecta do IIS.
O que é um web server?
Um web server nada mais é do que um listener TCP especializado em processar requisições HTTP. Isso quer dizer que você pode escrever um web server em C#, a partir de uma classe chamada TCP Listener.
Mas calma, eu não estou dizendo que basta meia dúzias de classes e você terá um IIS, nada disso. Estou dizendo que IIS é um software como qualquer outro, muito poderoso, mas ele não é nem especial nem mágico, em sua base, ele é um listener TCP que usa recursos avançados do Windows e da arquitetura do Windows para entregar performance e resiliência.
Se você quiser criar algo rudimentar, leia esses 2 posts: Simple C# Web Server e Creating your own Web Server using C#. Eles irão abrir tua cabeça a respeito do que é um web server.
Escutando portas
Como vocês viram nos links acima, tudo começa com um listener escutando uma porta. E vou te contar um segredo: A escuta de uma porta é uma tarefa exclusiva de 1 único processo. Isso quer dizer que 2 processos não podem escutar a mesma porta. Se você está antenado nos IIS Worker Processes, talvez “bugue” tua cabeça agora.
Sim, e nesse caso aqueles processos sequer estão escutando portas.
Em um servidor de testes eu fiz o seguinte teste: Configurei o IIS para escutar uma porta “esquisita”, a porta 81.
Depois com o SysInternals TCPView eu fui ver, quem estava escutando a porta 81.
E Voilà! O processo System (PID 4) estava escutando a porta.
O processo System é um processo que lida com o agendamento de tarefas no nível do kernel. Ele inicializa todos os demais processos automáticos que fazem o sistema operacional funcionar.
A arquitetura do IIS
Assim o IIS está usando uma feature do Windows delegando para o Sistema Operacional, escutar essa porta. Curioso, já que diversas outras escutas de porta acontecem direto pelos processos, como vemos no caso do lsass, msdtc, que estão na imagem acima. Essa parte da arquitetura é melhor detalhada em Introduction to IIS Architectures.
Agora com outro utilitário, o SysInternals Process Explorer, vemos o processo System escutando nossa porta 81.
Curiosamente o W3WP.exe não estava rodando.
Então eu rodei um CURL no Powershell para ver se ele apareceria….
Novamente Voilà!
Nosso processo aparece magicamente.
Outra curiosidade interessante é que nosso W3WP.exe não está escutando porta alguma.
O que isso quer dizer?
E agora? Como o Windows criou esse processo e delegou o processamento do meu CURL pra ele?
Todo esse pipeline é descrito na mesma página sobre arquitetura do IIS, mas no tópico HTTP Request Processing in IIS.
Qual a relevância disso?
O que eu quero dizer com isso, é que há um tipo de comunicação entre processos, teu worker process não escuta HTTP, ele não aloca a porta.
Outro ponto relevante é que se vamos falar de outros web servers, e há uma grande probabilidade de você ser um(a) desenvolvedor(a) .NET, ou ter algum vínculo com tecnologias Microsoft. Para você, conhecer esses elementos da arquitetura do IIS faz muito sentido, principalmente para entender como as coisas funcionam.
Acredito que somente entendendo como as coias funcionam aqui, é possível entender como funcionam no “resto do mundo” (linux, etc).
Como o resto do mundo funciona?
O IIS usa features próximas ao Kernel do Windows, isso o faz “roubar” no processo de escuta HTTP, no Linux temos outro ponto de vista. No Linux, não temos esse tipo de resposta no Kernel, o kernel não faz esses tipos de truques, faz outros. E por isso é ótimo.
No Linux, ou em qualquer outra plataforma, o processo é mais simples. Simplesmente não há essa “pegadinha” de ter um cara no kernel fazendo esse trabalho. O teu processo é quem de fato faz isso. No Windows, exceto o IIS e WCF, todos os demais processos funcionam exatamente da mesma forma que no Linux: Cada processo escutando uma ou mais portas.
No Linux o Kernel tem outras capacidades, como entregar um IP independente para um processo, é o que vemos nos containers. Cada container tem 1 processo (em geral só 1), e esse processo tem um IP interno.
O fim do IIS
Com o Kestrel, temos um novo web server, feito com código gerenciado, muito parecido com o que temos no NodeJS. Antes da versão 2.1 do ASP.NET Core, Kestrel usava a LIBUV, mesma lib usada pelo NodeJS. Mas hoje já usa socket gerenciado.
No tópico When to use Kestrel with a reverse proxy vemos o maior exemplo de uso do Kestrel. Com proxy reverso na frente, servindo de edge.
Esse diagrama acima é o desenho mais comum que vemos no mercado, usando NGINX como proxy reverso. Esse é o que mais vemos em deployments baseados ou não em containers no Linux.
Isso quer dizer que um container é um NGINX, que está ali encaminhando requisições para outros containers com base nos host headers.
Eu apresentei meu uso de NGINX com Docker na live NGINX: Load Balancer, WebServer, Proxy Reverso, SSL e muito mais…
Aí vem a pergunta:
IIS ou NGINX?
NGINX sem sombra de dúvidas! Minha escolha é óbvia, eu tenho 100% da configuração à mão. Inclusive meu processo de geração de código é que mantém essas configurações.
Nunca viu uma configuração do NGINX? Que tal visitar nginxconfig.io?
O link acima que disponibilizei tem:
- NGINX como proxy reverso
- SSL offload e configuração para o uso de Let’s Encrypt
- GZIP para compressão
- Brotli para compressão
- Cabeçalhos de Segurança
Tudo isso para que sua aplicação tenha o mínimo de esforço na hora de configurar e disponibilizar. Um update de certificado ou algo assim, não gera um restart da tua aplicação.
Conclusão
Nós aprendemos que sempre que colocamos um elemento a mais em um stack, sempre estamos aumentando o processamento, e adicionando um ponto de lentidão. Sim, é tão verdade quanto mentira. Cabe um “depende” e um olhar minucioso sobre o que escolhemos. É sempre importante entender o que estamos usando para decidirmos melhor.
Entender como funciona a escuta de portas, entender como sistemas operacionais funcionam, entender como um web server funciona, entender como um proxy reverso funciona ajuda na compreensão do universo ao seu redor. São muitas variáveis, é muita informação. Mas só entendendo os fundamentos de cada coisa, estudando de forma séria, podemos compreender qual a melhor forma de uso de cada tecnologia.
O IIS não vai morrer, ele estará presente com o Windows sempre. Só não faz sentido não abrir a cabeça para novas oportunidades que favorecem e privilegiam a automação.
No StackShare temos uma comparação super interessante sobre o consumo de IIS, Apache e NGINX no mercado.
NGINX não é o único nesse papel. Ainda não consegui parar para colocar o envoy no meu server, mas já falei sobre ele também no Canal .NET
Cara você realmente é uma pessoa muito foda, você fala o que estudar, o que olhar de forma clara e objetiva e com muito lógica.
Parabéns pelo conteúdo dos posts e das aulas. Logo mais quero fazer se curso.