Otimize a Subparte de Duração da Conexão (TCP + TLS) do Time to First Byte

Otimize a Subparte de Duração da Conexão (TCP + TLS) do Time to First Byte

Este artigo faz parte do nosso guia sobre o Time to First Byte (TTFB). A duração da conexão é a quarta subparte do TTFB e representa o tempo que o navegador gasta estabelecendo uma conexão TCP e negociando a criptografia TLS com o servidor. Para usuários geograficamente distantes do servidor, a duração da conexão pode adicionar de 100 a 500 milissegundos ao TTFB devido às múltiplas viagens de ida e volta (round trips) exigidas para os handshakes TCP e TLS.

O Time to First Byte (TTFB) pode ser dividido nas seguintes subpartes:

• Waiting + Redirect (ou duração de espera)
• Worker + Cache (ou duração do cache)
• DNS (ou duração do DNS)
• Connection (ou duração da conexão)
• Request (ou duração da solicitação)

Procurando otimizar o Time to First Byte? Este artigo cobre a parte da duração da conexão do Time to First Byte. Se você está procurando entender ou corrigir o Time to First Byte e não sabe o que significa a duração da conexão, leia o que é o Time to First Byte e como corrigir e identificar problemas de Time to First Byte antes de começar com este artigo.

A parte da duração da conexão do Time to First Byte consiste no tempo em que o navegador está se conectando ao servidor web. Após essa conexão, o navegador e o servidor geralmente adicionarão uma camada de criptografia (TLS). O processo de negociação dessas 2 conexões levará algum tempo, e esse tempo é adicionado ao Time to First Byte.

O Processo de Conexão em Detalhes

O Transmission Control Protocol (TCP) é responsável por estabelecer uma conexão confiável entre o cliente (navegador) e o servidor. Esse processo envolve um handshake de três vias (three-way handshake):

• Pacote SYN (Synchronize): O cliente envia um pacote SYN ao servidor para iniciar a conexão e solicitar a sincronização.
• Pacote SYN-ACK (Synchronize-Acknowledge): O servidor responde com um pacote SYN-ACK, confirmando o recebimento do pacote SYN e concordando em estabelecer uma conexão.
• Pacote ACK (Acknowledge): O cliente envia um pacote ACK de volta ao servidor, confirmando o recebimento do pacote SYN-ACK. Neste ponto, uma conexão TCP é estabelecida, permitindo que os dados sejam transferidos de forma confiável entre o cliente e o servidor.

O TCP garante que os dados sejam enviados e recebidos na ordem correta, reenviando quaisquer pacotes perdidos e gerenciando o controle de fluxo para corresponder à capacidade da rede.

Uma vez que a conexão TCP é estabelecida, o protocolo Transport Layer Security (TLS) é usado para proteger a conexão. O handshake TLS envolve várias etapas para autenticar o servidor e estabelecer um canal de comunicação seguro:

• ClientHello: O cliente envia uma mensagem "ClientHello" para o servidor, indicando as versões TLS suportadas, conjuntos de cifras (cipher suites) e um número aleatório (Client Random).
• ServerHello: O servidor responde com uma mensagem "ServerHello", selecionando a versão TLS e o conjunto de cifras da lista do cliente, e fornecendo seu certificado digital e um número aleatório (Server Random).
• Troca de Certificado e Chave: O servidor envia seu certificado digital para o cliente para autenticação. O cliente verifica o certificado em relação a autoridades certificadoras confiáveis.
• Segredo Pré-mestre (Premaster Secret): O cliente gera um segredo pré-mestre, criptografa-o com a chave pública do servidor (do certificado) e o envia ao servidor.
• Geração da Chave de Sessão: Tanto o cliente quanto o servidor usam o segredo pré-mestre, juntamente com o Client Random e o Server Random, para gerar uma chave de sessão compartilhada para criptografia simétrica.
• Mensagens Finished: O cliente e o servidor trocam mensagens criptografadas com a chave de sessão para confirmar que o handshake foi bem-sucedido e que ambas as partes têm a chave de sessão correta.

Assim que o handshake TLS for concluído, o cliente e o servidor terão estabelecido uma conexão segura e criptografada. Isso garante que quaisquer dados trocados fiquem protegidos contra espionagem e adulteração por terceiros.

TLS 1.3 vs TLS 1.2: Por que isso importa para o TTFB

A versão do TLS que o seu servidor usa tem um impacto direto na duração da conexão. O TLS 1.3 é mais rápido que o TLS 1.2 porque reduz o número de round trips necessários para completar o handshake:

O TLS 1.3 reduz o handshake de dois round trips para um. Para um usuário que está a 100ms de distância do servidor (tempo de round trip), isso economiza aproximadamente 100ms em cada nova conexão. Para visitantes recorrentes, a retomada 0-RTT (zero round trip time) do TLS 1.3 permite que o cliente envie dados criptografados imediatamente após a reconexão, reutilizando informações de sessão trocadas anteriormente. Isso pode reduzir a sobrecarga do handshake TLS a quase zero para visitantes que retornam.

HTTP/3 e QUIC: O Futuro das Conexões Rápidas

HTTP/3 acelera conexões TLS integrando-se ao protocolo QUIC, que reduz o número de round trips necessários para estabelecer uma conexão segura combinando os processos de handshake em um só, e suporta a retomada 0-RTT para reconexões mais rápidas. Além disso, o uso de UDP pelo QUIC elimina o bloqueio de início de fila (head-of-line blocking) e melhora o controle de congestionamento, levando a uma transmissão de dados mais eficiente e a carregamentos de página mais rápidos.

O HTTP/3 traz várias melhorias em relação ao HTTP/2 que afetam diretamente a duração da conexão:

• Handshake combinado: Com HTTP/2 sobre TCP, o handshake TCP e o handshake TLS ocorrem sequencialmente (3 round trips no total para uma nova conexão). O HTTP/3 sobre QUIC combina o handshake de transporte e TLS em um único round trip. Para novas conexões, isso economiza um round trip inteiro em comparação com o HTTP/2.
• Retomada de conexão 0-RTT: Assim como o TLS 1.3, o QUIC suporta retomada 0-RTT. Visitantes recorrentes podem começar a enviar dados imediatamente sem esperar a conclusão de qualquer handshake. Isso é particularmente eficaz para usuários de dispositivos móveis que alternam frequentemente entre conexões Wi-Fi e de rede celular.
• Sem head-of-line blocking (bloqueio de início de fila): Com HTTP/2 sobre TCP, um único pacote perdido bloqueia todos os fluxos (streams) naquela conexão até que o pacote seja retransmitido. O QUIC usa UDP e lida com os fluxos de forma independente, portanto, um pacote perdido afeta apenas o fluxo específico a que pertence. Isso resulta em um desempenho de conexão mais consistente em redes não confiáveis.
• Migração de conexão: As conexões QUIC são identificadas por um ID de conexão, em vez de um IP de origem e porta. Isso significa que, quando um usuário de dispositivo móvel muda do Wi-Fi para o celular (e seu endereço IP muda), a conexão QUIC sobrevive sem precisar ser restabelecida. Isso evita o handshake completo de TCP + TLS que seria necessário de outra forma.

Como o Tempo de Conexão Impacta o Time to First Byte?

Como Minimizar o Impacto do Tempo de Conexão no TTFB

Use Preconnect para Origens Críticas

A dica de recurso (resource hint) <link rel="preconnect"> diz ao navegador para estabelecer uma conexão (DNS + TCP + TLS) para uma origem especificada antes que quaisquer recursos dessa origem sejam realmente necessários. Isso elimina a duração da conexão do caminho crítico quando o recurso for finalmente solicitado:

<!-- Preconnect to critical third-party origins -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">

Use o preconnect com moderação (máximo de 3 a 5 origens). Cada preconnect abre uma conexão TCP + TLS completa, o que consome CPU e recursos de rede. Use preconnect apenas para origens que são necessárias em cada carregamento de página. Para origens que são necessárias apenas ocasionalmente, use o dns-prefetch em vez disso (veja nosso guia de duração de DNS).

Configuração de Servidor para TLS 1.3 e HTTP/3

• HTTP/3: traz o protocolo QUIC sobre UDP em vez de TCP, permitindo uma transferência de dados mais rápida e eficiente.
• TLS 1.3: adiciona mais segurança e reduz os round trips de handshake. Obrigatório para a retomada de conexão 0-RTT.
• Retomada de Conexão 0-RTT: Recurso do TLS 1.3 que permite a clientes recorrentes enviarem dados criptografados imediatamente após a reconexão, reutilizando informações trocadas anteriormente.
• TCP Fast Open: permite que os dados sejam enviados no pacote SYN inicial, reduzindo o tempo de round trip para o handshake TCP.
• TLS False Start: permite o envio antecipado de dados antes que o handshake TLS seja concluído.
• OCSP Stapling: acelera a validação do certificado eliminando a necessidade de o cliente contatar diretamente a autoridade de certificação.

Aqui está um exemplo de configuração do Nginx que habilita o TLS 1.3 e o OCSP Stapling:

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # TLS 1.3 cipher suites
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # Enable OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # Enable session resumption (TLS session tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... rest of your server configuration
}

Para o Apache, habilite o TLS 1.3 com:

<VirtualHost *:443>
    SSLEngine on
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Enable OCSP Stapling
    SSLUseStapling On
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    # Enable session resumption
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... rest of your virtual host configuration
</VirtualHost>

Dica de Time to First Byte: uma CDN não apenas oferece tempos de round trip mais curtos. O uso de uma CDN geralmente melhorará imediatamente os tempos de conexão TCP e TLS porque provedores de CDN premium terão configurado essas opções corretamente para você. Veja nosso guia sobre como configurar o Cloudflare para performance para começar.

Medindo a Duração da Conexão com JavaScript

Você pode medir a subparte de duração da conexão do TTFB diretamente no navegador usando a Navigation Timing API:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');

  const tcpDuration = nav.connectEnd - nav.connectStart;
  const tlsDuration = nav.connectEnd - nav.secureConnectionStart;
  const totalConnection = tcpDuration;

  console.log('Connection Duration:', totalConnection.toFixed(0), 'ms');
  console.log('  TCP handshake:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  TLS negotiation:', tlsDuration.toFixed(0), 'ms');

  if (nav.nextHopProtocol) {
    console.log('  Protocol:', nav.nextHopProtocol);
  }
}).observe({
  type: 'navigation',
  buffered: true
});

A propriedade nextHopProtocol revela qual protocolo foi usado para a conexão. Valores comuns são "h2" (HTTP/2), "h3" (HTTP/3) e "http/1.1". Se o seu servidor suportar HTTP/3, mas seus dados RUM mostrarem a maioria das conexões usando "h2", pode indicar que o suporte ao HTTP/3 não está sendo anunciado adequadamente por meio do cabeçalho Alt-Svc.

Como Encontrar Problemas de TTFB Causados por Tempo Lento de Conexão

Para encontrar o impacto que os usuários reais experienciam causado pela latência de conexão, você precisará usar uma ferramenta RUM como o CoreDash. O Real User Monitoring permitirá rastrear os Core Web Vitals em maiores detalhes e sem o atraso de 28 dias do Google.

No CoreDash, clique em "Time to First Byte breakdown" para visualizar a parte de conexão do Time to First Byte.

Leitura Adicional: Guias de Otimização

Guias relacionados:

• 103 Early Hints: o servidor pode enviar dicas de recurso (preload, preconnect) enquanto ainda está processando a resposta principal, permitindo que o navegador comece a estabelecer conexões mais cedo.
• Configure o Cloudflare para Performance: O Cloudflare habilita automaticamente HTTP/3, TLS 1.3 e OCSP Stapling. O uso de uma CDN também aproxima o seu servidor dos usuários, reduzindo os tempos de round trip para todas as conexões.

Subpartes do TTFB: Guias Completos

A duração da conexão é uma das cinco subpartes do TTFB. Explore as outras subpartes para entender o quadro completo:

• Corrija e Identifique Problemas do TTFB: o ponto de partida do diagnóstico para toda otimização de TTFB.
• Duração de Espera: redirecionamentos, enfileiramento de navegador e otimização de HSTS.
• Duração do Cache: desempenho de service worker, buscas no cache do navegador e bfcache.
• Duração do DNS: seleção de provedor DNS, configuração de TTL e dns-prefetch.
• Duração da Solicitação: tempo de processamento do servidor, consultas de banco de dados e otimização de backend.