Como a Internet Funciona

Navegador → DNS → TCP → HTTP → Servidor → Banco de dados → Resposta → Renderização

Em alto nível, uma requisição web não é uma única ação, mas uma cadeia de sistemas trabalhando juntos. Cada etapa existe para resolver um problema específico - encontrar o destino, estabelecer comunicação, definir a requisição, processar a lógica, recuperar dados e retornar resultados.

DNS responde “Onde este serviço está localizado?” TCP responde “Como nos comunicamos de forma confiável?” HTTP responde “O que exatamente está sendo solicitado?” O servidor e o banco de dados respondem “O que o sistema deve calcular e retornar?”

Essas camadas operam de forma independente, mas cooperam em sequência. Nenhum componente entende o sistema inteiro - cada um executa seu papel e passa o controle para o próximo.

O que parece instantâneo para o usuário é, na verdade, um pipeline estruturado de abstrações executando em milissegundos.

Quando um usuário digita uma URL, o navegador faz mais do que apenas “abrir uma página”. Primeiro, ele analisa a entrada para identificar o protocolo (como HTTPS), o nome de domínio e o caminho solicitado.

Os computadores não conseguem rotear tráfego usando nomes de domínio como example.com. As redes operam com endereços IP, que são identificadores numéricos.

O navegador verifica seu cache local para ver se já conhece o endereço IP desse domínio. Se não, ele inicia um processo de consulta DNS para resolver o nome em um endereço IP roteável.

Somente após essa etapa de tradução o sistema pode avançar para o estabelecimento de uma conexão.

DNS foi projetado como um diretório distribuído para a Internet. Em vez de depender de um único banco de dados central, a responsabilidade é dividida entre várias camadas de servidores para suportar escala global.

Quando um domínio ainda não é conhecido localmente, um resolvedor recursivo inicia o processo de consulta. Primeiro, ele contata um servidor raiz, que aponta para o servidor correto de Top-Level Domain (TLD), como .com ou .org. Em seguida, o servidor TLD direciona o resolvedor para o servidor de nomes autoritativo daquele domínio específico.

O servidor autoritativo fornece o endereço IP final. Esse endereço é retornado ao cliente, permitindo que o navegador avance e estabeleça uma conexão de rede com o destino correto.

Esse design em camadas mantém o DNS organizado, escalável e capaz de suportar bilhões de consultas todos os dias.

O TCP não começa imediatamente a enviar dados da aplicação. Primeiro, ele estabelece uma conexão usando um processo de três etapas: SYN → SYN-ACK → ACK.

O cliente começa enviando uma mensagem SYN (synchronize) para solicitar uma conexão. O servidor responde com SYN-ACK, confirmando a solicitação e compartilhando seu próprio número inicial de sequência. Em seguida, o cliente envia um ACK para confirmar o recebimento. Nesse ponto, ambos os lados concordam com os números iniciais de sequência e sabem que o outro lado está pronto.

Essa troca estabelece a base para uma entrega confiável. O TCP acompanha os números de sequência, detecta pacotes perdidos, retransmite dados ausentes e ajusta a velocidade de envio com base nas condições da rede.

Somente depois dessa etapa de coordenação os dados reais da aplicação começam a fluir.

TCP garante a entrega confiável de bytes, mas não define o que esses bytes significam. HTTP fica acima do TCP e dá estrutura e semântica à comunicação. Ele define como um cliente pede algo e como um servidor responde.

Uma requisição HTTP inclui um método (como GET ou POST), headers que descrevem metadados e, opcionalmente, um body contendo dados. O servidor responde com um status code, headers e o conteúdo solicitado. Como ambos os lados seguem as mesmas regras, eles podem interpretar as mensagens de forma consistente.

HTTP é essencial porque a Internet é um sistema compartilhado. Sem um protocolo comum definindo a estrutura e a intenção das mensagens, navegadores e servidores não se entenderiam. HTTP cria essa linguagem compartilhada para a web.

Ele define o que está sendo solicitado e retornado, não como os dados trafegam fisicamente pela rede.

Quando os dados chegam a uma máquina, eles não “executam” automaticamente. O sistema operacional recebe os dados da rede e os direciona para o processo correto usando sockets. É assim que a solicitação chega ao programa do servidor.

Em seguida, o SO gerencia os recursos necessários. Ele agenda o tempo de CPU para que o servidor possa executar, atribui memória para o processamento e controla o acesso a arquivos ou bancos de dados. Sem o sistema operacional coordenando esses recursos, várias solicitações não poderiam ser tratadas com segurança ou eficiência.

Depois que a solicitação entra no processo do servidor, a lógica da aplicação assume o controle. Ela interpreta a mensagem HTTP, realiza os cálculos necessários ou consultas ao banco de dados e constrói uma resposta.

O sistema operacional permite a execução. A aplicação do servidor define o comportamento.

As aplicações geram dados constantemente — contas de usuário, posts, transações, logs e configurações. Se esses dados existissem apenas na memória, eles desapareceriam sempre que o programa reiniciasse. Os bancos de dados resolvem isso fornecendo armazenamento durável em disco ou em sistemas distribuídos.

Mas armazenamento sozinho não é suficiente. Os dados precisam ser estruturados e consultáveis. Os bancos de dados organizam as informações em tabelas ou coleções e fornecem linguagens de consulta que permitem às aplicações recuperar registros específicos sem precisar varrer tudo manualmente.

Para melhorar o desempenho, os bancos de dados usam índices — estruturas de dados especializadas que funcionam como um mapa de consulta. Em vez de verificar cada linha, o mecanismo pode ir diretamente para as entradas relevantes.

Os bancos de dados são críticos porque as aplicações modernas exigem estado persistente. Sem eles, cada requisição operaria de forma isolada, sem memória de atividades anteriores.

Quando um usuário solicita o mesmo recurso várias vezes, recalculá-lo do zero é ineficiente. O cache resolve isso armazenando uma cópia da resposta para que solicitações futuras possam ser atendidas imediatamente, sem acionar novamente o banco de dados ou a lógica da aplicação.

Os caches existem em várias camadas — dentro do navegador, no servidor e na borda da rede. Uma Content Delivery Network (CDN) amplia essa ideia globalmente ao distribuir conteúdo para data centers geograficamente dispersos. Em vez de sempre contatar o servidor de origem, os usuários são direcionados para a localização de edge mais próxima.

Reduzir a distância física diminui a latência de rede, e reduzir cálculos repetidos diminui a carga no servidor. Juntas, essas otimizações melhoram drasticamente o tempo de resposta em escala.

No entanto, os dados em cache podem ficar desatualizados, então os sistemas precisam equilibrar velocidade com atualização dos dados.

Como o ciclo de vida de uma requisição na Internet abrange DNS, transporte, servidores e bancos de dados, problemas podem ocorrer em qualquer etapa. Se o DNS não conseguir resolver um domínio, a conexão nem chega a começar. Se a rede descartar pacotes ou a conexão TCP quebrar, a comunicação é interrompida.

Mesmo depois que uma requisição chega ao servidor, falhas ainda podem ocorrer. O processo do servidor pode travar, ficar sem memória ou não conseguir se conectar ao banco de dados. Um banco de dados lento ou sem resposta pode atrasar toda a resposta.

Sistemas distribuídos raramente falham de uma vez. Em vez disso, eles falham parcialmente — uma região, uma instância ou uma dependência por vez. Projetar sistemas resilientes exige adicionar redundância, verificações de saúde, tentativas e mecanismos de fallback em várias camadas.

Entender onde as falhas podem ocorrer é essencial para entender como sistemas do mundo real se comportam.