Handshake: o custo invísivel das APIs modernas

#api #architecture #networking #performance

O que ta acontecendo?

Quando localmente a API responde em 20ms, os logs não apontam gargalos, o banco já foi otimizado e o código está limpo.

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 TEM que estar ali.

O que geralmente esquecemos, ou simplesmente não percebemos, é que antes do primeiro byte ser enviado, um custo já foi pago.

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.

Localmente esse custo é imperceptível, mas não conseguimos fugir dele em produção. E quando ignorado, se multiplica silenciosamente em arquiteturas modernas.

Caminho percorrido

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.

Cada uma dessas etapas gera uma comunicação ida e volta e pode adicionar latência antes mesmo da conexão ser estabelecida.

Ainda antes de qualquer dado ser transmitido, o TCP precisa estabelecer uma conexão confiável entre cliente e servidor. Esse processo chamado de three way handshake, exige no mínimo uma ida e volta pela rede.

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.

O custo já foi pago. E não podemos eliminá-lo, mas é possível amortizar ou reduzir seu impacto arquiteturalmente.

Redução de danos

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 quando, quantas vezes e onde esse custo será pago.

Podemos começar com a maneira mais simples, e reutilizar essas conexões. Com keep-alive e connection pooling, o custo do DNS, TCP e TLS será pago uma única vez, enquanto múltiplas requisições trafegam pelo mesmo canal.

Utilizar o protocolo HTTP/2 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.

Em conexões seguras, mecanismo como TLS session resumption 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 load balancers ou API gateways muda onde esse custo acontece e impede que ele se espalhe de forma descontrolada entre serviços internos.

Apesar de ainda estar se consolidando, o HTTP/3, 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.

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.

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.