O que o DNS realmente faz em cada requisição Toda requisição para example.com começa com uma busca que não tem nada a ver com sua aplicação: algo precisa transformar aquele nome em um endereço IP antes que um único pacote TCP saia da máquina. Essa tradução é o DNS, o Domain Name System, e ela acontece em toda requisição, seja o cliente um navegador, o curl, ou um serviço de backend chamando outro pelo hostname. ...
O que o TLS realmente protege em uma conexão HTTPS Carregue uma página por http:// puro em uma rede que você não controla, um aeroporto ou o roteador de uma cafeteria, e tudo o que você envia viaja como texto legível. O caminho da URL, os cookies, os campos do formulário, a senha em um POST de login: qualquer pessoa nessa rede com um sniffer de pacotes lê tudo isso ao passar. TLS, Transport Layer Security, é o protocolo que impede isso. Ele fica entre o TCP e o protocolo de aplicação, então quando o HTTP começa a falar, a conexão já está criptografada e vinculada a uma identidade de servidor verificada. HTTPS é o HTTP rodando sobre essa conexão em vez de uma em texto plano. ...
O que um CDN realmente faz com uma requisição Um usuário em Tóquio que carrega uma página hospedada num servidor na Virgínia paga essa distância duas vezes: uma vez para a requisição chegar, outra para a resposta voltar. A fibra óptica corre numa fração fixa da velocidade da luz, e só essa viagem já custa algo entre 150 e 200ms de round-trip antes de a origem fazer qualquer trabalho. Some uma query no banco de dados e mais um ou dois saltos lentos. Uma página que parece instantânea na porta ao lado fica arrastada do outro lado do planeta. ...
O que fica entre o navegador e sua app Aponte o navegador para example.com e a requisição nunca toca diretamente no processo que executa seu código. Ela encontra primeiro outra coisa: um servidor que lê a requisição, decide qual backend deve responder, a encaminha para lá e devolve a resposta como se a tivesse produzido ele mesmo. Esse servidor é um reverse proxy. Nginx, Caddy, Traefik e HAProxy fazem esse trabalho, assim como o load balancer que fica na frente de um cluster Kubernetes. O esquema nunca muda: os clientes falam com o proxy e com mais nada. Os servidores reais ficam atrás, em qualquer quantidade e onde quer que rodem. ...
Por que dois containers no mesmo host não se enxergam por padrão Suba o Postgres e sua API com um docker run simples, e a API não consegue alcançar o banco de dados, mesmo com os dois containers rodando na mesma máquina. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Os dois caem na bridge padrão do Docker, aquela em que todo container Docker entra a menos que você diga o contrário. Eles recebem um endereço IP. O que não recebem é uma forma de se encontrarem pelo nome — a API teria que ter o IP interno do banco fixado no código, um endereço que muda a cada reinício do container. ...