The latest articles on Forem by Caio Macedo (@caioandre182). https://forem.com/caioandre182 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3693270%2Fcc5d55bc-e060-41d8-b3e3-697a2640634d.png https://forem.com/caioandre182 en Caio Macedo Thu, 08 Jan 2026 13:53:43 +0000 https://forem.com/caioandre182/handshake-o-custo-invisivel-das-apis-modernas-1l75 https://forem.com/caioandre182/handshake-o-custo-invisivel-das-apis-modernas-1l75 <h2> O que ta acontecendo? </h2> <p>Quando localmente a API responde em 20ms, os logs não apontam gargalos, o banco já foi otimizado e o código está limpo. </p> <p>Pronto para produção, porém, ela passa a responder com 400ms. Voltamos imediatamente aos logs, revisamos o código, olhamos para banco, e temos certeza que o problema <strong>TEM</strong> que estar ali.</p> <p>O que geralmente esquecemos, ou simplesmente não percebemos, é que <em>antes do primeiro byte ser enviado</em>, um custo já foi pago.</p> <p>Cliente e servidor precisam se comunicar. A negociação dessa comunicação por segurança e confiabilidade, gera um custo que é influenciado pela qualidade da rede, a distância entre as regiões envolvidas e o protocolo de transporte utilizado. </p> <p>Localmente esse custo é imperceptível, mas não conseguimos fugir dele em produção. E quando ignorado, se multiplica silenciosamente em arquiteturas modernas.</p> <h2> Caminho percorrido </h2> <p>Caso a resolução do DNS não estiver no cache, a requisição irá percorrer um processo hierárquico. O cliente consulta os root servers, que indicam quais servidores são responsáveis pelo TLD. Em seguida, os servidores de TLD apontam para os servidores autoritativos do domínio, que finalmente retorna o endereço IP.</p> <p>Cada uma dessas etapas gera uma comunicação ida e volta e pode adicionar latência antes mesmo da conexão ser estabelecida.</p> <p>Ainda antes de qualquer dado ser transmitido, o TCP precisa estabelecer uma conexão confiável entre cliente e servidor. Esse processo chamado de <strong>three way handshake</strong>, exige no mínimo uma ida e volta pela rede.</p> <p>Em conexões que exigem segurança, esse custo aumenta. Após o estabelecimento do TCP, ainda precisam negociar segurança, e o TLS vai exigir mais uma etapa de comunicação entre cliente e servidor.</p> <p>O custo já foi pago. E não podemos eliminá-lo, mas é possível <strong>amortizar</strong> ou <strong>reduzir seu impacto</strong> arquiteturalmente.</p> <h2> Redução de danos </h2> <p>Essa latência não é um problema de implementação, e sim uma consequência de decisões corretas sobre confiabilidade e segurança. Como não é possível eliminá-lo, a ideia é decidir <strong>quando</strong>, <strong>quantas vezes</strong> e <strong>onde</strong> esse custo será pago.</p> <p>Podemos começar com a maneira mais simples, e reutilizar essas conexões. Com <strong>keep-alive</strong> e <strong>connection pooling</strong>, o custo do DNS, TCP e TLS será pago uma única vez, enquanto múltiplas requisições trafegam pelo mesmo canal.</p> <p>Utilizar o protocolo <strong>HTTP/2</strong> permite multiplexar várias requisições em uma única conexão, isso reduz o número de conexões necessárias. O ganho não é tornar a rede mais rápida, mas sim em reduzir quantas vezes o custo inicial precisa ser pago.</p> <p>Em conexões seguras, mecanismo como <strong>TLS session resumption</strong> permite que cliente e servidor reutilizem informações de uma conexão TLS anterior, evitando repetir todo o handshake completo. Além disso, centralizar a terminação de TLS em <strong>load balancers</strong> ou <strong>API gateways</strong> muda onde esse custo acontece e impede que ele se espalhe de forma descontrolada entre serviços internos.</p> <p>Apesar de ainda estar se consolidando, o <strong>HTTP/3</strong>, baseado em QUIC, elimina a dependência do TCP e incorpora o TLS na camada de transporte, isso reduz o número de etapas necessárias antes do primeiro byte. Em cenários como mobile e conexões estáveis, essa diferença costuma ser decisiva.</p> <p>Por fim, evitar chamadas desnecessárias é, na maioria das vezes, a forma mais eficaz de diminuir o custo dos handshake. Cache, agregação de dados e redução de fan-out não tornam o handshake mais rápido, só evita que o mesmo aconteça.</p> <p>Latência é o resultado de quantas vezes decidimos atravessar a rede. Quando o custo do handshake é ignorado, ele se multiplica. Quando é tratado como parte da arquitetura, ele pode ser controlado, amortizado e muitas vezes deixado fora do caminho crítico.</p> <h3> Referências </h3> <p>System Design – Protocolos e Comunicação de Rede<br> <a href="https://fidelissauro.dev/protocolos-de-rede/" rel="noopener noreferrer">https://fidelissauro.dev/protocolos-de-rede/</a></p> <p>Optimizing TLS over TCP to Reduce Latency – Cloudflare Blog<br> <a href="https://blog.cloudflare.com/optimizing-tls-over-tcp-to-reduce-latency/" rel="noopener noreferrer">https://blog.cloudflare.com/optimizing-tls-over-tcp-to-reduce-latency/</a></p> <p>SSL/TLS Recommender – Cloudflare Blog<br> <a href="https://blog.cloudflare.com/ssl-tls-recommender/" rel="noopener noreferrer">https://blog.cloudflare.com/ssl-tls-recommender/</a></p> <p>What is DNS? – Cloudflare Learning<br> <a href="https://www.cloudflare.com/pt-br/learning/dns/what-is-dns/" rel="noopener noreferrer">https://www.cloudflare.com/pt-br/learning/dns/what-is-dns/</a></p> api architecture networking performance