O cliente resolve o hostname via DNS, abre uma conexão TCP para o endereço resolvido ou reaproveita uma existente, e aí completa um handshake TLS que valida o certificado do servidor e acorda chaves de sessão. O request criptografado atravessa load balancers e proxies até a sua aplicação, que trata e escreve a resposta de volta pela mesma conexão. Keep alive e multiplexação do HTTP/2 deixam requests posteriores pularem a maior parte do setup.
Por que os entrevistadores perguntam isso
Essa é uma pergunta de amplitude, e o entrevistador vai seguir sua resposta até a camada em que você soar menos seguro. Respostas fortes andam limpo por DNS, transporte, TLS e a cadeia de proxies, e apontam de onde latência e falhas realmente vêm, que geralmente é setup de conexão, cache de DNS velho, ou algo no meio terminando TLS e reescrevendo headers.
Como estruturar sua resposta
- Ande camada por camada: DNS, TCP, TLS, HTTP, aplicação.
- Diga o que o handshake TLS prova e o que ele acorda.
- Mencione a cadeia de proxy ou load balancer na frente da aplicação.
- Aponte onde o reaproveitamento de conexão elimina a maior parte do custo.
Exemplo de resposta
Primeiro o cliente precisa de um endereço, então ele checa o próprio cache, depois o resolver do sistema operacional, depois um resolver recursivo, e recebe de volta um IP com um tempo de vida. Depois um handshake TCP para aquele endereço, a não ser que já exista uma conexão aberta no pool, o que normalmente existe. Depois TLS: o servidor apresenta uma cadeia de certificados, o cliente valida contra a trust store dele e checa se o hostname bate, e eles acordam chaves de sessão. Com TLS 1.3 isso é um round trip, ou zero numa sessão retomada. O request sai criptografado, e na prática ele bate primeiro num CDN ou load balancer, que geralmente termina o TLS e abre a própria conexão para o meu serviço. Minha aplicação trata e a resposta volta pelo mesmo caminho. O motivo de eu me importar com a sequência é latência: no celular o primeiro request paga DNS mais TCP mais TLS antes de um byte do meu código rodar, então reaproveitar conexão costuma ser o maior ganho disponível.
Vai encarar essa entrevista em breve? O GhostPilot escuta a sua chamada ao vivo, identifica a pergunta no instante em que ela é feita e coloca uma resposta estruturada na sua tela em tempo real. Teste na sua próxima entrevista simulada ou pegue um Session Pass de $29, sem assinatura, para a hora da verdade.
Veja como funcionaPerguntas de acompanhamento que você pode esperar
- O que muda se o load balancer terminar o TLS?
- Como você depuraria um erro de certificado que só aparece em um cliente?
- O que a multiplexação do HTTP/2 resolve que o keep alive não resolvia?
Mais perguntas para Engenheiro de Software
Seu entrevistador vai fazer a própria versão desta. Cole a descrição real da vaga no Question Predictor gratuito e receba as 20 perguntas que essa vaga tem mais chance de fazer, com o que cada uma está de fato sondando.
Prever minhas perguntas