O fim do IIS
Publicado em: domingo, 11 de ago de 2019
Categorias: .NET | Architecture | Geral
Tags: IIS

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

O Kestrel não exige que você use NGINX ou qualquer webserver na frente como proxy reverso, ele mesmo tem capacidades para realizar as principais atividades, inclusive ser um proxy reverso.

Normalmente usamos Kestrel para servir nossas próprias aplicações, quem já viu as configurações de um Startup.cs sabe que não temos um arquivo de configuração, temos código fonte que precisa ser compilado a cada grande mudança (talvez até baixar novos pacotes nuget).

Isso faz com que não seja muito prático, usá-lo na borda (edge) da sua infraestrutura, embora seja perfeitamente possível. E não há nada de errado nisso. Se você terá sua aplicação .NET como único processo nesse servidor, não há problema algum, desde que você use as configurações de segurança (https, HSTS etc).

Adicionar um proxy reveso, mediando as requisições para diversos containers, ajuda a compartilhar seu servidor usável com diversos projetos/processos, já que, como disse, não existe compartilhamento de portas.

Sempre que você escutar em algum lugar, “Compartilhamento de portas” em sistemas operacionais, saiba que na realidade, somente 1 processo está escutando a tal porta, provavelmente esse processo é externo e faz parte do sistema operacional ou produto. Em geral a comunicação entre esse processo( que escuta a porta) e teu processo acontece via outro protocolo, possivelmente bem eficiente, por sinal.

WCF port sharing é um exemplo clássico disso. WCF port Sharing usa um serviço de port sharing no windows. Como a Microsoft é responsável por .NET Framework e pelo Windows, é fácil criar um “combinado” para que isso pareça real, e pareça que realmente estamos compartilhando portas. Mas lembre-se de que há um mediador que é o serviço de port sharing.

Essas “facilidades” que tornam esse tipo de coisa transparente para usuários do Windows, facilmente fará com que você sinta falta disso no Linux. Outro ponto é que se você achava que usar NGINX como mediador é colocar um elemento a mais na arquitetura e que possivelmente afetará performance. A internet se baseia nesse conceito e se você é usuário de windows e usa port sharing, ou mesmo IIS, você já faz uso dessas estratégias, só talvez não fizesse ideia disso.

Claro que a grande diferença entre o port sharing do windows e um proxy reverso NGINX, é o protocolo entre o mediador e teu processo. No windows, com .NET Framework e WCF temos essa mediação está sendo realizada por um protocolo binário de alta performance, diferente do NGINX que usará HTTP ou HTTP2.

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

 

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou. 

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Eventos passados

outubro 2020
setembro 2020
agosto 2020
Nenhum evento encontrado!
Carregar Mais

Publicidade

Assine

0 comentários

Trackbacks/Pingbacks

  1. .NET no Linux, vale a pena? | | gaGO.io - […] O fim do IIS […]

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Próximos Eventos Próximo
22 outubro 2020
  • 00

    dias

  • 00

    horas

  • 00

    minutos

  • 00

    segundos

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.

Agenda & Eventos

setembro

outubro 2020

novembro
DOM
SEG
TER
QUA
QUI
SEX
SAB
27
28
29
30
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
Events for 30th setembro
Events for 1st outubro
Events for 2nd outubro
Sem Eventos
Events for 3rd outubro
Sem Eventos
Events for 4th outubro
Sem Eventos
Events for 5th outubro
Sem Eventos
Events for 6th outubro
Sem Eventos
Events for 7th outubro
Sem Eventos
Events for 8th outubro
Sem Eventos
Events for 9th outubro
Sem Eventos
Events for 10th outubro
Sem Eventos
Events for 11th outubro
Sem Eventos
Events for 12th outubro
Sem Eventos
Events for 13th outubro
Sem Eventos
Events for 14th outubro
Sem Eventos
Events for 15th outubro
Sem Eventos
Events for 16th outubro
Sem Eventos
Events for 17th outubro
Sem Eventos
Events for 18th outubro
Sem Eventos
Events for 19th outubro
Sem Eventos
Events for 20th outubro
Sem Eventos
Events for 21st outubro
Sem Eventos
Events for 22nd outubro
Events for 23rd outubro
Sem Eventos
Events for 24th outubro
Sem Eventos
Events for 25th outubro
Sem Eventos
Events for 26th outubro
Sem Eventos
Events for 27th outubro
Sem Eventos
Events for 28th outubro
Sem Eventos
Events for 29th outubro
Sem Eventos
Events for 30th outubro
Sem Eventos
Events for 31st outubro
Sem Eventos
Share This