TCP handshake vs TLS handshake: o que acontece antes de abrir um site HTTPS
Publicado em 2026-10-26 por frfrand
Sequência SYN e TLS, e diagnóstico de conexões lentas
Abrir um site com HTTPS parece que a conexão é instantânea. Por trás, há etapas distintas: DNS, estabelecimento de conexão e negociação de criptografia. Entendê-las ajuda quando o navegador demora antes de receber o primeiro byte.
A ideia é resolver um problema de dados ou implantação que aparece em aplicações reais. Vamos ver o conceito sem rodeios, um exemplo de implementação e o que verificar antes de levá-lo à produção.
O que fazem o handshake TCP e o handshake TLS
No TCP clássico, são trocados SYN, SYN-ACK e ACK para estabelecer um fluxo confiável. Depois, no HTTPS sobre TCP, o TLS negocia parâmetros criptográficos e verifica a identidade do servidor por meio de certificados. O HTTP/3 utiliza QUIC sobre UDP, portanto não segue exatamente a mesma sequência.
Não basta repetir uma receita se você não entender quem lê os dados, de qual processo e com quais permissões. Em uma aplicação com reservas, faturas ou usuários, uma condição de corrida ou uma política de acesso mal feita pode ser mais grave do que uma API lenta.
Um exemplo concreto
# Comprobar DNS
dig api.ejemplo.com A +short
# Ver tiempos de una petición
curl -s -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' https://api.ejemplo.com/health
# Inspeccionar la cadena TLS
openssl s_client -connect api.ejemplo.com:443 -servername api.ejemplo.com </dev/nullOs nomes, tabelas e chaves deste exemplo são ilustrativos. Teste primeiro em um banco ou ambiente de homologação e adapte permissões, índices e versões. Quando houver operações de gravação, não execute consultas de amostra sobre dados de clientes sem revisar o que elas modificam.
Passo a passo
- Meça quanto consome resolver o domínio.
- Meça o estabelecimento da conexão TCP com uma requisição real.
- Revise a negociação e validação TLS sem desativar verificações de certificados.
- Compare o tempo até o primeiro byte e a duração completa da resposta.
- Repita o teste em mais de uma rede antes de atribuir a latência ao servidor.
No final, não fique com «o SQL não deu erro». Verifique o efeito real pela API e com testes de concorrência ou permissões, conforme o caso. Em bancos de dados, há erros que só aparecem quando dois usuários fazem algo ao mesmo tempo.
Exemplo de projeto de trabalho
Uma API hospedada na Europa tem usuários da América. A consulta SQL leva 15 ms, mas criar cada nova conexão adiciona latência de rede. Reutilização de conexões e região do servidor podem importar mais que otimizar outro índice.
Esse cenário ajuda a distinguir desempenho de consistência. Acelerar uma consulta não adianta se permite criar duas reservas para uma única vaga, nem um banco enorme resolve o fato de o backend permitir consultar dados de outro cliente.
O erro típico
Não confunda time_connect com o tempo total da página. Também não afirme que todo site usa TCP: o HTTP/3 geralmente funciona sobre QUIC/UDP e muda as fases observáveis.
Também convém ter um plano de recuperação. Antes de alterar esquema, usuários ou políticas, faça uma cópia verificável ou migração reversível e verifique se o aplicativo pode continuar funcionando durante a mudança.
Como resolveria com o ArduMaker?
No ArduMaker você pode escolher a arquitetura de domínio, HTTPS e processos de um VPS. Medir a latência de cada fase ajuda a decidir se vale a pena aproximar a infraestrutura dos usuários ou revisar o backend.
O ArduMaker permite que você implante serviços a partir do Git e trabalhe com bancos de dados e processos dentro do VPS. O painel não substitui a lógica do seu aplicativo: transações, permissões e validações devem estar corretamente projetadas no código e no banco de dados.
Três verificações antes de publicar
Integridade: se uma solicitação for repetida ou falhar no meio do caminho, os dados terminam em um estado válido?
Segurança: um usuário autenticado pode acessar apenas suas informações, e a API utiliza uma identidade de banco de dados com permissões mínimas?
Recuperação: você sabe restaurar os dados e reverter a versão do código compatível se uma atualização der errado?
Se você puder responder a essas três perguntas com testes, seu backend estará bastante mais preparado do que quando você apenas verificou se o endpoint retornava 200.
Recursos para aprofundar
Para encerrar: escolha a solução mais simples que permita manter dados corretos, seguros e recuperáveis. O desempenho vem depois de medir.